Hej Habr.
Moje ime je Misha Butrimov, rad bi vam povedal nekaj o Cassandri. Moja zgodba bo koristna za tiste, ki se še nikoli niso srečali z bazami podatkov NoSQL - ima veliko funkcij implementacije in pasti, o katerih morate vedeti. In če niste videli ničesar drugega kot Oracle ali katero koli drugo relacijsko bazo podatkov, vam bodo te stvari rešile življenje.
Kaj je tako dobrega na Cassandri? To je zbirka podatkov NoSQL, zasnovana brez ene same točke napake, ki se dobro prilagaja. Če morate dodati nekaj terabajtov za neko bazo podatkov, preprosto dodate vozlišča v obroč. Ga razširite na drug podatkovni center? Dodajte vozlišča v gručo. Želite povečati obdelane RPS? Dodajte vozlišča v gručo. Deluje tudi v obratni smeri.
V čem je še dobra? Gre za obravnavo številnih zahtev. Toda koliko je veliko? 10, 20, 30, 40 tisoč zahtevkov na sekundo ni veliko. 100 tisoč zahtevkov na sekundo za snemanje – tudi. Nekatera podjetja trdijo, da hranijo 2 milijona zahtev na sekundo. Verjetno bodo morali verjeti.
In načeloma ima Cassandra eno veliko razliko od relacijskih podatkov - sploh jim ni podobna. In to si je zelo pomembno zapomniti.
Ne deluje vse, kar je videti enako
Nekoč je k meni prišel kolega in vprašal: »Tukaj je poizvedovalni jezik CQL Cassandra in ima stavek select, ima kje, ima in. Pišem pisma in ne gre. Zakaj?". Obravnavanje Cassandre kot relacijske zbirke podatkov je popoln način za nasilen samomor. In tega ne promoviram, v Rusiji je prepovedano. Samo načrtoval boš nekaj narobe.
Na primer, stranka pride k nam in reče: »Naredimo bazo podatkov za TV serije ali bazo podatkov za imenik receptov. Tam bomo imeli jedi ali pa seznam televizijskih serij in igralcev v njih.« Veselo rečemo: "Gremo!" Samo pošljite dva bajta, nekaj znakov in končali ste, vse bo delovalo zelo hitro in zanesljivo. In vse je v redu, dokler ne pridejo kupci in rečejo, da gospodinje rešujejo tudi nasprotno težavo: imajo seznam izdelkov in želijo vedeti, katero jed želijo skuhati. Mrtev si.
To je zato, ker je Cassandra hibridna baza podatkov: hkrati zagotavlja ključno vrednost in shranjuje podatke v širokih stolpcih. V Javi ali Kotlinu bi to lahko opisali takole:
Map<RowKey, SortedMap<ColumnKey, ColumnValue>>
Se pravi zemljevid, ki vsebuje tudi razvrščen zemljevid. Prvi ključ tega zemljevida je tipka vrstice ali particijski ključ – particijski ključ. Drugi ključ, ki je ključ do že razvrščenega zemljevida, je ključ Clustering.
Za ponazoritev porazdelitve baze podatkov narišimo tri vozlišča. Zdaj morate razumeti, kako razstaviti podatke na vozlišča. Kajti če strpamo vse v eno (mimogrede, lahko jih je tisoč, dva tisoč, pet - kolikor hočete), tu pravzaprav ne gre za distribucijo. Zato potrebujemo matematično funkcijo, ki bo vrnila število. Samo številka, dolg int, ki bo spadal v določen obseg. Imeli bomo eno vozlišče, odgovorno za eno območje, drugo za drugo, n-to za n-to.
Ta številka se pridobi s funkcijo zgoščevanja, ki se uporabi za to, kar imenujemo particijski ključ. To je stolpec, ki je določen v direktivi primarnega ključa, in to je stolpec, ki bo prvi in najosnovnejši ključ preslikave. Določa, katero vozlišče bo prejelo katere podatke. Tabela je ustvarjena v Cassandri s skoraj enako sintakso kot v SQL:
CREATE TABLE users (
user_id uu id,
name text,
year int,
salary float,
PRIMARY KEY(user_id)
)
Primarni ključ je v tem primeru sestavljen iz enega stolpca in je tudi particijski ključ.
Kakšni bodo rezultati naših uporabnikov? Nekateri bodo šli v eno vozlišče, nekateri v drugo in nekateri v tretje. Rezultat je navadna zgoščena tabela, znana tudi kot zemljevid, znana tudi kot slovar v Pythonu, ali preprosta struktura vrednosti ključa, iz katere lahko beremo vse vrednosti, beremo in pišemo po ključu.
Izberite: kdaj se dovoli filtriranje spremeni v popoln pregled ali česa ne storiti
Napišimo nekaj izbranih izjav: select * from users where, userid = . Izkazalo se je kot v Oracle: napišemo select, določimo pogoje in vse deluje, uporabniki dobijo. Če pa izberete na primer uporabnika z določeno letnico rojstva, se Cassandra pritoži, da ne more izpolniti zahteve. Ker ne ve čisto nič o tem, kako distribuiramo podatke o letnici rojstva - kot ključ ima označen samo en stolpec. Nato reče: »V redu, še vedno lahko izpolnim to zahtevo. Dodaj dovoli filtriranje." Dodamo direktivo, vse deluje. In v tem trenutku se zgodi nekaj groznega.
Ko izvajamo testne podatke, je vse v redu. In ko izvedeš poizvedbo v produkciji, kjer imamo na primer 4 milijone zapisov, potem za nas ni vse najbolje. Ker je dovoljenje filtriranja direktiva, ki omogoča Cassandri, da zbere vse podatke iz te tabele iz vseh vozlišč, vseh podatkovnih centrov (če jih je veliko v tej gruči) in jih šele nato filtrira. To je analog popolnega skeniranja in komaj kdo je navdušen nad njim.
Če bi potrebovali samo uporabnike po ID-ju, bi bilo to v redu. Toda včasih moramo napisati druge poizvedbe in uvesti druge omejitve pri izbiri. Zato si zapomnimo: vse to je zemljevid, ki ima particijski ključ, vendar je v njem razvrščen zemljevid.
In ima tudi ključ, ki ga imenujemo Clustering Key. Ta ključ, ki je sestavljen iz stolpcev, ki jih izberemo, s pomočjo katerih Cassandra razume, kako so njeni podatki fizično razvrščeni in se bodo nahajali na vsakem vozlišču. To pomeni, da vam bo za nek particijski ključ ključ združevanja v gruče natančno povedal, kako potisnete podatke v to drevo, na katerem mestu bodo tam.
To je v resnici drevo, tam se enostavno prikliče primerjalnik, ki mu posredujemo določen nabor stolpcev v obliki objekta, podano pa je tudi kot seznam stolpcev.
CREATE TABLE users_by_year_salary_id (
user_id uuid,
name text,
year int,
salary float,
PRIMARY KEY((year), salary, user_id)
Bodite pozorni na direktivo primarnega ključa, njen prvi argument (v našem primeru letnica) je vedno particijski ključ. Lahko je sestavljen iz enega ali več stolpcev, ni pomembno. Če je stolpcev več, jih je treba znova odstraniti v oklepaju, da jezikovni predprocesor razume, da je to primarni ključ, za njim pa so vsi drugi stolpci ključ združevanja v gruče. V tem primeru bodo v primerjalniku poslani v vrstnem redu, v katerem se pojavijo. To pomeni, da je prvi stolpec pomembnejši, drugi manj pomemben in tako naprej. Kako pišemo na primer enaka polja za podatkovne razrede: naštejemo polja in zanje napišemo, katera so večja in katera manjša. V Cassandri so to, relativno gledano, polja podatkovnega razreda, za katera bodo uporabljene enakovrednosti, zapisane zanj.
Nastavljamo razvrščanje in postavljamo omejitve
Zapomniti si morate, da je vrstni red (padajoče, naraščajoče, karkoli) nastavljen v istem trenutku, ko je ključ ustvarjen, in ga kasneje ni več mogoče spremeniti. Fizično določa, kako bodo podatki razvrščeni in kako bodo shranjeni. Če morate spremeniti ključ združevanja v gruče ali vrstni red razvrščanja, boste morali ustvariti novo tabelo in vanjo prenesti podatke. To ne bo delovalo z obstoječim.
Našo tabelo smo napolnili z uporabniki in videli, da so padli v obroč, najprej po letu rojstva, nato pa znotraj vsakega vozlišča po plači in ID-ju uporabnika. Zdaj lahko izbiramo z uvedbo omejitev.
Spet se pojavi naš delovni where, and, dobimo uporabnike in spet je vse v redu. Če pa poskušamo uporabiti samo del ključa za združevanje v gruče in še manj pomembnega, se bo Cassandra takoj pritožila, da ne more najti mesta na našem zemljevidu, kjer je ta objekt, ki ima ta polja za ničelni primerjalnik, in ta ki je bil pravkar nastavljen, - kje leži. Znova bom moral pridobiti vse podatke iz tega vozlišča in jih filtrirati. In to je analog popolnega pregleda znotraj vozlišča, to je slabo.
V kakršni koli nejasni situaciji ustvarite novo tabelo
Kaj naj storimo, če želimo imeti možnost ciljanja na uporabnike glede na ID, starost ali plačo? nič. Samo uporabite dve tabeli. Če želite uporabnike doseči na tri različne načine, bodo na voljo tri tabele. Minili so dnevi, ko smo varčevali s prostorom na vijaku. To je najcenejši vir. Stane veliko manj kot odzivni čas, kar je lahko škodljivo za uporabnika. Za uporabnika je veliko bolj prijetno nekaj prejeti v sekundi kot v 10 minutah.
Nepotreben prostor in denormalizirane podatke zamenjamo za sposobnost dobrega prilagajanja in zanesljivega delovanja. Konec koncev je pravzaprav grozd, ki ga sestavljajo trije podatkovni centri, od katerih ima vsak pet vozlišč, s sprejemljivo stopnjo ohranjenosti podatkov (ko se nič ne izgubi) popolnoma preživeti smrt enega podatkovnega centra. In še dve vozlišči v vsakem od preostalih dveh. In šele po tem se začnejo težave. To je precej dobra redundanca, vredno je nekaj dodatnih pogonov SSD in procesorjev. Zato morate za uporabo Cassandre, ki nikoli ni SQL, v kateri ni odnosov, tujih ključev, poznati preprosta pravila.
Vse oblikujemo po vaši želji. Glavna stvar niso podatki, ampak kako bo aplikacija delala z njimi. Če mora prejemati različne podatke na različne načine ali iste podatke na različne načine, jih moramo postaviti na način, ki je primeren za aplikacijo. V nasprotnem primeru ne bomo uspeli v Full Scan in Cassandra nam ne bo dala nobene prednosti.
Denormalizacija podatkov je norma. Pozabljamo na običajne obrazce, nimamo več relacijskih baz podatkov. Če nekaj 100-krat odložimo, se bo 100-krat uleglo. Še vedno je ceneje kot ustaviti.
Ključe za particioniranje izberemo tako, da so normalno porazdeljeni. Ne želimo, da zgoščenost naših ključev pade v en ozek obseg. To pomeni, da je leto rojstva v zgornjem primeru slab primer. Natančneje, dobro je, če so naši uporabniki normalno razporejeni po letnicah rojstva, in slabo, če govorimo o učencih 5. razreda - tam razdelitev ne bo zelo dobra.
Razvrščanje je izbrano enkrat na stopnji ustvarjanja ključa združevanja v gruče. Če jo je treba spremeniti, bomo morali našo tabelo posodobiti z drugim ključem.
In kar je najpomembnejše: če moramo iste podatke pridobiti na 100 različnih načinov, potem bomo imeli 100 različnih tabel.
Vir: www.habr.com