Slovník pojmů

Elasticsearch

Elasticsearch hledá a vyhodnocuje data rychle nad připraveným indexem. Obvykle ale není zdrojem pravdy pro objednávky, ceny ani sklad.

Stručná definice

Vyhledávací index vedle hlavní databáze.

Elasticsearch přijímá dokumenty, připravuje je podle mappingu pro konkrétní dotazy a umí kombinovat fulltext, přesné filtry i agregace. V e-shopu to může být hledání produktů, našeptávač, filtry značek a parametrů nebo přehled počtů výsledků.

Není to obecná náhrada relační databáze. Vyhledávací dokument bývá denormalizovaný pohled složený z dat uložených jinde. Při výpadku indexu, zpožděné synchronizaci nebo změně mappingu musí aplikace vědět, která data jsou autoritativní a jak index bezpečně znovu sestavit.

Použití

Kdy vyhledávací index řeší konkrétní problém

Největší přínos má tam, kde databázový dotaz nestačí pro očekávané hledání, filtrování nebo analytiku.

  • fulltextové hledání produktů, kategorií, dokumentů nebo interních záznamů
  • našeptávač a tolerance překlepů podle pravidel konkrétního vyhledávání
  • filtrování katalogu podle značky, parametrů, ceny a dostupnosti
  • facety a agregace, například počty produktů pro jednotlivé filtry
  • prohledávání logů, událostí a provozních dat v téměř reálném čase

Praktický příklad

Katalog s fulltextem, filtry a dostupností

E-shop sestaví pro každý produkt dokument s názvem, popisem, značkou, kategoriemi, parametry, cenou a dostupností. Název a popis jsou textová pole s analyzérem; značka a kódy mají keyword variantu. Dotaz „běžecké boty“ seřadí podle relevance, filtr značky pracuje přes keyword a agregace vrátí počty velikostí.

Změna produktu nejprve proběhne v hlavní databázi. Worker pak podle události vytvoří nový dokument. Když je indexace opožděná, výsledky hledání se mohou lišit od detailu; při vložení do košíku se proto cena a sklad ověřují v autoritativním systému.

Tok dat

Od změny produktu po výsledek vyhledávání

Index je samostatný pohled na data. Spolehlivost závisí na bezpečném předání změny i návrhu dokumentu.

  1. Zdroj pravdy Produkt, cena a sklad se změní v autoritativní databázi; transakce chrání businessový stav.
  2. Předání změny Outbox, fronta nebo import předá událost ProductChanged indexačnímu workeru.
  3. Indexace Worker načte data, vytvoří dokument a podle mappingu jej zapíše do indexu.
  4. Refresh a vyhledávání Po refreshi jsou změny vyhledatelné. Dotaz s filtry a řazením vrátí dokumenty a agregace.
  5. Kontrola stavu Detail produktu nebo nákupní akce případně ověří cenu, dostupnost a oprávnění v autoritativním systému.

Důležité pojmy

Dokument, mapping a dotaz mají odlišnou roli.

Kvalita výsledku začíná datovým modelem a očekáváním uživatele, ne až volbou jedné query.

Index a dokument

Index sdružuje dokumenty podobného účelu. Dokument je JSON pohled určený pro hledání; nemusí mít stejný tvar jako tabulky ani jako odpověď veřejného API.

Mapping: text a keyword

Mapping určuje typ a způsob indexace pole. text se analyzuje pro fulltext, keyword drží přesnou hodnotu pro filtr, řazení či agregaci. Jedno pole proto často potřebuje obě reprezentace.

Analyzér a inverted index

Analyzér text rozdělí a normalizuje do tokenů. Inverted index pak vede od tokenu k dokumentům. Nastavení jazyka, synonym a analyzéru ovlivňuje, co uživatel najde.

Query, filter a agregace

Fulltextová query obvykle počítá relevanci. Filter pracuje s přesnou podmínkou, například značkou nebo dostupností. Agregace spočítá výsledky ve skupinách.

Shard, replika a refresh

Index se dělí na shardy rozložené mezi uzly; repliky podporují čtení a dostupnost. Refresh zpřístupňuje nedávno zapsaná data vyhledávání, ale nepotvrzuje businessovou transakci.

Vztah k podobným pojmům

Vyhledávání, databáze a fronta řeší různé hranice.

Elasticsearch doplňuje aplikaci; nesmí zakrýt, odkud data pocházejí ani kdy jsou skutečně platná.

PostgreSQL
Relační databáze může chránit zdroj pravdy, transakce a constrainty. Elasticsearch nad ní drží vyhledávací pohled.
Fronta zpráv
Oddělí zápis businessové změny od indexace a dovolí dohledat či opakovat selhání.
API
API může index používat pro vyhledávání, ale má jasně popsat limity, stránkování a význam návratových dat.

Výhody a omezení

Rychlé hledání za cenu dalšího datového a provozního toku.

Přínosy

  • fulltext, filtry, relevance a agregace nad jedním vyhledávacím modelem
  • rychlé odpovědi pro katalog a našeptávač bez složitých databázových dotazů
  • škálování hledání přes shardy a repliky

Rizika

  • zpoždění synchronizace vytvoří rozdíl proti zdroji pravdy
  • nevhodný mapping se často opravuje novým indexem a reindexací
  • mnoho shardů, polí nebo analyzovaných dat zvyšuje provozní náklady
  • relevance musí odpovídat úkolu uživatele a měřit se na reálných dotazech

Hranice použití

Nejdříve určit, zda problémem je opravdu vyhledávání.

Elasticsearch dává smysl pro rozsáhlejší katalog, hledání textu s relevancí nebo kombinaci filtrů a agregací. Pro několik přesně indexovaných atributů může být jednodušší dobře navržený SQL dotaz. Rozhodnutí vychází z objemu, očekávané odezvy, typů dotazů a ceny zastaralého výsledku.

Index není vhodné používat jako jediný stav pro objednávku, platbu nebo rezervaci zásoby. Složitější integrace proto potřebuje idempotentní indexaci, dohledání neúspěšných změn a bezpečný postup pro úplnou reindexaci.

Na co myslet

Modelovat data i obnovu indexu před provozem.

Vyhledávání je produktová funkce i samostatná provozní závislost.

  • mapping, analyzéry a dotazy ověřené na skutečných datech a jazycích uživatelů
  • zdroj pravdy, synchronizační tok a chování při zpožděné indexaci
  • idempotentní indexace, evidence chyb a možnost cíleného i úplného reindexu
  • měření latence, chybovosti, velikosti shardů, diskové kapacity a zdraví clusteru
  • omezený přístup k clusteru, ověřený klient a žádné citlivé údaje zbytečně kopírované do dokumentů

Časté otázky

Co Elasticsearch vyřeší a co ne

Je Elasticsearch databáze?

Ukládá dokumenty a má vlastní perzistenci, ale jeho obvyklou rolí je vyhledávací a analytický index. Pro transakční businessová data je nutné vědomě vybrat autoritativní úložiště.

Proč nestačí uložit produkt jako jeden JSON dokument?

Pouhé uložení JSONu nevytvoří fulltext. Mapping a analyzér určují hledání, filtry, řazení i agregace.

Jsou nová data ve vyhledávání okamžitě?

Ne nutně. Elasticsearch zpřístupňuje zápisy po refreshi a zpoždění může vzniknout už předáním změny do indexu.

Nahradí Elasticsearch relační databázi e-shopu?

Ne automaticky. Objednávky, platby, skladové rezervace a jejich pravidla potřebují transakce a constrainty. Index je vhodný pro hledání a odvozený pohled na tato data.

Jak pracuji s e-commerce systémy

Vyhledávání navrhuji spolu s katalogem, cenou a datovým tokem.

U e-shopových aplikací posuzuji, jak se produktová data mění, které filtry lidé skutečně používají a kde musí systém ověřovat aktuální stav.

Zavolejte mi

Zavolám vám následující pracovní den mezi 9:00 a 17:00.

Můžete mi také zavolat rovnou.

+420 605 181 728

Nechte mi telefonní číslo a pošlete žádost o zpětné zavolání.

Odesláním souhlasíte se zpracováním údajů pro vyřízení žádosti.