Elasticsearch está usando muito espaço em disco

Question

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

Meu arquivo de configuração elasticsearch.yml é uma modificação mínima do envio com o elasticsearch como padrão. Uma vez despojada de todas as linhas comentadas, parece que:

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 compactação em by default , e eu li vários benchmarks colocando a taxa de compressão de 50% a tão alta como 95%. Infelizmente, a taxa de compactação no meu caso é de -400%, ou em outras palavras: os dados armazenados com o ES levam 4 vezes mais espaço em disco do que o arquivo de texto com o mesmo conteúdo . Veja:

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: 1 ao meu arquivo de configuração, pois descobri que no elasticsearch 0.19.5 release notes (foi quando a compactação store saiu primeiro), mas eu ainda não sou capaz de dizer se está fazendo a diferença, e de qualquer forma a compressão deve estar ativada por padrão, hoje em dia ...

    

Answer 1

O Elasticsearch não encolhe seus dados automaticamente. Isso é verdade para qualquer banco de dados. Além de armazenar os dados brutos, cada banco de dados precisa armazenar metadados junto com ele. Os bancos de dados normais armazenam apenas um índice (para pesquisa mais rápida) para as colunas que o administrador de banco de dados escolheu antecipadamente. O ElasticSearch é diferente, pois indexa a coluna todos por padrão. Assim, tornar o índice extremamente grande, mas, por outro lado, oferece um desempenho perfeito ao recuperar dados.

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

Portanto, para diminuir o tamanho do banco de dados, você precisa fazer o contrário, como fez nos RDBMs: Excluir colunas de serem indexadas ou armazenadas que você não precisa ser indexado.

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 as entradas do arquivo de log.

Existem algumas comparações e dicas úteis aqui: link

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