Sveiki, Habr.
Mano vardas Miša Butrimovas, norėčiau šiek tiek papasakoti apie Cassandra. Mano istorija bus naudinga tiems, kurie niekada nesusidūrė su NoSQL duomenų bazėmis – joje yra daug diegimo funkcijų ir spąstų, apie kuriuos reikia žinoti. Ir jei nematėte nieko, išskyrus Oracle ar bet kurią kitą reliacinę duomenų bazę, šie dalykai išgelbės jūsų gyvybę.
Kuo Cassandra taip gerai? Tai NoSQL duomenų bazė, sukurta be vieno gedimo taško, kuri gerai keičiasi. Jei reikia pridėti keletą terabaitų kuriai nors duomenų bazei, tiesiog pridėkite mazgus prie žiedo. Išplėsti jį į kitą duomenų centrą? Pridėkite mazgus prie klasterio. Padidinti apdorotą RPS? Pridėkite mazgus prie klasterio. Jis taip pat veikia priešinga kryptimi.
Ką dar ji moka? Tai susiję su daugelio užklausų tvarkymu. Bet kiek yra daug? 10, 20, 30, 40 tūkstančių užklausų per sekundę nėra daug. 100 tūkstančių užklausų per sekundę įrašymui – taip pat. Yra įmonių, kurios teigė, kad per sekundę išlaiko 2 mln. Tikriausiai jiems teks tuo patikėti.
Ir iš principo Cassandra turi vieną didelį skirtumą nuo reliacinių duomenų – ji visai į juos nepanaši. Ir tai labai svarbu atsiminti.
Ne viskas, kas atrodo taip pat, veikia taip pat
Kartą kolega atėjo pas mane ir paklausė: „Čia yra CQL Cassandra užklausos kalba, ir ji turi pasirinktą teiginį, turi kur, turi ir. Rašau laiškus ir neveikia. Kodėl?". Cassandra traktavimas kaip reliacinė duomenų bazė yra puikus būdas smurtinei savižudybei. Ir aš to nereklamuoju, Rusijoje tai draudžiama. Tiesiog suprojektuosite kažką ne taip.
Pavyzdžiui, pas mus ateina klientas ir sako: „Sukurkime serialų duomenų bazę arba receptų katalogo duomenų bazę. Ten turėsime maisto patiekalų arba jame serialų ir aktorių sąrašą“. Mes džiaugsmingai sakome: „Eime! Tiesiog atsiųskite du baitus, porą ženklų ir viskas, viskas veiks labai greitai ir patikimai. Ir viskas gerai, kol ateina klientai ir nepasako, kad šeimininkės sprendžia ir priešingą problemą: turi produktų sąrašą, nori sužinoti, kokį patiekalą nori gaminti. Jūs esate miręs.
Taip yra todėl, kad „Cassandra“ yra hibridinė duomenų bazė: joje vienu metu pateikiama pagrindinė reikšmė ir duomenys saugomi plačiuose stulpeliuose. „Java“ arba „Kotlin“ kalboje tai galėtų būti apibūdinta taip:
Map<RowKey, SortedMap<ColumnKey, ColumnValue>>
Tai yra žemėlapis, kuriame taip pat yra surūšiuotas žemėlapis. Pirmasis šio žemėlapio raktas yra eilutės klavišas arba skaidinio raktas – skaidymo raktas. Antrasis raktas, kuris yra raktas į jau surūšiuotą žemėlapį, yra grupavimo raktas.
Norėdami iliustruoti duomenų bazės pasiskirstymą, nubrėžkime tris mazgus. Dabar jūs turite suprasti, kaip suskaidyti duomenis į mazgus. Nes jei viską sugrūsime į vieną (beje, gali būti tūkstantis, du tūkstančiai, penki – kiek tik nori), tai tikrai ne apie platinimą. Todėl mums reikia matematinės funkcijos, kuri grąžins skaičių. Tik skaičius, ilgas int, kuris pateks į tam tikrą diapazoną. Ir turėsime vieną mazgą, atsakingą už vieną diapazoną, antrą už antrą, n-tą už n-ąjį.
Šis skaičius paimamas naudojant maišos funkciją, kuri taikoma tam, ką vadiname skaidinio raktu. Tai yra stulpelis, nurodytas pirminio rakto direktyvoje, ir tai yra stulpelis, kuris bus pirmasis ir pagrindinis žemėlapio raktas. Jis nustato, kuris mazgas kokius duomenis gaus. „Cassandra“ sukuriama lentelė su beveik ta pačia sintaksė kaip ir SQL:
CREATE TABLE users (
user_id uu id,
name text,
year int,
salary float,
PRIMARY KEY(user_id)
)
Pagrindinis raktas šiuo atveju susideda iš vieno stulpelio ir taip pat yra skaidymo raktas.
Kaip veiks mūsų vartotojai? Kai kurie pateks į vieną mazgą, kiti į kitą, o kiti į trečią. Rezultatas yra įprasta maišos lentelė, dar žinoma kaip žemėlapis, taip pat žinomas kaip žodynas Python, arba paprasta rakto reikšmių struktūra, iš kurios galime perskaityti visas reikšmes, skaityti ir rašyti pagal raktą.
Pasirinkite: kada leisti filtravimą virsta visu nuskaitymu arba ko nedaryti
Parašykime tam tikrą teiginį: select * from users where, userid = . Išeina kaip Oracle: parašome select, nurodome sąlygas ir viskas veikia, vartotojai gauna. Bet jei pasirenkate, pavyzdžiui, vartotoją su tam tikrais gimimo metais, Cassandra skundžiasi, kad negali įvykdyti užklausos. Kadangi ji visiškai nieko nežino apie tai, kaip mes platiname duomenis apie gimimo metus - ji turi tik vieną stulpelį, nurodytą kaip raktą. Tada ji sako: „Gerai, aš vis tiek galiu įvykdyti šį prašymą. Pridėti leisti filtruoti“. Pridedame direktyvą, viskas veikia. Ir šią akimirką atsitinka kažkas baisaus.
Kai vykdome bandymų duomenis, viskas yra gerai. O kai vykdote užklausą gamyboje, kur, pavyzdžiui, turime 4 milijonus įrašų, tada mums viskas nėra labai gerai. Nes leisti filtruoti yra direktyva, leidžianti Cassandra surinkti visus duomenis iš šios lentelės iš visų mazgų, visų duomenų centrų (jei jų šiame klasteryje yra daug) ir tik tada filtruoti. Tai yra „Full Scan“ analogas, ir vargu ar kas nors juo džiaugiasi.
Jei mums reiktų tik naudotojų pagal ID, tai būtų gerai. Tačiau kartais mums reikia rašyti kitas užklausas ir nustatyti kitus pasirinkimo apribojimus. Todėl prisimename: visa tai yra žemėlapis, turintis skirstymo raktą, tačiau jo viduje yra surūšiuotas žemėlapis.
Ji taip pat turi raktą, kurį mes vadiname grupavimo raktu. Šis raktas, kuris, savo ruožtu, susideda iš mūsų pasirinktų stulpelių, kurių pagalba Cassandra supranta, kaip jo duomenys yra fiziškai rūšiuojami ir bus kiekviename mazge. Tai reiškia, kad tam tikram skirsnio raktui Clustering raktas tiksliai nurodys, kaip perkelti duomenis į šį medį, kokią vietą jie ten užims.
Tai iš tikrųjų yra medis, ten tiesiog vadinamas lygintuvas, kuriam perduodame tam tikrą stulpelių rinkinį objekto pavidalu, taip pat jis nurodomas kaip stulpelių sąrašas.
CREATE TABLE users_by_year_salary_id (
user_id uuid,
name text,
year int,
salary float,
PRIMARY KEY((year), salary, user_id)
Atkreipkite dėmesį į pirminio rakto direktyvą; pirmasis jos argumentas (mūsų atveju metai) visada yra skirsnio raktas. Jį gali sudaryti vienas ar daugiau stulpelių, nesvarbu. Jei yra keli stulpeliai, jį reikia dar kartą pašalinti skliausteliuose, kad kalbos pirminis procesorius suprastų, kad tai yra pagrindinis raktas, o už jo visi kiti stulpeliai yra klasterizacijos raktas. Tokiu atveju jie bus perduodami palyginimo priemonėje tokia tvarka, kokia jie rodomi. Tai yra, pirmasis stulpelis yra reikšmingesnis, antrasis yra mažiau reikšmingas ir pan. Kaip rašome, pavyzdžiui, duomenų klasių laukams prilygsta: išvardijame laukus, o jiems rašome, kurie didesni, o kurie mažesni. Kasandroje tai, santykinai kalbant, yra duomenų klasės laukai, kuriems bus taikomi jai parašyti lygūs.
Nustatome rūšiavimą ir taikome apribojimus
Reikia atsiminti, kad rūšiavimo tvarka (mažėjanti, didėjanti, bet kokia) nustatoma tuo pačiu momentu, kai sukuriamas raktas, o vėliau jos keisti negalima. Jis fiziškai nustato, kaip duomenys bus rūšiuojami ir kaip jie bus saugomi. Jei reikia pakeisti klasterizacijos raktą arba rūšiavimo tvarką, turėsite sukurti naują lentelę ir perkelti į ją duomenis. Tai neveiks su esamu.
Užpildėme savo lentelę vartotojų ir pamatėme, kad jie pateko į žiedą, pirmiausia pagal gimimo metus, o paskui kiekvieno mazgo viduje pagal atlyginimą ir vartotojo ID. Dabar galime pasirinkti nustatydami apribojimus.
Vėl pasirodo mūsų darbinis where, and, ir sulaukiame vartotojų, ir vėl viskas gerai. Bet jei bandysime naudoti tik dalį klasterizavimo rakto ir ne tokį reikšmingą, Cassandra iš karto skųsis, kad neranda vietos mūsų žemėlapyje, kur yra šis objektas, kuriame yra šie laukai nuliniam palyginimui, ir šis. kad buvo ką tik nustatyta , - kur jis guli. Turėsiu dar kartą surinkti visus duomenis iš šio mazgo ir juos filtruoti. Ir tai yra viso nuskaitymo mazge analogas, tai yra blogai.
Bet kurioje neaiškioje situacijoje sukurkite naują lentelę
Jei norime nukreipti naudotojus pagal ID, amžių ar atlyginimą, ką turėtume daryti? Nieko. Tiesiog naudokite dvi lenteles. Jei norite pasiekti naudotojus trimis skirtingais būdais, bus trys lentelės. Praėjo tie laikai, kai sutaupydavome vietos ant varžto. Tai pigiausias šaltinis. Tai kainuoja daug mažiau nei atsako laikas, o tai gali pakenkti vartotojui. Vartotojui daug maloniau ką nors gauti per sekundę nei per 10 minučių.
Prekiaujame nereikalinga erdve ir denormalizuotais duomenimis, kad galėtume tinkamai keisti mastelį ir veikti patikimai. Galų gale, klasteris, susidedantis iš trijų duomenų centrų, kurių kiekvienas turi penkis mazgus, su priimtinu duomenų išsaugojimo lygiu (kai niekas neprarandama), gali visiškai išgyventi vieno duomenų centro mirtį. Ir dar du mazgai kiekviename iš likusių dviejų. Ir tik po to prasideda problemos. Tai gana geras atleidimas, verta poros papildomų SSD diskų ir procesorių. Todėl norint naudoti „Cassandra“, kuri niekada nėra SQL, kurioje nėra santykių, užsienio raktų, reikia žinoti paprastas taisykles.
Viską projektuojame pagal Jūsų pageidavimą. Svarbiausia ne duomenys, o tai, kaip programa su jais dirbs. Jei jai reikia gauti skirtingus duomenis skirtingais būdais arba tuos pačius duomenis skirtingais būdais, turime juos pateikti programai patogiu būdu. Priešingu atveju mums nepavyks Full Scan ir Cassandra nesuteiks mums jokio pranašumo.
Duomenų denormalizavimas yra norma. Pamirštame įprastas formas, nebeturime reliacinių duomenų bazių. Jei ką nors paguldysime 100 kartų, tai atsiguls 100 kartų. Tai vis tiek pigiau nei sustoti.
Parenkame skirstymo raktus, kad jie būtų paskirstyti įprastai. Mes nenorime, kad mūsų raktų maiša patektų į vieną siaurą diapazoną. Tai yra, gimimo metai aukščiau pateiktame pavyzdyje yra blogas pavyzdys. Tiksliau, gerai, jei mūsų vartotojai normaliai pasiskirsto pagal gimimo metus, o blogai, jei kalbame apie 5 klasės mokinius - ten skirstymas nebus labai geras.
Rūšiavimas pasirenkamas vieną kartą grupavimo rakto kūrimo etape. Jei ją reikės pakeisti, turėsime atnaujinti lentelę naudodami kitą raktą.
Ir svarbiausias dalykas: jei mums reikės tuos pačius duomenis gauti 100 skirtingų būdų, tada turėsime 100 skirtingų lentelių.
Šaltinis: www.habr.com