Názor k článku evitaDB: představení rychlé in-memory databáze pro e-commerce od Pavel Stěhule - Je tam několik principiálních problémů: a) U klasické databáze...

Je tam několik principiálních problémů:

a) U klasické databáze jsou data na disku v jiném formátu než v paměti, takže když data načítáte, tak neustále musíte dělat konverze. Klasické relační databáze jsou navržené tak, aby mohli nějak fungovat s minimem paměti. Indexy nejsou navržené, aby měly co nejlepší výkon, ale aby se daly serializovat, případně aby se s nimi dalo pracovat, i když se vám vejde do RAM jen relativně malá část, a pořád to ještě bude funkční. Tohle celé u inmemory databází odpodá (za tu cenu, že pokud se vám data nevejdou do RAM, tak inmemory db nefungují nebo mají tragický výkon).

b) Relační databáze jsou většinou generické (nejsou optimalizované pro nějakou konkrétní úlohu) a jsou to interprety - interpret výrazů, interpret prováděcích plánů, atd. Inmemory databáze tak generické nejsou, mají menší sadu operací, která je zkompilovaná (alespoň větší část).

c) SQL optimalizátor předpokládá relační model, předpokládá denormalizovanou databázi, předpokládá určité chování statistik nad daty. Pokud něco z toho nemáte - jdete proti relačnímu modelu - např. použitím EAV, tak extra výkon mít nebudete.

d) SQL optimalizátor má určitou režii plus protokol. To je vidět u extrémně krátkých rychlých dotazů. Pokud nemáte generickou optimalizaci, nedokážete optimalizovat síťovou komunikaci, tak máte brutální overhead, který se projeví u krátkých extrémně častých dotazů (typicky benchmark). U Postgresu je dobré použít socket, prepared statements. Navíc JDBC je dost těžkotonážní interface - předpokládám, že pro přístup s Javy byl použit. To se dá redukovat uloženými procedurami, ale ne všichni tuhle technologii znají. Dovedu si představit, že to co dělá inmemory databáze, bych mohl dosáhnout v Cčkové extenzi Postgresu (ale ne všechno). Ale pro klasického programátora bude jednodušší si napsat vlastní inmemory db v Javě (a použije řadu hotových knihoven, komponent) než napsat Cčkovou extenzi pro Postgres.

Postgres, pokud máte dost paměti, tak data bude držet v cache datových stránek. Je tam i extenze pg_prewarm, abyste se tato cache rychle zahřála. Problém je, jako u všech klasických databází, že jsou tato data ve formátu v kterém jsou na disku. Když s nimi chcete pracovat, tak je musíte rozbalit, zkonvertovat a tyto konvertovaná data jsou časově omezená na max jeden dotaz, jednu operaci - a jinak to nejde. U klasických databází předpokládáte, že se vám data nevejdou do paměti. Vždy by šlo něco vymyslet, ale pokud nechcete aby vám db lagovala, tak není co moc vymýšlet. Ty klasické databáze nejsou navržené tak, aby vám v nějakých úlohách dávaly nejlepší výkon, ale jsou navržené tak, aby vám ve všech úlohách, které nejdou proti relačnímu modelu, dávaly vždy použitelný výkon. Navrhují se pesimisticky, nikoliv optimalisticky. U inmemory db je to pravý opak.

Plus máte nějakou režii s garancemi konzistence, s implementací zámků. Inmemory db mohou používat techniky, které jsou jednodušší, rychlejší - mohou používat podobný model jako SQLite. To klasické databáze nemohou - dotazy tam trvají delší dobu, běžně dochází k souběhu, a s jednoduchými řešeními by to ve více uživatelském režimu (máte víc zapisujících procesů) mělo tragický výkon (což je např. vlastnost SQLite).

Nějaký vývoj směrem k tomu, co dělají inmemory db, je třeba i u Postgresu (u jiných db to nesleduji), např. https://www.orioledata.com/ nicméně obecný názor je, že klasická databáze nemá suplovat inmemory databázi. Cílí to někam jinam, má to jinak uložená data, tudíž i jiné vlastnosti

Obecně u benchmarků různých technologií je několik problémů - první, že se občas porovnává neporovnatelné, druhý, že se porovnává pouze jeden use case, a třetí - že dost často autoři testů mají expertní znalost pouze jedné technologie, ale už pak jim chybí expertní znalost těch dalších technologií. Plus samozřejmě, že může být zadání, které nějaké technologii prostě sedět nebude.