> Hát na, ettől szoktam agyfaszt kapni, amikor kinn van egy specializált workload, amivel tud százszoros teljesítményt rövid távon, mielőtt megborulna, aztán amikor heteket kellene futnia változatos workload esetén, akkor meg kapok egy degradált teljesítményt és ugyanúgy ott vagyok, hogy kell egy szakértő, aki elmagyarázza, hogy a termék alapvetően jó ("nézze csak, itt van a benchmark"), csak nem jól fogom.
En nem azt mondtam, hogy csak egy specializalt workload eseten gyorsabb hanem, hogy a gyorsulas nem egyenlo merteku minden workload eseten. Altalanossagban veve minden workload eseten jelentosen gyorsabb a scylla, ha nem azt bug-nak vesszuk es kijavitjuk. En peldaul jelenleg is egy ilyen bug kijavitasan dolgozok.
Mi nem egy szep benchmarkkal adjuk el az adadbazisunkat, mindenki tud olyan benchmarkot kesziteni amiben az o sajat termeke jobb mint tetszoleges X masik termek. Az ilyen bullshitek kibuknak a PoC elso napjan. A klienseink mind egy szalig egy alapos PoC utan dontottek ugy, hogy valtanak, nem egy bullshit marketing-maszlag alapjan.
> Igen, amíg el nem ér a falig. A jellemző probléma az, hogy Cassandra esetén látok a futásban trendeket, hogy lassul-lassul, de dolgozik, ScyllaDB esetén pedig azt láttam, hogy megy-megy-megy-összeomlott és azért ez nem igazán üzemeltetés barát dolog. Értem én, hogy gyorsabb, de a gyorsaságnak ára van.
Ezek mind bugok amiknek nagyreszet kijavitottuk es a maradekon dolgozunk.
Hogy miert hangsulyozom annyira a bugokat? Mert a bugokokat ki lehet javitani es ki is javitjuk de ami architekturas limitacio azzal nincs mit kezdeni.
> A mindenféle vizsgálatot, ami Java esetén out-of-the-box benne van a JVM-ben, viszont natív C/C++ esetén nagyvonalúan el lehet hagyni, aztán pedig lehet csodálkozni, hogy rommá törik, amint elterjed.
>
> A JVM azért eléggé gyors, megfelelően megírt Java kód eléggé gyorsan és hatékonyan tud futni a C/C++ kódhoz képest (adott esetben akár gyorsabban is), viszont amitől nem lehet a JVM esetén megszabadulni, az a folyamatos ellenőrzés és finomra hangolható policy, ami a homokozóban > tartja a futtatott kódot és csak bizonyos helyekre engedi ki.
>
> Általában addig gyorsabb jelentősen a C/C++ kód, amíg ezeket a folyamatos ellenőrzéseket elhanyagolják, hogy úgy se lesz belőle baj, minek nézzem meg minden egyes hívásnál, hogy tömbön belül vagyok-e még, hoppá, egy remote buffer overflow exploit, hogy került ez ide?!
Hat eppen ez az, hogy a JVM es a Java sulyosan korlatolt a sebesseg teren. Ha nem igy lenne akkor a scyllanak nem lenne letjogosultsaga, mert mar valaki reg optimalizalta volna a C* kodbazist. Ellenben azt latjuk, hogy komoly igeny van a piacon egy gyorsabb C*-ra.
A scylladb (a ceg, akkor meg cloudius-systems) is ugy kezdte anno, hogy a C*-ot (es ugy altalaban a JVM-et) probaltak gyorsabba tenni de nem sikerult akkora gyorsulast alerni ami piackepes lett volna. A C*-nal a Java-ban valo optimalizalasal elertek a falig es nincs tovabb (sot, a C*-nal is kiserleteznek C++-ban irt storage-engine hasznalatara).
Es hidd el a teljesitmeny kulonbsegek *messze* tulmennek azon, hogy leellenorzom-e a tomb hatarait vagy nem, ez egy massziv lebutitasa a problemanak.
Igen lehet ugy is lehet programozni C++ ban ahogy te mondod. De a C++ rengeteget fejlodott a C++98 ota es mi mar a C++17-et hasznaljuk. A C++11 ota nagyon mas vilag a C++.
--
:wq