Elasticsearch использует слишком много дискового пространства

12

У меня есть сервер CentOS 6.5, на котором я установил Elasticsearch 1.3.2 .

Мой elasticsearch.ymlконфигурационный файл является минимальной модификацией одного файла с эластичным поиском по умолчанию. После удаления всех закомментированных строк это выглядит так:

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 должны иметь сжатия ПО по умолчанию , и я прочитал различные тесты положить степень сжатия от самого низкого до 50% выше , чем 95%. К сожалению, степень сжатия в моем случае составляет -400%, или, другими словами: данные, хранящиеся в ES, занимают в 4 раза больше места на диске, чем текстовый файл с тем же содержимым . Видеть:

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!

против:

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

Что я делаю неправильно? Почему данные не сжимаются?

Я временно добавил index.store.compress.stored: 1к своему файлу конфигурации, как я обнаружил в elasticsearch 0.19.5примечаниях к выпуску (именно тогда storeкомпрессия вышла первой), но я пока не могу сказать, если это имеет значение, и в любом случае сжатие должно быть включено по умолчанию, в настоящее время ...

elasticsearch disk-space-utilization lucene макинтош
источник
Вы когда-нибудь задумывались о том, какие дополнительные затраты необходимы для хранения и индексации этих данных? Вот откуда разница.
mailq
@mailq - AFAIK, Elastic сжимает как данные, так и индексы, и вы все равно должны заметить уменьшение использования дискового пространства по сравнению с текстовыми журналами. Я предполагаю, что пробег может варьироваться в зависимости от структуры журналов, но журналы, как правило, очень повторяющиеся по своей природе, поэтому индексация не должна занимать больше места из операций. ... или я ошибаюсь?
Mac
Логи на самом деле не повторяются. Пользователь A входит в систему во время 1. Пользователь B входит в систему во время 2. Что повторяется? Оба кортежа должны быть проиндексированы и храниться отдельно. В дополнение к самой записи в журнале.
mailq
1
Попробуйте эти рекомендации. github.com/jordansissel/experiments/tree/master/elasticsearch/...
mailq
@mailq - Supercool maliq, огромное спасибо. Если вы расширите свой комментарий и напишите правильный ответ, я буду рад пометить его как принятый (в противном случае я сделаю это позже, но не хочу воровать ваш гром!).
Mac

Ответы:

17

Elasticsearch не сокращает ваши данные автоматически. Это верно для любой базы данных. Помимо хранения необработанных данных, каждая база данных должна хранить метаданные вместе с ней. Обычные базы данных хранят только индекс (для более быстрого поиска) для столбцов, которые db-admin выбрал заранее. ElasticSearch отличается тем, что индексирует каждый столбец по умолчанию. Таким образом, индекс становится чрезвычайно большим, но, с другой стороны, обеспечивает отличную производительность при получении данных.

В обычных конфигурациях вы видите увеличение от 4 до 6 раз необработанных данных после индексации. Хотя это сильно зависит от реальных данных. Но это на самом деле намеренное поведение.

Таким образом, чтобы уменьшить размер базы данных, вы должны пойти другим путем, как в RDBM: исключить столбцы из индексации или хранения, которые вам не нужно индексировать.

Кроме того, вы можете включить сжатие, но это улучшится только тогда, когда ваши «документы» будут большими, что, вероятно, неверно для записей в файле журнала.

Здесь есть несколько сравнений и полезных советов: https://github.com/jordansissel/experiment/tree/master/elasticsearch/disk

Но помните: поиск обходится дорого. Стоимость, которую нужно заплатить, это место на диске. Но вы получаете гибкость. Если ваш объем хранилища превышает, то растите горизонтально! Вот где ElasticSearch побеждает.

mailq
источник