Vlákno názorů k článku evitaDB: spuštění, definice schématu a naplnění daty od cc - Mě třeba fascinuje, že lidi dělají pořád tu...

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.