Cassandra vodič: Kako izbeći početničke greške?

Kroz nekoliko naših poslednjih projekata konsultovali smo timove sa razvojnim iskustvom sa relacionim podacima i koji su u tom trenutku usvajali Cassandru i pomogli nam da uočimo da dosta ljudi tom prilikom koristi prečice, a ne duboko razumevanje kako ova baza radi.

Pokušaću da predstavim neke od najčešćih naznaka problema i savete kako da ih izbegnete i da podelim sa vama put koji je, po mom mišljenju, najbolji za učenje ove baze.

Obrazac je sledeći: Neki programer u timu prati trendove, pročita da Cassandra odlično funkcioniše sa velikim data setovima, i da je pogodna kao baza za senzor podatke, vremenske serije, IoT aplikacije… Postoji i zahtev da je tom delu sistema potrebno distribuirano skalabilno rešenje za čuvanje podataka.

Senior developer donese odluku. Cassandra je seksi i popularna i uklapa se u naš projekat.  Pozadina razvojnog tima je uglavnom u relacionom svetu.  I tako se timovi odlučuju za Cassandru.

Onda instaliraju Cassandru na jednom node-u (1. znak problema), nemaju potrebu za više i u tom trenutku počinje development. Modeliranje podatakaData modeling je naredni zadatak i iz iskustva sa relacionim podacima, to je nešto što se uradi usput -ne moraš da se trudiš mnogo, jer tabele u bazi podataka liče na domenske entitete (2. znak problema).

Dakle, počinju da modeluju tabele za pojedinačne entitete, od kojih svaki ima svoj generisani id, a celokupni set podataka se join-uje na aplikativnom nivou. Rečeno je da je Cassandra skalabilna i brza, tako da dodavanje više node-ova rešava probleme u performansama usled loše modelovanih podataka. Data model počinje da “priča”, join-ovani podaci na aplikativnom nivou na ogromnim listama postaju veliki i spori, kreiranje upita na mnogim tabelama postaje previše komplikovano, tim vredno radi da bi podaci u različitim tabelama ostali sinhronizovani.

Čak i kada se problemi manifestuju sporim učitavanjem, development tim odlučuje da ne promeni data model zato što se drže onoga što je u svetu relacionih podataka normalno, a to je da se treba držati tabela kako su inicijalno modelovane (3. znak problema).

Aplikacija postaje sve popularnija i potrebno je skalirati je.

Razvojni tim počinje da dodaje node-ove i onda shvate da Cassandra i nije baš toliko skalabilna. Istina je da ako počnete sa tri node-a umesto sa jednim, izabraćete NetworkTopologyStrategy, a ne SimpleStrategy tako da ćete imati jedan problem manje pri skaliranju. Ovo je samo jedan od mnogih primera koji komplikuje proces skaliranja kada koristite jedan node na početku.

1. znak problema — korišćenje Cassandre na jednom node-u

Ovaj problem nije specifičan samo za Cassandru, već je problem svakog distribuiranog sistema. Kad god radite sa distribuiranim sistemima, budite sigurni da radite sa bar tri node-a od samog početka.

Problemi u ovim sistemima su potpuno drugačiji od problema sa sistemima sa jednim node-om, recimo: konzumiranje poruka tačno jednom, čuvanje fajlova u fajl sistemu, distribuirano schedule-ovanje, distribuirani lock mehanizmi.

Ovde je bitno zapamtiti: ako imate potrebu za distribuiranom tehnologijom kao što je Cassandra, kreirajte klaster od tri node-a i od početka razvijajte na takvom okruzenju. Ako koristite klaster sa jednim node-om, platićete cenu na duže staže kada bude došlo do skaliranja.

2. znak problema — data modeling u svetu relacionih podataka

Cassandra je specifična baš kao i svaka NoSQL baza. Da bi se postigle performanse, morate da znate kako radi, i eksterno i interno. Relacione baze kriju mnogo detalja od developera i ne morate da znate kako se podaci skladište da biste napravili efikasne upite.

U Cassandri je bitno da se koristi query-based modeling, morate da znate kako ćete čitati podatke pre nego što ih modelujete. To je distribuirani sistem, tako da bi podaci trebalo da budu denormalizovani i replicirani sa mnogo dupliranja. Poznata je stvar videti iste podatke kroz mnoge tabele gde je svaka optimizovana za određeni upit.

3. znak problema — konstantno optimizovanje data modela

Pre nego što smo počeli da radimo sa Cassandrom, rešavali smo probleme ne tako savršenog data modela sa dodatim upitima ili dodatnim join-ovima.

Sa jedne strane, ovde nemate mogućnost join-ovanja podataka; sa druge strane, morate da optimizujete data model onako kako ćete ga čitati. Kao što je naglašeno u prethodnom znaku problema, treba vam najbolji data model za svaku funkcionalnost, tako da ako se zahtevi funkcionalnosti menjaju, data model takođe treba promeniti.

U query-based modeling-u, data model je izložen na aplikativnom nivou (tradeoff da bi se postigle performanse) tako da bi ga trebalo menjati i prilagođavat kako se i zahtevi funkcionalnosti menjaju.

Ovo je primarni razlog zašto smo osmislili Cassandra Migration Tool, biblioteku koja beleži verzije promena na bazi i olakšava Schemu i Data promene.

Vodič za učenje

Dakle, kako prevazići ove prepreke i prilagoditi ovu novu tehnologiju?

Pre svega, pogledajte Uvod u NoSQL od Martin-a Fowler-a, ovo nije preduslov za Cassandru, ali odlično objašnjava NoSQL baze i zašto one postoje.

Cassandra je razvijena na osnovu dva storage engine-a Google BigTable i Amazon DynamoDB, tako da je moj predlog da ispratite ova dva whitepapera.

Sada kada imate dovoljno informacija, spremni ste za DataStax Akademiju. Oni imaju online kurseve koji će vas brzo doučiti. Kao osnovni minimum, savetovao bih vam da pogledate DS201: najbitnije koncepte Cassandre i DS220: Data Modeling.

Kao poslednji korak, pogledajte seriju od četiri videa na temu data modelinga Patrika Mekfedina, DataStax Cassandra evanđeliste. Priča o stvarnim primerima i naprednim tehnikama kako postiči sjajne data modele.

Ovo je redovni način učenja u SmartCat-u i time smo samo zagrebali površinu, ali vas dovodi do mesta gde možete da razumete odluke koje donosite o Cassandri. Nadam se da će ovo pomoći da prevaziđete neke od prepreka kada započinjete rad sa ovom bazom.

Ovo je put koji oduzima neko vreme, ali nakon što odgledate sve ove videe, definitivno će se isplatiti na duže staze. Biće vam mnogo jasnije zašto su neke odluke donete, zašto data model mora da se menja sa načinom čitanja podataka i zašto je poznavanje internala toliko bitno za njen učinak.

Bilo bi nam interesantno da čujemo i vaša iskustva i koji način učenja ste odabrali.

Nenadov originalni tekst možete naći na SmartCat blogu.