Elasticsearch sta utilizzando troppo spazio su disco

Ho un server CentOS 6.5 su cui ho installato Elasticsearch 1.3.2 .

Il mio elasticsearch.ymlfile di configurazione è una modifica minima di quello fornito con elasticsearch come predefinito. Una volta spogliato di tutte le righe commentate, sembra:

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

Elasticsearch dovrebbe avere la compressione attivata per impostazione predefinita e leggo vari parametri di riferimento che portano il rapporto di compressione da un minimo del 50% a un massimo del 95%. Sfortunatamente, nel mio caso il rapporto di compressione è -400%, ovvero: i dati memorizzati con ES occupano 4 volte più spazio su disco rispetto al file di testo con lo stesso contenuto . Vedere:

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!

contro:

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

Che cosa sto facendo di sbagliato? Perché i dati non vengono compressi?

Ho aggiunto provvisoriamente index.store.compress.stored: 1al mio file di configurazione, come ho scoperto che nelle elasticsearch 0.19.5note di rilascio (in quel momento è storevenuta fuori la compressione), ma non sono ancora in grado di dire se sta facendo la differenza, e comunque la compressione dovrebbe essere ATTIVATA da predefinito, al giorno d'oggi ...

elasticsearch disk-space-utilization lucene

— Mac
fonte

Hai mai considerato l'overhead necessario per archiviare e indicizzare quei dati? Ecco da dove viene la differenza.

— mailq

@mailq - AFAIK, Elastic comprime sia i dati che gli indici e dovresti comunque notare una riduzione dell'utilizzo dello spazio sul tuo disco, rispetto ai registri di testo. Presumo che il chilometraggio possa variare in base alla struttura del registro, ma i registri sono in genere molto ripetitivi in natura, quindi l'indicizzazione non dovrebbe essere la più dispendiosa in termini di spazio. ... o sto sbagliando?

— mac,

I registri non sono molto ripetitivi. L'utente A accede al momento 1. L'utente B accede al momento 2. Che cos'è ripetitivo? Entrambe le tuple devono essere indicizzate e archiviate separatamente. Oltre alla voce di registro stessa.

— mailq

Prova questi consigli. github.com/jordansissel/experiments/tree/master/elasticsearch/…

— mailq

@mailq - Supercool maliq, grazie mille. Se espandi il tuo commento e scrivi una risposta adeguata, sarei felice di contrassegnarlo come accettato (altrimenti lo farò in seguito, ma non voglio rubare il tuo tuono!).

— mac,

Elasticsearch non riduce i dati automaticamente. Questo è vero per qualsiasi database. Oltre a memorizzare i dati non elaborati, ogni database deve archiviare metadati insieme a esso. I database normali memorizzano solo un indice (per una ricerca più rapida) per le colonne scelte in anticipo da db-admin. ElasticSearch è diverso in quanto indicizza ogni colonna per impostazione predefinita. Rendendo così l'indice estremamente grande, ma d'altra parte offre prestazioni perfette durante il recupero dei dati.

Nelle configurazioni normali si vede un aumento da 4 a 6 volte dei dati grezzi dopo l'indicizzazione. Anche se dipende fortemente dai dati effettivi. Ma questo è in realtà un comportamento previsto.

Quindi, per ridurre le dimensioni del database, è necessario fare il contrario come nelle RDBM: escludere le colonne dall'indicizzazione o dall'archiviazione che non è necessario indicizzare.

Inoltre, puoi attivare la compressione, ma questo migliorerà solo quando i tuoi "documenti" sono grandi, il che probabilmente non è vero per le voci del file di registro.

Ci sono alcuni confronti e suggerimenti utili qui: https://github.com/jordansissel/experiments/tree/master/elasticsearch/disk

Ma ricorda: la ricerca ha un costo. Il costo da pagare è lo spazio su disco. Ma ottieni flessibilità. Se le dimensioni dello spazio di archiviazione superano, aumenta in senso orizzontale! Qui vince ElasticSearch.

— mailq
fonte