Názory k článku evitaDB: základy dotazovacího jazyka evitaQL

Článek dobrý, ale jestli pana autora překvapuje, že LLM pochopil ten dotaz, měl by taky zauvažovat proč asi a trochu se dovzdělat co se tohoto týká. Můj dotaz by taky "pochopil" i když můj text určitě nebyl v datech, na kterých se učil. Vždyť ten dotaz obsahuje standardní konstrukce a tokeny z přirozeného jazyka.

Použití LLM mělo jen doložit, že pokud se dotazovací jazyk konstruuje tímto způsobem, je stravitelnější nejen pro LLM, ale i pro vývojáře - tj. snižuje vstupní bariéru jazyka.

Aha. Díky za odpověď. Trochu to z toho třeba pro mě nevyplývá. Klidně to tam příště pro nás pomalejší napište :-)

Skvělé články.

Co je špatně s SQL?
Jako toy si myslím, že dobrý, … ale ne.
Nemyslím, že je v možnostech správce projektu to dotáhnout.
Rád se mýlím.. :-)
Přijde mi to ukecaný.

Tak o DSL více či méně odlišné od SQL pro dotazování se v posledních letech snaží více projektů . Článků je na síti spoustu. Ale pokud vám stačí a nikde netlačí, pak asi nemáte motivaci to hledat.

Špatného nic. Ale třeba prostě nechceš relační algebru.

Byly doby, kdy SQL bylo chápáno nejen jako jazyk, ale i architektura. Například dokumentové databáze nebo key-value databáze mají své místo. Ale automaticky se jim říkalo "no-SQL" databáze. To už sice řadu let neplatí, přesto se to dodnes motá.

Dnes je SQL podporováno i v no-SQL databázích. Do té míry, že by se možná místo no-SQL mělo začít používat nějaké jiné označení. Některé databáze už tu zkratku vykládají jako "noSQL = not only SQL". Osobně jsem za to rád, protože SQL považuji za velmi dobrý jazyk. A tak jsem rád, že funguje i v no-SQL databázích, které používáme.

Mate pre C# klienta aj LINQ povider?

Ne, LINQ podpora v C# klientu zatím není (kontribuce jsou vítány).

Ty silene dlouhe nazvy funkci jsou skutecne hrozne. Nakonec to nedela o moc vic nez sql, ale nez to napises, se upises.

I mně přijde lepší naimplementovat SQL, respektive nějakou jeho podmnožinu. SQL by měl aspoň v základu umět každý programátor a je to vědomost, kterou využije i jinde. Proprietární DSL je věc, která nepomůže ani novým lidem se znalostí standardních technologií a při přechodu na standardní DB taky ne.

Take jsem z tech co by jednoznacne preferoval SQL. Ale kydz uz ne, tak je fajn, ze mate docela normalni syntax.

Nechcete si pridat "trailing comma"? Jinak je otrava stale pridavat a ubirat carky kdyz clovek neco zakomentuje.

Pri pohledu na ty velikost vystupu bude monza lepsi kdyz uzivatele nebudou delat jeden dotaz ale (alespon) dva. Jeden pro produkty a druhy pro facety, histogramy atd. Jinak jen ten cas posilani a parsovani take velke odpovedi na serveru a klientovi zhorsi ux.

Co je spatne na transakcich s embedovanym Lucene? Ten mel snad vzdy transakce. Minimalne pred deseti lety ano. Ale dulezitejsi je ten NN search. O tom mate mluvit a ten mate delat! Totiz nejen jeden embeding a NN. To je jednoduche. To se delalo pred deseti lety. Ten je spis pro similarity a recomendation nez pro search. Dnes mame LLM a tudiz zitra budeme ocekavat mnohem vic!

BTW: Trochu nezvyk videt neco jineho nez S2/H3 pro query engine, ale v tomhle pripade to asi bude stacit a ty dve java knihovny vypadaji na prvni pohled pekne.

Jako vzdy - clanek, kod, web i to prolinkovani do examplu mate paradni!

SQL má tu výhodu, že je obecně známé, ale má také spoustu nevýhod. Je to "string based" jazyk, se kterým se nepracuje dobře z programového hlediska - buď se spojují stringy, nebo se nad tím buduje další vrstva abstrakce (výrazového stromu, který se na string přeloží až těsně před předáním do databázového ovladače). Pokud chcete nad SQL vybudovat REST/GraphQL API, tak pravděpodobně také skončíte u nějakého vlastního DSL, protože posílání SQL v requestu nedává moc smysl - proč tedy rovnou nepracovat s jazykem, který je velmi podobný jak z nativního kódu, tak i z pohledu webových API a zároveň rovnou reprezentuje výrazový strom se kterým se dobře pracuje jak na klientu, tak na serveru?! Zároveň budou všichni zainteresovaní (jak frontendisti, tak backendisti) mluvit "stejnou" řečí a tím spíš si budou více rozumět.

Poznámka: o našich webových API bude pojednávat další článek série.

Trailing comma je dobrá připomínka - rovnou jsem založil issue https://github.com/FgForrest/evitaDB/issues/493 a s kolegy to probereme. Už jsem nad tím také přemýšlel, že to zbytečně komplikuje život.

Co se týká množství dotazů - docházíme k závěru, že tahle myšlenka se třeba v prostředí komponentově orientovaných frameworků (např. Next.JS) špatně realizuje a zamýšlíme se nad tím, že bychom dokázali optimalizovat a přepoužívat mezivýsledky napříč různými dotazy, pokud jsou poslány v rámci jedné dávky (batche) dotazů. Tj. analogii k request collapsing technice ve Varnishi - i když u nás by se jednalo o sdílení mezivýsledků na granulárnější úrovni než je celý dotaz. Stále nám ale dává smysl posílat více queries v rámci jediného requestu kvůli amortizaci nákladů na request/response režii. Velikost by v prostředí HTTP/2 nemusel být úplně zásadní problém. Tady uvidíme, co nám ukáže praxe.

Vyhledávání podle embeddingů je samo o sobě obrovská kapitola. Už teď existují databáze, které to dělají skvěle - např. Vespa.ai. Osobně mi dává smysl v nejdříve podporovat propojení s těmito specializovanými databázemi než se snažit tuto problematiku pokrýt vlastními silami. V tomhle směru se zatím teprve rozkoukáváme (https://github.com/FgForrest/evitaDB/issues/258).

Celkově děkuji za velmi cenný feedback!

> poslány v rámci jedné dávky (batche) dotazů
Budem hovorit zo svojich skusenosti. Rozdelit query dokaze uz na proxy a je to vyhodne v microservisnej architekture aj ked by ten dotaz mal ist na rovnaky server. Pred databazou mate predradeny este aplikacny server a ten je zodpovedny za 'poskladanie' vysledku. Nemyslim si ze je potrebne aby to robila DB. Toto je uplne zbytocne mixovanie funkcii kam nepatria. Databaza ma byt rychla, transakcna, ... nemusi vediet to co dokaze aplikacny server.

Asi jsem to nenapsal dostatečně přesně. Představme si trochu komplexnější příklad - na stránce jsou 3 komponenty, které generují samostatné dotazy:

• výpis TOP 5 neprodávanějších v kategorii
• stránkovaný výpis produktů seřazený dle abecedy
• facetový filtr

Pokud by byly query odeslány v jedné dávce, databáze by dokázala vyhodnotit, že všechny 3 dotazy sdílí společný základ - tj. filtrace produktů v kategorii s nějakou další sadou podmínek na cenu, validitu, stav na skladě atp. Tj. ten by se vypočetl pouze jednou (databáze vidí souvislost), následně by se pro každou z těchto query ale vygeneroval jiný výsledek:

• seřazení dle počtu prodejů sestupně + výřez prvních 5
• seřazení dle abecedy + výřez pro požadovanou stránku
• výpočet facetů pro vyfiltrovanou sadu produktů

Tj. collapsing se neděje na úrovni celých dotazů, ale jejich logických součástí. Toto nelze dělat nikde jinde než na úrovni databáze.

Ano, vraceni listu a facetu je stereotipicky priklad proc se to dela dohromady. Zejmena u search enginu se o tom hodne mluvi.

Batchovani je pro klienta vice ci mene slozite. Komponenty jsou jednim duvodem. V predchozim komentari jsem chtel poukazat take na velikost odpovedi. Ty priklady ukazuji json nekolik MB. Cas na presun a zpracovani tak velke odpovedi skrz aplikacni server a wifi koncoveho uzivatele prida latency. Tipoval bych, ze jednoduchy eshop nebude umet poskladat batch. Pokrocilejsi to neudela, aby mel nizsi latency na produkt listu.

Proc opakovane mluvite o "http rezii"? Neni zanedbatelna?

Dobre argumentujete jinymi technologiemi. Mate prehled. Takze vite jak to bylo s "NoSQL". V cem je EvitaDB tak vyjimecna?

Nemusite mi na to odpovidat. Detaily - co, proc a jak - by byli na delsi diskuzi. Flamewar nemame zapotrebi.

Vespa uz leta roste v oblibe, ale nic poradneho jsem s ni jeste nezkusil. Pouzit ji pro vas zni rozumne. Meli by jste neco rychle. Zesloziti to deployment a synchronizaci dat. Zasadni otazka ovsem je jak efektivne zkloubit "ruzovy top" vyhledavani ve Vespe s cenami, facety a tim vsim v Evite. Pro uvazovanych <100k produktu muzete prenest v podstate bitmapovy index a fungovat to muze. Tedy jestli ho Vespa stihne vygenerovat dost rychle.

To co uz dnes mate vypada dobre. Pracujte na prodeji. Jedinou vec, kterou bych udelal pred tim je pat si nejakou AI / LLM story na home page.

Chápu, kam tím míříte. Kdo si v dnešní době nedá na produkt nálepku AI/LLM, tak zájem v dnešní době nezíská. Ale tohle téma bych tu nerad otevíral - řídit se heslem - fake it till you make it, se mi protiví.

Část dotazovacího jazyka by asi byla mapovatelná na SQL konstrukce, ale u jiných si to úplně neumím představit (facety, výpočet cen, hierarchie) - možná leda v podobě nějakých funkcí. Argumentaci rozumím, ale prozatím mi poměr cena / výkon u podpory SQL syntaxe nevychází.

Osobně v SQL vidím velkou spoustu nevýhod odpovídajících době vzniku a primárnímu účelu relačních databází, na které jsme si prostě časem tak zvykli, že je považujeme za normu.

Nekomu jde o nalepku. Me osobne ne. "AI" nalepky na vsem me take (dost) rozciluji. Ale nepochybuji, ze dnes a v brzke dobe to radu veci zasadne zmeni. Vcetne e-commerce. A je otazka co z toho co jsme delali pred deseti lety bude konkurenceschopne za dva roky.

Myslim, ze si kolem SQL nerozumime ani v tom "co?" a "proc?" natoz v "jak?". Ale je jasne, ze SQL nechcete. Nemusite.

Ja suhlasim z Jan Novotný, SQL je super jazyk, ale nasrobovat ho na toto by vyzadovalo spravit vlastny dialekt SQL-ka. Naco ked mozem pouzit domenovo specificky jazyk, ktory bude na dany ucel jednoduchsi?

S tim bych nesouhlasil. Ale uz to ze to reknu vas dost mozna nastve. Kdyz reknu proc tak se jeste vice defenzivne zakopeme v zakopove Flamewar. Pojdme radeji delat neco uzitecneho.

Do diskuze jsem zkusil prispet, ze jsem chtel pomoct. To se vubec nepovedlo. Spis naopak. Uz mlcim ;-)

Preji uspech!