Economia de espaço: um benefício menos conhecido da classificação de índices no Elasticsearch

No Elasticsearch 6.0, lançamos um novo recurso chamado classificação de índices. Para saber mais a respeito, leia o blog, mas, resumidamente, esse recurso pega os documentos no momento da indexação e classifica-os por uma chave ou conjunto de chaves na ordem que você selecionar. Isso garante algumas vantagens:

• Se você solicitar ao Elasticsearch para retornar um conjunto de resultados classificados pela mesma chave que usou para classificar o índice, o Elasticsearch não precisará fazer a classificação dos resultados no momento da consulta. Eles já estarão pré-classificados.
• Se você não precisar do total de resultados e estiver classificando pela chave, o Elasticsearch poderá interromper a consulta quando tiver encontrado resultados suficientes para atender à sua solicitação. Isso pode melhorar a performance de consultas livres.
• Se tiver consultas que utilizam ANDs em diferentes campos, a classificação de índices nesses campos poderá agrupá-los para que o Elasticsearch ignore grandes blocos de documentos não correspondentes, o que também acelera a pesquisa.

Resumindo, a classificação de índices torna a pesquisa mais rápida em alguns casos, especialmente quando você tem algumas formas comuns de pesquisa e classificação de documentos. O que nem sempre se diz é que a classificação de índices também pode reduzir o espaço que os índices ocupam em disco. Veja aqui como e por quê.

Cuidado: a classificação de índices não é para todos

Antes de contar o que acontece, quero mencionar mais uma vez que a classificação de índices não é para todos. Ela faz a ação de classificação acontecer no momento da indexação. A classificação é uma operação cara, portanto, se a velocidade da indexação for uma questão principal, pense duas vezes. Ela pode deixar a performance de gravação de 40 a 50% mais lenta. Portanto, se o resultado da indexação for uma prioridade, como geralmente acontece nos casos de uso de registros em log, métricas e análises de segurança de grandes volumes, provavelmente a classificação de índices não será para você. Ela poderá ser útil se você tiver uma taxa de indexação menor, se a velocidade da consulta for mais importante para seu caso de uso ou se tiver um processo regular de reindexação que atue durante horários de indexação fora do pico.

Análise de possíveis ordens de classificação: exemplo

Imagine que eu executo uma instância do Elasticsearch usada para pesquisar produtos. E que eu tenho um conjunto de documentos que, no momento da indexação, tem a seguinte apresentação (colocarei em uma matriz para facilitar a visualização):

E agora, imagine que queremos habilitar a classificação de índices. Qual seria a ordem de classificação? Temos algumas opções: categoria do produto, cor do produto e/ou preço podem ser opções interessantes. Se as pesquisas do usuário quase sempre são classificadas por preço e não temos filtros para a categoria ou para a cor, a classificação por preço pode fazer mais sentido. No entanto, é provável que os usuários selecionem uma categoria antes de encontrar o item mais barato, e eles também podem ter preferência de cor. Vamos, então, classificar por categoria, cor e preço, todos do menor para o maior.

"sort.field" : ["product_category", "product_color", "price"], "sort.order" : ["asc", "asc", "asc"]

O índice classificado fica mais ou menos assim:

Alguns pontos interessantes acontecem, por exemplo:

• Se eu perguntar ao Elasticsearch quais são os dois calçados mais baratos classificados por preço e não solicitar uma contagem total de todos os calçados, ele precisará encontrar o bloco de calçados, o que faz facilmente ignorando todas as outras categorias. E depois de encontrar apenas dois resultados, ele poderá parar de processar o resto do índice e retornar. Observe que para que isso funcione, você precisa incluir todos os elementos da ordem de classificação no índice, mesmo se tiver filtros correspondentes.
• Se eu perguntar ao Elasticsearch categoria_produto:Jaqueta AND cor_produto:Preto, ele poderá ignorar todos os chapéus e todos os calçados e, em Jaquetas, ele pode encontrar as “Pretas” e, quando terminar de pesquisar nelas, poderá ignorar todas as outras cores de forma eficiente.
• O Elasticsearch usa muita compressão internamente. A compressão funciona quando há valores repetidos e é muito mais eficiente quando os valores repetidos estão próximos uns dos outros no índice. Colocando todas as “jaquetas” ou “cores” próximas umas das outras, é possível compactar esses dados de maneira eficiente no disco. Isso significa menos espaço em disco e que o sistema operacional poderá armazenar mais informações no cache do sistema de arquivos, o que torna tudo ainda mais rápido.

Em geral, é uma melhor prática usar ordens de classificação do menor para o maior para termos o benefício do máximo de valores repetidos possível em uma linha.

Quanto espaço em disco vou economizar?

Então, quanto espaço em disco você economizará se habilitar a classificação de índices? Como para muita coisa na vida, a resposta é “depende”. Um dos principais fatores é a cardinalidade do campo pela qual você classifica. No entanto, a economia de espaço pode ser substancial. No fim de semana passado, decidi mudar alguns dados de IoT/automação residencial que estou usando para um projeto pessoal de uma máquina antiga para uma nova. Há maneiras mais rápidas de fazer essa migração de dados, como snapshot/restauração, mas eu tinha tempo para fazer uma reindexação e queria ver quanto espaço a classificação de índices garantiria. Primeiro, eu fiz a reindexação remota em um índice não classificado:

status    index           pri    docs.count    docs.deleted    pri.store.size 
open      devices-2017    1      33310674      0               4.2gb

trata-se de um pouco mais de 30 dispositivos e cada um envia seu status aproximadamente a cada 30 segundos, então, a taxa total de indexação é de cerca de 1 documento por segundo. Nunca estou em uma situação próxima de ser limitado pela indexação, e teria que aumentar muito a taxa de índice ou o número de dispositivos para isso mudar. Parece um candidato razoável para a classificação de índices. Os dados são IDs de hardware, nomes de hardware, horários e várias leituras de sensores, como temperatura ou se o dispositivo está ligado ou desligado no momento ou o nível de algum outro sensor. Classifiquei o índice por ID do dispositivo e por horário, considerando que é provável que, para determinado dispositivo, haja uma chance razoavelmente alta de haver valores similares ou iguais perto do mesmo horário, o que pode gerar melhor compressão. Por exemplo, se um interruptor é “ligado” às 7h00min00s, há uma chance bastante alta de que esteja “ligado” às 7h00min30s, 7h01min00s e os próximos poucos minutos depois e essa compressão é feita facilmente. As estatísticas do índice classificado mostram...

status    index           pri    docs.count     docs.deleted    pri.store.size
open      devices-2017    1      3310674        0               2.5gb

Cerca de 40% de economia em disco.

Novamente, cuidado

Nesse ponto, sinto a necessidade de alertar a todos novamente, porque quase todo mundo gostaria de ocupar 40% menos espaço em disco para acomodar os mesmos dados. Vou resumir em duas frases curtas:

• seus resultados vão variar. Eu usei a classificação de índices em outro conjunto de dados e tive 20% de economia de espaço. Seja cuidadoso com os campos da sua classificação.
• Sua taxa de indexação ficará lenta. Se a taxa de indexação for muito importante para você, por exemplo, caso esteja executando um caso de uso com alto volume de registros em log ou métricas, poderá estar mais suscetível ao número de documentos que pode indexar em pouco tempo e poderá não ser uma boa opção ativar a classificação de índices

Se para você o espaço em disco for muito mais importante do que a velocidade da indexação ou se seus volumes foram baixos o suficiente para não limitá-lo pela velocidade de indexação, poderá ser interessante ver se a classificação de índices vale a pena.