Posty oznaczone etykietą fts

ElasticSearch 6 - na dobrej drodze

Wersja 6

Wersja 6.0 ElasticSearch jest dla mnie szczególna - twórcy wprowadzają zmiany ułatwiające zarządzanie, ale też rezygnują z dawnych błędów, które krytykowałem na łamach tego bloga.

Każdemu polecam migrację do wersji 6.x. Służę pomocą w migracji z wersji 2.x oraz 5.x.

Aktualizacje ElasticSearch - jak wykonać?

Nie można zaprzeczyć, że ElasticSearch jest rozwijany dynamicznie. Tak szybki rozwój produktu nie zawsze jest oczekiwany, bo albo wdrożenie zostaje (z przyczyn obiektywnych) oparte o zamrożoną (i nie wspieraną) wersję, albo konieczne staje się przeprowadzanie migracji do nowszych wersji. Takie operacje trzeba zaplanować, zabudżetować, a na dodatek nie obejdzie się bez downtime i sukcesem jest, gdy przerwa techniczna jest relatywnie krótka.

Przypomnę w tym miejscu daty końca wsparcia poszczególnych wersji ElasticSearch:

Elasticsearch EOL Date Maintained Until
2.0.x 2017-04-28 2.1.0
2.1.x 2017-05-24 2.2.0
2.2.x 2017-08-02 2.3.0
2.3.x 2017-09-30 2.4.0
2.4.x 2018-02-28 6.0.0
5.0.x 2018-04-26 5.1.0
5.1.x 2018-06-08 5.2.0
5.2.x 2018-07-31 5.3.0
5.3.x 2018-09-28 5.4.0
5.4.x 2018-11-04 5.5.0
5.5.x 2019-01-06 5.6.0
5.6.x 2019-03-11 7.0.0
6.0.x 2019-05-14 6.1.0
6.1.x 2019-06-13 6.2.0
6.2.x 2019-08-06 6.3.0
6.3.x 2019-12-13 6.4.0
6.4.x 2020-02-23 6.5.0
6.5.x 2020-05-14 6.6.0
6.6.x 2020-07-29 6.7.0
6.7.x 2020-09-26 8.0.0
7.0.x 2020-10-10 7.1.0

Przygotowując się do jakichkolwiek operacji powinno się opracować procedurę, z którą należy zapoznać wszystkich zainteresowanych, opracować procedurę odwrotną, tj. wycofującą zmiany w razie nieprzewidzianych problemów, albo oznaczyć jasno punkty po realizacji których nie ma już odwrotu.

W przypadku ElasticSearch procedura jest o tyle bezpieczna, że ryzyko utraty danych jest stosunkowo niewielkie i ogranicza się do przypadku utraty danych z kartoteki wtórnej (zazwyczaj bazy danych RDBMS systemu OLTP), co ma miejsce niezwykle rzadko ale jest możliwe (a jak coś jest możliwe, to zazwyczaj dzieje się w najgorszym momencie).

Czy można śmiało aktualizować ElasticSearch? Tak, ale pod warunkiem, że został zapewniony backup danych lub środowiska. Największym problemem jest downtime, czyli czas braku usługi, który będzie skutkował wyłączeniem bądź dysfunkcją aplikacji web.

A czy warto aktualizować? Tak!

Aktualizacja od 5.x

Producent zapewnia, że aktualizacja od wersji 5.6.3 nie wymaga downtime. Zachowanie kompatybilności wstecznej na poziomie fizycznym jest ogromnym plusem tego wydania.

Wyjątkiem jest użycie X-Pack Security bez SSL/TLS, co wymaga przekonfigurowania węzłów (włączenia SSL/TLS) i restartu całego klastra. Pomijam przypadki, gdzie w stacku używana jest np. Kibana i najlepiej użyć jest asystenta migracji.

Etapy migracji warto zatem podzielić na: - migrację 2.x do 5 - migrację 5.x do 5.6.3 - migrację 5.6.3 do 6.x

Koniec z mappingami

Nie mogę powiedzieć, że to mój osobisty sukces, ale wersja 6.0 wycofuje tzw. mappingi, czyli grupowanie atrybutów w bliżej nieokreślonym celu. O bezsensie mappingów pisałem szerzej we wpisie z 2016 roku.

Dzięki temu posunięciu indeksy są w końcu takie, jakie powinny być. Tworzenie bibliotek klienckich też staje się o prostsze (dokładnie o jedną warstwę), gdyż struktura indeksu nie musi być opisywana wieloma mappingami. Wydajność takich indeksów staje się lepsza, a zarządzanie nimi - prostsze.

ElasticSearch 6.x zachowuje kompatybilność pozostawiając obsługę mappingów w starych indeksach, sam ogranicza tworzenie dokładnie jednego mappingu do indeksu, aż w wersji 7.0 mappingi zostaną kompletnie usunięte (z wyjątkami w 9.0).

Twórcy ElasticSearch argumentują zmiany takimi słowami:

In the early days of Elasticsearch, we spoke about an “index” being similar to a “database” in an SQL database, and a “type” being equivalent to a “table”. This was a bad analogy that led to incorrect assumptions. In an SQL database, tables are independent of each other. The columns in one table have no bearing on columns with the same name in another table. This is not the case for fields in a mapping type.

Tak. Ta analogia była po prostu głupia.

In an Elasticsearch index, fields that have the same name in different mapping types are backed by the same Lucene field internally. In other words, using the example above, the user_name field in the user type is stored in exactly the same field as the user_name field in the tweet type, and both user_name fields must have the same mapping (definition) in both types.

I dokładnie to krytykowałem w moim poprzednim wpisie.

Cieszę się, że twórcy ElasticSearch w końcu to dostrzegli. Czekam, aż przyjmą do wiadomości, że ich API HTTP/JSON nie jest RESTful :)

Co nowego w ElasticSearch 6.0?

Wersja 6.0, oprócz pierwszych kroków do usunięcia naprawdę głupich mappingów, poprawia wydajność wyszukiwania, szczególnie skracając czasy wyszukiwania posortowanych zbiorów, ale też usprawnia w wyszukiwanie rozproszone oraz bezpieczeństwo.

To pierwsza wersja ElasticSearch, do której gorąco namawiam obecnych i potencjalnych klientów. Zainteresowanych proszę o kontakt przez stronę firmową lub telefonicznie +48326100016.