Přejít na obsah|Přejít k hlavnímu menu|Přejít k vyhledávání
Tak jako se internet postupem času přesunul od rozcestníků k vyhledávačům (a nyní k AI), tak se i moderní aplikace snaží nabídnout co nejlepší způsob, jak se jednoduše dostat k uloženým datům.
Proč nutit uživatele, aby si vzpomněl kde se nachází hledaný obsah, když můžeme nabídnout jednoduché vyhledávání a zobrazit všechno pěkně na jednom místě? Zkusím nyní informativně představit několik způsobů, jak je možné uchopit vyhledávání v databázi.
Jako prvotní nápad často přichází tvorba vyhledávacích dotazů nad existujícím datovým modelem – nevyžaduje to přece nic složitého, jen vytvořit pár SQL dotazů nad potřebnými sloupci. Avšak postupem času, nárůstem uložených dat a přibývajícím množstvím prohledávaných tabulek se dotazy začnou zpomalovat až na neúnosnou míru. Orientačně například použití LIKE při vyhledávání nad textovým sloupcem při milionech řádků může trvat i několik minut. Navíc uživatelé přicházejí se stále dalšími požadavky a chtějí například, aby vyhledávání dokázalo tolerovat překlepy, chtějí, aby když hledají text „moře“ tak aby aplikace zobrazila i výsledky pro „oceán“ a podobně, tak jako jsou zvyklí z různých internetových vyhledávačů.
Nejprve toho můžeme zkoušet dosáhnout přidáváním různých indexů a zlepšováním logiky našeho vyhledávacího kódu, ale časem zjistíme, že kolikrát vlastně potřebujeme úplně jiný datový model pro vyhledávání než pro funkčnost samotné aplikace.
Hlavní nevýhodou tohoto řešení je malá výkonnost a flexibilita.
Naproti tomu má však velmi malé datové nároky – obvykle prohledáváme již existující záznamy a není potřeba vytvářet duplicitu dat pomocí indexů nebo specializovaných tabulek.
Pokud prohledáváme malé množství dat a uživatelé nemají velké nároky na možnosti hledání (překlepy, ranking, synonyma…) může být toto řešení plně dostačující.
Pokud v aplikaci používáme databázi, která má zabudovanou podporu pro fulltextové vyhledávání (např. MS SQL či PostgreSQL) můžeme (a měli bychom) toho s výhodou využít. Vhodně zvolenými indexy v katalogu můžeme vyhledávání výrazně zrychlit, a ještě k tomu dostaneme spoustu věcí navíc – hledání dle prefixu, významu slov, podporu synonym (thesaurus), toleranci překlepů, podporu pro více jazyků a mnoho dalšího.
Chování fulltextového vyhledávání není mezi jednotlivými databázemi nijak sjednocené, obvykle je třeba vytvořit nějaký katalog a naplnit jej fulltextovými indexy založenými na existujících tabulkách či pohledech. Je třeba zvolit vhodnou synchronizační strategii, tedy zda se má každá změna přenášet ihned do fulltextových indexů, nebo budou změny promítnuty o něco později – což sice způsobí mírnou prodlevu ve výsledcích vyhledávání, ale může to pomoci výkonnosti aplikace při častých změnách dat.
Velkou výhodou tohoto řešení je, že je integrované v existující databázi, a tím pádem nezesložiťuje nasazení a údržbu řešení. Další výhodou je automatická synchronizace indexů.
Nevýhodou potom je, že jsme stále zčásti svázáni datovým modelem aplikace. Můžeme si sice pomoci vytvářením různých specializovaných pohledů, čistě puristicky však tyto pohledy do modelu nepatří a mohou jej zbytečně komplikovat.
Potenciální nevýhodou mohou být také vyšší nároky na diskový prostor, fulltextový index totiž bude prohledávaná data duplikovat a transformovat.
Pokud databáze, kterou používáme, nemá podporu fulltextového vyhledávání, máme náročné uživatele, nebo potřebujeme opravdu bleskově rychlé vyhledávání, například pro různé našeptávače, nabízí se použít specializované vyhledavače jako Typesense, Elasticsearch či Meilisearch.
Jejich použití je v zásadě podobné používání fulltext indexů zmíněných v předchozí části, s tím rozdílem, že nabízejí mnohem více konfiguračních a vyhledávacích možností. Principiálním rozdílem ale je, že nejsou svázány relačními pravidly a pracují jako dokumentové databáze. Nad kolekcemi těchto dokumentů pak definujeme pravidla, podle kterých se budou prohledávat.
Tuto kolekci pak udržujeme aktuální podle toho, jak se mění prohledávaná data. To je na jednu stranu výhodou, protože si data před umístěním do kolekce můžeme transformovat dle potřeby, na druhou stranu to může představovat výzvu, protože musíme podchytit všechna místa, kde se nám data mění, pokud chceme mít vyhledávání nad živými daty.
Následně při prohledávání definujeme, které kolekce prohledáváme, můžeme dodefinovat různá pravidla platná pro dané hledání (třídění, ranking a podobně) a jako výsledek hledání pak dostaneme seznam dokumentů v té podobě, v jaké jsme je do kolekce umístili. To umožňuje získat různá další pomocná data, která mohou být využitá při zobrazení nebo dalším zpracování výsledku hledání.
Až dosud se, kromě pravděpodobně vyšší rychlosti vyhledávání, neliší specializované vyhledávače od fulltextového vyhledávání v databázi. Co by mohly nabídnout navíc?
Jde o techniku, která umožňuje filtrovat a zúžit výsledky vyhledávání pomocí různých kategorií nebo atributů. Při hledání můžeme upřesnit rozsah našeho vyhledávání pomocí různých interaktivních filtrů, definovat například značku výrobku a případná další kritéria, která nám pomohou přesněji zacílit. Například v e-shopu s notebooky mohou být facety třeba značka výrobce, uhlopříčka obrazovky, barva nebo další kritéria která mohou usnadnit zákazníkovi výběr.
Můžeme indexovat vektorové reprezentace (embeddings) z modelů strojového učení a provádět hledání nejbližších sousedů. Tento přístup můžeme využít k vytvoření vyhledávání na základě podobnosti, sémantického vyhledávání, vizuálního vyhledávání, doporučení a dalších funkcí.
Pokud dokument obsahuje geografické souřadnice, vyhledávač pak umožňuje hledat data definovaná pro okolí dané GPS souřadnice, nebo v rámci definovaného ohraničujícího obdélníku. Tedy můžeme snadno např. najít firmy v našem okolí, které končí na „s.r.o.“.
Pokud potřebujeme odpovědět na otázky jako
a mnohé další, poskytují specializované vyhledávače řešení v podobě specializovaných API, přes které je možné tato data získat, analyzovat a na jejich základě upravovat parametry hledání a podobně.
Specializované vyhledávače umožňují třídit výsledky nejenom podle rankingu či podobnosti, ale je možné určité konkrétní záznamy „zafixovat“ na konkrétních pozicích ve výsledcích vyhledávání. Tuto funkci znáte například z placených odkazů při vyhledávání v Google. Další využití může záviset od konkrétní aplikace, můžeme např. výsledky upravovat podle sezónnosti, oblíbenosti atd.
Jde asi o největší výhodu specializovaných vyhledávačů – i při milionech záznamů je dokáží prohledat, setřídit podle požadovaných kritérií, filtrovat pomocí facetů, podobností a dalších filtrů, a to vše v časech obvykle pod 50 ms. Samozřejmě, jako vše, mají specializované vyhledávače i své nevýhody. Mezi ně patří zejména větší nároky na zdroje – jak diskovou kapacitu, protože data jsou mnohdy duplikována, tak i na operační paměť, kde si drží maximum dat pro co nejrychlejší vyhledávání.
Pokud potřebujete ve své aplikaci řešit prohledávání dat, dat máte hodně nebo chcete nabídnout pokročilé možnosti vyhledávání, rozhodně zvažte některý z dostupných vyhledavačů, ať už půjde o ElasticSearch, MeiliSearch či Typesense či jakýkoliv jiný.
Děkujeme za váš zájem o odběr našeho newsletteru! Pro dokončení registrace je potřeba potvrdit vaše přihlášení. Na zadaný e-mail jsme vám právě zaslali potvrzovací odkaz. Klikněte prosím na tento odkaz, aby bylo vaše přihlášení dokončeno. Pokud e-mail nenajdete, zkontrolujte prosím složku nevyžádané pošty (spam) nebo složku hromadné pošty.
