Elasticsearch wykorzystuje zdecydowanie za dużo miejsca na dysku

Mam serwer CentOS 6.5 , na którym zainstalowałem Elasticsearch 1.3.2 .

Mój elasticsearch.ymlplik konfiguracyjny jest minimalną modyfikacją tej, która jest domyślnie dostarczana z elasticsearch. Po usunięciu wszystkich skomentowanych linii wygląda następująco:

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 powinien mieć kompresji ON domyślnie , i czytałem różne standardy stawianie współczynnik kompresji już od 50% do nawet 95%. Niestety, stopień kompresji w moim przypadku wynosi -400%, innymi słowy: dane przechowywane w ES zajmują 4 razy więcej miejsca na dysku niż plik tekstowy o tej samej zawartości . Widzieć:

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!

przeciw:

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

Co ja robię źle? Dlaczego dane nie są kompresowane?

Tymczasowo dodałem index.store.compress.stored: 1do mojego pliku konfiguracyjnego, ponieważ stwierdziłem, że w informacjach o elasticsearch 0.19.5wydaniu (to jest, kiedy storekompresja wyszła jako pierwsza), ale nie jestem jeszcze w stanie stwierdzić, czy to robi różnicę, a kompresja powinna być włączona przez domyślnie, obecnie ...

elasticsearch disk-space-utilization lucene

— prochowiec
źródło

Czy zastanawiałeś się kiedyś nad tym, ile potrzeba do przechowywania i indeksowania tych danych? To stąd pochodzi różnica.

— mailq

@mailq - AFAIK, Elastic kompresuje zarówno dane, jak i indeksy, i nadal powinieneś zauważyć zmniejszenie zużycia miejsca na dysku, w porównaniu do dzienników tekstowych. Zakładam, że przebieg może się różnić w zależności od struktury kłód, ale kłody są zazwyczaj bardzo powtarzalne, więc indeksowanie nie powinno zajmować najwięcej miejsca. ... czy mylę się?

— Mac

Dzienniki nie są tak naprawdę powtarzalne. Użytkownik A loguje się w czasie 1. Użytkownik B loguje się w czasie 2. Co jest powtarzalne? Obie krotki muszą być indeksowane i przechowywane osobno. Oprócz samego wpisu dziennika.

— mailq

Wypróbuj te rekomendacje. github.com/jordansissel/experiments/tree/master/elasticsearch/…

— mailq

@mailq - Supercool maliq, dziękuję za tonę. Jeśli rozwiniesz swój komentarz i napiszesz poprawną odpowiedź, chętnie oznaczę go jako zaakceptowany (inaczej zrobię to później, ale nie chcę kraść twojego gromu!).

— Mac

Elasticsearch nie zmniejsza danych automatycznie. Dotyczy to każdej bazy danych. Oprócz przechowywania surowych danych, każda baza danych musi przechowywać metadane wraz z nimi. Normalne bazy danych przechowują tylko indeks (dla szybszego wyszukiwania) dla kolumn, które db-admin wybrał z góry. ElasticSearch jest inny, ponieważ domyślnie indeksuje każdą kolumnę. Dzięki temu indeks jest wyjątkowo duży, ale z drugiej strony zapewnia doskonałą wydajność podczas pobierania danych.

W normalnych konfiguracjach po indeksowaniu widoczny jest wzrost od 4 do 6 razy surowych danych. Chociaż w dużej mierze zależy to od rzeczywistych danych. Ale tak naprawdę jest to zamierzone zachowanie.

Aby zmniejszyć rozmiar bazy danych, musisz przejść na drugą stronę, tak jak w RDBM: Wyklucz kolumny z indeksowania lub przechowywania, które nie muszą być indeksowane.

Dodatkowo możesz włączyć kompresję, ale poprawi się to tylko wtedy, gdy twoje „dokumenty” będą duże, co prawdopodobnie nie jest prawdą w przypadku wpisów do pliku dziennika.

Istnieje kilka porównań i przydatnych wskazówek tutaj: https://github.com/jordansissel/experiments/tree/master/elasticsearch/disk

Pamiętaj jednak: Wyszukiwanie wiąże się z pewnymi kosztami. Kosztem zapłaty jest miejsce na dysku. Ale zyskujesz elastyczność. Jeśli Twój rozmiar pamięci przekracza, zwiększ poziomo! To tutaj wygrywa ElasticSearch.

— mailq
źródło