Gerenciar petabytes de dados de pesquisa significa tomar decisões difíceis: manter tudo rápido e caro ou torná-lo acessível, mas somente leitura. Ultraquente é uma solução comprovada e econômica para dados históricos de leitura intensa. No entanto, algumas cargas de trabalho precisam ocasionalmente atualizar registros históricos, como dados atrasados ou correções de conformidade. Com o UltraWarm, você deve migrar esses índices de volta para sizzling, realizar a atualização e migrar de volta. E se você pudesse gravar diretamente em seu armazenamento quente e econômico?
Nesta postagem, mostro como o armazenamento quente gravável elimina o caro ciclo de migração. Você pode reduzir seus custos de infraestrutura em até 48% e atualizar dados históricos em segundos, em vez de horas. Faço uma comparação de custos e benchmarks de desempenho do mundo actual e ajudo você a decidir quando usar aquecimento gravável versus UltraWarm.
O desafio do armazenamento em camadas
Serviço Amazon OpenSearch lida com cargas de trabalho de pesquisa e análise com uso intensivo de dados, desde análise de log em tempo actual e monitoramento de aplicativos até detecção de eventos de segurança. À medida que seus volumes de dados crescem de terabytes para petabytes, você enfrenta uma questão elementary: como manter os dados recentes rapidamente e, ao mesmo tempo, tornar os dados anteriores acessíveis?
O OpenSearch Service resolve isso com uma arquitetura de armazenamento em camadas:
- Quente – Maior desempenho para indexação ativa e pesquisa usando armazenamento anexado a instância.
- Ultraquente – Camada econômica e somente leitura, apoiada por Serviço de armazenamento simples da Amazon (Amazon S3) com cache native para dados consultados com menos frequência.
- Frio – Totalmente desvinculado do cluster, com o menor custo para dados raramente acessados. Os índices frios devem ser migrados de volta para UltraWarm ou quentes antes que qualquer leitura ou gravação possa ser executada.
Para dados de log imutáveis, este modelo funciona bem. No entanto, uma classe específica de cargas de trabalho atinge suas limitações quando ocasionalmente precisa gravar em dados anteriores, e o somente leitura se torna um gargalo.
Pré-requisitos
Para usar armazenamento quente gravável, você precisa do seguinte:
- Um domínio do Amazon OpenSearch Service executando a versão 3.3 ou posterior.
- Suporte à família de instâncias OpenSearch Optimized (OI2) na sua região da AWS.
- Cargas de trabalho com intervalo de atualização mínimo de 5 segundos.
- Nós de dados que usam a família de instâncias OpenSearch Optimized (OR2 para quente, OI2 para quente).
Observação: Quente gravável atualmente não suporta o camada de armazenamento frio.
O gargalo UltraWarm
Com o UltraWarm, a atualização de até mesmo um único documento requer a migração do índice de volta para sizzling, a execução da gravação e a migração de volta. Essa viagem de ida e volta envolve uma mesclagem forçada (consolidação de segmentos de índice), criação de instantâneo e realocação de fragmentos. Essas operações consomem CPU, memória e espaço em disco significativos em seus nós ativos e levam aproximadamente 130 minutos por índice de 100 GB. Esse tempo foi medido em um domínio com 3 × nós quentes r6g.2xlarge, 3 × nós quentes ultrawarm1.massive e 3 nós líderes dedicados (Leste dos EUA, Norte da Virgínia), usando um índice de fragmento único com uma réplica. Os tempos reais variam com base na configuração do domínio, contagem de fragmentos, contagem de segmentos, utilização de sizzling node e profundidade da fila de migração. O resultado é que você provisiona nós ativos em excesso, cria pipelines complexos ou mantém os dados ativos por mais tempo do que o necessário, o que aumenta o custo e a complexidade.
Apresentando armazenamento quente gravável
O OpenSearch Service agora oferece nós quentes graváveis que usam OpenSearch otimizado (OI2) instâncias, a mesma família de instâncias que alimenta o armazenamento durável apoiado pelo Amazon S3 em nós ativos. Como os dados já são persistentes no Amazon S3, as transições de níveis tornam-se uma relocação leve de fragmentos, em vez de uma migração que consome muitos recursos. O mecanismo Lucene, que é a biblioteca de pesquisa subjacente do OpenSearch, opera de forma idêntica em ambas as camadas. Como resultado, os nós quentes graváveis suportam gravações ativas, fusões em segundo plano e atualizações periódicas, assim como os nós quentes.
Dados atrasados, preenchimentos de conformidade e correções que antes exigiam uma viagem de ida e volta de quente para quente agora são resolvidos com gravação direta em segundos. Não há mesclagem forçada, nenhum instantâneo, nenhuma realocação de shard e nenhum consumo de recursos de sizzling node.
Fluxo de dados UltraWarm (legado): os dados são ingeridos na camada quente (SSD, leitura e gravação). As políticas de Index State Administration (ISM) migram índices para UltraWarm (apoiado pelo Amazon S3, somente leitura). Qualquer atualização requer a migração do índice de volta para sizzling (seta tracejada), gravação e migração de volta.
Fluxo de dados quente (novo) gravável: mesmo caminho de ingestão através de quente, com índices de transição ISM para quente gravável. A principal diferença é que o modo quente gravável suporta leituras e gravações. As atualizações que chegam tarde vão diretamente para a versão quente, sem migração de volta para a versão quente. Como ambas as camadas usam o Amazon S3 como armazenamento durável por meio de instâncias OpenSearch Optimized, as transições são realocações leves de fragmentos, e não migrações que consomem muitos recursos.
Os benefícios: custo, operações e flexibilidade
A tecnologia gravável oferece vantagens em três áreas: custo, simplicidade operacional e flexibilidade.
Custo
Ao contrário do UltraWarm, que oferece apenas preços sob demanda, as instâncias OI2 suportam preços de instâncias reservadas (RI), um modelo de desconto baseado em compromisso. Ao se comprometer com uma instância reservada de 1 ou 3 anos, você pode economizar de 31 a 52 por cento em comparação com os nós UltraWarm. Isso torna o gravável quente significativamente mais econômico para cargas de trabalho previsíveis e de longa duração. O recém-introduzido plano de economia de banco de dados para OpenSearch Service oferece economia de cerca de 22% em relação às instâncias UltraWarm. Ambas as camadas usam o Amazon S3 para armazenamento durável, portanto, a falha do nó significa apenas indisponibilidade temporária, não perda de dados. Para cargas de trabalho sensíveis ao custo que podem tolerar um breve tempo de inatividade durante a recuperação do nó, você pode configurar zero réplicas em índices quentes para reduzir ainda mais os custos.
Comparação de custos do mundo actual
Considere uma carga de trabalho que ingere 2 TB/dia com retenção complete de 210 dias, onde as atualizações podem chegar a qualquer momento. Com a restrição somente leitura do UltraWarm, você deve manter os dados quentes por 30 dias antes de migrar para quentes. Com o modo quente gravável, as atualizações acontecem diretamente no modo quente, portanto a retenção do modo quente cai para apenas 7 dias.
Em pequena escala, o benefício da redução do nível quente é modesto. A operação gravável ainda é econômica se você precisar de capacidade de gravação em dados quentes, puder se comprometer com preços de RI ou valorizar a simplicidade operacional de eliminar pipelines de migração. Para dados puramente imutáveis com retenção curta, o UltraWarm sob demanda ainda pode ser mais barato. Use o Calculadora de preços AWS para modelar seu cenário específico.
A tabela a seguir mostra os custos mensais estimados usando preços sob demanda e todas as instâncias reservadas antecipadamente (AURI) na região Leste dos EUA (Norte da Virgínia) em março de 2026. Para obter os preços mais recentes, consulte Preços do Amazon OpenSearch Service no web site da AWS.
| Componente | Quente + UltraWarm (30d quente / 180d quente) | Quente + quente gravável (7d quente / 203d quente) |
| Nós de dados importantes | US$ 12.264 (21 × ou 2,2xgrande) | US$ 12.264 (21 × ou 2,2xgrande) |
| Custo de EBS quente | $ 10.212,84 (21 * 3.986 GB) | US$ 2.636 |
| Armazenamento remoto quente | US$ 2.008,28 | US$ 518 |
| Nós de dados quentes | $ 39.128 (20 × ultraquente1.grande) | US$ 50.409 (15× oi2,8xgrande) |
| Armazenamento Amazon S3 | US$ 9.504 | US$ 1.070 |
| Nós líderes | $ 1.307 (3 × m8g.2xgrande) | $ 1.307 (3 × m8g.2xgrande) |
| Whole sob demanda | US$ 74.427 | US$ 69.297 |
| AURI de 1 ano | US$ 69.674 | US$ 43.918 (~36% menos) |
| AURI de 3 anos | US$ 67.367 | $ 34.939 (~ 48% menos) |
| Plano de economia de banco de dados | US$ 71.708 | US$ 55.406 (~22%) |
Operações
Recupere a capacidade do nó ativo. O modo quente gravável elimina duas causas comuns de superprovisionamento de nó quente: reservar 35% do espaço em disco para operações de mesclagem forçada e manter capacidade further para mover temporariamente os dados de volta para quente para gravações. Você pode executar sua camada ativa com maior utilização, o que reduz o número de nós ativos necessários.
Migrações mais simples. As migrações UltraWarm são operações de várias etapas (forçar mesclagem, instantâneo e realocação de fragmentos) que precisam de agendamento cuidadoso durante janelas de baixo tráfego e são limitadas a ten na fila por vez. O modo gravável simplifica isso para uma realocação leve de fragmentos, com políticas ISM mais diretas e sem restrições de agendamento.
Flexibilidade
UltraWarm oferece apenas dois tamanhos de instância: ultrawarm1.medium (1,5 TiB) e ultrawarm1.massive (20 TiB). A capacidade gravável com instâncias OI2 oferece uma gama completa de oi2.massive a oi2.16xlarge. Cada tamanho aborda até 5x o tamanho do cache native, para que você possa dimensionar corretamente a capacidade quente com precisão para sua carga de trabalho.
Desempenho de pesquisa
Comparamos a latência de pesquisa usando a carga de trabalho NYC Taxis, comparando gravável quente (oi2.massive) com nós UltraWarm. Todas as medições são latências P90.
No benchmark NYC_TAXIS, a correspondência quente gravável ou superou o UltraWarm em 6 dos 7 tipos de consulta no P90, incluindo filtros leves, intervalos, classificações e agregações de histograma de tempo. Para a maioria dos padrões de pesquisa do mundo actual, o gravável quente oferece desempenho comparável ou melhor que o UltraWarm, além da capacidade de gravar diretamente na camada.
Desempenho de pesquisa: gravável quente em comparação com UltraWarm
| Tarefa | Latência gravável do nó quente em ms | Latência UltraWarm em ms | UltraWarm vs. % de diferença quente gravável |
| Tipo de carga de trabalho NYC_TAXIS | ** ** | ** ** | ** ** |
| padrão (P90) | 21.287 | 23.857 | 12.07223 |
| alcance (P90) | 21.23 | 21.016 | -1,00718 |
| distância_quantidade_agg (P90) | 5.069 | 3929.23 | -22.48406 |
| autohisto_agg (P90) | 21.076 | 22.002 | 4.39348 |
| data_histograma_agg (P90) | 21.363 | 21.792 | 2.01031 |
| desc_sort_tip_amount (P90) | 23.224 | 23.797 | 2,46636 |
| asc_sort_tip_amount (P90) | 22.483 | 22.482 | -0,00445 |
Quando escolher o que
Você deve mudar de UltraWarm para quente gravável? Depende da sua carga de trabalho.
| Exigência | Quente gravável | Ultraquente |
| Gravação habilitada | ✓ | Somente leitura |
| Preços de instâncias reservadas | ✓ | ✗ |
| Flexibilidade de tamanho de instância | Ampla variedade (grande – 8xgrande) | 2 opções apenas |
| Suporte de camada fria | ✗ | ✓ |
| Necessidade de famílias de instâncias otimizadas para OpenSearch | ✗ | ✓ |
| Transições simultâneas de níveis | ✓ | ✗ (sequencial) |
| Impacto do sizzling node durante a migração | Mínimo | Alto (CPU/memória) |
Limpar recursos
Se você criou um domínio de teste para avaliar o armazenamento quente gravável, exclua-o para evitar cobranças contínuas. No console do OpenSearch Service, selecione seu domínio e escolha Excluir. Isso take away todos os nós e interrompe as cobranças de armazenamento do Amazon S3 para esse domínio.
Resumo
Nesta postagem, mostrei como o armazenamento quente gravável elimina o caro ciclo de migração criado pela limitação somente leitura do UltraWarm. Você obtém até 36% de economia de custos com instâncias reservadas de 1 ano, desempenho de pesquisa mais rápido e um modelo operacional mais simples. A capacidade gravável também take away as transições de dados entre os níveis, e o preço da instância reservada fica disponível para armazenamento quente pela primeira vez.
A operação gravável requer o OpenSearch Service versão 3.3 ou posterior com instâncias OI2. Para domínios que precisam de suporte de nível frio, versões anteriores do OpenSearch Service ou famílias de instâncias não otimizadas, o UltraWarm continua sendo a escolha certa.
Próximas etapas: Comece analisando sua divisão quente e quente atual. Quantos dias de dados você mantém atualizados apenas para acomodar atualizações ocasionais? Use o Calculadora de preços AWS para modelar suas economias potenciais e ativar a capacidade gravável em um domínio de teste em minutos. No momento desta postagem, o gravável quente é compatível com o OpenSearch Service versão 3.3. Para obter instruções passo a passo, consulte Migrando para armazenamento quente gravável na documentação do OpenSearch Service.
Você já tentou armazenamento quente gravável? Eu adoraria ouvir sobre sua experiência e qualquer dúvida que você tenha nos comentários.