Kodėl tradicinės duomenų bazės nebespėja
Prisimenu, kaip prieš kokį dešimtmetį dirbau projekte, kur MySQL duomenų bazė tiesiog atsisakė bendradarbiauti. Ne dėl to, kad būtų blogai suprojektuota – tiesiog duomenų srautai tapo tokie dideli, kad tradicinė reliacinė architektūra ėmė dusti. Tuomet pirmą kartą susidūriau su NoSQL pasauliu ir Apache Cassandra. Šiandien, kai kalbame apie milijonus užklausų per sekundę ir petabaitus duomenų, tokios situacijos tampa norma, o ne išimtimi.
Apache Cassandra atsirado ne tuščioje vietoje. Ją sukūrė Facebook inžinieriai 2008 metais, kai susidūrė su inbox paieškos problema. Vėliau projektas tapo atvirojo kodo ir perėjo Apache fondui. Šiandien Cassandra naudojasi tokie gigantai kaip Netflix, Apple, Instagram ir daugelis kitų kompanijų, kurioms kritinė yra ne tik sparta, bet ir patikimumas.
Kas daro Cassandra tokią ypatingą
Pirmiausia, Cassandra yra sukurta horizontaliam masteliui. Tai reiškia, kad jūs galite tiesiog pridėti daugiau serverių, kai reikia daugiau galios ar vietos. Nereikia perkonfigūruoti visos sistemos, nereikia sustabdyti veikimo – tiesiog prijungiate naują mazgą, ir sistema automatiškai pradeda perskirstyti duomenis.
Antra svarbi savybė – nėra vieno gedimo taško. Tradicinėse master-slave architektūrose, jei nukrisdavo pagrindinis serveris, prasidėdavo panika. Cassandra veikia pagal peer-to-peer principą – visi mazgai yra lygiaverčiai. Galite išjungti pusę klasterio, ir sistema vis tiek veiks (nors, žinoma, to daryti nerekomenduoju).
Trečia – geografinis paskirstymas. Jei jūsų vartotojai yra Europoje, Azijoje ir Amerikoje, galite turėti Cassandra mazgus visuose šiuose regionuose. Duomenys automatiškai replikuojasi, o vartotojai gauna atsakymus iš artimiausio duomenų centro. Tai ne tik pagreitina darbą, bet ir užtikrina veikimą net jei visas regionas tampa nepasiekiamas.
Kaip Cassandra saugo ir organizuoja duomenis
Čia prasideda įdomiausia dalis. Cassandra naudoja vadinamąjį wide-column modelį, kuris yra kažkas tarp tradicinių lentelių ir key-value saugyklų. Galite galvoti apie tai kaip apie lentelę, kur kiekviena eilutė gali turėti skirtingus stulpelius. Skamba keistai? Iš pradžių man irgi taip atrodė.
Duomenys saugomi partition key principu. Tai yra raktas, kuris nulemia, kuriame mazge bus saugomi jūsų duomenys. Pavyzdžiui, jei kuriate socialinio tinklo aplikaciją, partition key galėtų būti vartotojo ID. Visi to vartotojo įrašai būtų saugomi kartu, užtikrinant greitą prieigą.
CREATE TABLE user_posts (
user_id uuid,
post_time timestamp,
post_id uuid,
content text,
likes int,
PRIMARY KEY (user_id, post_time)
) WITH CLUSTERING ORDER BY (post_time DESC);
Šiame pavyzdyje user_id yra partition key, o post_time – clustering key. Tai reiškia, kad visi vieno vartotojo įrašai bus saugomi kartu ir surūšiuoti pagal laiką mažėjimo tvarka. Tokia struktūra leidžia žaibiškai gauti naujausius vartotojo įrašus.
Konsistencijos ir prieinamumo balanso menas
Vienas didžiausių iššūkių dirbant su paskirstytomis sistemomis – CAP teorema. Ji sako, kad negalite vienu metu turėti visų trijų: konsistencijos (Consistency), prieinamumo (Availability) ir atsparumo tinklo skaidymui (Partition tolerance). Cassandra leidžia jums pasirinkti, ką prioritizuoti kiekvienoje užklausoje.
Praktiškai tai veikia per konsistencijos lygius. Kai rašote duomenis, galite nurodyti, kiek mazgų turi patvirtinti operaciją prieš gaunant atsakymą:
- ONE – pakanka vieno mazgo patvirtinimo (greičiausias, bet mažiausiai patikimas)
- QUORUM – dauguma mazgų turi patvirtinti (balansas tarp greičio ir patikimumo)
- ALL – visi mazgai turi patvirtinti (lėčiausias, bet patikimiausias)
Aš paprastai rekomenduoju naudoti QUORUM daugumai aplikacijų. Tai užtikrina, kad duomenys bus įrašyti į daugumą replikų, bet neprailgina operacijos laiko iki begalybės. Finansinėms transakcijoms galite naudoti ALL, o analitikai ar logams – ONE.
Duomenų modeliavimas Cassandra stiliumi
Čia daugelis pradedančiųjų suklysta. Jie bando projektuoti Cassandra schemas taip pat, kaip SQL duomenų bazėse. Tai kelias į katastrofą. Cassandra reikia modeliuoti pagal užklausas, o ne pagal duomenų normalizaciją.
Tarkime, kuriate muzikos streaming platformą. SQL pasaulyje turėtumėte lentelę „songs”, „artists”, „albums” ir daug ryšių tarp jų. Cassandra pasaulyje sukurtumėte atskiras lenteles kiekvienam užklausos tipui:
-- Dainų paieška pagal atlikėją
CREATE TABLE songs_by_artist (
artist_name text,
release_date timestamp,
song_id uuid,
song_title text,
duration int,
PRIMARY KEY (artist_name, release_date, song_id)
);
-- Dainų paieška pagal albumą
CREATE TABLE songs_by_album (
album_id uuid,
track_number int,
song_id uuid,
song_title text,
duration int,
PRIMARY KEY (album_id, track_number)
);
Taip, duomenys dubliuojasi. Taip, tai atrodo neefektyvu. Bet Cassandra pasaulyje diskų vieta yra pigi, o JOIN operacijos – brangios. Geriau turėti dubliuotus duomenis ir greitas užklausas, nei normalizuotą schemą ir lėtas užklausas.
Praktiniai patarimai diegiant Cassandra
Kai pirmą kartą diegiau Cassandra produkcijai, padariau kelias klaidas, kurias jūs galite išvengti. Pirma ir svarbiausia – neskubėkite. Cassandra nėra „drop-in replacement” jūsų esamai SQL duomenų bazei. Ji reikalauja kitokio mąstymo.
Pradėkite su bent trimis mazgais. Taip, galite paleisti Cassandra vienoje mašinoje testavimui, bet produkcijai reikia bent trijų mazgų. Tai minimalus skaičius, užtikrinantis aukštą prieinamumą su replication factor 3.
Monitoringas yra kritinis. Naudokite įrankius kaip Prometheus su Cassandra exporter arba DataStax OpsCenter. Stebėkite tokius metrikų kaip read/write latency, compaction operacijos, garbage collection. Cassandra gali tyliai kentėti, kol staiga viskas sugriūva.
Backup strategija nuo pirmos dienos. Cassandra turi snapshot funkciją, bet tai tik dalis sprendimo. Jums reikia automatizuoto backup proceso, kuris reguliariai išsaugo snapshots į išorinę saugyklą. Aš naudoju kombinaciją tablesnap ir S3 – veikia puikiai.
Tuning JVM yra būtinas. Cassandra veikia ant Java, todėl JVM nustatymai turi didžiulę įtaką. Pradėkite su G1GC garbage collector ir heap size apie 8-16GB. Daugiau ne visada geriau – per didelis heap gali sukelti ilgas GC pauzės.
Kada Cassandra nėra tinkamas pasirinkimas
Būkime sąžiningi – Cassandra nėra universalus sprendimas. Yra situacijų, kai ji sukels daugiau problemų nei išspręs. Jei jūsų duomenų kiekis telpa į vieną serverį ir neplanuojate augti iki milijonų vartotojų – tikriausiai jums pakaks PostgreSQL ar MySQL.
Cassandra nėra gera transakcijoms, kurioms reikia ACID garantijų. Nors ji turi lightweight transactions (LWT), jos yra lėtos ir turėtų būti naudojamos tik išimtiniais atvejais. Jei kuriate bankinę sistemą, kur kiekvienas centas turi būti apskaitytas – geriau rinktis tradicines SQL bazes.
Taip pat Cassandra nėra optimizuota ad-hoc užklausoms. Jei jūsų analitikai nori paleisti sudėtingas užklausas su JOIN, GROUP BY ir subqueries – jie bus nusivylę. Tokiems atvejams geriau naudoti Cassandra kaip operacinę bazę ir replikuoti duomenis į analitinę platformą kaip ClickHouse ar BigQuery.
Realūs panaudojimo scenarijai ir rezultatai
Netflix yra vienas žinomiausių Cassandra vartotojų. Jie naudoja ją saugoti visus vartotojų peržiūros duomenis, rekomendacijas, A/B testų rezultatus. Jų Cassandra klasteris turi daugiau nei 1000 mazgų ir apdoroja milijonus operacijų per sekundę. Svarbiausia – jie gali atnaujinti sistemą be prastovų, kas kritinė paslaugai, kuri veikia 24/7.
Apple naudoja Cassandra savo iCloud servisui. Kai išsaugote nuotrauką ar dokumentą, yra didelė tikimybė, kad metaduomenys apie jį saugomi Cassandra. Jiems svarbu, kad duomenys būtų prieinami iš bet kurio pasaulio taško su minimalia vėlava.
Asmeniškai dirbau projekte, kur migravome IoT platformą iš MongoDB į Cassandra. Turėjome milijonus sensorių, siunčiančių duomenis kas kelias sekundes. MongoDB pradėjo strigt, kai duomenų kiekis viršijo 10TB. Po migracijos į Cassandra su 6 mazgų klasteriu, sistema lengvai tvarkė 50,000 įrašų per sekundę, o read latency sumažėjo nuo 200ms iki 10ms.
Ką reikia žinoti apie Cassandra ateitį
Cassandra bendruomenė aktyviai dirba prie 5.0 versijos, kuri žada reikšmingų patobulinimų. Vienas įdomiausių – virtual tables, leidžiantys lengviau stebėti sistemos būseną. Taip pat planuojami storage engine patobulinimai, kurie turėtų sumažinti disk I/O ir pagerinti compaction procesą.
Kubernetes integracija tampa vis geresnė. K8ssandra projektas suteikia production-ready Cassandra operatorių Kubernetes, su automatizuotu backup, repair ir monitoring. Tai žymiai supaprastina Cassandra valdymą cloud native aplinkose.
Dar viena įdomi kryptis – Cassandra kaip paslauga (DBaaS). AWS, Azure ir GCP siūlo managed Cassandra paslaugas, kurios pašalina daug operacinės naštos. Nors jos brangesnės už self-hosted sprendimus, daugeliui organizacijų tai verta, nes leidžia sutelkti dėmesį į produkto kūrimą, o ne infrastruktūros valdymą.
Kelias į Cassandra meistriškumą
Pradėti su Cassandra nėra sunku – galite paleisti local klasterį per kelias minutes naudojant Docker. Bet tapti tikru ekspertu užtrunka. Reikia suprasti ne tik kaip rašyti CQL užklausas, bet ir kaip veikia gossip protokolas, kaip vyksta compaction, kaip optimizuoti read/write paths.
Mano patarimas – pradėkite nuo mažo projekto. Sukurkite paprastą aplikaciją, kuri naudoja Cassandra. Eksperimentuokite su skirtingais konsistencijos lygiais, stebėkite kaip keičiasi performance. Tyčia išjunkite mazgą ir pažiūrėkite kaip sistema reaguoja. Tokia praktinė patirtis verta daugiau nei bet kokia teorija.
Skaitykite oficialią dokumentaciją ir DataStax Academy kursus – jie nemokami ir labai kokybiški. Sekite Cassandra Summit įrašus – ten dalijamasi realiais case studies ir best practices. Ir svarbiausia – prisijunkite prie bendruomenės. Cassandra Slack kanalas ir mailing list yra pilni žmonių, norinčių padėti.
Cassandra nėra lengviausias NoSQL sprendimas, bet kai jums reikia tikrai didelio masto, patikimumo ir geografinio paskirstymo – ji neturi daug konkurentų. Taip, mokymosi kreivė yra statesne nei norėtumėte, bet rezultatai to verti. Kai matote sistemą, kuri be problemų apdoroja milijonus užklausų per sekundę ir išlieka veikianti net kai krinta duomenų centrai – supranti, kodėl Cassandra išlieka vienu populiariausių NoSQL sprendimų po daugiau nei dešimtmečio.
