Elasticsearch to rozproszony silnik wyszukiwania i analityki, przechowujący dane w postaci dokumentów i indeksów odwróconych. Odpowiada na zapytania pełnotekstowe i agregacje w czasie, w którym baza operacyjna dopiero zaczynałaby skanowanie. Decyzja o nim nie dotyczy szybkości samej w sobie — dotyczy tego, ile organizacja płaci za to, że odpowiedź przychodzi za późno.
Na skróty
Czego dowiesz się z artykułu:
- Czym organizacja płaci, gdy odnalezienie faktu w danych trwa dłużej niż decyzja
- Jakie warunki muszą wystąpić razem, żeby osobny silnik był właściwą odpowiedzią
- W jakich sytuacjach osobny silnik nie rozwiązuje realnego problemu
- Jakie alternatywy pozostają i jaką cenę niesie każda z nich
- Co organizacja podpisuje, biorąc na siebie utrzymanie klastra
Dla kogo ten artykuł:
- Architekci rozstrzygający, gdzie mieszka warstwa wyszukiwania i analityki
- Kierownicy utrzymania odpowiedzialni za czas diagnozy awarii
- Menedżerowie planujący budżet infrastruktury, licencji i kompetencji
Czym płaci organizacja, w której odnalezienie faktu trwa dłużej niż podjęcie decyzji?
Rachunek nie zaczyna się od nazwy silnika. Zaczyna się od czasu, który ktoś już traci: dyżurny przeszukuje logi z kilkunastu usług, żeby ustalić, kiedy zaczęła się awaria; analityk czeka na raport, bo zapytanie po tekście blokuje bazę produkcyjną; klient nie znajduje produktu, który jest w katalogu, bo wyszukiwarka porównuje ciągi znaków zamiast znaczeń. Ten koszt jest ponoszony codziennie i nie ma osobnej pozycji w budżecie — ukrywa się w wydłużonym czasie reakcji, w porzuconych koszykach i w nadgodzinach zespołu utrzymania.
Problem ma odmiany, a ich pomylenie jest tu najdroższym błędem. Pierwsza odmiana to wyszukiwanie dla użytkownika: katalog produktów, baza dokumentów, zgłoszenia serwisowe. Liczy się trafność wyniku, odmiana słów, literówki i podpowiedzi, a nie sama prędkość. Druga odmiana to analityka zdarzeń: logi aplikacji, metryki infrastruktury, ślady transakcji i zdarzenia bezpieczeństwa. Liczy się tu wolumen zapisu, retencja i możliwość zadania pytania, którego nikt nie przewidział podczas projektowania schematu. Odpowiedź na obie odmiany bywa ta sama technologicznie, ale wymagania operacyjne — retencja, koszt dysku, tryb pracy klastra — rozchodzą się bardzo szybko.
Obie odmiany widać najostrzej tam, gdzie dane rosną szybciej niż zespół: w handlu z rozbudowanym katalogiem, w platformach usługowych z ruchem całodobowym, w środowiskach rozproszonych, w których ta sama transakcja przechodzi przez wiele usług. Tam brak warstwy wyszukiwania nie kończy się niewygodą, tylko wydłużonym czasem usunięcia awarii i utraconą sprzedażą.
Kiedy osobny silnik wyszukiwania i analityki jest właściwą odpowiedzią?
Osobny silnik jest właściwą odpowiedzią wtedy, gdy występują razem trzy warunki, a nie gdy spełniony jest którykolwiek z nich osobno:
- Zapytania są pełnotekstowe albo eksploracyjne. Pytanie nie brzmi „podaj rekord o tym identyfikatorze”, tylko „znajdź wszystko, co przypomina ten opis” albo „pokaż rozkład tych zdarzeń w czasie”. Indeks odwrócony i agregacje odpowiadają na takie pytania bez skanowania całości.
- Wolumen i tempo napływu przekraczają możliwości bazy operacyjnej. Zapis strumieniowy, retencja liczona w miesiącach i zapytania analityczne obok ruchu produkcyjnego to obciążenia, które w jednej bazie zaczynają ze sobą konkurować.
- Odpowiedź ma przyjść w czasie interakcji. Wynik potrzebny podczas wpisywania frazy albo podczas diagnozy trwającej awarii ma inną wartość niż ten sam wynik po kwadransie.
Dopiero gdy te warunki występują łącznie, sensowna staje się praca po stronie implementacji: projekt mapowania pól, dobór analizatorów językowych, strategia indeksowania i zapytania, które nie przenoszą filtrowania na aplikację. Ten zakres — od modelu dokumentu po wydajne zapytania i integrację z kodem — obejmuje szkolenie Elasticsearch dla programistów.
Kiedy osobnego silnika nie wybierać?
Najczęstszym błędem jest sięgnięcie po osobny silnik w imię wydajności, zanim ktokolwiek zmierzył, gdzie ta wydajność ucieka. Brak indeksu na kolumnie i zapytanie generowane przez warstwę odwzorowania obiektowego kosztują tyle samo, ile kosztowały wcześniej — tyle że teraz w dwóch systemach naraz.
Poza tym są sytuacje, w których silnik nie odpowiada na realny problem. Zapytania są ściśle strukturalne i po kluczu: wtedy baza relacyjna z właściwym indeksem odpowiada szybciej i taniej, a wbudowane wyszukiwanie pełnotekstowe wystarcza do prostych przypadków. Dane są źródłem prawdy dla rozliczeń: silnik przeszukiwania nie jest systemem transakcyjnym, a traktowanie go jako jedynej kopii danych kończy się rozjazdem, którego nikt nie umie odtworzyć. Zespół nie ma kompetencji operacyjnych i nie planuje ich zbudować: klaster bez właściciela nie jest tańszy od bazy — jest droższy o awarię, która przyjdzie w najgorszym momencie. Koszt utopiony w wdrożeniu nie jest argumentem za utrzymaniem żadnej z tych sytuacji. Przegląd klas składowania, wśród których zapada właściwe rozstrzygnięcie, zebrano w tekście o nowoczesnych bazach danych.
Jakie są alternatywy i ile kosztują?
Wyszukiwanie pełnotekstowe wbudowane w bazę relacyjną nie dokłada żadnego systemu do utrzymania i korzysta z kopii zapasowych, które już istnieją; jego ceną jest sufit — przy rosnącym wolumenie i wymaganiach trafności zapytania zaczynają konkurować z ruchem produkcyjnym. Usługa zarządzana zdejmuje z zespołu aktualizacje, kopie i skalowanie, a płaci się za to rachunkiem rosnącym wraz z wolumenem oraz mniejszą swobodą konfiguracji. Otwarte rozwidlenie tej samej rodziny silników zmienia model licencyjny i dostawcę wsparcia, ale nie zmienia kosztu operacyjnego klastra — ten zostaje po stronie organizacji.
Osobną klasą są komercyjne platformy analizy danych maszynowych, rozliczane od wolumenu przyjmowanych zdarzeń. Bywają najszybszą drogą do gotowej analityki bezpieczeństwa i utrzymania, a ich cena rośnie dokładnie z tym, co w takich wdrożeniach rośnie najszybciej — z liczbą zbieranych zdarzeń. Model działania i zakres zastosowań takiej platformy opisuje tekst o Splunku.
Co organizacja podpisuje, biorąc na siebie utrzymanie klastra?
Podpisuje przede wszystkim rachunek, który rośnie z retencją: dane w indeksie zajmują więcej miejsca niż w postaci źródłowej, a każdy dodatkowy miesiąc przechowywania to dysk, pamięć i czas odtwarzania kopii. Podpisuje też cykl aktualizacji — wersje silnika mają swoje okna wsparcia, a migracja indeksów jest planowanym przedsięwzięciem, nie czynnością administracyjną.
Najdroższą pozycją nie jest jednak infrastruktura, tylko kompetencja operacyjna. Klaster bez właściciela działa dobrze do pierwszego przeciążenia, po którym trzeba umieć odczytać stan węzłów, rozłożyć odłamki, zaplanować cykl życia indeksów i odróżnić problem zapytania od problemu maszyny. Zakres tej pracy — administracja, monitorowanie i utrzymanie środowiska — obejmuje szkolenie Zaawansowana administracja, monitorowanie i utrzymanie Elasticsearch. Warto zauważyć, że jest to inny zakres kompetencji niż praca po stronie implementacji, a nie jej trudniejsza wersja: rozstrzyga rola, którą organizacja obsadza, a nie stopień zaawansowania.
FAQ — najczęściej zadawane pytania
Czy silnik wyszukiwania może zastąpić bazę operacyjną?
Nie. Silnik tej klasy jest zoptymalizowany pod odczyt i analizę, a nie pod gwarancje transakcyjne. Właściwym wzorcem jest źródło prawdy w bazie operacyjnej i indeks odbudowywalny z tego źródła. Gdy indeks jest jedyną kopią danych, każda awaria zmienia się w pytanie, którego nikt nie chce usłyszeć: skąd odtworzyć stan.
Usługa zarządzana czy własny klaster?
Rozstrzygnięcie zapada na kosztach ludzi, nie maszyn. Usługa zarządzana jest tańsza dopóty, dopóki organizacja nie ma i nie potrzebuje kompetencji operacyjnych; własny klaster zaczyna się opłacać przy stałym, dużym wolumenie i przy wymaganiach konfiguracyjnych, których usługa nie obsługuje. Rachunek warto policzyć razem z kosztem dyżuru i odtwarzania kopii.
Od czego zacząć ocenę, czy warto wydzielić warstwę wyszukiwania?
Od pomiaru, a nie od wyboru narzędzia. Trzeba wiedzieć, które zapytania są wolne, jaki mają udział w ruchu i czy są strukturalne, czy tekstowe. Jeżeli wolne są zapytania po kluczu, odpowiedzią jest indeks w bazie. Jeżeli wolne są zapytania eksploracyjne po tekście i zdarzeniach, warstwa wyszukiwania zwraca koszt.