O Elasticsearch está usando muito espaço em disco

Eu tenho um servidor CentOS 6.5 no qual instalei o Elasticsearch 1.3.2 .

Meu elasticsearch.ymlarquivo de configuração é uma modificação mínima da remessa com elasticsearch como padrão. Uma vez retirado todas as linhas comentadas, ele se parece com:

cluster.name: xxx-kibana

node:
    name: "xxx"
    master: true
    data: true

index.number_of_shards: 5

index.number_of_replicas: 1

path:
    logs: /log/elasticsearch/log
    data: /log/elasticsearch/data


transport.tcp.port: 9300

http.port: 9200

discovery.zen.ping.multicast.enabled: false

O Elasticsearch deve ter a compactação ativada por padrão , e eu li vários benchmarks, colocando a taxa de compactação de 50% a 95%. Infelizmente, a taxa de compactação no meu caso é -400%, ou seja, os dados armazenados no ES ocupam 4 vezes mais espaço em disco do que o arquivo de texto com o mesmo conteúdo . Vejo:

12K     logstash-2014.10.07/2/translog
16K     logstash-2014.10.07/2/_state
116M    logstash-2014.10.07/2/index
116M    logstash-2014.10.07/2
12K     logstash-2014.10.07/4/translog
16K     logstash-2014.10.07/4/_state
127M    logstash-2014.10.07/4/index
127M    logstash-2014.10.07/4
12K     logstash-2014.10.07/0/translog
16K     logstash-2014.10.07/0/_state
109M    logstash-2014.10.07/0/index
109M    logstash-2014.10.07/0
16K     logstash-2014.10.07/_state
12K     logstash-2014.10.07/1/translog
16K     logstash-2014.10.07/1/_state
153M    logstash-2014.10.07/1/index
153M    logstash-2014.10.07/1
12K     logstash-2014.10.07/3/translog
16K     logstash-2014.10.07/3/_state
119M    logstash-2014.10.07/3/index
119M    logstash-2014.10.07/3
622M    logstash-2014.10.07/  # <-- This is the total!

versus:

6,3M    /var/log/td-agent/legacy_api.20141007_0.log
8,0M    /var/log/td-agent/legacy_api.20141007_10.log
7,6M    /var/log/td-agent/legacy_api.20141007_11.log
6,7M    /var/log/td-agent/legacy_api.20141007_12.log
8,0M    /var/log/td-agent/legacy_api.20141007_13.log
7,6M    /var/log/td-agent/legacy_api.20141007_14.log
7,6M    /var/log/td-agent/legacy_api.20141007_15.log
7,7M    /var/log/td-agent/legacy_api.20141007_16.log
5,6M    /var/log/td-agent/legacy_api.20141007_17.log
7,9M    /var/log/td-agent/legacy_api.20141007_18.log
6,3M    /var/log/td-agent/legacy_api.20141007_19.log
7,8M    /var/log/td-agent/legacy_api.20141007_1.log
7,1M    /var/log/td-agent/legacy_api.20141007_20.log
8,0M    /var/log/td-agent/legacy_api.20141007_21.log
7,2M    /var/log/td-agent/legacy_api.20141007_22.log
3,8M    /var/log/td-agent/legacy_api.20141007_23.log
7,5M    /var/log/td-agent/legacy_api.20141007_2.log
7,3M    /var/log/td-agent/legacy_api.20141007_3.log
8,0M    /var/log/td-agent/legacy_api.20141007_4.log
7,5M    /var/log/td-agent/legacy_api.20141007_5.log
7,5M    /var/log/td-agent/legacy_api.20141007_6.log
7,8M    /var/log/td-agent/legacy_api.20141007_7.log
7,8M    /var/log/td-agent/legacy_api.20141007_8.log
7,2M    /var/log/td-agent/legacy_api.20141007_9.log
173M    total

O que estou fazendo de errado? Por que os dados não estão sendo compactados?

Eu adicionei provisoriamente index.store.compress.stored: 1ao meu arquivo de configuração, como descobri nas elasticsearch 0.19.5notas de versão (foi quando a storecompactação saiu primeiro), mas ainda não sou capaz de saber se está fazendo a diferença e, de qualquer forma, a compactação deve estar ativada por padrão hoje em dia ...

elasticsearch disk-space-utilization lucene

— Mac
fonte

Você já considerou a sobrecarga necessária para armazenar e indexar esses dados? É daí que vem a diferença.

— mailq

@mailq - AFAIK, Elastic comprime tanto os dados e índices, e você ainda deve notar uma diminuição no uso de espaço no seu disco, em comparação com logs de texto. Presumo que a milhagem possa variar de acordo com a estrutura dos logs, mas os logs geralmente são de natureza muito repetitiva, portanto, a indexação não deve ser a que consome mais espaço nas operações. ... ou estou entendendo errado?

— mac

Os logs não são realmente repetitivos. O usuário A efetua login no momento 1. O usuário B efetua login no momento 2. O que é repetitivo? Ambas as tuplas devem ser indexadas e armazenadas separadamente. Além da própria entrada do log.

— mailq

Tente essas recomendações. github.com/jordansissel/experiments/tree/master/elasticsearch/…

— mailq 10/10

@mailq - Supercool maliq, muito obrigado. Se você expandir seu comentário e escrever uma resposta adequada, ficarei feliz em marcá-lo como aceito (caso contrário, farei isso mais tarde, mas não quero roubar seu trovão!).

— mac

O Elasticsearch não reduz seus dados automaticamente. Isso vale para qualquer banco de dados. Além de armazenar os dados brutos, cada banco de dados precisa armazenar metadados junto com eles. Os bancos de dados normais armazenam apenas um índice (para pesquisa mais rápida) das colunas que o db-admin escolheu antecipadamente. O ElasticSearch é diferente, pois indexa todas as colunas por padrão. Dessa forma, o índice é extremamente grande, mas, por outro lado, oferece desempenho perfeito ao recuperar dados.

Nas configurações normais, você vê um aumento de 4 a 6 vezes os dados brutos após a indexação. Embora isso dependa fortemente dos dados reais. Mas esse é realmente o comportamento pretendido.

Portanto, para diminuir o tamanho do banco de dados, você deve fazer o contrário, como fez nos RDBMs: Excluir colunas da indexação ou armazenamento de colunas que não precisam ser indexadas.

Além disso, você pode ativar a compactação, mas isso só melhorará quando seus "documentos" forem grandes, o que provavelmente não é verdadeiro para entradas de arquivos de log.

Existem algumas comparações e dicas úteis aqui: https://github.com/jordansissel/experiments/tree/master/elasticsearch/disk

Mas lembre-se: a pesquisa tem um custo. O custo a pagar é o espaço em disco. Mas você ganha flexibilidade. Se o tamanho do seu armazenamento exceder, aumente horizontalmente! É aqui que o ElasticSearch vence.

— mailq
fonte