Práticas recomendadas

Siga essas melhores práticas para otimizar o desempenho e o custo ao executar domínios com o mecanismo otimizado.

Mantenha os fragmentos por nó abaixo de 500

Evite ultrapassar 500 fragmentos por nó de dados. Uma alta contagem de fragmentos aumenta a sobrecarga de coordenação do cluster e pode degradar o desempenho da consulta e a estabilidade do cluster. Monitore a contagem de fragmentos à medida que você aumenta o volume de ingestão. Use as políticas do Index State Management (ISM) para gerenciar o ciclo de vida do índice.

Minimize os subcampos de palavras-chave

No mecanismo otimizado, o armazenamento colunar do Parquet gerencia a classificação e as agregações de forma nativa, sem exigir subcampos. .keyword Ao definir seus mapeamentos de índice, considere omitir subcampos de palavras-chave para campos de texto nos quais você não precisa de filtragem de correspondência exata. A remoção de subcampos de palavras-chave desnecessários de seus mapeamentos reduz o consumo de armazenamento e a sobrecarga de ingestão.

Prefira consultas de correspondência em vez de consultas curinga

Use match ou match_phrase para pesquisa de texto em vez de padrões like (curinga). As consultas de correspondência utilizam o índice invertido do Lucene de forma eficiente, embora as consultas curinga consumam mais recursos e possam resultar em tempos de resposta mais lentos.

Dimensione os nós do coordenador de forma adequada

Se você habilitar nós coordenadores dedicados, use uma proporção de 1 nó coordenador para cada 5 nós de dados. Escolha um tipo de instância de nó coordenador com a mesma configuração de memória dos nós de dados para garantir que o planejamento de consultas e a mesclagem de resultados tenham recursos suficientes.

Otimize a indexação e o armazenamento

Os dados de log têm padrões previsíveis. Os registros de data e hora aumentam monotonicamente, os códigos de status se repetem com frequência e as mensagens são sequências de caracteres de comprimento variável. Combine suas configurações de codificação, compressão, filtro bloom e classificação de índice com esses padrões para otimizar a eficiência de armazenamento e o desempenho de consultas.

Codificação Parquet

Escolha codificações que correspondam às características de dados de cada tipo de campo.

Tipo de campo	Codificação recomendada	Motivo
@timestamp	DELTA_BINARY_PACKED	Os timestamps aumentam monotonicamente. Os deltas são pequenos e se comprimem bem.
Low-cardinality palavras-chave (log.level,status_code,region,service.name)	DICIONÁRIO DE REGRAS	Poucos valores distintos. O dicionário mais a codificação de duração de execução produzem uma sobrecarga próxima de zero por linha.
High-cardinality Identificações (trace_id,span_id,request_id)	MATRIZ DE BYTES DELTA	Armazena matrizes de bytes de comprimento variável de forma incremental. Mais compacto do que PLAIN para strings de formato fixo, como UUIDs ou IDs codificados em hexadecimal que compartilham padrões estruturais.
Floating-point métricas (response_time,cpu_usage)	BYTE_STREAM_SPLIT	Separa os bytes mantissa e expoente para melhor compressão das séries numéricas.
message(texto longo)	PLAIN (padrão)	Variable-length texto não estruturado não se beneficia de codificação especializada.

Per-field compressão

Por padrão, os campos de texto e palavra-chave usam compressão ZSTD, e outros campos usam LZ4_RAW. Com a compactação por campo, você pode equilibrar a eficiência do armazenamento com a latência da consulta.

ZSTD

Ideal para campos de texto grandes e cadeias de caracteres de alta cardinalidade em que a taxa de compressão é mais importante do que a velocidade de decodificação.

LZ4_RAW (padrão para numérico)

Ideal para campos numéricos, de carimbo de data/hora e de baixa cardinalidade digitalizados com frequência por agregações e consultas de intervalo.

SNAPPY

Ideal para CPU-constrained nós com altas taxas de ingestão.

Para campos de palavras-chave de baixa cardinalidade que você usa principalmente em agregações e consultas de intervalo, considere substituir o ZSTD padrão por LZ4_RAW para obter uma velocidade de decodificação mais rápida.

Filtros Bloom

Ative filtros de floração em campos que você filtra frequentemente com predicados de igualdade. Quando um campo é usado somente para filtragem de igualdade (não para consultas de intervalo ou pesquisa de texto completo), você também pode desativar o índice de palavras-chave do Lucene nesse campo para evitar a manutenção de estruturas adicionais.

Low-cardinality fields (log.level,, status_codeservice.name,region) — Os filtros Bloom são pequenos e as pesquisas são rápidas. O desempenho da consulta permanece consistente enquanto você economiza armazenamento desativando o índice de palavras-chave do Lucene nesses campos.

High-cardinality fields (trace_id,request_id,user_id) — Os filtros Bloom ainda podem eliminar grupos de linhas e reduzir o armazenamento em comparação com um índice totalmente invertido, mas o filtro em si se torna maior e cada sonda trabalha mais. Use filtros bloom em campos de alta cardinalidade quando a economia de armazenamento é a prioridade e você pode tolerar uma sobrecarga um pouco maior por consulta.

Classificação do índice

A classificação por índice controla a ordem física dos documentos em cada segmento. Quando os documentos são classificados, as linhas adjacentes na mesma coluna do Parquet tendem a compartilhar valores, o que melhora a compactação. Isso é especialmente eficaz com a codificação de RLE e dicionário.

Para análise de registros, classifique primeiro por um campo de baixa cardinalidade (para criar execuções de valor longas) e depois por data e hora (para manter os eventos em cada grupo em ordem):

• Classificando por service.name grupos todos os registros do mesmo serviço. O RLE_DICTIONARY compacta essas execuções até uma sobrecarga quase zero.

• Dentro de cada grupo de serviço, a @timestamp ordem decrescente garante valores delta estreitos entre as linhas adjacentes. DELTA_BINARY_PACKED os codifica com eficiência.

• Outros campos correlacionados (host.name,log.level,region) também se beneficiam porque se agrupam naturalmente quando o principal classifica grupos por serviço.

Posição de classificação	Campo recomendado	Motivo
1º (primário)	Lowest-cardinality campo em que você costuma filtrar (service.name,host.name,region)	Cria as execuções de valor mais longas e permite a remoção de grupos de linhas nos filtros.
2º	@timestamp	Mantém a ordem temporal dentro de cada grupo e permite a poda por intervalos de tempo.
3º (opcional)	Campo categórico secundário () log.level	Melhora ainda mais a duração das tiragens, com retornos decrescentes.

Considere as seguintes vantagens e desvantagens ao ativar a classificação por índice:

• A classificação adiciona o custo da CPU durante as mesclagens de segmentos. Para altas taxas de ingestão, limite a um ou dois campos de classificação.

• Escolha campos de classificação que se alinhem aos filtros de consulta mais frequentes. Um campo classificado permite a min/max remoção de grupos de linhas, além dos benefícios de compressão.

Exemplo de combinação

A configuração de índice a seguir aplica as recomendações de codificação, compactação, filtro de florescência e classificação de índice em conjunto:

PUT my-logs
{
  "settings": {
    "index.sort.field": ["service.name", "@timestamp"],
    "index.sort.order": ["asc", "desc"],
    "index.parquet.encoding.field": [
      "@timestamp",
      "log.level",
      "status_code",
      "service.name",
      "region",
      "response_time",
      "trace_id"
    ],
    "index.parquet.encoding.value": [
      "DELTA_BINARY_PACKED",
      "RLE_DICTIONARY",
      "RLE_DICTIONARY",
      "RLE_DICTIONARY",
      "RLE_DICTIONARY",
      "BYTE_STREAM_SPLIT",
      "DELTA_BYTE_ARRAY"
    ],
    "index.parquet.compression.field": ["message", "trace_id", "@timestamp", "response_time"],
    "index.parquet.compression.value": ["ZSTD", "ZSTD", "LZ4_RAW", "LZ4_RAW"],
    "index.parquet.bloom_filter_enabled.field": [
      "log.level", "status_code", "service.name", "region"
    ],
    "index.parquet.bloom_filter_enabled.value": [true, true, true, true]
  },
  "mappings": {
    "properties": {
      "@timestamp": { "type": "date" },
      "message": { "type": "text" },
      "host.name": { "type": "keyword" },
      "trace_id": { "type": "keyword" },
      "span_id": { "type": "keyword" },
      "service.name": {
        "type": "keyword",
        "index": false
      },
      "log.level": {
        "type": "keyword",
        "index": false
      },
      "status_code": {
        "type": "keyword",
        "index": false
      },
      "region": {
        "type": "keyword",
        "index": false
      },
      "response_time": { "type": "float" }
    }
  }
}

As configurações do índice se aplicam somente no momento da criação

Você define as configurações de codificação, compressão, filtro bloom e classificação do índice do Parquet no momento da criação do índice. Você não pode alterá-los nos índices existentes. Para aplicar essas recomendações, atualize seu modelo de índice para que os índices recém-criados usem as configurações otimizadas.

Ajuste a precisão para consultas Top-N distribuídas

As consultas TOP-N agrupadas distribuídas (aquelas que agrupam por uma chave, classificam por um agregado e limitam a saída) usam a sobreamostragem para equilibrar precisão e desempenho. Cada fragmento retorna apenas sua parte superior local para o coordenador, em vez de embaralhar cada grupo.

Você pode controlar essa compensação com a configuração do analytics.shard_bucket_oversampling_factor cluster:

Propriedade	Valor
Tipo	Float
Padrão	1.5
Dinâmico	Sim (configuração de cluster)

Cada fragmento retorna ceil(N × factor) + N grupos, onde N é o head limite. A aproximação só pode subestimar um grupo, nunca superestimá-lo. Um grupo é retirado de um fragmento quando suas fileiras ficam abaixo do limite local desse fragmento.

Valor	Precisão	Custo
0.0	Exato	Mais alto. Cada grupo está embaralhado. Grupos de cardinalidade muito alta podem atingir o disjuntor.
Baixo (por exemplo,5)	Aproximado	Menor latência e memória.
Alto (por exemplo,100)	Near-exact	Mais dados misturados. Converge para exato à medida que o fator cresce.

Aumente o fator quando os resultados agrupados entre N e N são subestimados. O valor necessário varia de acordo com a distorção da distribuição da chave e a profundidade do head limite. Defina como 0 para desativar a sobreamostragem e retornar resultados exatos.

Exemplo:

PUT _cluster/settings
{
  "transient": { "analytics.shard_bucket_oversampling_factor": 5.0 }
}