Fulltext v databáze prakticky, alebo čo nadšenci nepovedia (diskuse)

[Tom K]

Doporučuju zkusit v postgresu ještě trigram index, který umí výrazně zrychlit LIKE '%blabla%' dotazy. Není to sice fulltext, ale s unaccent a lower() to lze také kombinovat. Pro některé potřeby to dokonale stačí.

[Dr.]

Asi to bude zajímavý, ale je to (kuva) moc dlouhý. Zkrať to, nebo to napiš jako seriál .-)

[J]

Pockej az objevis solr a full text search…

[podlesh]

Evidentně už se stalo, zmínil Elasticsearch (no, není to sice SOLR, ale oboje je Lucene).

[mirec]

Skúšal som sa hrať so všeličím, okrem vyše uvedených aj napríklad Xapian, typesense ...

Momentálne pre ne však nemám veľké využitie. Absolútna väčšina klientov potrebuje tak do 200MB RAM, nasadenie niečoho komplexného by brutálne zdvihlo náklady na servery.

Okrem toho som nespomenul ešte jednu veľkú výhodu vyhľadávania v databáze - môžem kombinovať fulltextové vyhľadávanie s rôznymi filtrami podľa atribútov, kategórií, dostupnosti, ceny atď (nie, že by sa to nedalo v elasticsearchi ale ... veľká časť výpisu produktov by musela byť duplikovaná s dotazmi cez elasticserch).

[J]

Jakoze mas servery s 512mb ram? Ja tedy v posledni dobe nevidel nasazeneho nic mensiho nez 256gb ram.

[Max]

Předpokládám, že mu běží u nějakého poskytovatele nějaké VM, nebo něco v tom duchu. Tj. je zaměřením asi někde jinde, než si myslíš.
Zdar Max

[mirec]

Ako je napísané vyššie, sú to menšie prenajaté VPS-ky s menšími kontajnermi v kubernetese do 200MB RAM a cenou za prevádzku na zákazníka za smiešne sumy. Jednoducho pri tomto projekte sa orientujem na časť trhu, kde by bola cena za elasticsearch neakceptovateľná.

[J]

Zeptam se, co je use case? Kolik zakaznika stoji tva sluzba?

[mirec]

Na mieru robené b2b / b2c e-commerce riešenia. O cene hovorím nerád, lebo je to vysoko individuálne. Záleží na tom koľko prostriedkov je potrebných na beh, či je to na dedikovanej VPS, alebo sú služby ako db zdieľané atď. Ale bavíme sa v zásade do 100€ mesačne.

Napríklad tu vidím samostatnú VPS s vlastným postgresom, cleery, rabbitmq, cez 30k produktov, dáta v CDN s cenou keď tak pozerám pod 10€ mesačne.

[J]

Zajimave, diky!

[mirec]

Ešte malý tip, PostgreSQL má podporu FDW s možnosťou prepojiť napríklad elasticsearch. Nikdy som sa nedokopal k tomu, aby som to reálne vyskúšal, ale možnosť tu je.

[J]

Elasticsearch neni solr a ano, videl jsem par “odborniku” ktery je zamenuji. Pokud pracujes s textem a vyhledavanim v textu tak postgres nebo elasticsearch se v performance na solr nechyta.

[plostenka]

Vyhľadávanie zriedkavého slova teraz vráti 25x viac výsledkov než pôvodne v PostgreSQL a 10x viac než v MySQL, pretože vo vyhľadávaní sú zahrnuté rôzne tvary slov ... Ako detekcia môže poslúžiť napríklad to, že vyhľadávanie nevráti žiadne výsledky, alebo vráti málo výsledkov. V takom prípade zistíme podobné slová v databáze slov.

Týchto niekoľko trikov výrazne zlepšilo kvalitu vyhľadávania.

Zlepsilo?!? Vyhledavani ma vratit pokud mozno jeden spravny vysledek, pripadne nekolik nejblizsich shod. Zaplevelit vysledky dohadama, fake-opravama a nesouvisejima podobnostma je uplny antipattern. Kazdeho kdo ve vyhledavani nepodporuje rezim "pouze presna shoda" povesit za koule do pruvanu.

[mirec]

Nie, presný výsledok nie je objektívne lepší. Nebavíme sa tu o vrátení nesúvisiacich výsledkov pre podobné slová. Bavíme sa len a len o skloňovaní (využíva sa reálny slovník) a ignorovaní diakritiky. Vďaka tomu nemusím skúšať zadávať slovo v 14 možných tvaroch a keďže sa vyhľadávajú všetky tvary.

[plostenka]

Ne, kvuli tomu clovek nenajde presne "linuxacka" (8 vysledku), ale spoustu irelevantnich vysledku Linus, linux, linuxák, linuxačka, linuxu (4587 vysledku)...

[mirec]

Linus, linux, linuxák nie sú v slovníku definované ako skloňovanie slova "linuxačka". V tomto fiktívnom prípade by sa so skloňovaním mali vyhľadať tvary linuxačka, linuxačky, linuxačke, linuxačku, linuxačkou + plurál. Skloňovanie nie je vyhľadávanie podobne znejúcich slov.

[mirec]

Teraz ma asi napadlo, v čom je nedorozumenie. Postgres má štandardne konfiguráciu pre stemmer, čo je softvér, ktorý urobí zo slova jeho základ (koreň) pomocou algoritmu. V tom prípade je celkom pravdepodobné, že by z linuxačky zobral ako základ linux. Ak sa však bavíme o slovníku, ten má skutočne vypísané jednotlivé tvary slová, alebo pravidlá, akými sa skloňujú. Nedochádza teda ku odstráneniu prípon / predpon, ale k skutočnému nahradeniu slova jeho základným tvarom a to aj pre nepravidelné skloňovanie. Dúfam, že teraz je to už jasné.

Nechcem tým povedať, že požiadavka na exaktnú zhodu je úplne nelegitímna, ale v drvivej väčšine prípadov je nájdenie rôznych tvarov toho istého slova žiadúce.

[spam]

In the realm of database management systems, PostgreSQL and MySQL (including its fork MariaDB) exhibit noteworthy capabilities when harnessed for full-text search. In this article, we will delve into two distinct facets: performance and quality. These aspects operate independently of one another, ensuring that the search experience remains efficient and responsive. Unlike conventional tutorials that predominantly cater to English-speaking contexts, our exploration extends to encompass a broader range of languages and regions. So, whether you're troubleshooting issues like Epson printer printing blank pages or grappling with Epson printer not printing black, or even embarking on the initial Epson printer setup, our insights will help you optimize your database search operations, ensuring that your data remains accessible even when your Epson printer occasionally goes offline.

[Ivan]

OT: Kdysi jsem delal neco podobnyho na Oracle Text. Byla to hotova tragedie. V Oracle se trigramy ukladaji jako bezne radky do dedikovanych tabulek. To ma za nasledek, ze transakce, ktere na sobe do te doby nezavisely se zacaly se navzajem blokovat.

IMHO: Full Text nema v relacni OTLP databazi co delat a je lepsi data indexovat asynchronne v jine dedikovane databazi.

[J]

+100

[spam]

In the realm of relational databases, both PostgreSQL and MySQL MariaDB have made significant strides in bolstering their full-text search capabilities, catering to a global audience with diverse linguistic needs. When it comes to YouTube-support, users worldwide encounter various challenges, such as YouTube TV keeps buffering and YouTube TV not working issues. In terms of performance, both databases exhibit robust capabilities in handling extensive datasets, ensuring that search operations remain swift and responsive, irrespective of the language or region. Additionally, their innate scalability empowers developers to fine-tune and optimize search operations for various languages, ensuring high quality search results. These databases have evolved beyond basic English-centric functionality, making them versatile tools for addressing multilingual search requirements without compromising performance.

[okbobcz]

Záleží na kontextu a i na kvalitě implementace. Když budu aplikaci pro stovky nebo tisíce uživatelů, tak se mi elastic (a práce s ním) zaplatí. Pro aplikace pro menší počet uživatelů nebo aplikace pro uživatele, kteří jsou citliví na cenu tam dedikovaná databáze může znamenat dost dalších nákladů. Aktuálně pracuji s jedním větším eshopem, kde elastic je ok, nicméně dost provozních problémů i práce jde na úkor elasticu.

[z_sk]

A nepoužívajú ľudia na zložitejšie vyhľadanie napr. google?

D. K.

[podlesh]

To je samozřejmě řešením, pokud je všechno veřejně dostupné takže to google naindexuje. Pokud jsou ale data dostupná jen přes login, tak to logicky nejde.

[alkoholik]

Co blokovani transakci, ale tech ORA-600 a ORA-7445.

[podlesh]

Nikdy jsem nepochopil, proč někdo používá Oracle. Úplně všechno co umí, umí i jiné... a lépe.

Dokonce ani nargument "chceme sypat nekřesťanské peníze nadnárodní megakorporaci" nefunguje; od roku 2007 (minimálně) existuje DB2 for Linux!

[alkoholik]

Jenze to umel driv a od tebe doby se drzi vendor lock-in.

[Max]

RAC myslím stále jiná řešení neumějí. Ale ano, má to performance impact (asi do 10%) a je to řešení kvůli blbě navrženým app a věcím okolo. Nicméně je to jedna z mnoha věcí, co Oracle umí. Není to ovšem jediná věc. Stále platí, že je na tom Oracle hodně dobře oproti konkurenci.
Pokud ale začínám na čisté louce a udělám si dobrý návrh, není samozřejmě problém.
Zdar Max

[podlesh]

RAC myslím stále jiná řešení neumějí. Ale ano, má to performance impact (asi do 10%) a je to řešení kvůli blbě navrženým app a věcím okolo.

Ok, beru, praktické zkušenosti nemám takže je to možné.

[Max]

Myslím si, že tam toho bude mnohem více, nejenom RAC. Nevím, jak je na tom konkurence s kontejnerizací (Oracle Pluggable Database), jaké jsou dostupné diagnostické nástroje (Oracle Diagnostics Pack, Tuning Pack, Performance Health Check a milion věcí okolo, co dokáže vyhodnocovat stav db, navrhovat řešení atd.), jak dobře umí konkurence flashback techniky (dívání se do historie přímo na produkci, tj. načíst si stav db z nějakého času), jak umí konkurence application continuity (patchování db bez výpadku služeb) atd.
Zdar Max

[plostenka]

Diagnostiku, tuning a patchovani bez vypadku umi snad vsichni, Db2 to umi i v ramci upgradu verze+1 kdyz mas SSID v plexu. Flashback se typicky dela pres flashcopy+log replay (consistent point-in-time service) k zadanemu timestampu, fakt to Oracke umi jako online view nad read-write produkci?

[Max]

Ano, umí to read only nad běžnou produkcí s možností udělat rollback (udělat rollback transakcí), uživatelské info:
Database Development Guide: Using Oracle Flashback Technology.
Také není třeba problém detekovat corrupci (způsobenou hw apod.) v části databáze a provést obnovu jen toho vadného bloku (Block Media Recovery). Oracle tyto věci monitoruje, takže já v rámci všech db monitoruji Corrupted Blocks. Naštěstí stále nula, i u db, co má 14TiB.
Jinak ano, vím, že všichni mají diag, tuning apod., ale už nevím, do jaké hloubky a jednoduchosti. To je ale jedno, nechci tu nějak Oracle obhajovat, jen jsem vždy slyšel, že to a to nějaká db nemá apod.
Zdar Max

[podlesh]

Ok, díky za info. Já jsem vývojář, takhle se setkám spíš s tím co umí SQL (DQL+DML+DDL) a tam je Oracle fakt děs a běs.

[Max]

Ještě se zeptám na tu hlášku o DB2? To je jakože co? Resp. o čem to má vypovídat? DB2 je komerční produkt stejně jako Oracle, jaký je rozdíl?
Zdar Max

[podlesh]

Ještě se zeptám na tu hlášku o DB2? To je jakože co? Resp. o čem to má vypovídat? DB2 je komerční produkt stejně jako Oracle, jaký je rozdíl?
Zdar Max

No právě, když někdo chce komerční produkt od megakorporace, může si koupit DB2 a klidně i platit víc.

A moje praktické zkušenosti (byť několik let staré) jsou takové, že takové ty základní věci jako optimalizace dotazů fungují v DB2 výrazně lépe.

[Max]

Co mi o tom někdo kdysi říkal, tak DB2 byla levnější. Každopádně nejde o to, zda chci produkt od megakorporace, nebo ne, ale spíše o to, že potřebuji nějaké fce, nebo ne. A na základě toho pak dělám výběr. A pak začíná cenová rozstřelka s možností případného oželení nějakých fcí.
Zdar Max

[podlesh]

No právě. Za dvacet let jsi první kdo dokázal nějaké ty funkce jmenovat (výše).

[bigfood]

Používáte někdo na fulltextové hledání Sphinx? Nasadil jsem to na jednom projektu a funguje to už delší dobu slušně, aniž by to vyžíralo všechnu RAM.

[hydrandt]

Pekne, dik!

Bude to fungovat i nad jsonb sloupcem? Resim takto multilingualitu: Stringy, ktere mohou byt prekladany, jsou ulozeny jako

{'en': 'Hello', 'zh': '你好', 'defaultLocale': 'en'}

Predpokladam, ze budu muset vytvorit jeden index na kazdy mozny jazyk, a pak ho vybrat pri vyhledavani?

[mirec]

V tomto prípade samostatné indexy pre každý jazyk.

Mimochodom ja používam preklady v externej tabuľke, ktorá vyzerá: (id int, master_id int, language_code varchar, text ...) a tsvector je vytvorený ako to_tsvector("language_code", "text"), teda nastavenie jazyka sa načítava priamo zo stĺpca v tabuľke. Nie je to úplne ideálne riešenie, ale ide to aj s jediným indexom.

[skajrajdr]

Ten trik s odstranenim diakritiky se nam (minimalne v cestine) neosvedcil. V nasem UC potrebujeme mit vyhledavani presne - tedy nejenom maximalizovat pocet, ale i minimalizovat false positive. A k velikemu narustu false positive prave tim "zmrsenim" slovniku/tvorby lexemmu jdes vyrazne naproti (proste slova s diakritikou nejsou ta sama co bez a ty tenhle rozdil zahodis a zacnes spojovat veci, co k sobe nepatri). Zaroven je dobre se kouknout, jak vlastne uzivatele hledaji. Alespon u nas vetsina uzivatelu hleda slova s diakritikou se "spravnou" diakritikou rpvnou a ne bez ni.

[podlesh]

Záleží na aplikaci. Běžnou praxí v tomto ohledu je samozřejmě naindexovat oboje a zohlednit při výpočtu relevance. Úplně správným řešením je zaindexovat s diakritikou a korektní morfologií kdy písmeno nesouhlasí vůbec (tj. dům - domu - domů >> dum), ale to jsme samozřejmě úplně mimo možnosti jakékoliv SQL databáze a AFAIK i jakéhokoliv opensource řešení.

[mirec]

Morfológia práve, že nie je žiaden problém. Stačí uložiť text so slovami konvertovanými na základný tvar a query tak isto konvertovať na základný tvar (presne to som popisoval v druhej časti blogu). Ku konverzii však musí byť použitý reálny slovník obsahujúci informácie o skloňovaní. Napríklad vyberám z ispellu:

// sk_SK.dict
žena/zZ po:noun is:feminine

// sk_SK.aff
SFX z Y 7     # vzor žena jednotné číslo
SFX z   a           y          a is:genitive
SFX z   a           e          [^euo]a is:dative
SFX z   a           i          [euo]a is:dative
SFX z   a           u          a is:accusative
SFX z   a           e          [^euo]a is:locative
SFX z   a           i          [euo]a is:locative
SFX z   a           ou         a is:instrumental
...

Okrem slov sú v slovníku uložené metainformácie k skloňovaniu vďaka čomu je možné väčšinu slov jednoznačne konvertovať na základný tvar.

[podlesh]

No, jako základ OK, lepší než drátem do oka, ale pořád to není ono - chybí informace k tomu aby se ten správný tvar upřednostil.

Lidé dnes očekávají že když zadají frázi "s jeho ženou" (tj. instrumentál) tak jim to najde jako první dokumenty kde se skutečně vyskytuje instrumentá (a mezi nimi pak první ty kde jsou i ostatní slova ve správném pořadí) a až pak dole budou všechny dokumenty kde se vyskytuje "žena" (nominativ).

Jinak ano, "problém" do skutečně není, udělat to lze, ale nevím o tom že by to někde fungovalo pěkně out-of-box.

[mirec]

Ak ľudia zadávajú s diakritikou, je blbosť ju odstraňovať. U mňa je 70-80% výrazov, ktoré majú diakritiku zadaných bez diakritiky, takže dáva zmysel skôr odstránenie..