Kas slepiasi už šių duomenų bazių?
Kai pradedi gilintis į NoSQL pasaulį, anksčiau ar vėliau susiduri su Apache Cassandra. Ši duomenų bazė jau seniai tapo standartu, kai reikia valdyti milžiniškus duomenų kiekius paskirstytose sistemose. Tačiau pastaraisiais metais vis dažniau girdime apie ScyllaDB – naująją kartą, kuri žada tą patį funkcionalumą, tik daug greitesnį.
ScyllaDB atsirado ne iš tuščios vietos. Jos kūrėjai ėmė Cassandra koncepciją ir nusprendė perrašyti viską iš naujo C++ kalba, kai originalas buvo parašytas Java. Skamba paprasta, bet rezultatai tikrai ne tokie paprasti. Kalbame apie 10 kartų ar net didesnį našumo padidėjimą tam tikrose situacijose.
Bet ar tai reiškia, kad Cassandra tapo pasenusi? Ne taip greitai. Cassandra turi milžinišką bendruomenę, dešimtmečio patirtį gamybinėse aplinkose ir ekosistemą, kurią sunku pervertinti. Tai klasikinis atvejis, kai naujesnis nebūtinai reiškia geresnį visoms situacijoms.
Architektūros skirtumai, kurie daro įtaką
Pagrindinis skirtumas tarp šių dviejų sistemų slypi giliai po gaubtu. Cassandra veikia Java virtualioje mašinoje (JVM), o tai reiškia, kad ji turi kovoti su garbage collection pauzėmis. Jei kada nors teko stebėti Cassandra klasterį gamyboje, tikriausiai matei tas trumpas, bet skaudžias pauzes, kai GC nusprendžia atlikti savo darbą.
ScyllaDB šio galvos skausmo neturi. Būdama parašyta C++, ji tiesiogiai bendrauja su operacine sistema ir aparatine įranga. Tai leidžia efektyviau išnaudoti CPU, atmintį ir diskus. ScyllaDB komanda įdėjo daug pastangų, kad sistema automatiškai prisitaikytų prie aparatinės įrangos – ji pati nustato, kiek gijų naudoti, kaip valdyti atmintį ir kaip optimizuoti I/O operacijas.
Kitas svarbus momentas – kaip šios sistemos tvarko konkurenciją. Cassandra naudoja tradicinį thread-per-core modelį su bendrinama atmintimi, o ScyllaDB pasitelkia shared-nothing architektūrą. Kiekvienas CPU branduolys gauna savo atminties dalį ir dirba nepriklausomai. Tai sumažina lock contention ir pagerina našumą daugiabranduliuose procesuoriuose.
Našumo testas realiame pasaulyje
Skaičiai popieriuje atrodo įspūdingai, bet kas nutinka realiose situacijose? Kai testuoji šias sistemas su panašia konfigūracija, ScyllaDB dažniausiai laimi throughput kategorijoje. Kalbame apie 1-2 milijonus operacijų per sekundę vienoje mašinoje, kai Cassandra paprastai pasiekia 100-300 tūkstančių.
Tačiau čia yra niuansas – šie skaičiai labai priklauso nuo workload tipo. Jei tavo aplikacija daugiausia skaito duomenis ir tie duomenis telpa į cache, skirtumas gali būti mažesnis. Bet kai pradedi intensyviai rašyti duomenis arba dirbti su dideliais duomenų rinkiniais, ScyllaDB pranašumas tampa akivaizdus.
Latency – tai kita istorija. ScyllaDB paprastai rodo žemesnį p99 latency, nes neturi GC pauzių. Cassandra p99 latency gali šokti iki kelių šimtų milisekundžių, kai vyksta garbage collection, o ScyllaDB paprastai išlieka stabilesnė. Tai kritiškai svarbu aplikacijoms, kurioms reikia nuspėjamo atsako laiko.
Vienas įdomus pastebėjimas iš praktikos – ScyllaDB geriau elgiasi su dideliais duomenų įrašais. Kai pradedi saugoti objektus, kurie didesni nei keletas kilobaitų, ScyllaDB efektyvumas tampa dar akivaizdesnis. Cassandra tokiais atvejais pradeda kentėti, ypač kai GC turi tvarkyti dideles heap struktūras.
Suderinamumas ir migracija
Vienas iš gražiausių ScyllaDB sprendimų – jie išlaikė suderinamumą su Cassandra Query Language (CQL) ir wire protokolu. Tai reiškia, kad dauguma Cassandra klientų bibliotekų veikia su ScyllaDB be jokių pakeitimų. Tavo Python aplikacija su cassandra-driver? Veiks. Java aplikacija su DataStax driver? Irgi veiks.
Bet suderinamumas nėra 100%. Yra smulkių skirtumų, kurie gali sukelti problemų. Pavyzdžiui, kai kurios Cassandra funkcijos, kaip materialized views, ScyllaDB implementuotos skirtingai arba vis dar tobulėja. Taip pat kai kurie JMX metrics, kuriuos naudoji monitoringui, gali neegzistuoti arba turėti kitokią reikšmę.
Migracija iš Cassandra į ScyllaDB nėra triviali, bet įmanoma. Paprasčiausias būdas – naudoti dual writes kurį laiką, kol pilnai persikelsi. Arba gali pasinaudoti ScyllaDB Migrator įrankiu, kuris padeda perkelti duomenis. Tačiau prieš tai būtinai išbandyk savo workload testavimo aplinkoje – gali būti netikėtumų.
Operacinė realybė ir palaikymas
Cassandra turi vieną didžiulį pranašumą – brandą. Ji naudojama Netflix, Apple, Instagram ir šimtuose kitų įmonių jau daugiau nei dešimtmetį. Tai reiškia, kad beveik bet kokiai problemai rasi atsakymą Stack Overflow arba kokiame nors blog poste. Bendruomenė milžiniška, įrankių ekosistema plati.
ScyllaDB jaunesnė, bet auga sparčiai. Komercinis palaikymas geras – ScyllaDB įmonė aktyviai investuoja į produktą ir klientų aptarnavimą. Tačiau jei esi įpratęs prie open source bendruomenės palaikymo modelio, gali pastebėti, kad ScyllaDB bendruomenė mažesnė. Forume rasi atsakymus, bet gali tekti palaukti ilgiau.
Diegimo ir konfigūravimo prasme ScyllaDB paprastesnė. Ji turi gerą auto-tuning – dažniausiai tiesiog paleidi ir ji pati nustato optimalius parametrus. Cassandra reikalauja daugiau rankinio darbo su heap dydžiais, GC nustatymais ir kitais JVM parametrais. Tai gali būti privalumas arba trūkumas, priklausomai nuo to, kiek kontrolės nori.
Monitoring ir debugging įrankiai Cassandra brandesnį. Nodetool, JMX metrics, įvairūs third-party įrankiai – viskas gerai dokumentuota ir patikrinta. ScyllaDB turi savo įrankius, kurie veikia gerai, bet ekosistema mažesnė. Jei naudoji Prometheus ir Grafana, abi sistemos integruojasi neblogai.
Kaina ir resursų naudojimas
Čia ScyllaDB tikrai spindi. Kadangi ji efektyviau naudoja aparatinę įrangą, gali pasiekti tą patį throughput su mažiau serverių. Praktikoje tai reiškia, kad cloud infrastruktūros sąskaitos gali būti gerokai mažesnės. Kai kurios įmonės praneša apie 50-70% infrastruktūros sąnaudų sumažėjimą po migracijos.
Tačiau yra niuansas – ScyllaDB nori galingų mašinų. Ji sukurta išnaudoti visus resursus, kuriuos jai duodi. Tai reiškia, kad maža EC2 instancija neatskleis jos potencialo. Cassandra gali veikti ir ant kukliesnės aparatinės įrangos, nors ir ne taip efektyviai.
Atminties naudojimas irgi skiriasi. Cassandra reikia nemažai heap atminties, ir dažnai tenka duoti 8-16GB ar net daugiau JVM. ScyllaDB naudoja atmintį efektyviau – ji tiesiogiai valdo cache ir kitas struktūras be JVM overhead. Tai leidžia daugiau atminties skirti duomenims, o ne infrastruktūrai.
Diskų I/O prasme abi sistemos panašios – naudoja LSM tree struktūrą su compaction. Bet ScyllaDB compaction paprastai efektyvesnis ir mažiau trikdo normalų darbą. Cassandra compaction gali sukelti latency spike’ų, ypač jei nesuderinai parametrų tinkamai.
Kada rinktis vieną ar kitą
Cassandra vis dar puikus pasirinkimas, jei tau reikia maksimalios brandos ir stabilumo. Jei tavo įmonė jau turi Cassandra ekspertizės, migracija į ScyllaDB gali neatnešti pakankamai vertės, kad pateisintų pastangas. Taip pat jei naudoji specifines Cassandra funkcijas ar integracijas, kurios ScyllaDB dar nevisiškai subrendusios.
Finansinės institucijos, sveikatos priežiūros sistemos ir kitos labai reguliuojamos sritys dažnai renkasi Cassandra dėl jos ilgos istorijos ir plačios adoption. Auditoriai ir compliance komandos geriau žino Cassandra, o tai sumažina biurokratinį sunkumą.
ScyllaDB puikiai tinka, kai našumas yra kritinis. Jei statai naują sistemą ir žinai, kad reikės tvarkyti didelius duomenų srautus su mažu latency, ScyllaDB turėtų būti tavo shortlist viršuje. Ypač jei dirbi su real-time analytics, IoT duomenimis ar bet kuo, kas generuoja milžinišką write throughput.
Startupiams ir mažesnėms komandoms ScyllaDB gali būti patrauklesnė dėl paprastesnio operavimo ir mažesnių infrastruktūros sąnaudų. Mažiau laiko praleidžiama tuning’ui ir troubleshooting’ui reiškia, kad galima daugiau fokusuotis į produktą.
Ateities perspektyvos ir galutinės mintys
NoSQL duomenų bazių pasaulis nuolat keičiasi, ir abi šios sistemos aktyviai vystosi. Cassandra 4.0 versija atnešė nemažai patobulinimų, įskaitant geresnį virtual tables palaikymą ir audit logging. ScyllaDB irgi nesėdi vietoje – jie dirba prie Raft-based consensus mechanizmo, kuris turėtų pagerinti consistency garantijas.
Įdomu tai, kad konkurencija tarp šių sistemų yra sveika. ScyllaDB iššūkis privertė Cassandra bendruomenę labiau fokusuotis į našumą. O Cassandra branda ir funkcionalumas verčia ScyllaDB komandą užpildyti spragas ir tobulėti.
Jei šiandien turėčiau rinktis naujam projektui, greičiausiai pradėčiau nuo ScyllaDB, nebent turėčiau specifinę priežastį rinktis Cassandra. Našumo pranašumas ir paprastesnis operavimas yra sunkūs argumentai. Bet jei jau turiu veikiančią Cassandra sistemą, kuri atitinka reikalavimus, skubėti migruoti nereikėtų.
Galiausiai, abi šios duomenų bazės yra puikūs įrankiai tinkamose situacijose. ScyllaDB greitis įspūdingas, bet Cassandra patikimumas ir branda irgi turi vertę. Tavo pasirinkimas turėtų priklausyti nuo konkrečių poreikių, komandos patirties ir ilgalaikės strategijos. Išbandyk abi sistemas su savo workload, pamatuok rezultatus ir tik tada priimk sprendimą. Benchmarkai iš interneto gražūs, bet niekas nepakeis realių testų su tavo duomenimis ir tavo naudojimo scenarijais.
