Elasticsearch utilise beaucoup trop d'espace disque

J'ai un serveur CentOS 6.5 sur lequel j'ai installé Elasticsearch 1.3.2 .

Mon elasticsearch.ymlfichier de configuration est une modification minimale de celui livré avec elasticsearch par défaut. Une fois débarrassé de toutes les lignes commentées, il ressemble à:

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 devrait avoir la compression activée par défaut , et j'ai lu divers points de repère plaçant le taux de compression d'aussi bas que 50% à 95%. Malheureusement, le taux de compression dans mon cas est de -400%, ou en d'autres termes: les données stockées avec ES prennent 4 fois plus d'espace disque que le fichier texte avec le même contenu . Voir:

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!

contre:

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

Qu'est-ce que je fais mal? Pourquoi les données ne sont-elles pas compressées?

J'ai provisoirement ajouté index.store.compress.stored: 1à mon fichier de configuration, comme je l'ai trouvé dans les elasticsearch 0.19.5notes de version (c'est à ce moment que la storecompression est sortie en premier), mais je ne suis pas encore en mesure de dire si cela fait une différence, et de toute façon la compression devrait être activée par par défaut, de nos jours ...

elasticsearch disk-space-utilization lucene

— Mac
source

Avez-vous déjà considéré les frais généraux nécessaires pour stocker et indexer ces données? C'est de là que vient la différence.

— mailq

@mailq - AFAIK, Elastic compresse à la fois les données et les index, et vous devriez toujours remarquer une diminution de l'utilisation de l'espace sur votre disque, par rapport aux journaux de texte. Je suppose que le kilométrage peut varier selon la structure du journal, mais les journaux sont généralement de nature très répétitive, donc l'indexation ne devrait pas être la plus consommatrice d'espace. ... ou je me trompe?

— mac

Les journaux ne sont pas vraiment répétitifs. L'utilisateur A se connecte à l'heure 1. L'utilisateur B se connecte à l'heure 2. Qu'est-ce qui est répétitif? Les deux tuples doivent être indexés et stockés séparément. En plus de l'entrée de journal elle-même.

— mailq

Essayez ces recommandations. github.com/jordansissel/experiments/tree/master/elasticsearch/…

— mailq

@mailq - Supercool maliq, merci beaucoup. Si vous développez votre commentaire et écrivez une bonne réponse, je serais heureux de le marquer comme accepté (sinon je le ferai plus tard, mais je ne veux pas voler votre tonnerre!).

— mac

Elasticsearch ne réduit pas automatiquement vos données. Cela est vrai pour n'importe quelle base de données. Outre le stockage des données brutes, chaque base de données doit stocker des métadonnées avec elle. Les bases de données normales stockent uniquement un index (pour une recherche plus rapide) pour les colonnes choisies par db-admin. ElasticSearch est différent car il indexe chaque colonne par défaut. Ce qui rend l'indice extrêmement grand, mais donne en revanche des performances parfaites lors de la récupération des données.

Dans les configurations normales, vous voyez une augmentation de 4 à 6 fois des données brutes après l'indexation. Bien que cela dépende fortement des données réelles. Mais c'est en fait un comportement voulu.

Donc, pour diminuer la taille de la base de données, vous devez faire l'inverse comme vous l'avez fait dans les RDBM: exclure les colonnes de l'indexation ou du stockage que vous n'avez pas besoin d'indexer.

De plus, vous pouvez activer la compression, mais cela ne s'améliorera que lorsque vos "documents" sont volumineux, ce qui n'est probablement pas vrai pour les entrées de fichier journal.

Il existe des comparaisons et des conseils utiles ici: https://github.com/jordansissel/experiments/tree/master/elasticsearch/disk

Mais rappelez-vous: la recherche a un coût. Le coût à payer est l'espace disque. Mais vous gagnez en flexibilité. Si la taille de votre stockage dépasse, alors grandissez horizontalement! C'est là que ElasticSearch gagne.

— mailq
source