Técnicas de otimização de custos para o Amazon OpenSearch Service

OpenSearch armazena cada documento ingerido duas vezes: uma vez no _source campo (documento bruto) e uma vez como campos indexados para pesquisa.

O _source campo sozinho pode consumir um espaço de armazenamento significativo — geralmente de 30 a 50% do armazenamento total do índice.

Com o Derived Source, você pula o armazenamento _source e, em vez disso, o reconstrói dinamicamente a partir de campos indexados quando necessário (durante operações de pesquisa, obtenção, mget, reindexação ou atualização).

Isso é opcional, ativado na criação do índice usando configurações de índice composto.

Disponível em todas as regiões em que a OpenSearch versão 3.1 ou posterior é suportada.

OR2: Taxa de transferência de indexação até 26% maior do que as OR1 instâncias R7g.

OM2: taxa de transferência de indexação até 15% maior do que as OR1 instâncias M7g.

Ambos usam a mesma arquitetura: EBS local para armazenamento primário e S3 para durabilidade.

Elimina o custo de armazenamento de réplicas — réplicas armazenadas no S3 (durabilidade de 11 a nove) em vez de volumes caros do EBS.

Melhoria de até 30% no preço-desempenho em relação às instâncias da geração anterior.

Suporta instantâneos superficiais v2 — instantâneos quase instantâneos sem sobrecarga. I/O

Dados de IoT/sensores: mantenha os dados por segundo em um armazenamento dinâmico dos últimos períodos; faça resumos horários ou diários dos dados mais antigos.

Métricas do sistema: mantenha métricas detalhadas dos últimos 30 dias; agregue dados antigos em resumos horários ou diários.

Dados de registro: preserve todos os detalhes da janela ativa de solução de problemas (por exemplo, 1 semana); mantenha padrões de erro resumidos para períodos anteriores.

Combine com as políticas do ISM para automatizar a migração cumulativa e hierárquica em uma única política de ciclo de vida.

Maior economia ao agregar de segundos a horas versus segundos a minutos.

Migre índices automaticamente: de quente para frio UltraWarm para excluir, com base na idade, tamanho ou contagem de documentos.

Acione os rollups antes das transições de nível para reduzir o volume de dados.

Defina políticas de rollover (por exemplo, quando um índice atinge 50 GB ou tem 30 dias) para controlar o crescimento do índice.

Automatize a mesclagem forçada em índices somente para leitura para recuperar o armazenamento de documentos excluídos.

Combine com pacotes cumulativos para obter o máximo de economia em grandes conjuntos de dados de séries temporais.

Termos de compromisso de 1 ou 3 anos sem opções de pagamento adiantado, adiantado parcial ou totalmente adiantado.

Ideal para nós de dados de camada ativa e nós mestres dedicados que funcionam continuamente.

Use a Calculadora AWS de Preços para estimar a economia antes de se comprometer.

As instâncias reservadas são um desconto de cobrança aplicado às instâncias sob demanda, sem necessidade de alterações na infraestrutura.

Sempre use a última geração de instâncias (por exemplo, as instâncias Graviton3 oferecem desempenho até 25% melhor do que as instâncias baseadas em Graviton2).

Use volumes EBS gp3 em vez de gp2 — melhor desempenho a um custo menor sem custo adicional.

Combine o tipo de instância com a carga de trabalho: otimizado para memória para pesquisas pesadas, otimizado para computação para indexação pesada.

Avalie os nós dedicados do gerenciador de cluster: necessários apenas para 3 ou mais nós de dados; evite provisionar em excesso o tamanho do nó principal.

Monitore CloudWatch métricas para detectar o excesso de provisionamento: CPU sustentada abaixo de 40%, JVM abaixo de 50% e armazenamento abaixo de 50% são sinais de desperdício.

Intervalos ideais: CPU de 60 a 80%, JVM de 65 a 85%, armazenamento de 70 a 85% para cargas de trabalho sustentadas.

Tamanhos de fragmento recomendados: 10—50 GiB por fragmento, dependendo da carga de trabalho.

Não mais do que 25 fragmentos por GiB de heap Java, não mais do que 1.000 fragmentos por nó de dados.

Use as políticas de rollover do ISM para controlar o crescimento do índice e evitar a proliferação ilimitada de fragmentos.

Reduza o número de réplicas onde a durabilidade permitir (OR1/OR2 as instâncias eliminam totalmente a necessidade de réplicas).

Use a mesclagem forçada em índices somente de leitura para reduzir a contagem de segmentos e recuperar o armazenamento.

Sem custo de ingestão — os dados permanecem no S3.

Sem custo de armazenamento de alto nível para dados de arquivamento.

Pay-per-query modelo computacional.

Suporta OpenSearch painéis para visualização.

A latência de segundos ou minutos é aceitável — não para casos de uso em tempo real.

Amostragem: consuma somente um subconjunto representativo de fluxos de registros de alto volume (por exemplo, 10% dos registros de depuração).

Compressão de índice: ative o melhor codec de compressão para reduzir o espaço de armazenamento.

Filtragem de campos: elimine campos de alta cardinalidade e baixo valor antes da indexação (por exemplo, rastreamentos de pilha brutos para registros antigos).

Políticas de retenção: defina janelas máximas de retenção alinhadas aos requisitos de conformidade — nunca armazene dados indefinidamente.

Permanecer em versões mais antigas e sem suporte gera cobranças adicionais além dos custos da instância.

Atualize para as versões atuais suportadas para evitar taxas de Extended Support.

Aplique etiquetas de alocação de custos aos OpenSearch domínios para monitorar detalhadamente os custos por equipe ou carga de trabalho.

Defina CloudWatch alarmes para utilização do armazenamento, pressão da JVM e CPU para detectar o excesso de provisionamento mais cedo.

Use o AWS Cost Explorer para identificar domínios com baixa utilização consistente.

Avalie o ajuste automático — ajusta automaticamente o tamanho da pilha da JVM e outras configurações para melhorar o desempenho e reduzir o desperdício de recursos.

No modo standard (in_memory), o gráfico HNSW completo é carregado na RAM, o que se torna proibitivamente caro em grande escala.

No on_disk modo, somente vetores compactados (quantizados) são mantidos na memória para geração de candidatos; vetores de precisão total são recuperados do disco somente para a fase final de repontuação (pesquisa em duas fases).

Isso reduz drasticamente os requisitos de RAM e, ao mesmo tempo, mantém a alta qualidade da pesquisa.

O on_disk modo padrão usa quantização binária de 32x — reduzindo os requisitos de memória em 97% em relação ao modo na memória.

Suporta níveis de compressão: 2x (FP16), 4x (byte), 8x, 16x, 32x (binário).

Latência P90 na faixa de 100 a 200 ms — adequada para cargas de trabalho que não exigem tempos de resposta de um dígito em milissegundos.

Oferece recomendações de otimização em menos de uma hora.

Integrado com tubulações de ingestão de vetores.

Pode ser combinado com a indexação acelerada por GPU para bancos de dados vetoriais em escala de bilhões.

Tempos de criação de índices de 6,4 a 13,8 vezes mais rápidos em comparação com a indexação somente com CPU.

Custo de OCU de indexação até 75% menor para cargas de trabalho vetoriais com muita gravação.

GPUs são conectados dinamicamente — você só paga OCUs quando a aceleração da GPU está ativa.

Permite que bancos de dados vetoriais em escala de bilhões sejam criados em menos de uma hora.

Carregado separadamente como aceleração vetorial OCUs.

Nível da conta: qualquer valor de até 1.700 OCUs (não restrito a múltiplos de 16).

Grupos de coleta: 1, 2, 4, 8, 16 e múltiplos de 16 até OCUs 1.696.

Defina períodos de retenção de 24 horas a 3.650 dias por índice ou padrão de índice.

O Amazon OpenSearch Service Serverless exclui dados automaticamente com base no melhor esforço (normalmente dentro de 48 horas ou 10% do período de retenção).

As regras podem ser aplicadas no nível da coleção, no nível do padrão do índice ou no nível do índice individual — regras mais específicas têm precedência.

1 TiB/day ingestão com retenção de 30 dias = aproximadamente 1 TiB de dados ativos = 20 OCUs para indexação + 20 para pesquisa. OCUs

Reduzir para uma retenção de 7 dias = aproximadamente 233 GiB de dados ativos = aproximadamente 4 OCUs para indexação + 4 para pesquisa. OCUs

Filtrar campos na ingestão: use pipelines para eliminar campos de baixo valor antes que eles cheguem à coleção.

Evite ingerir dados duplicados ou redundantes: desduplique no nível do pipeline.

Use mapeamentos de índice apropriados: desative a indexação em campos que são armazenados, mas nunca pesquisados (). "index": false

Para coleções de pesquisa: evite armazenar grandes bolhas binárias ou texto bruto que aumente o armazenamento sem valor de pesquisa.

Anteriormente, cada chave KMS exclusiva exigia uma chave dedicada OCUs , tornando o isolamento por inquilino proibitivamente caro.

Com grupos de coleta, inquilinos com chaves de criptografia separadas podem compartilhar a capacidade da OCU.

Economia de custos de até 90% para grandes quantidades de cargas de trabalho de locatários menores.

Suporta tanto o mínimo OCUs (linha de base garantida, sem partidas a frio) quanto o máximo OCUs (limite de custo).

Coleções com diferentes tipos de acesso à rede (pública e VPC) podem coexistir no mesmo grupo.

CloudWatch as métricas fornecem visibilidade por grupo sobre o consumo e a latência de recursos.