Elasticsearch belegt viel zu viel Speicherplatz

Ich habe einen CentOS 6.5- Server, auf dem ich Elasticsearch 1.3.2 installiert habe .

Meine elasticsearch.ymlKonfigurationsdatei ist eine minimale Änderung derjenigen, die standardmäßig mit elasticsearch ausgeliefert wird. Sobald alle kommentierten Zeilen entfernt wurden, sieht es so aus:

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 sollte Kompression ON standardmäßig , und ich las das Verdichtungsverhältnis von so niedrig wie 50% so hoch wie 95% verschiedene Benchmarks setzen. Leider beträgt die Komprimierungsrate in meinem Fall -400%, oder mit anderen Worten: Mit ES gespeicherte Daten belegen viermal mehr Speicherplatz als die Textdatei mit demselben Inhalt . Sehen:

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!

gegen:

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

Was mache ich falsch? Warum werden Daten nicht komprimiert?

Ich habe vorläufig index.store.compress.stored: 1zu meiner Konfigurationsdatei hinzugefügt , da ich dies in den elasticsearch 0.19.5Versionshinweisen festgestellt habe (da kam die storeKomprimierung zuerst heraus), aber ich bin noch nicht in der Lage zu erkennen, ob sie einen Unterschied macht, und trotzdem sollte die Komprimierung auf EIN gesetzt sein Standard heutzutage ...

elasticsearch disk-space-utilization lucene

— Mac
quelle

Haben Sie jemals über den Aufwand nachgedacht, der erforderlich ist, um diese Daten zu speichern und zu indizieren? Hier liegt der Unterschied.

— mailq

@mailq - AFAIK, Elastic komprimiert sowohl Daten als auch Indizes. Im Vergleich zu Textprotokollen sollten Sie dennoch einen Rückgang des Speicherplatzbedarfs auf Ihrer Festplatte feststellen . Ich gehe davon aus, dass der Kilometerstand je nach Protokollstruktur variieren kann, die Protokolle jedoch in der Regel sehr sich wiederholend sind. Daher sollte die Indizierung nicht die platzaufwendigste aller Vorgänge sein. ... oder verstehe ich das falsch?

— Mac

Protokolle wiederholen sich nicht wirklich. Benutzer A meldet sich zur Zeit an 1. Benutzer B meldet sich zur Zeit an 2. Was ist wiederholend? Beide Tupel müssen indiziert und getrennt gespeichert werden. Neben dem Protokolleintrag selbst.

— mailq

Versuchen Sie diese Empfehlungen. github.com/jordansissel/experiments/tree/master/elasticsearch/…

— mailq

@mailq - Supercool maliq, vielen Dank. Wenn Sie Ihren Kommentar erweitern und eine richtige Antwort schreiben, würde ich ihn gerne als akzeptiert markieren (ansonsten werde ich es später tun, aber ich möchte Ihren Donner nicht stehlen!).

— Mac

Elasticsearch verkleinert Ihre Daten nicht automatisch. Dies gilt für jede Datenbank. Neben der Speicherung der Rohdaten muss jede Datenbank auch Metadaten speichern. Normale Datenbanken speichern nur einen Index (für eine schnellere Suche) für die Spalten, die der Datenbankadministrator im Voraus ausgewählt hat. ElasticSearch ist anders, da standardmäßig jede Spalte indiziert wird . Dadurch wird der Index extrem groß, bietet aber andererseits eine perfekte Leistung beim Abrufen von Daten.

In normalen Konfigurationen sehen Sie nach der Indizierung eine 4- bis 6-fache Zunahme der Rohdaten. Obwohl es stark von den tatsächlichen Daten abhängt. Aber das ist eigentlich beabsichtigtes Verhalten.

Um die Datenbankgröße zu verringern, müssen Sie wie in RDBMs umgekehrt vorgehen: Schließen Sie Spalten von der Indizierung oder Speicherung aus, die Sie nicht indizieren müssen.

Außerdem können Sie die Komprimierung aktivieren, was sich jedoch nur verbessert, wenn Ihre "Dokumente" groß sind. Dies gilt wahrscheinlich nicht für Protokolldateieinträge.

Hier finden Sie einige Vergleiche und nützliche Tipps: https://github.com/jordansissel/experiments/tree/master/elasticsearch/disk

Aber denken Sie daran: Suchen ist mit Kosten verbunden. Die zu zahlenden Kosten sind der Speicherplatz. Sie gewinnen aber Flexibilität. Wenn Ihre Speichergröße übersteigt, wachsen Sie horizontal! Hier gewinnt ElasticSearch.

— mailq
quelle