Slovník pojmů

Fulltextové vyhledávání

Fulltext nehledá jen doslovný podřetězec. Připravuje text do vyhledávacího indexu, zpracuje dotaz a výsledky ohodnotí podle pravidel relevance.

Stručná definice

Hledání podle významných částí textu.

Fulltextové vyhledávání prohledává název, popis nebo celý dokument podle slov a jejich normalizovaných podob. Na rozdíl od přesného filtru může pracovat s více slovy, jejich pořadím a významností v kolekci a každému výsledku přiřadit skóre.

Může běžet přímo v relační databázi, v samostatném systému, jako je Elasticsearch, nebo jako kombinace obou přístupů. Elasticsearch je jeden možný nástroj, nikoli synonymum fulltextu.

Jaký problém řeší

Najít užitečný obsah i bez přesné znalosti uloženého textu.

Uživatel často nezná přesný název produktu ani tvar slov v popisu. Fulltext převede volný dotaz na hledatelné jednotky a dovolí aplikaci vrátit a seřadit více přibližně odpovídajících dokumentů.

hledání produktů podle názvu, popisu, značky a kategorie
prohledávání článků, dokumentace, ticketů nebo interních záznamů
hledání více slov bez požadavku na jeden doslovný souvislý řetězec
přesná fráze, prefix slova nebo opatrně nastavená tolerance překlepů
řazení podle relevance a vytvoření krátkého zvýrazněného úryvku s nalezenými výrazy

Praktický příklad

Dotaz „černá zimní bunda“ v e-shopovém katalogu.

Dokument produktu obsahuje název, popis, SKU, značku a kategorii. Název a popis se analyzují jako přirozený text, značka a kategorie mohou mít vedle textové podoby také přesnou hodnotu pro filtr. SKU se zpracovává samostatně: pomlčky, lomítka a kombinace písmen s čísly nejsou běžná česká slova a jazykový stemming by jejich hledání mohl poškodit.

Dotaz „černá zimní bunda“ analyzátor rozdělí na tokeny černá, zimní a bunda a normalizuje je stejnými pravidly jako dokumenty. Podle zvoleného českého zpracování může sjednotit velikost písmen, variantu s diakritikou nebo slovní tvary. Odstranění diakritiky, stop words a stemming či lemmatizace nejsou povinné kroky: každý z nich se zapíná jen tehdy, když na skutečných dotazech zlepšuje výsledky.

Vyhledávač v indexu najde dokumenty obsahující odpovídající tokeny. Skóre může zvýhodnit shodu v názvu proti popisu, více nalezených slov, vzácnější výraz nebo blízkost tokenů. Výsledek není objektivně „nejlepší“; je to pořadí podle zvolené funkce relevance, vah polí a případných businessových pravidel, které je nutné ověřovat na reálných dotazech.

Současně se použijí přesné filtry, například cena od 2 000 do 5 000 Kč a dostupnost skladem. Filtr neurčuje textovou podobnost a obvykle nemění skóre: pouze vyřadí nevyhovující kandidáty. Před nákupem aplikace ověří cenu a dostupnost v autoritativní databázi, protože samostatný vyhledávací index může být proti ní krátce opožděný.

Jak funguje

Dokumenty → analyzátor → index; dotaz → analýza → relevance → výsledky.

Následující textový tok je zároveň alternativou diagramu: stejná základní pravidla musí připravit dokumenty i uživatelský dotaz, aby vzniklé tokeny bylo možné porovnat.

Dokumenty Aplikace vybere hledatelná pole a odliší přirozený text od přesných kódů, značek, cen a stavů.
Analyzátor Tokenizer rozdělí text na tokeny; filtry je mohou převést na malá písmena, upravit diakritiku, stop words nebo slovní tvary.
Fulltextový index Inverzní struktura vede od tokenu k dokumentům a může uchovat četnost a pozice potřebné pro fráze a skórování.
Analýza dotazu Víceslovný dotaz se zpracuje kompatibilně s indexem a pravidla určí, zda musí odpovídat všechna slova, některá slova nebo přesná fráze.
Shoda, skóre a filtry Index najde kandidáty, relevance je ohodnotí a přesné podmínky ceny, značky či dostupnosti omezí výsledek.
Výsledky Aplikace seřadí položky podle skóre nebo zvoleného řazení a může vytvořit zvýrazněný úryvek; skóre samo nevysvětluje správnost businessových dat.

Hlavní části a principy

Kvalitu výsledků určuje index, analýza i způsob dotazování.

Fulltext není jeden univerzální algoritmus. Jednotlivá pole a druhy dotazů potřebují pravidla odpovídající jazyku a chování uživatelů.

Tokenizace a normalizace

Token je hledatelná jednotka, nejčastěji slovo. Tokenizer určí její hranice a normalizace sjednotí například velikost písmen. České hledání musí vědomě řešit diakritiku; bez testu nelze předpokládat, že každý analyzátor spojí „cerna“ s „černá“ správně.

Analyzátor a jazyk

Analyzátor je řetězec tokenizeru a následných filtrů. Stop words mohou vynechat velmi častá slova. Stemming zkracuje slova podle pravidel, lemmatizace hledá základní slovní tvar; ani jedna technika sama nezaručuje správnou češtinu a příliš agresivní nastavení slučuje nesouvisející výrazy.

Fulltextový a běžný databázový index

Běžný databázový index, například B-tree, vede od celé hodnoty nebo její uspořádané části k řádkům. Fulltextový index obvykle vede od analyzovaných tokenů k dokumentům. Specializovaný fulltextový index může být přitom technicky uložen přímo v databázi, například jako GIN nad textovou reprezentací v PostgreSQL.

Více slov, fráze, prefix a fuzzy matching

Dotaz může vyžadovat všechna slova, povolit jen některá nebo zvýšit skóre při větším počtu shod. Přesná fráze používá pořadí a pozice tokenů. Prefix hledá začátek tokenu. Fuzzy matching toleruje omezený počet znakových změn, ale je volitelný, dražší a při příliš širokém nastavení vrací nesouvisející výsledky.

Relevance a skóre

Skóre je číselný odhad shody pro konkrétní dotaz. Může zohlednit četnost výrazu, jeho vzácnost, délku dokumentu, pozici a váhu pole. Ladění relevance vyžaduje sadu reprezentativních dotazů, očekávaných výsledků a měření; samotné vyšší číslo není obecné hodnocení kvality dokumentu.

Fulltext, filtr a řazení

Fulltext odpovídá na otázku, které dokumenty textově odpovídají a jak silně. Filtr podle přesné značky, dostupnosti nebo číselného rozsahu pouze rozhodne ano či ne. Výsledky lze řadit podle relevance, ale také podle ceny nebo data; tím se původní pořadí podle skóre záměrně nahradí nebo zkombinuje.

Výhody, omezení a časté chyby

Lepší hledání přidává datový model, ladění a provozní odpovědnost.

Konkrétní přínosy

rychlé hledání více slov nad připravenou textovou kolekcí
řazení podle měřitelné relevance místo náhodného pořadí řádků
oddělení analyzovaného textu od přesných filtrů a identifikátorů
možnost přidat fráze, prefixy, zvýraznění nebo opatrnou toleranci překlepů podle potřeby

Omezení a chyby

považovat fulltext za totéž co LIKE nebo za běžný B-tree index
nasadit obecný analyzátor bez testu češtiny, diakritiky a produktových kódů
označit první pořadí podle skóre za objektivně nejlepší výsledky
zapnout široké fuzzy hledání pro všechny krátké dotazy
ignorovat aktualizaci indexu, neúspěšné zápisy a rozdíl proti primární databázi

Volba implementace

Začít požadovaným chováním, ne názvem technologie.

Výraz SQL LIKE '%text%' hledá doslovný vzor v původním řetězci. Neprovádí jazykovou analýzu ani běžné skórování relevance a úvodní wildcard často nevyužije obyčejný B-tree. Pro malou tabulku nebo jednoduchou administraci však může být přiměřený; fulltext není povinná náhrada každého LIKE.

PostgreSQL nabízí tsvector, tsquery, ranking a specializované indexy, MySQL index FULLTEXT s dotazy MATCH … AGAINST a SQLite rozšíření FTS5. Databázový fulltext může být nejjednodušší dostatečné řešení, pokud jeho jazykové možnosti, relevance a provoz odpovídají produktu.

Samostatný Elasticsearch se hodí pro rozsáhlejší index, vlastní analyzátory, kombinaci fulltextu s filtry a agregacemi nebo nezávislé škálování hledání. Přidává ale synchronizaci, monitoring a reindexaci. Primární databáze zůstává autoritativní pro cenu, sklad a objednávku; kombinované řešení musí počítat s dočasnou nekonzistencí.

Na co myslet

Vyhledávání se testuje jako uživatelská i datová funkce.

Správná odpověď není jen nízká latence. Systém musí vracet očekávané produkty, bezpečně aktualizovat index a jasně oddělit hledání od autoritativního businessového stavu.

udržovat sadu českých dotazů s diakritikou i bez ní, více slovy, frázemi a překlepy
měřit relevanci odděleně pro název, popis, značku, kategorii a přesné SKU
definovat, zda více slov znamená AND, OR nebo minimální počet shod
sledovat zpoždění, chyby indexace a rozdíl počtu dokumentů proti primární databázi
mít idempotentní aktualizaci a bezpečný postup úplné reindexace
před zobrazením ceny či nákupní akcí ověřit kritická data v autoritativním zdroji

Časté otázky

Fulltext v databázi a aplikaci.

Je fulltext totéž co SQL LIKE '%text%'?

Ne. LIKE porovnává řetězec se vzorem. Fulltext pracuje s analyzovanými tokeny, specializovaným indexem a může počítat relevanci, fráze nebo další textová pravidla.

Je pro fulltext vždy nutný Elasticsearch?

Ne. PostgreSQL, MySQL i SQLite mají vlastní fulltextové možnosti. Samostatný vyhledávací systém má smysl až tehdy, když jeho funkce a škálování ospravedlní další provoz a synchronizaci.

Proč hledání s českou diakritikou vrací jiné výsledky?

Rozhoduje analyzátor použitý při indexaci i dotazu. Sjednocení diakritiky lze nastavit, ale musí se otestovat, protože normalizace může také sloučit výrazy, které mají zůstat odlišné.

Je výsledek s nejvyšším skóre vždy nejlepší?

Ne. Skóre vyjadřuje zvolený model relevance pro daný dotaz. Váhy polí, jazyková pravidla a produktové signály je potřeba ladit a ověřovat proti očekávání uživatelů.

Proč se nově změněný produkt hned neobjeví?

U samostatného indexu může být změna ještě ve frontě, čekat na refresh nebo selhat. Aplikace má zpoždění sledovat, umět změnu zopakovat a kritická data ověřovat v primární databázi.

Jak pracuji s databázemi v praxi

Vyhledávací model navrhuji spolu se zdrojem dat a způsobem aktualizace.

U e-commerce a integračních aplikací odděluji autoritativní data od vyhledávacího pohledu a relevanci ověřuji na skutečných dotazech.

Jak pracuji s databázemi Nezávazně probrat projekt