evitaDB, úzce specializovaná databáze pro potřeby e-commerce

evitaDB je úzce specializovaná databáze pro potřeby e-commerce. Dle vývojového týmu složeného se zaměstnanců společnosti FG Forrest a Univerzity Hradec Králové je evitaDB 100x rychlejší než PostgreSQL a 10x rychlejší než Elasticsearch. Vývoj byl spolufinancován Evropskou unií. Zdrojové kódy jsou zveřejněny na GitHubu pod licencí Business Source License 1.1. Nejedná se tedy o Open Source ani o Free Software.

16.8.2023 00:11 | Ladislav Hagara | IT novinky

Komentáře

[antinazi]

jak je neco financovano EU tak je na konci nemec, stopy vedou do GTS/Telekom

[antinazi]

https://www.root.cz/clanky/ipv6-u-nejvetsich-ceskych-operatoru-v-roce-2023-vodafone-a-ti-druzi/nazory/

Aneb kdy uz pochopite ze ti druzi jsou ve skutecnosti jedni i kdyz spravovany nezavisle ale vsechno jsou to dcerinky Telekom.de. O2 je dcera Tefonica (ES) dcera Telekom.de, Vodafone (UK) dcera Telekom.de

[pupu]

Naprosty nesmysl. O2 Czech Republic je firma vlastnena PPF (konkretne PPF Telco). Telefonica byla predchozim vetsinovym vlastnikem a je to spanelska akciova spolecnost. S nemeckym Telecomem nemaji krome predmetu podnikani nic spolecneho.

[antinazi]

S nemeckym Telecomem nemaji krome predmetu podnikani nic spolecneho

Lzes ale spis nic nevis. Vim ze pod PPF to je ted, primemu Kelnerovi vedeni spolecnosti ale neverim.

[antinazi]

kelnerovo

[fik]

Tak teď jsi se odkopal. Jestli nevěříš faktům, tak pardon, to se dostáváme na úroveň příznivců QAnon, tudíš k smíchu, k pláči, jak kdo chce.

[antinazi]

Jestli nevěříš faktům

Ktere to to jsou?

[Marek]

Takže zázračná databáze v Javě s interním benchmarkem dokazujícím možná že je zázračná a možná že někdo opět prasí pg nebo elastic search.

Škoda že nenabízí smysluplnější benchmark se skutečně měřitelnými výsledky. Trochu to připomíná prezentaci obchodního oddělení.

[Jan Novotný]

Dobrý večer, jsem autor jádra databáze, o které se tu mluví.

Benchmarků jsme dělali více (viz. jejich popis) - interní benchmark je jediné, co aktuálně můžeme nabídnout, ale můžete jej minimálně revidovat a projít i zmíněné testované implementace. Vše je stále dostupné na GitHubu. Pokud budete ochotni podrobit naše řešení Vašemu vlastnímu benchmarku na Vašich datech a use-casech, které stále spadají pod řešenou doménu, budeme jedině rádi a případně s ním i ochotně pomůžeme.

Pokud byste měl další dotazy, bude lepší je řešit na našem Discordu. Konstruktivní kritiku vítáme.

[zajca]

Haha, napíšu úzce specializovanou DB a řeknu, že je 100x rychlejší než obecná databáze. Navíc napsaná v Javě, nechápu jak někdo dnes může ještě dělat takové věci v Javě a prezentovat takové kraviny. Hold je potřeba ty EU chechtáky někde utopit, skončí grant a skočí aj vývoj.

[sid]

A pointa? Pre ten usecase co riesia je to dolezite porovnanie. Ked budem riest pocitanie matic tak ma asi nezaujima, ze iny produkt vie riesit matice a dalsich 1000 veci ale to aky vykon ma pri mojich maticiach. A obecne dnes jazyk je podstatne menej dolezity ako skor veci okolo.

[RealJ]

Pak ale nebudes taky srovnavat pocitani matic s tim jak rychle to generuje grafiku ale budes srovnavat svuj algoritmus s necim srovnatelym aby jsi vedel jestli ten tvuj algoritmus je lepsi nebo nahovno. Tady jsou srovnavany hrusky s jabkami aby se obhajola dotace. Nic vic bych za tim nehledal. Autorum preji hezke vyuziti penez a posilam pisnicku.

[BoneFlute]

Na algoritmus nešaháš. Srovnáváš, čím to proženeš.

[RealJ]

Technicky mas pravdu. To ale nic nemeni na faktu ze srovnavat inmemory read only db vs postgresql v nejakem defaultnim nastaveni je picovina.

[Zdenek H.]

Příjde mi to naopak rozumné.

před 10 - 15 lety by každý rovnou šáhl po sql databázi

před 5 lety by každý rovnou šáhl po ElasticSearch nebo jiné NoSql databázi

když už to celá má hype za sebou tak se rojí další pokusy. Pokud toto řešení dokáže nahradit pro daný use case 10 EL serverů tak je to super. Testy i výkonostní testy jsou k dispozici a může si je každý spustit.

Podívej se na diskuzi na Lupě.

[BoneFlute]

PostgreSQL je obecná relační databáze která taky podporuje nosql, fulltext, etc.

EvitaDB není obecná relační databáze.

Takže samozřejmě to porovnání mě zajímá, a nesmysl to není. Pokud požaduju obecnost, šáhnu po PostgreSQL. Pokud ne, může být EvitaDB dobrou volbou. A proto potřebuju porovnání, abych věděl jaké benefity mi to dá za tu obecnost.

Ledaže byste se vytasil, jak PostgreSQL nastavit tak, aby byl stejně rychlý v požadované doméně.

[RealJ]

Jeste jednou, pokud chci udelat nejaky benchmark tak srovnavam jabka s jabkama a ne hrusky s kolem. Nebo snad u testu EV vozidel vidite porovnani diesel nakladaku a motorky? Ne. Tohle je read only in memmory nosql db, to srovnani vykonu by melo byt s readonly nosql inmemmory db a ne s necim jinym. A ano, pokud te zajima vykon vuci postgresql tak si ho klidne udelej ale bude to pro tvuj use case irelevantni protoze pokud hledas nosql inmemmory readonly db tak tou postgrsql neni.

[BoneFlute]

Tak ještě jednou.

Jsem rád, že napsali v čem je jejich řešení zajímavé proti něčemu co znám. Hned vím, zda nad tím mám přemýšlet.

Zda vám to přijde irelevantní na tom zas tolik nezáleží.

[RealJ]

Tak az si priste budete chtit koupit rodinny vuz, odtestujte i nakladak… ;)

[BoneFlute]

Máte chybu v uvažování.

Já si nechci koupit rodinný vůz, stejně jako si nechci nainstalovat konkrétně PostgreSQL. Já chci vůz a vhodnou databázi na můj problém. Jestli to bude náklaďák, nebo sedan, nebo pickup, nebo taková ta kráva co s tím vozí děti v americe do škol, to je právě to co budu posuzovat.

[RealJ]

Kdyz nechces postgresql na reseni sveho problemu proc srovnavas nastroj na reseni sveho problemu s postgresql? Si protirecis. Tvuj problem ma reseni rradonly inmemmory db, takze srovnavej evitu s dalsimi xx resenim ktere nabizi to co hledas. Pokud jsi plsacenej z dotaci a potrebujes ukazat uspesnost sveho reseni tak vemes nejakou picovinu a porovnas to se svym resenim ktere vyjde skvele. Ja rikam ze kdyby to sve reseni porovnali s jinym podobnym resenim tak to nebude 100x rychlejsi a nejsem presvedcen ani o tom ze to bude rychlejsi uz jenom proto ze porovnavaji reseni ktera nejsou stejna. Co je kurva na tom tezkeho pochopit?

[Jan Novotný]

Dobrý večer, jsem autor jádra databáze, o které se tu mluví.

Dovolím si reagovat na argument srovnávání "jablek s hruškami" a vysvětlit, proč jsme naše alternativní implementace stavěli právě nad PostgreSQL a Elasticsearch. Chtěli jsme mít typické zástupce relačních a NoSQL technologií, které se aktuálně pro řešení e-commerce katalogů používají. Neexistuje žádná oficiální statistika, a informace o použité databázové technologii nebo architektuře si většinou firmy nechávají pro sebe. Přesto existuje řada výjimek - např. Shoptet používá MySQL Galera cluster, Zalando používá farmu Elasticsearch serverů, Pecka Design staví na relační databázi, ale uvažuje o migraci na Elasticsearch a dalo by se pokračovat dál. Pokud se podíváte na diskusní fóra, také si ověříte, jak řada vývojářů přemýšlí. Zároveň jsme chtěli zástupce, kteří jsou open-source a jsou zdarma, to je typicky první volba pro implementátory aplikací.

Stále si myslím, že obě dvě vybrané databáze byly v našem segmentu dobrou volbou, ale nechci se s Vámi přít.

Pokud byste měl další dotazy, bude lepší je řešit na našem Discordu. Konstruktivní kritiku vítáme.

[BoneFlute]

Ten problém nebyl na vaší straně

[zajca]

Sorry krapet sem si musel kopnůt do Javy, každopádně dělat něco zaměřené primárně na performace navíc databázi v Jave už je vtipné, ES a 1000x big data databází pod záštitou apache foundation to jen uceluje :) Benchmark se sice snaží vypadat objektivně, každopádně nijak objektivní není srovnává totiž databázi, která jak píší na GH "evitaDB is expected to act as a fast secondary lookup/search index used by front stores." je dělaná aby seděla jako "cache" před postgre, ale před posgre na čtení nic nepostavili, ale musím vzdát hold, že článek o optimalizaci postgre je zajímavý. Každopádně porovnání s něčím jako ScylaDB by bylo zajímavější. Problém takového řešení je, ale stejně nakonec nákladnost vývoje a features, které nabízí. Udržovat to bude drahé, pokud do toho EU nebude sypat prachy, a pak narazí člověk na škálovatelnost, je fajn držet všechno v paměti pohromadě, ale ta není nekonečná a jakmile ty relační data rozdělím na shardy tak přijdou úplně jiné výzvy, které jiné řešení už mají vyřešeny.

[RealJ]

Souhlas.

[sid]

Vtipne je akurat to, ze v realite sa hodnoti technologia ako celok. Tj monitoring, nasadzovanie, ludi ktoeych mas. Ked budes mat nosql java memory db ktora ti ulohu vyriesi 100x rychlejsie a okrem toho dostanes bonus v pokrocilom monitoringu jvm a oproti tomu rust co prida napr 2x na vykone ale stratis monitoring tak rozumny clovek si vyberie tu prvu moznost. Inac povedane je rozdiel ci zrychlujes o desiatky percent alebo radoco napr 100x.

[Jan Novotný]

Dobrý večer, jsem autor jádra databáze, o které se tu mluví.

Cachování je v e-commerce velmi ošidná věc. Některé části jsou díky kombinatorické složitosti prakticky necachovatelné - např. filtrace v listinzích produktů ve chvíli, kdy cena produktu je dynamická podle přihlášeného uživatele (a uživatel může filtrovat a řadit podle ceny), máte tam parametrické filtrování (stovky parametrů nejsou výjimkou), mění se skladová dostupnost produktů, která má vliv na existenci produktu ve výpisu atd. Uživatelé i zákazníci jsou navíc na "eventuální konzistenci" velmi citlivý, pokud vykoupím poslední kus, pokud změním cenu produktu, chci změny vidět ideálně hned. To vše má vliv na komplexnost a možnost použít ve větší míře cache.

Na volbu databázové technologie pro alternativní implementace jsem odpověděl v jiném komentáři.

Souhlasím s tím, že vývoj je nákladný a že před sebou máme ještě hodně výzev.

Pokud byste měl další dotazy, bude lepší je řešit na našem Discordu. Konstruktivní kritiku vítáme.

[Zdenek H.]

Poddívej se na komentáře na Lupě, tam se toho dočteš víc a na dotazy tam reaguje přímo autor.

Možná by sis měl položit otázku proč to dělají a pak se nad ní třeba zamyslet a pak se pokusit konstruktivně kritizovat.

[RealJ]

Tam autor psal ze z casovych duvodu na to nemeli cas… proc bych mel konstruktivne kritizovat projekt ktery me nezajima? Me jenom zarazi ze se srovnavaji jabka s hruskami, nic vic.

[Jan Novotný]

Dobrý večer, jsem autor jádra databáze, o které se tu mluví.

Nerad bych zabíhal do technologických hádek. Existují reálné případy enginů v Javě, které jsou velmi výkonné - např. QuestDB, Kafka, Lucene / Elasticsearch, Druid, Pinot a mnohé další. Java platforma je nám nejbližší a máme s ní i největší operační zkušenosti a proto volba padla na ni. Dalším faktorem je to, že JVM je naší domovskou platformou a sdílení stejné platformy i pro databázi nám umožňuje provozovat evitaDB v embedovaném režimu, který se např. výborně hodí pro implementaci rychlých integračních testů.

Grant již skončil, vývoj dál pokračuje. Nemohu samozřejmě předvídat budoucnost, ale je v našem vlastním zájmu ve vývoji dál pokračovat, když na něm chceme stavět naše vlastní projekty.

Pokud byste měl další dotazy, bude lepší je řešit na našem Discordu. Konstruktivní kritiku vítáme.

[Drak jak mrak]

TL;DR Relační db nejsou vhodné pro EAV resp. naopak. To pánové objevili celý nový světadíl, řekl bych přímo Ameriku

Zase nechci shazovat práci a odbornost, která za tím určitě je, ale rýpnutí bylo třeba. A třeba se to i dokonce v praxi úspěšně použije, jeden nikdy neví, nechci hodnotit.

[BoneFlute]

Oni nabízejí službu. A tu službu popisují. Nic neobjevují. Vytváříte zbytečný problém.

To už ta zmínka, že je to v Javě je užitečnější.

[Drak jak mrak]

Mě zaujaly spíš technické detaily a za tou "službou" je nějaký postupný vývoj a výzkum. Jejich datový model má dva hlavní aspekty: EAV + hierarchickou (stromovou) strukturu. To jsou dnes již naprosto klasické problémy, které se v SQL db řeší špatně nebo přinejmenším nepohodlně a je o tom popsána spousta internetu.

A jak jsem psal, určitě nechci projekt odsuzovat. Vždyť nakonec docházíme ke stejnému závěru - SQL db na to není ideální. Jen rýpu (v zásadě v dobrém), že totéž by jim každý zkušený databázista řekl rovnou i bez výzkumu

[BoneFlute]

OK.

A tak když už rejpeme, tak ono najít zkušeného databázistu...

[Drak jak mrak]

Tak žádnej učenej z nebe nespad. Dovolím si parafrázovat známé rčení:

Kdo nikdy nezkoušel udělat EAV v SQL, není databázový guru, kdo to zkoušel více jak jednou, je nepoučitelný blázen.

[BoneFlute]

+1

Máte zkušenosti s používáním nosql v relační databázi přes json/xml (jako náhradu za EAV)?

[Mrak jako drak]

Ano, JSON* je podle mě v SQL dobrá náhrada za EAV pro heterogenní data a "free-form" atributy. Zkušeností nemám úplně mnoho, ale co mohu říci, tak se osvědčil. Klíčová otázka je pak samozřejmě indexování položek v JSONu, konkrétně Postgres to umožňuje přímo.

*) XML poslouží také, ale to moc nemusím a zkušeností mám ještě méně.

Je celkem škoda, že tvůrci evitaDB nevyzkoušeli a neporovnali SQL řešení na JSONu. Plus ještě třeba jednu z fint na tu hierarchickou strukturu, tipuji, že by pak Postgres dopadl o dost lépe.

[RealJ]

Tvurci evity chteli dotace a uspesnost projektu nejak musis zhodnotit. Pokud by ho hodnotili stylem vynalezli jsme stejnou inmemmory read only db jakych je tady 300 tak ty dotace tezko obhaji. Kdyz predlozi spravu o tom ze jejich prace je 100x rychlejsi nez neco co hodnotitel nezna protoze tomu nerozumi tak ty dotace obhaji. Kdyby to nedelali kvuli dotacim tak to srovnani udelaji s necim srovnatelnym za srovnatelnych podminek.

[BoneFlute]

ok, už to všichni chápem, a dej pokoj

[RealJ]

LOL

[BoneFlute]

Traverzování kolem stromu podle doc zkoušeli. Nebo špatně čtu?

[Drak jak mrak]

A jo, čtete správně, to jsem zrovna nějak moc rychle přehlédl.

[Jan Novotný]

Asi je to na delší studium závěrů našeho PosgreSQL týmu, ale JSON se při implementacích také zkoušel. Stejně tak Vámi zmiňovaná "finta" MPTT. MPTT algoritmus je užitečný, ale bohužel komplikovaný ve chvíli, kdy se hierarchie v čase mění (a naši zákazníci ji mění až překvapivě často). Proto jsme také kdysi implementovali upravenou verzi tohoto algoritmu PMPTT, která sice má svá omezení předem daný maximální počet uzlů na jedné úrovni a maximální možná hloubka stromu, ale řeší z velké části problém přepočítávání hranic ve stromu. Naše PostgreSQL implementace, kterou jsme testovali používá právě tuto PMPTT knihovnu a Vámi uvedenou "fintu".

[Drak jak mrak]

Aha, na první otázku odpovídáte zde, zkoušeli. Popis PMPTT jsem po upozornění napodruhé pročetl podrobněji a vypadá to na pěkné kompromisní vylepšení, který řeší úpravy hierarchie. Jiná řešení, která se dobře vyrovnají s úpravami, už směřují víceméně k label path.

[Jan Novotný]

Teď si nejsem jistý, jestli tento přístup kolegové testovali. Na první pohled se zdá, že by mohl vyloučit limitace dané PMPTT, ale na druhou stranu by si nejspíš vyžádal další join navíc (pokud by se path udržoval na úrovni tabulky hierarchické entity). Pokud vím, tak naše implementace těží z toho, že hranice jsou už na úrovni vazby na hierarchickou entitu a tudíž join na entitní tabulku není potřeba. Pokud by se stejně ukládaly i ty informace o path (duplicitně), tak databáze objemově naroste (vazeb je řádově víc, než hierarchických entit) a zároveň se bude muset mnohokrát provést ten regex na varchar sloupci. Těžko odhadovat, jak by to posunulo výkonnostní statistiky, ale můj osobní tip je, že spíš směrem dolů.

[Jan Novotný]

Dobrý večer, jsem autor jádra databáze, o které se tu mluví.

Náš datový model kromě atributů, nestrukturovaných dat a hierarchií řeší ještě další problémové oblasti - parametrické filtrování (facety) a práci s cenami. Obě dvě domény jsou v oblasti e-commerce velmi komplexní a výpočetně náročné. Bohužel tyto části ještě nemáme zdokumentované na webu, ale jsou kompletně implementované a pokryté testy. Dokumentaci průběžně doplňujeme a řádu měsíců bude kompletně dokončená.

Kromě jádra databáze přinášíme i automaticky generovaná webová API (REST / GraphQL / gRPC), které by měly vést ke zjednodušení komunikace mezi backendovými a frontendovými týmy a ušetřit práci na obou stranách. Tj. snažíme se nezůstat pouze u databáze jako takové a dívat se na ní z širší perspektivy - tj. jako na API, které má pomáhat při vývoji e-commerce katalogových aplikací. S databází dostanete do ruky i podporu pro vývoj integračních testů (v Javě), způsob jak vygenerovat dokumentaci, detekovat zpětně nekompatibilní změny v modelu, monitoring a další nástroje.

Pokud byste měl další dotazy, bude lepší je řešit na našem Discordu. Konstruktivní kritiku vítáme.

[Drak jak mrak]

Vážím si, že reagujete a nabízíte diskuzi, ale obávám se, že moje kritika zas tak konstruktivní není Zaujaly mě jen právě uvedené aspekty db vrstvy a je mi jasné, že celý projekt a problematika jsou mnohem komplexnější, než co jsem přečetl nebo spíš prolétl. A i v rámci té db vrstvy je vidět, že jste mnoho věcí důkladně prozkoumali a odborně vyřešili. Ale pokud jste ochoten reagovat ještě stručně (více ani není třeba) zde, tak by (asi nejen) mě zajímalo:

• Zkoušeli jste pro implementaci v PostgreSQL více využít db typ JSON? Všiml jsem si, že právě u těch facetů ho využíváte, ale možná by byl vhodný i pro ty atributy aj.
• Proč jste nezkusili jen nějakou custom nadstavbu na existující NoSQL/in-memory db? Porovnání výkonu - jak tu někteří zmínili - by bylo určitě zajímavé a relevatnější než srovnávat s SQL db modelem, byť v mnoha ohledech vyladěným.

[Jan Novotný]

Ad 1) ano testovali - cituji z těch závěrů kolegů:

> Later in the optimization phase, when we revisited hierarchy queries after further performance testing we found that no DB index could be effectively used to further speed up querying in the JSON objects mentioned above. Further testing and re-read of the PostgreSQL documentation led to an unfortunate discovery for us. PostgreSQL does not store statistics about the JSON columns.Therefore, it cannot properly and effectively query the complex JSON objects when read performance is the most important aspect.

Viz. např. tento článek V tomto směru už ale nějaká aktivita v PostgreSQL probíhá, tak se to třeba časem posune.

Co se týká těl entit, které neslouží k vyhledávání - i tam se JSON formát zkoušel, ale nakonec se ukázalo jako rychlejší (na našich datech) ukládat data binárně. Viz. tato kapitola.

Ad 2) tenhle dotaz úplně nechápu - implementace nad PostgreSQL / Elasticsearch byly právě pokusem o naši custom nadstavbu nad existující databází. Důvody pro volbu těchto technologií jsem popsal v komentáři výše (ty důvody byly spíš "byznysové" uznávám). Snažili jsme se o porovnání s technologiemi, o kterých víme, že se v současnosti pro katalogová řešení často používají, jsou open-source a zdarma.

Řada in-memory databází je key/value store, takže implementace pokročilých dotazů by nad nimi byla velmi náročná a i kdybychom vybrali např. VoltDB či Tarantool, který by byl k naší doméně nejblíž, stali bychom se pravděpodobně zase terčem kritiky, proč jsme vybrali zrovna tuhle (málo známou databázi) a ne jinou. Např. zmiňovaná ScyllaDB není in-memory databází, respektive nabízí in-memory tables, ale až v Enterprise placené verzi.

Rozpočet na více jak tři altenativní implementace nám už nevycházel, ani časově ani velikostí týmu.

[Drak jak mrak]

Děkuji za odpovědi. Je vidět, že máte přinejmenší přehled, jaká řešení se nabízejí, a určitě nemusíte projekt nějak obhajovat, alespoň co se mě týče. Přeji hodně štěstí v práci

[BoneFlute]

Přidávám se.