Elasticsearch — Qual o tamanho de um dado indexado?

João Neto
4 min readJun 20, 2023

--

INTRODUÇÃO

Recentemente em meu trabalho como consultor Elastic me deparei com o cenário onde a volumetria de dados apresentado no DATA IN do ambiente Cloud não correspondia com a volumetria de dados indexados dentro do Elasticsearch, pois o volume indexado no Elasticsearch estava sempre menor e após entender o porque isso aconteceu eu me senti obrigado a compartilhar com todos vocês, por isso o motivo deste artigo!

POR QUE DA DIFERENÇA?

Eu trabalho com Elasticsearch desde a versão 5, e nessa epoca eu percebia que o dado indexado no Elasticsearch sempre ficava MAIOR que o dado raw, isso porque o Elasticsearch colocava metadados, etc, etc.

Dado Raw VS Metadado

Então assumi isso como sendo uma verdade, porém Elasticsearch vem sempre se aprimorando “OBRIGADO ELASTIC por isso” e a cada nova versão novas features surgem, assim como melhorias em como a ferramenta trabalha.

Dentre essas evoluções o que também evoluiu foi a fator de compressão de strings, assim como a deduplicação de strings:

https://www.elastic.co/pt/blog/save-space-and-money-with-improved-storage-efficiency-in-elasticsearch-7-10

Isso em ambientes onde o foco principal é observabilidade existe possibilidade da grande maioria dos dados serem parecidos, desta forma otimizando a deduplicação de strings, o que responderia a seguinte pergunta: “Por que o dado indexado ficou menor que o DATA IN da Cloud?”

Mas não satisfeito com a teoria eu quis ver na prática como isso se comporta, por isso nas próximas sessões vou demostrar a PoC que fiz que comprova o incrível poder da compressão em conjunto com a deduplicação de dados.

AMBIENTE

O ambiente utilizado é composto por duas máquinas virtuais, sendo uma destinado ao Elastic Agent (Origem dos dados) e a outra para rodar a Stack da Elastic.

Elastic Agent

  • Sistema Operacional: Windows 10
  • Memória: 4 GB
  • Processador: 4 Cores na VM (Intel Core i7)
  • Disco: 100 GB (NVMe)

Hospedeira (Docker Elastic Stack)

  • Sistema Operacional: Debian 11
  • Memória: 8 GB
  • Processador: 4 Cores na VM (Intel Core i7)
  • Disco: 100 GB (NVMe)

Elastic Stack

EXECUÇÃO

Como origem de dados eu utilizei a seguinte linha de log abaixo:

{"category": ["Men's Clothing"], "currency": "EUR", "customer_first_name": "Eddie", "customer_full_name": "Eddie Underwood", "customer_gender": "MALE", "customer_id": 38, "customer_last_name": "Underwood", "customer_phone": "", "day_of_week": "Monday", "day_of_week_i": 0, "email": "eddie@underwood-family.zzz", "manufacturer": ["Elitelligence", "Oceanavigations"], "order_date": "2023-05-29T09:28:48+00:00", "order_id": 584677, "products": [{"base_price": 11.99, "discount_percentage": 0, "quantity": 1, "manufacturer": "Elitelligence", "tax_amount": 0, "product_id": 6283, "category": "Men's Clothing", "sku": "ZO0549605496", "taxless_price": 11.99, "unit_discount_amount": 0, "min_price": 6.35, "_id": "sold_product_584677_6283", "discount_amount": 0, "created_on": "2016-12-26T09:28:48+00:00", "product_name": "Basic T-shirt - dark blue/white", "price": 11.99, "taxful_price": 11.99, "base_unit_price": 11.99}, {"base_price": 24.99, "discount_percentage": 0, "quantity": 1, "manufacturer": "Oceanavigations", "tax_amount": 0, "product_id": 19400, "category": "Men's Clothing", "sku": "ZO0299602996", "taxless_price": 24.99, "unit_discount_amount": 0, "min_price": 11.75, "_id": "sold_product_584677_19400", "discount_amount": 0, "created_on": "2016-12-26T09:28:48+00:00", "product_name": "Sweatshirt - grey multicolor", "price": 24.99, "taxful_price": 24.99, "base_unit_price": 24.99}], "sku": ["ZO0549605496", "ZO0299602996"], "taxful_total_price": 36.98, "taxless_total_price": 36.98, "total_quantity": 2, "total_unique_products": 2, "type": "order", "user": "eddie", "geoip": {"country_iso_code": "EG", "location": {"lon": 31.3, "lat": 30.1}, "region_name": "Cairo Governorate", "continent_name": "Africa", "city_name": "Cairo"}, "event": {"dataset": "sample_ecommerce"}}

Dupliquei essa linha de log em um arquivo até o mesmo atingir por volta de 100 Megas, totalizando 58.909 linhas.

Clonei esse arquivo por 51 vezes, totalizando 5.07 Gigas e com um total de 3.063.268 de linhas.

Feito isso instalei um Elastic Agent com o integration de Custom Logs para coletar esses eventos e enviar para o Elasticsearch, após a conclusão criei o seguinte Dashboard e para meu espanto foi isso que vi:

Exatamente! Ao analizar o metadado “_size” é possível ver que tivemos quase 9 GB indexados, porém ao analisar o tamanho do índice vemos que o dado indexado ocupou APENAS 234 MB aproximadamente.

COM ISSO É POSSÍVEL CHEGAR EM UMA COMPRESSÃO DE APROXIMADAMENTE 97%! 🤯

⚠️ OBS: Certamente essa taxa de compressão só foi obtida pois o mesmo dado foi indexado várias as vezes, portanto em um ambiente produtivo essa taxa de compressão pode variar bastante!

Pensando ainda em um cenário financeiro, teríamos a seguinte estimativa de redução de custo:

https://cloud.elastic.co/pricing?elektra=pricing-page

E ai já pensou em quanto utilizar versões mais atualizadas podem impactar seu negócio?

Issa era o que eu tinha para compartilhar hoje, te vejo em breve!

Isso é tudo, pessoal ;)

REFERÊNCIA

Link da documentação oficial: https://www.elastic.co/pt/blog/save-space-and-money-with-improved-storage-efficiency-in-elasticsearch-7-10

--

--

João Neto

Especialista Elasticsearch, entusiasta na área de segurança da informação, cientista louco e acredita que melhor maneira de aprender é através do humor.