Názory k článku evitaDB: spuštění, definice schématu a naplnění daty

Proc nepouzit klasicke SQL pribalene treba jako SQLite? Je k tomu urcite i nejake ORM, pokud se nekomu zda byt lepsi pracovat s java tridama. V cem je ta evitaDB lepsi?

Postupně se k tomu dostaneme v dalších dílech seriálu, ale můžu pár bodů vyjmenovat i zde:

- webová API ihned k použití (GraphQL, REST, gRPC)
- výrazně rychlejší odezvy oproti relačním DB pro "katalogové scénáře"
- podpora facet kalkulací, práce s cenami a hierarchicky organizovanými daty
- sjednocený způsob práce a dotazování skrz různé technologie - tj. jak pro frontendové, tak i backendové týmy
- CDC a streaming změn na klienty a další ...

Zopar veci ktore ma zarazili:
- Webove API fajn viem si urobit CRUD aplikaciu. Ale nepoznam aplikaciu ktora by nemala aspon nejaku minimalnu logiku. Existuje moznost upravit 'standardne' spravanie operacie? Ak nie nakoniec aj tak skoncim tak ze musim pred tu DB predradit aplikacny server a potom je to REST rozhranie skor nevyhodou.
- evitaDb je inmemory DB? Porovnavate vykonnost DB na cloude v kubernetoch? To by asi chcelo ferovejsie porovnanie. Ako si stojite voci inym inmemory databazam alebo noSql databazam?
- Price typ sa mi zda nezmysel, urcit strukturu ktorou definujem ceny ... neviem aky to ma zmysel, hierarchicke udaje sa daju asi nahradit rekurzivnymi query
- Ako je to so zabezpecenim (autorizacia/au­thentikacia) ked uz teda vystavujem REST sluzbu?

V aktuální verzi nemá databáze autorizaci / autentikaci - máme to v backlogu. Souvisí to s tím, jak databázi používáme a tím, že nás to zatím ještě tolik netlačí. Databázi nemáme otevřenou koncovým klientům, ale dalším vnitřním aplikacím, které nad tím staví další logiku.

Konkrétně je tam administrační část také psaná v Javě, která používá gRPC protokol a do databáze migruje data z primární relační databáze, zároveň používá evitaDB ke generování feedů, rozesílání e-mailů a dalších podobných úloh.

Vedle toho existuje Next.JS frontend, který má dvě části - serverovou, které říkáme middleware, a klientskou a ta už běží v klientově prohlížeči. Middleware obaluje GraphQL rozhraní evitaDB a přidává si tam věci navíc, zároveň federuje do jednoho GraphQL i další interní a externí REST služby, takže se to vůči koncovému klientovi tváří jako jedno velké GraphQL schéma.

Takže je to tak, jak píšete, máme tam předřazený aplikační server. Výhoda je, že ten si může sám vybrat protokol, se kterým se mu pracuje dobře. U Next.JS je to GraphQL, v Javě a C# to bude pravděpodobně spíše gRPC.

Díky tomu, že máme databázi "zavřenou" vůči vnějšímu světu, řešení autentizační issue posouváme a soustředíme se jiné funkce. Nicméně na to nezapomínáme a chceme to řešit.

Na význam ceny, která se na první pohled do struktury nehodí, odpoví příští článek. Prosím o trpělivost. Co se týká rekurzivních query, tak u nich jsme si prakticky ověřili, že na větších datech nejsou dostatečně rychlé.

Porovnání vůči in-memory databázím nedává smysl, pokud bychom neimplementovali klíčovou část katalogového API a testovali na shodných dotazech / datasetech. Toto jsme udělali pro PostgreSQL a Elasticsearch a zabralo to několik měsíců práce. Bohužel na víc testů už není prostor. Obecně nedává smysl ukazovat výkonnost řešení na jednom izolovaném dotazu, ale aby dávalo smysl, je nutné řešit na vzorku reálného provozu z nějakého řešení. Jinak se bude pořád jednat jen o "akademické diskuse".

Na vyse odpovede vam odpovie prvy clanok serie.

Jo, dekuju, mate pravdu. Ten prvni clanek serialu mne unikl. Presto - ja jsem konzervativni, kdyz to neni vylozene extra vyhodne pouzivam zabehane vzorce/standardy.

Běžíte stále LAMP? Jinak i od flat-files jsme se k RDBMS také museli nějak dopracovat.

To je určitě zdravý pohled na věc. Pokud vám dobře funguje to, co používáte, není důvod to měnit.

Nové komponenty musí přinést kvalitativní skok v nějaké oblasti, kterou řešíte - ať už výkon / snížení nákladů na provoz, nebo náklady na vývoj (můžu smazat spoustu řádků kódu, o které bych se musel starat sám), nebo jednodušší zapracování / shánění nových lidí (tj. levnější mzdové náklady).

Ja se obavam, ze je to zbytecna prace.

Taky tomu moc nerozumím.

Je to financované EU, takže vlastně nevím, jestli jen ten grant drží ten projekt při životě a autoři to zabalí až příjem vyschne, a nebo to má nějaký větší potenciál.

Jde mi o to, že ta databáze třeba může být dobrá, ale pokud se ten projekt neuživí a skončí, tak chudáci ti, kteří to v něčem použili - budou muset migrovat a to bude práce navíc.

1. 2. 2024, 11:19 editováno autorem komentáře

Pro tyto jednoúčelové speciály nemáte moc náhradu. Většinou to řeší něco, co se v SQL dělá extrémně špatně, a výsledek může být pomalý a může vám přetěžovat db. Nejsem expert na e-shopy, takže mohu být mimo, ale řekl bych že tato db cílí na eshopy typu alzy nebo mall.cz. Velké a hodně zatížené. Tam pokud budou mít zájem, a licence to dovolí, budou mít bezproblémově kapacity, aby případně pokračovali ve vývoji. Tyto databáze nejsou extra komplikované, a šikovný (třeba ne průměrný) programátor si s nimi poradí.

Rekl bych, ze predstava, ze si provozovatel libovolne aplikace bude sam vyvijet nejakou libovolnou databazi je hodne naivni. Zcela bez ohledu na velikost.

Naopak, pokud ma firma svepravne vedeni, tak nebude nasazovat zadnou technologii, ktera neni na trhu dostatecne dlouho a neporadi si sni dostatecne velky pocet lidi/dodavatelu.

Jednoduse proto, ze nechce kazdych par mesicu resit, ze to uz zase umrelo nebo odesel jediny clovek, ktery o tom neco vedel.

To platí za předpokladu, že je na trhu nějaká technologie, kterou si můžete koupit, a která vám vyhovuje, a která je na trhu dost dlouho. U jednoho projektu, kterého jsem se účastnil jsme řešili neskutečně dlouho problémy s nasazením jedné analytické databáze, tehdy 10 let starý produkt, v majetku velké korporace. Tři roky trvalo, než se podařilo tento produkt nasadit - odladit chyby, stabilizovat. Za tu dobu by si firma jednoúčelovou colum store databázi napsala bez problémů. Produkt neumřel, ale dostal jiného majitele, který se snaží vytěžit, co jde, takže bez ohledu na podepsané smlouvy změnil licenci, změnil ceny, a ta firma musí nakonec tento produkt stejně opustit. To by se u vlastní databáze nestalo.

Je důležité si uvědomit, že jsou různé typy databází s různou složitostí. V momentě, kdy například nemusíte řešit plný ACID nebo máte např. append only data, tak napsat si vlastní databázi není až tak pracné. Dnes navíc nemusíte psát 100% kódu - na hromadu komponent databáze jsou knihovny, můžete vzít existující řešení a to si upravit, nebo napsat extenzi do Postgresu nebo MySQL. Na druhou stranu to znamená, že musíte mít vývojáře i management, který je v obraze a rozumí technologiím - což může být problém.

Nemá cenu si psát vlastní řešení, které je k dispozici za rozumných podmínek a rozumnou cenu. Pokud ale už musíte hodně znásilňovat nějakou technologii, tak je lepší si napsat vlastní db - i když to může být jenom knihovna, nebo nějaký wrapper - a in memory db jsou jednoduché.

.... ale řekl bych že tato db cílí na eshopy typu alzy nebo mall.cz. ....

vseobecne by se snad dalo souhlasit, ale ja mam u toho takovy zvlastni pocit.

Na netu je mozno si precist napr. o te Alze a tom jejich systemu a ten jede tvrde uz desetileti na MSSQL a v soucasnosti je pry mozno pouzit i pgsql nebo Mongo. T.zn. ze i takove velke shopy 'patrne' nepotrebuji nejakou specialni databazi. U Alzy napr. tu rychlost resi tak, ze servry maji 6 TB pameti.
V tech popisech tech velkych shopu je ovsem napadne, ze ta problematika neni ani tak ta databaze, ale ta komplexita cele problematiky. Ja se jako rada dalsich zde nedokazu tak nejak zbavit dojmu, ze autori to cele delaji hlavne 'rádi'.

Jak to mají v Alze by mne zajímalo také, nicméně pochybuji, že by jeli čistě na MSSQL nebo čistě na Postgresu. Co jsem zažil, tak i v rámci jednoho projektu se používal Postgres, a MySQL (pro jiný typy dat a dotazů), do toho redis a Elastic. Zde popisovaná evitaDB není ani tak konkurent Postgresu jako spíš Elasticu. Můžete mít dost paměti, tak že kompletně všechna data a indexy budete mít v RAM, a inmemory databáze bude rychlejší (protože používáte jednodušší datové struktury - přímočařejší), a to přestože to bude naprogramované v Javě. Můžete se podívat třeba na testy MonetDB a Postgresu - a v určitých testech je Monet 100x rychlejší, a pokud by se použilo jádro, které používá vektorové zpracování dat, tak je 1000x rychlejší.
Není to proto, že by byl Postgres špatně naprogramovaný - žádná relační db není 2x rychlejší než Postgres, ale je to o tom, že pro inmemory db můžete použít jiné algoritmy a jiné datové struktury.

To, že má někdo nějaký sw rád, a rád na něm dělá, je dobře. Navíc to jak to tady autor prezentuje mi přijde jako věcné, realistické, bez snahy někoho balamutit. Možná si tady ještě pár pamětníků bude pamatovat pár projektů, které prošly zdejším IT mediálním prostorem ve stylu úžasná databáze, a nový dotazovací jazyk, který nahradí SQL, atd atd. EvitaDB mi ale nepřijde jako tenhle případ. Pro mne EvitaDB není databáze, kterou bych použil, nebo se s ní někdy prakticky setkal, a stejně tak pro 80% čtenářů roota. Stejně jako se čtenáři roota asi nesetkají s proudovými databázemi nebo databázemi polí. Je to ale ukázka jak se dají dělat věci inteligentně - ne úplně otrocky. Jestli je to správné nebo ne, to záleží na kontextu.

Grant skončil rokem 2022 (to je dohledatelné). Rozvoj financujeme i nadále sami, protože databázi současně používáme pro vlastní potřeby. Vlastnosti databáze nám kompenzují část práce, kterou bychom museli tak jako tak investovat na stejné funkcionality budované nad "zavedenou" databází. Riziko, že se projekt jednou ukončí tu je samozřejmě vždy - ale záruku nemáte nikdy a to ani u největších společností.

Výhoda u této databáze je ta, že cílí na to být sekundárním vyhledávacím indexem - tj. primární data a primární logiku máte jinde. evitaDB vám pomáhá jen zrychlit a zlevnit vývoj frontendu + ustát peaky v návštěvnosti (a zároveň na tom neprodělat kalhoty), což je jen část Vašeho systému.

Jinak k těm grantům - velká část toho, co v IT dennodenně používáme vznikla díky grantům a státním zakázkám - TCP/IP, SQL, PostgreSQL, HTTP, ADA, PL/SQL, ...

Mě třeba fascinuje, že lidi dělají pořád tu stejnou chybu a volí jazyk s GC pro psaní DB.

To nie je chyba, len clovek nesmie byt tzv. lopata-programator.

Neviem ako java, ale robim v C# a tam som sa dostal k porovnaniu nativnych a manazovanych riesni, co sa tyka vykonu req/sec, tak server (+redis) v ruste mal pripustnost vyssiu len o 2%, dlzka spracovania requestu bola priblizne rovnaka. Zas ine riesnie co bolo v C a prepisovalo sa do C#, tak tam bol narast vykonu o 15%. Co sa tyka RAM tak tam to bolo viac o konstantu a drzalo sa to spolu umerne vykonu.
A to vsteko bez akychkolvek optimalizacii.

C# poslednych X rokov ide na vykon, lebo sa pouziva v cloudovych sluzbach, takze optimalizaciami dalo by sa vytazit este viac vykonu a vyrazne zredukovat pouzivanie GC. Samozrejme, ked sa robi inMemory Db tak sa trochu treba pohrat s memory layoutom a vediet ako GC funguje, ale to pre dobreho programatora nie je problem.

Navyse JIT ma vyrazne viac kontextu ako staticky kompilator a preto vie mnohe kusy zoptimalizovat lepsie.

Myslim, ze v Jave to bude podobne. Navyse jetvuju uspesne databazy, ktore tieto jazyky pouzivaju. Napriklad RavenDb (C#) je vyrazne richlejsia ako MongoDb (C++ a bez transkacii).

Na transakce u RavenDB pozor - viz. poslední testy od Jepsena.

Tak to by mě docela zajímalo, protože (nedeterministický) GC na DB je dle mých zkušeností totální zlo. Já mám teda zase zkušenosti jen s JVM, ale tady jde o to, že vy dostanete odpověd za třeba 50ms, ale třeba i běžně za 500ms když se trefíte do GC a při fullGC jste už v sekundách v lepším případě. Tohle fakt moc nechcete, ale rád se přiučím...

Nepodceňoval bych vývoj na poli GC. Bohužel jsme v rámci našich performance testů jsme měřili jen průměrnou latenci + směrodatnou odchylku a neměřili její distribuci, ale ta čísla vycházela celkově dobrá - a to jsme ještě stále na Java 17 a používali jsme výchozí GC.

Ono hlavne nie je GC ako GC, napr. serverovy GC pre C# (resp. Net Core) tie zaseky reguluje na minimum, takze ta nedeteminickost je na urovni max. stoviek nanosekund. A treba si povedat, ze ani aplikacie napisne v nemanazovanom kode nie su uplne deteministicke (spominane DB napriklad budu nedtemnisticke v tom ake datove stranky maju prave nacitane, na vytazeni IO, co prave robi planovac OS atd...).

Samozrejme realtime program na realtime OS by som s tym nerobil, ale databazu kludne.

Divej, já jsem pracoval na pár projektech, kde se zpracovávalo celkem velké množství dat, a pokud to bylo v jazyce s GC, tak GC byl od nějaké fáze ten největší problém. A je celkem jedno jaký jazyk to je, i když jsou jazyky, kde si člověk může zavolat mmap a mít svoji vlastní ne-gc paměť (třeba v go to jde).

Až se takový projekt dostane do fáze, kdy už je celkem použitelný, tak se začne řešit to, aby se alokovalo míň paměti a aby se některé věci znovu používali (object pools, atd...), aby se ulehčilo GC. A toto se děje vždycky...

V jazyce, kde si člověk může alokovat sám je to v pohodě, protože se dají použít např. inkrementální alokátory a pak zahodit všechno najednou - a toto je asi to nejlepší řešení při zpracovávání požadavků, kdy se po zpracování všechny dočasné data prostě zahodí (nic z těch dat není potřeba, GC je úplmý waste of cycles v tomto případě).

Navíc, při in-memory DB chci určitě použít SIMD, protože jaký má smysl volat stovky funkcí při zpracování jednoho řádku, když všechno mám k dispozici... Kolik managed jazyků umí SIMD? Snad jen C#...

A porovnávání čehokoliv s MongoDB si strč někam - MongoDB je sračka :)

Java má podporu pro non-managed memory a v nové verzi to již budeme využívat. Stejně tak má i memory mapped files, i když třeba Andy Pavlo nedoporučuje MMF pro účely databází používat. Co se týká SIMD, tak nějaké SIMD konverze umí udělat Java kompilátor sám, ale je to špatně predikovatelné - proto vzniklo Vector API, které je aktuálně v sedmé verzi inkubátoru (ale už se dá používat a API je stabilní). Např. Lucene už Vector API používá pro správu HSNW indexu. My pod kapotou používáme pro většinu výpočtů RoaringBitmap, kde C implementace už SIMD implementované má, Java verze prozatím ne - ale pevně věřím, že jednou bude.

Dělám si našeptávač do osCommerce. Chtěl bych se zeptat autorů, jesti můžu udělat to, že použiju evitaDB pro našeptávač:

1. nastavím evitaDB pro svou neuronku v Rustu místo SQLite;
2. přidám do evitaDB sloueček karma jako výsledek inicializace neuronky při načtení stránky, kdy se vždycky přepočítává karma produktů por daného uživatele relativně k aktuálnímu a minulému adresáři v katalogu a dalším parametrům;
3. použiju evitaDB pro našeptávač nebo filtrování produktů s tím, že setřídím podle karmy.

Tohle bude nepraktické řešit tady - nemohli bychom se s diskusí přemístit na náš Discord server?