Doba čtení: 8-10 min

Vítejte u prvního vydání této série o technologii Elasticsearch (a nejenom o ní). Dnešní díl bude spíše teoretický. V těch dalších se už můžete těšit na více kódu a praktických ukázek. Cílem dnešního povídání bude získat základní představu o této technologii, zjistit její výhody a nevýhody. Dále si také vysvětlíme některé důležité pojmy, které nás budou provázet celou sérií.

V článku se dozvíte:

• Co je Elasticsearch?
• Jaké je jeho využití a kdy se naopak nehodí?
• Důležité termíny
• Na co se můžete těšit v příštím dílu?

Co je Elasticsearch?

Open-source, full-text vyhledávací a analytický engine, to vše lze shrnout pod název Elasticsearch (dále jen ES).
ES je založený na knihovně Apache Lucene, která je napsaná v Javě. A proto pro nikoho nebude překvapením, že i samotný engine je postavený na stejném programovacím jazyku. V perzistentní vrstvě jsou data uspořádaná nestrukturovaně. Jedná se tedy o NoSQL databázi. Komunikace s ES probíhá pomocí standardizovaného formátu JSON.

Jaké je jeho využití a kdy se naopak nehodí?

Mezi největší přednost enginu Elasticsearch (dále jen ES) patří zcela určitě rychlost vyhledávání. V této oblasti patří dle našeho názoru k těm nejlepším. Nabízí nám také rozsáhlou škálu technik, které můžeme využít pro práci s daty. K těm nejdůležitějším patří: full-text vyhledávání, filtrování, agregace, a nebo také napovídání a zvýrazňování textu. Nechybí ani podpora multijazyčnosti, která je už v dnešní době u webových aplikací samozřejmostí. Může se stát, že přestane stačit výkon serveru, např. z důvodu většího počtu návštěvníků, jednoduše si můžeme další výkon přidat. ES je k tomu dobře přizpůsobený a veškerou těžkou práci udělá za nás. Horizontální škálovatelnost je tedy další předností.

Pro nastavení serveru, databáze nebo správu dat nám ES přináší rozsáhlé REST API, které se mimo jiné výborně hodí i pro datovou analýzu. Za zmínku zde určitě stojí další nástroje, které nám práci s daty mohou výrazně ulehčit, protože jsou v přehledném grafickém prostředí s intuitivním ovládáním. Dnes asi nejznámější je tzv. ELK Stack (Elasticsearch, Logstash, Kibana and Beats).

V úvodu jsme se dozvěděli, že ES je NoSQL databáze. Oproti jiným databázím tohoto typu je ale silně zaměřená na rychlost a způsob vyhledávání. To je důvod, proč v této oblasti tolik vyniká. Nicméně to s sebou nese i stinné stránky.
Může se zdát, že ES nám řeší jak otázku datového uložiště, tak rychlého dotazování. Bohužel tomu tak není. Ukládání dat, tzv. indexování, je pomalejší oproti jiným typům databází. Navíc mohou nastat problémy při ukládání velkého množství dat. Pokud potřebujeme ukládat denně data např. v jednotkách terabajtů (TB), může se stát, že ES nezpracuje všechna data pořádku a dokonce můžeme v důsledku přetíženosti o některá data přijít.

Pokud chceme ukládat relační data, opět se zde ES moc nehodí. I když jsou způsoby, jak se tomuto přístupu přiblížit (vazby Parent-Child, Nested vazby), taková modelace struktury dat může být někdy velmi složitá. Z naší zkušenosti je nejlepší kombinace obou přístupů tzn. např. PostgreSQL nebo MongoDB pro perzistenci dat + ES pro vyhledávání. Ještě zde zmíním strměnjší učící křivku. ES je opravdu mocný nástroj, ale zároveň poměrně časově náročný, než se naučíte správně modelovat data, využít správné techniky a nastavení, abyste dosáhli plného potenciálu, který tento engine má.

Důležité termíny

Ještě předtím, než si ES stáhneme a začneme jej používat, je nezbytné si přiblížit několik klíčových pojmů, které musíme znát pro správné nastavení ES a modelaci dat.

Termíný jsou seřazeny chronologicky, od těch nejmenších prvků až po větší celky. Celý systém si tedy takto postupně vyskládáme.

Pole

Nejmenší prvek obsahující konkrétní data v celém systému. Např. autor, titulek, auto, atd. Každé pole má svůj datový typ, který omezuje obsah, který lze do něj uložit a taky záměr, jakým bude pole využíváno. Např. string povoluje ukládání pouze textových hodnot. V ES není přímo tento datový typ, ale dělí se dále na text, pakliže budeme chtít pole využít pro full-text search, nebo keyword, který se hodí hlavně pro filtrování nebo řazení. Dále můžeme ukládat celé JSON objekty nebo dokonce mezi nimi mít určitý vztah, podobně jako v relačních databázích. Za zmínku zde stojí datový typy: object, nested a join. Samozřejmě ES dále podporuje číselné typy, datumy aj. Kompletní přehled všech naleznete zde: Field data types.

Multi-Pole

Nejedná se o jiný typ polí (viz výše), ale spíše o jejich modifikátory. Často je potřeba, aby jedno pole, řekněme opět typu string, mohlo být využíto někdy jako text a někdy jako keyword. A přesně to nám multi-pole nabízejí. Samozřejmě bychom mohli mít i pole dvě, na každý záměr jedno, ale takový způsob není úplně dobrá praxe.

Metadata-Pole

Poslední typ polí se nazývají metadata-pole. Ty už jsou v ES předdefinované a systém je naplňuje automaticky. Taková data se nám hodí, když potřebujeme zjistit obecné informace jako název indexu, počet dokumentů v něm atd. Nejznámější jsou: _id, _type, _index nebo _source.

Dokument

Dokumenty jsou JSON objekty, které jsou uloženy v ES indexu. Ve světě relačních databází odpovídá jeden dokument jednomu řádku v tabulce. Příkladem může být produkt, objednávka a další. Dokument je tedy logické uspořádání dat, které spolu nějaký způsobem souvisí. Ukázka, jak může vypadat dokument uložený v indexu, v JSON formátu:

{
   "_id": 1,                            // id dokumentu       |
   "_type": ["doc"],                    // typ dokuemntu      | --> Metadata pole
   "_index": ["produkt"],               // název indexu       |
   "_source": {                         // uložená data
       "name": "ESPRIT Brýle 2021",
       "tags": [
          "2021", 
          "new collection", 
          "blue"
       ],
       "price": 5600
  }
}

Mapování

Mapování neboli mapping je předpis, který nám říká, jak má vypadat struktura dokumentů, které budou ukládány do indexu. Strukturou myslíme názvy polí a jejich datové typy, popř. další modifikátory pro tyto pole (viz multi-pole výše). Mapování může vypadat např. takto:

{
"mappings": {
      "document_type_name": {
         "properties": {
            "name": {
               "type": "string"
            },
            "tags": {
               "type": "keyword"
            },
            „price“: {
               "type": "double"
            },
         }
      }
   }
}

Typy mapování

V předchozím příkladu si můžeme všimnout pole document_type_name. Ten definuje navíc typ mapování, jehož název si můžeme zvolit. Takových typů je možno nadefinovat pro jeden index více a je lze tedy chápat jako jednotlivé tabulky v databázi. V každé takové klasifikaci dat můžeme definovat různá pole s různými datovými typy. Název dané klasifikace nalezneme také v každém dokumentu pod identifikátorem _type, který již jsme viděli v předchozích příkladech. Můžeme ho použít při filtrování na konkrétním indexu, kde můžeme specifikovat, který typ dat přesně hledáme.

Ačkoliv mohou být typy mapování na jednu stranu přínosné, postupem času se ukázaly s tím spojené problémy. Například, když máme ve dvou různých mapováních pole se stejným názvem, tyto pole musí mít (z interních důvodů) stejný datový typ, ačkoliv jsme před chvíli zmiňovali, že každé mapování může mít datové typy odlišné. Z tohoto důvodu a pár dalších (více se můžete dočíst v tomto článku) se vývojáři rozhodli, že typy mapování odstraní, a tedy mějte na paměti, že od ES verze 7.0.0 jde o zastaralou funkcionalitu. Nicméně z vlastních zkušeností doporučujeme definovat jeden typ mapování pro jeden index i pro verze starší.

Index

Největší datová struktura v ES se nazývá index. Jedná se o logické uspořádání souvisejících dat, nebo také uspořádání dokumentů jednoho či více typů. Jestliže jsme typ mapování přirovnali k tabulce, index poté označíme za databázi. Nicméně tato analogie není úplně přesná. V relačních databázích jsou stejně pojmenované pole v různých tabulkách na sobě nezávislá. Zde tomu tak není (viz předchozí odstavec). A proto za nás vhodnější formulací je označit index jako jednu tabulku a kolekci indexů poté nazvat databází.

Dalším důležitým termínem je tzv. indexování, nebo-li proces ukládání dat. ES data neukládá ve stejné podobě, jak je posíláme, ale nejdříve se data parsují a ukládají do lookup tabulky po jednolivých slovech, neboli termech. Tento způsob ukládání je velice výhodný pro rychlost vyhledávání, jelikož ES díky připraveným strukturovaným datům velice rychle nalezne vyhledávanou frázi v tabulce a přiřadí, ve kterých dokumentech se nachází. Takové datové uspořádání se nazývá interted index (více zde). Poznamenejme, že ES index je pojmenování určitého celku v systému, ale pokud hovoříme o indexu jako datové struktuře, jedná se spíše o způsob uložení dat.

Indexů můžeme definovat v systému téměř neomezeně. Jsme zde limitování pouze dostupnou velikostí uložiště.

Shard

Nyní se dostáváme k možná nejdůležitější části ES, která se nazývá shard. Každý jeden shard je na pozadí tzv. Lucene index (více informací), ve kterém probíhá samotné vyhledávání a také komunikace s shardy okolními.

Index, resp. jeho dokumenty, se uspořádávají alespoň do jednoho shardu. V praxi je ale častější, v závislosti na objemu dat, že dokumenty jsou rozmístěny hned v několika. Platí, že každý dokument indexu je vždy v jednom hlavním shardu, nebo-li primárním. Tento typ povoluje čtení i zápis, tedy indexace dat vždy probíhá na něm. Dalším typem jsou tzv. replika shardy, určené již pouze pro čtení a obsahují kopie dokumentů z shardů primárních. Přestože nejsou v systému nezbytně nutné, přinášejí 2 výhody. Slouží jako záloha dat, kdyby se něco pokazilo s hlavním shardem a zvyšuje vyhledávací kapacitu systému. Jinými slovy, pokud na váš e-shop bude chodit desetitisíce lidí a každý bude něco vyhledávat, replika shardy pomohou všechny zákazníky obsloužit se stejnou rychlostí. V případě, že bychom měli na takový provoz pouze jeden, rychlost vyhledávání by mohla být znatelně pomalejší. Nicméně replika shardy s sebou nesou i jisté nevýhody. Tou hlavní je zpomalení rychlosti indexace, jelikož data se musí nejen uložit, ale také vždy ještě kopírovat dál. Tím se samozřejmě i zvyšuje náročnost na velikost uložiště.

Node

Nyní již víme, jak ES data uspořádává a vyhledává. Všechno se to musí dít na nějakém fyzickém hardwaru. A tak si můžeme představit další logickou část ES, a tím je node, a nebo také server. Zde jsou umístěny jednotlivé shardy, ať už primární, nebo repliky.

Jedna z dalších velkých předností ES, kterou jsme zmínili v úvodu, je horizontální škálovatelnost. To znamená, že pokud nám přestane stačit výpočetní výkon serveru, např. z důvodu velké vytíženosti, můžeme si další servery poměrně jednoduše přidat. ES poté sám obstará distributivitu dat, tedy shardů, mezi všemy dostupnými nody. Udělá to tím způsobem, aby zátěž byla rozmístěná rovnoměrně na celý dostupný výkon (tzv. multi-node rebalancing).

Cluster

Posledním prvkem celého systému je cluster, nebo-li seskupení všech nodů. V praxi jsou většinou tyto servery umístěny ve stejném datovém centru, nebo alespoň v blízkých datových centrech. Jednotlivé nody mezi sebou potřebují takté komunikovat a tedy je snaha je držet co nejvíce u sebe z důvodu rychlosti.

Může se stát (i když asi vzácně), že celé datové centrum přestane být funkční, v tu chvíli je celý náš cluster vyřazen z provozu a zákazníci na našem e-shopu nemohou vyhledávat. Pro takové případy je dobré mít záložní řešení. ES nabízí pro zvýšení bezpečnosti dat kromě replikování shardů také replikování celých clusterů (Cross-cluster replication = CCR). To nám zajistí dostupnost dat i při takových mimořádných událostech, kdy ES ihned využije nejbližší záložní cluster.

Na co se můžete těšit v příštím dílu?

Dnešní teoretický, asi i vyčerpávající :), díl je za námi a na co se můžete těšit příště? Vyzkoušíme si, jak vytvořit index a naplnit ho daty, základní vyhledávání pomocí query DSL a také, jak získat informace o stavu našeho indexu nebo clusteru. Poté si představíme knihovnu Elasticsearch DSL a ukážeme si, jak vše naprogramovat v django aplikaci.