Czym jest elasticsearch?
Sam elastisearch reklamuje się tym sloganem:
You know, for search (and analysis)
I generalnie tak jest, gdy myślę o szukaniu danych (wydajnym) to na myśl przychodzi mi właśnie Elasticsearch. Ale czekaj, bo to nie tylko szukanie – to znaczy i tak i nie, bo Elastic to coś więcej niż search, jest tam także Kibana, która ułatwia przeglądanie tego co mamy w bazie czy Logstash do wrzucania logów do tejże bazy.
Ja, póki co skupiam się na Elasticsearch jako silniku do szukania, oprócz szukania potrafi też podać dodatkowe informacje dotyczące wyników; agregacje, statystyki, czy wyniki bliskie do tych, które są dla nas interesujące.
Jak Elasticsearch widzi dane
To jest piękne, bo w zasadzie dla prostych szukań nie trzeba nic robić, bierze taki jeden żejsona, wpycha do bazy danych i można szukać. Poważnie – to tak proste. Silnik samodzielnie będzie w stanie rozponać podstawowy typy danych; number (int oraz float), string, date, bool czy dane binarne (są też inne)
pimp up elastic
Jeśli chcesz odpicować swoje struktury i wyniki to możesz to zrobić, możesz opisać swój indeks; w Elasticsearch baza danych nazywa się indeksem, i zdefiniować jakiego rodzaju będą poszczególne pola, czy też będą dynamiczne i wyliczane w locie. Jest tego masa, oraz możesz tworzyć własne skomplikowane typy.
Lista wbudowanych dostępna jest tutaj: https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-types.html
Mapowanie możesz wykonać dynamiczne — niczym się nie martwisz, albo explicit. Ja będę korzystać tego drugiego, wydaje mi się, że wiem czego chce, a przynajmniej wiem, co chce osiągnąć, dlatego w Proficiento sam będę definiować swój indeks. O tym później.
Co potrafi znaleźć Elasticsearch
Jest moc, bo oprócz szukania pełnych słów, szuka także cząstek, podobieństwa czy prefiksów — które tak doskonale znany z autokomplita.
Dokumentacja chwiali się także dobrym wsparciem dla geospatial — ale to musisz sobie sam sprawdzić, to nie mój target.
Dla mnie ważne jest szybkość i trafność działa oraz możliwość konfiguracji porównywania tekstu;
Mam część materiałów w języku polskim i chciałbym, aby “szczescie“, “szczęscie“, “szczeście“, “szczęście” (czy jak to jeszcze napiszą) znalazło “szczęście“, a jednocześnie, żebym ja nie musiał kaleczyć danych i robić, obejść w kodzie na dziwne przypadki.
Meta informacje
Tak jak pisałem wyżej, meta informajce są bardzo przydatne, a jednocześnie, o ile rozumie dokumentacje w zasadzie za darmo, lub prawie za darmo, także spoko cena 🧅
Co na myśli o meta? Otóż mnie przydadzą się grupy (w Elasticsearch to są `facets` gdzie indziej buckets
) – to znaczy informacje: ile danych jest w wynikach, tak aby można to wyświetlić na ekranie. Np. gdy użytkownik wybierze przedział cenowy 1-100 będzie wiedzieć, że kursów w tej cenie jest 12345, gdy dodatkowo wybierze język polski ta liczba się zmieni, tak aby odpowiadać ilości kursów w cenie i wybranym języku, prosta sprawa i za darmo — biere!.
Więcej
Za dokumentacją, dodatkowe informacje, które można wyciągnąć, albo raczej zamiast szukania tych właściwych: “ile jest igieł w stogu siana” można się dowiedzieć także:
- Ile igieł znajduje się w stogu siana?
- Jaka jest średnia długość tych igieł?
- Jaka jest mediana długości igieł, podzielona według producenta?
- Ile igieł dodano do stogu siana w każdym z ostatnich sześciu miesięcy?
- Którzy producenci igieł są najpopularniejsi?
- Czy występują jakieś niezwykłe lub anomalie skupiska igieł?
Super moc!
No dobra, może przesadziłem z tą darmowością wyszukiwań i agregowaniem danych, ale jest to na tyle szybkie, że nie narzekam.
Czy to się skaluje?
Ło panie, to podstawa! Dodajesz nowe serwery, dodajesz nowy, dodaje się node i robię się autobalans. Do tego dochodzą repliki danych, shardowanie (dzielenie) danych. Z jednej strony im więcej serwerów tym lepiej, a jednak trudniej, bo Elasticsearch będzie musiał danymi żonglować, balansować i rozdzielać według swojego uznania. Są dobre praktyki (sugerowane przez Elasticsearch), które mówią, aby na początek działać tak:
- utrzymywać shardy w rozmiarach kilka – kilkanaścia GB
- spotyka się shardy w rozmiarach 20-40 GB dla danych seryjnych i związanych z czasem
- nie naparzaj dużej ilości shardów, bo będzie piekło
Gdy spadniesz z rowerka
Gdy masz zapasowe serwery, Elasticsearch będzie w stanie sam odnowić swoje dane, trochę jak w RAID na dyskach, ale tutaj także dane muszą wcześniej zostać zduplikowane i być gotowe, aby wejść na scenę całe na biało. Aby to mogło zadziać się szybko, serwery, klustery, shardy muszą się ze sobą szybko komunikować, być blisko, ale nie za blisko.
Jak dla mnie to ta nudna część, nie chce i nie planuje się zagłębiać dalej niż będę musiał.
Panie, ile za to wszystko?
I to jest piękne, bo można na wiele sposobów; można kupić hosting u nich i płacić za usługę, można postawić sobie taką usługę np. w azure, można wziąć sobie serwer, postawić serwer a na nim instację – czy to z dockera (https://jaroslawstadnicki.pl/2024/03/04/elasticsearch-i-docker/), czy to z zipa. Jest w czym wybierać, ustawiać czy płacić tyle ile potrzeba.
Na podstawie dokumentacji dostępnej na stronie:
https://www.elastic.co/guide/en/elasticsearch/reference/current/elasticsearch-intro.html