A ScyllaDB jobb, mint Cassandra, és íme, miért.

A ScyllaDB az egyik legújabb NoSQL adatbázis, amely igazán nagy átviteli sebességet kínál ezredmásodperc alatti késéseknél. A fontos szempont az, hogy ezt a modern NoSQL adatbázis költségeinek töredékével valósítja meg.

A ScyllaDB a Cassandra szinte minden tulajdonságát megvalósítja a C ++ nyelven. Ha azt mondanánk, hogy ez pusztán C ++ port, az alábecsülést jelentene. A Scylla fejlesztői sok olyan változtatást hajtottak végre a motorháztető alatt, amelyek nem láthatók a felhasználó számára, de hatalmas teljesítménynövekedéshez vezetnek.

Ugye viccelsz?

Nem, én nem.

Amint láthatja (ha erre a linkre ment), a legtöbb esetben a Scylla 99,9-es percentilis késleltetése 5–10-szer jobb, mint Cassandra.

Az itt említett referenciaértékekben is egy szokásos 3 csomópontos Scylla-fürt szinte ugyanolyan teljesítményt nyújt, mint egy 30 csomópontos Cassandra-fürt (ami a költség 10-szeres csökkenéséhez vezet).

Hogyan lehetséges ez?

A legfontosabb pont az, hogy a Scylla C ++ 14-be van írva. Tehát várhatóan gyorsabb lesz, mint a pusztán JVM-en futó Cassandra.

A Scylla-ban azonban számos jelentős alacsony szintű optimalizálás történt, ami jobbá teszi, mint a versenytársa.

Megosztott-Semmi megközelítés

Cassandra a párhuzamosság szálaira támaszkodik. A probléma az, hogy a szálakhoz kontextuskapcsoló szükséges, ami lassú.

A szálak közötti kommunikációhoz zárolást kell végrehajtania a megosztott memóriában, ami ismét pazarolt feldolgozási időt eredményez.

A ScyllaDB a seastar keretrendszert használja az egyes magok kéréseinek feldarabolására. Az alkalmazás magonként csak egy szálat tartalmaz. Így, ha egy munkamenetet az 1. mag kezeli, és az adott munkamenetre vonatkozó lekérdezési kérelem a 2. maghoz érkezik, akkor az az 1. magra irányul feldolgozásra. Bármelyik mag képes kezelni a választ ezután.

A megosztott semmi megközelítés előnye, hogy mindegyik szál saját memóriával, cpu-val és NIC puffersorral rendelkezik.

Azokban az esetekben, amikor a magok közötti kommunikáció nem kerülhető el, a Seastar aszinkron, zár nélküli magok közötti kommunikációt kínál, amely nagyon skálázható. Ezek a zár nélküli primitívek magukban foglalják a Futures and Promises-t, amelyeket meglehetősen gyakran használnak a programozásban, és így fejlesztőbarátak is.

Kerülje a kernelt

Ha egy sor megtalálható az SSTable-ben, azt a hálózaton keresztül kell elküldeni az ügyfélnek. Ez magában foglalja az adatok másolását a felhasználói térből a kerneltérbe.

A Linux kernel azonban általában többszálas zárolási műveleteket hajt végre, amelyek nem méretezhetők.

A ScyllaDB gondoskodik erről a Seastar hálózati verem használatával.

A Seastar hálózati vereme a felhasználói térben fut, és a DPDK-t használja a gyorsabb csomagfeldolgozáshoz. A DPDK megkerüli a kernelt, hogy az adatokat közvetlenül az NIC pufferbe másolja, és 80 CPU cikluson belül feldolgozza a csomagokat. (forrás: DPDK honlap)

Ne hagyatkozzon az oldalgyorsítótárra

Az oldal gyorsítótár nagyszerű, ha szekvenciális I / O-val rendelkezik, és az adatokat vezetékes formátumban tárolja a lemez.

A Scylla / Cassandra-ban azonban SSTable-k formájában vannak adatok. Az oldal-gyorsítótár ugyanabban a formátumban tárolja az adatokat, amely nagy mennyiségű memóriát foglal el a kis adatok számára, és ha sorba akarja állítani / deserializálni kell őket, amikor át akarja adni azokat.

A ScyllaDB ahelyett, hogy az oldal gyorsítótárára támaszkodna, memóriájának nagy részét a sor-gyorsítótárhoz rendeli.

A Row-Cache adatai optimalizált memóriaformátumban vannak, amely kevesebb helyet foglal és nem igényel sorosítást / deserializációt

A soros gyorsítótár használatának egy másik előnye, hogy nem távolítja el, ha tömörítés történik, miközben az oldal gyorsítótárát megsemmisítik.

Ezek a ScyllaDB legfontosabb optimalizálásai, amelyek sokkal gyorsabbá, megbízhatóbbá és olcsóbbá teszik, mint a Cassandra. A Scylla számos más optimalizálással rendelkezik a motorháztető alatt, amelyek itt találhatók.

Ha kíváncsi több olyan mintára, mint a fenti, vagy ha kapcsolatba szeretne lépni, lépjen velem kapcsolatba a LinkedIn vagy a Facebook oldalon, vagy e-mailt küldjön a [email protected] címre.