Słów kilka o optymalizacji

Pracjąc z elasticsearch nie sposób jest ominąć tematu optymalizacji shardów. Prędzej czy później każdy użytkownik bardziej rozbudowanego systemu będzie musiał podjąć się tego tematu. Niezoptymalizowane środowisko elasticsearch może skutkować powolnym indeksowanie danych, zwracaniem odpowiedzi, a nawet niestabilnym działaniem całego środowiska.

Im szybciej zrozumiemy skąd ten problem się bierze i im szybciej go zaadresujemy tym lepiej. Planowanie polityk shardów elasticsearch jest niezbędne aby zapewnić długotrwałe i stabilne działanie clustra. Warto też pamiętać, że shardy są niczym innym jak silnikiem Lucene, na bazie którego elasticsearch powstał.

 

Czym jest shard?

Index składa się z shardów i dzielimy je na primary i replica. Każdy shard trzyma jakąś część danych zgromadzonych w indexie, więc zbiór shardów primary w indexie będzie działał jak RAID 0. Dodatkowo każdy shard primary może mieć swoją replikę 1:1. Gwarantuje to dostępność danych w przypadku awarii clustra. Jeśli któryś shard primary przestanie być dostępny, jego replika go zastępuje.

 

Dyski

Często zdarza się, że środowiska elasticsearch, które odbierają dane nie są poprawnie zarządzane pod względem przestrzeni. Oznacza to, że dane wpuszczone do środowiska tam zostają na długi czas, niejako zapomniane. Indeksowanie dużej ilości danych bez odpowiedniego zarządzania szybko może pochłonąć nawet ogromne zasoby dyskowe. Powodem tego jest fakt, że repliki są kopiami 1:1 shardów primary.

Trzymając index (np. 100GB) z 4 shardów i każdy z nich ma swoje trzy repliki oznacza, że w mamy w sumie 15 shardów (4 primary + 12 replik) i 400 GB danych. Nietrudno zauważyć jak nieuwaga może doprowadzić do szybkiego zapełnienia dysku w takim scenariuszu.

Optymalizacja polega na kategoryzowaniu danych i przypisywaniu im odpowiedniej ilości shardów oraz replik. Oczywiście, każda replika zabrana oznacza większa podatność na permanentną utratę danych w przypadku awarii. Wiadome jest jednak, że nie każdy index jest krytyczny i dla tych o mniejszym priorytecie warto rozważyć jakiej ilości replik wymagają.

 

Pamięć

Elasticsearch jest oprogramowaniem stworzonym w java. Przypisany heap jest więc kluczowy dla poprawnego działania środowiska. Niepoprawne zaplanowanie zasobów pamięci serwera może przyczynić się do poważnej awarii wynikającej z braku dostępnej pamięci.

Jak ocenić ile pamięci węzeł elasticsearch wymaga? To zależy od wielkości clustra i ilości danych, które gromadzimy. Elasticsearch przetrzymuje dużo danych w pamięci, celem szybkiego dostępu. Rekomendowane jest, by węzeł elasticsearch nie posiadał więcej niż 25 shardów (primary jak i replik) na 1 GB pamięci w heap. Warto zaznaczyć, że elasticsearch nie jest w stanie tego limitować za nas. Jest to jedna z fundamentalnych czynności administratora, aby monitorować ilość shardów per pamięć heap.

 

Performance

Jeśli chodzi o optymalizację zapytań, tuta żadną wiedzą tajemną nie jest fakt, że głównym elementem jest struktura zapytania i zakres danych, na których te zapytanie jest wyzwolone. Innymi słowy: szybciej zwrócona zostanie odpowiedź z danych o wielkości 100GB niż z danych o wielkości 500GB.

Im bardziej skomplikowane zapytanie i na większej ilości danych zostanie uruchomione tym później otrzymamy odpowiedź. Dlatego ważne jest wyrównanie zależności pomiędzy ilością shardów, a ich rozmiarem.

Rekomendowane jest, by jeden shard zawierał pomiędzy 20GB a 40GB danych. Dlatego jeśli mamy index o wielkości 100GB danych, warto przydzielić mu sumarycznie 4 shardy primary. Repliki nie są wliczane do tego zabiegu optymalizacji, jako że trzymają one kopie danych 1:1 shardów primary.

 

Podsumowanie

Powyższe aspekty pokazują, że chociaż elasticsearch jest potężnym narzędziem i jednym z najlepszych silników do zarządzania dużą ilością danych, to wciąż wymaga dokładnej uwagi pod względem optymalizacji. Dobre zaplanowanie struktury indexów i shardów pozwoli cieszyć się stabilnym i bardzo wydajnym środowiskiem clustra.