Upnetix Labs · protocolo de experimento
Protocolo: Qual o impacto do número de shards no tempo de resposta de buscas simples no Elasticsearch?
Este protocolo avalia como o número de shards de um índice afeta a latência de consultas de busca simples no Elasticsearch. O objetivo é medir o tempo de resposta médio sob diferentes configurações de shards, mantendo o volume de dados e hardware constantes.
Como o tempo de resposta de buscas simples varia conforme o número de shards em um índice Elasticsearch, mantendo o volume de dados constante?
Hipótese
Aumentar o número de shards além de um certo ponto eleva a latência média das buscas simples, devido ao overhead de coordenação.
Variáveis
| Independentes (o que varia) | número de shards do índice |
|---|---|
| Dependentes (o que se mede) | tempo de resposta (latência) das buscas simples |
| Controladas (o que fica fixo) | volume total de dados indexados; tipo e quantidade de documentos; hardware do nó; número de réplicas; versão do Elasticsearch; tipo de consulta (match_all) |
Ambiente
Cluster Elasticsearch de código aberto (licença Apache 2.0), versão estável (consulte a documentação), rodando em um único nó dedicado, com hardware fixo. Ferramenta de geração de carga: k6 (https://k6.io/), configurada para executar consultas HTTP REST. Dados sintéticos indexados via bulk API, mantendo volume e estrutura idênticos entre os testes.
Procedimento
- Preparar ambiente
Instale Elasticsearch e k6 nas versões recomendadas pela documentação oficial.
- Gerar dados
Crie um conjunto fixo de documentos sintéticos (por exemplo, 1 milhão de registros EXEMPLO) e salve em arquivo JSON.
- Criar índice
Para cada teste, crie um novo índice com um número específico de shards (ex: 1, 2, 4, 8, 16).
PUT /indice_teste_{N} { "settings": { "number_of_shards": N, "number_of_replicas": 0 } } - Indexar dados
Carregue exatamente o mesmo conjunto de documentos no índice criado.
- Executar consultas
Utilize k6 para enviar consultas 'match_all' concorrentes ao índice, simulando 10 usuários simultâneos EXEMPLO, por 5 minutos.
k6 run script.js - Coletar métricas
Registre o tempo de resposta de cada consulta (latência em milissegundos).
- Repetir
Repita o teste para cada configuração de shards, sempre reindexando os dados.
Planilha de coleta
| num_shards (unidade) | tempo_resposta_ms (ms) | percentil_95_ms (ms) | usuarios_concorrentes (unidade) | volume_dados_mb (MB) |
|---|---|---|---|---|
| EXEMPLO: 4, 120, 180, 10, 500 | ||||
Repetições recomendadas: 5. Baixe a planilha vazia em CSV: colunas prontas.
Análise
Calcule a média e o percentil 95 do tempo de resposta para cada configuração de shards. Compare os valores para identificar o ponto de inflexão em que o aumento de shards começa a prejudicar a latência. Analise a variação entre repetições para garantir consistência.
Critérios de decisão
- A latência média e o percentil 95 devem ser estáveis entre repetições.
- Identificar o número de shards com menor latência sem aumento significativo de overhead.
Fontes de erro e mitigação
- Variação de carga no hardware: execute os testes em horários de baixa interferência.
- Cache do Elasticsearch: reinicie o serviço entre repetições para evitar influência de cache.
- Rede: use ambiente local ou isolado para evitar latências externas.
- Publicado
- 09/09/2026
- Última revisão
- 09/09/2026
- Versão do conteúdo
- 1.0
- Referências
- 0 oficiais
- Revisão técnica
- redação e revisão por IA, URLs conferidas na publicação
- Status
- Atual
