web-dev-qa-db-fra.com

Elasticsearch utilise beaucoup trop d'espace disque

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

Ma elasticsearch.yml le fichier 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 compression ON 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

Que fais-je de mal? Pourquoi les données ne sont-elles pas compressées?

J'ai ajouté provisoirement index.store.compress.stored: 1 à mon fichier de configuration, car j'ai trouvé que dans le elasticsearch 0.19.5 notes de version (c'est à ce moment que la compression store 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 défaut de nos jours. ..

elasticsearchdisk-space-utilizationlucene
12
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 n'oubliez pas: 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.

17
mailq