Cassandra. Kuidas mitte surra, kui tead vaid Oracle'it

Tere, Habr.

Minu nimi on Misha Butrimov ja sooviksin rääkida Cassandra'st. Minu jutt on kasulik neile, kes pole kunagi NoSQL-iga kokku puutunud — sellel on palju teostuse eripärasid ja peidetud võtteid, millest on hea teada. Kui olete näinud vaid Oracle'it või mõnda muud relatsioonilist andmebaasi, siis need teadmised võivad teie elu palju kergemaks teha.

Miks on Cassandra hea? See on NoSQL-andmebaas, mis on projekteeritud ilma ühegi rikke punktita ja millel on suurepärane skaleeritavus. Kui peate lisama paar terabaiti andmeid, lisate lihtsalt sõlmed ringi. Soovite selle laiendada teise andmekeskusesse? Lisage sõlmed klastrisse. Kas soovite suurendada töödeldud RPS-i? Lisage sõlmed klastrisse. Sama kehtib ka vastupidiselt.

Milles veel on see hea? Paljude päringute töötlemises. Aga palju — kui palju? 10, 20, 30, 40 tuhat päringut sekundis on natuke. 100 tuhat päringut sekundis kirjutamiseks — samuti. On ettevõtteid, kes väidavad, et nad hoiavad 2 miljonit päringut sekundis. Neile tuleb vist uskuda.

Ja Cassandra'l on üks suur erinevus relatsioonilistest andmetest — see ei sarnane neile üldse. Ja seda on väga oluline meeles pidada.

Mitte kõik, mis välja näeb sarnane, ei tööta sarnaselt.

Kord küsis üks kolleeg: «Siin on CQL, Cassandra päringukeel, ja seal on select-lause, seal on where, seal on and. Ma kirjutan tähti, aga see ei tööta. Miks?». Kui suhtuda Cassandra'sse nagu relatsioonilisse andmebaasi, siis on see ideaalne viis elu lõpetamiseks. Ja ma ei propageeri seda, see on Venemaal keelatud. Te lihtsalt projekteerite midagi valesti.

Näiteks tuleb tellija ja ütleb: «Ehitage meile andmebaas sarjade jaoks või retseptide infosüsteem. Meil on seal roogasid koos koostisosadega või nimekiri sarjadest ja näitlejatest». Meil on rõõm: «Teeme seda!». See on kaks bait'i edasi saata, paar tabelit ja kõik on valmis, kõik töötab väga kiiresti ja usaldusväärselt. Ja kõik on suurepärane, kuni tellijad ei tule ja ütle, et koduperenaised lahendavad veel ka vastupidi ülesande: neil on nimekiri koostisosadest ja nad tahavad teada, millist rooga nad soovivad valmistada. Te olete nüüd hukule määratud.

Selle põhjuseks on see, et Cassandra on hübriidandmebaas: see on samal ajal nii võtmeväärtus kui ka salvestab andmeid laias veergudes. Java või Kotlin keeles võiks seda niimoodi kirjeldada:

Map<RowKey, SortedMap<ColumnKey, ColumnValue>>

See tähendab, et kaardis on sees veel järjestatud kaart. Esimene võti selles kaardis on Row key ehk Partition key — partitsioneerimise võti. Teine võti, mis viib juba järjestatud kaardini, on Clustering key.

Andmebaasi hajutatusest illustreerimiseks joonistame kolm sõlme. Nüüd on vaja mõista, kuidas andmed sõlmedele jaotada. Sest kui me paneme kõik ühte (sõlmi võib olla tuhandeid, kahte tuhat, viit — kui palju tahes), ei ole see just väga hajutatud. Seetõttu on meil vaja matemaatilist funktsiooni, mis tagastab arvu. Lihtsalt numbri, pika int'i, mis jääb teatud vahemikku. Ja meil on üks sõlm, mis vastutab ühe vahemiku eest, teine — teise, n-nes — n-nda.

See number saadakse hash-funktsiooni abil, mida rakendatakse just sellele, mida me nimetame Partition key. See on see veerg, mis on toodud Primary key direktiivis, ja see veerg, mis on esialgne ja peamine kaardistamise võti. See määrab, millised andmed jõuavad millisele sõlmele. Tabel luuakse Cassandras peaaegu sama süntaksiga nagu SQL-is:

CREATE TABLE users (
	user_id uuid,
	name text,
	year int,
	salary float,
	PRIMARY KEY(user_id)

)

Primary key koosneb antud juhul ühest veerust, mis on samas ka partitseerimise võti.

Kuidas meie kasutajad jaotuvad? Osa läheb ühele sõlmele, osa teisele ja osa kolmandale. Tulemuseks on tavaline hash-tabel, see on ka kaardistus, Pythonis on see sõnastik, samuti on see lihtne Key value-struktuur, mille kaudu saame lugeda kõiki väärtusi ning lugeda ja kirjutada võtme abil.

Select: kui allow filtering muutub full scan-iks, või kuidas mitte teha

Kirjutame mingi select statementi: select * from users where user_id = . Tundub, et asi on Oracle’i moodi: kirjutame select, määrame tingimused ja kõik töötab, kasutajad saadakse kätte. Kuid kui valida näiteks kasutaja, kellel on teatud sünniaasta, siis Cassandra ütleb, et ei saa päringut täita. Sest tal ei ole aimugi, kuidas meie andmed sünniaasta kohta jaotuvad — tal on ainus võtme veerg. Siis ta ütleb: „Hea küll, ma saan siiski seda päringut täita. Lisage allow filtering.” Me lisame direktiivi ja kõik töötab. Ja sel hetkel juhtub kohutav asi.

Kui me katsetame testandmetega, siis on kõik suurepärane. Aga kui teete päringu tootmises, kus meil on näiteks 4 miljonit kirjet, siis ei ole meil asjad just väga hästi. Sest allow filtering — see on direktiiv, mis lubab Cassandrale koguda kõik andmed sellest tabelist kõigilt sõlmedelt, andmekeskustega (kui neid on palju selles klastris), ja siis alles seejärel filtreerida. See on analoogne Full Scan’iga ja vähesed on sellest elevil.

Kui me vajaksime kasutajaid ainult identifikaatorite järgi, sobiks see meile. Kuid mõnikord peame esitama teisi päringuid ja kehtestama muid filtreid. Seega peame meeles: see kõik on meil kaart, millel on partitsioneerimisvõti, kuid selle sees on sorteeritud kaart.

Ja sellel on samuti võti, mida nimetame Clustering Key. See võti koosneb veergudest, mille valime, millega Cassandra mõistab, kuidas andmed füüsiliselt sorteeritakse ja igas sõlmes paiknevad. See tähendab, et teatud Partition key jaoks Clustering key ütleb, kuidas täpselt andmed sellele puule suruda, kuhu nad seal jäävad.

See on tõeliselt puu, seal kutsutakse lihtsalt esile komparaator, kuhu edastame teatud veergude kogumi objektina, ja see määratakse samuti veergude loendina.

CREATE TABLE users_by_year_salary_id (
	user_id uuid,
	name text,
	year int,
	salary float,
	PRIMARY KEY((year), salary, user_id)

Pöörake tähelepanu primaarvõtme direktiivile: selle esimene argument (meie juhul aasta) on alati partitsioonivõti. See võib koosneda ühest või mitmest veerust, see pole oluline. Kui veerge on mitu, tuleb see veel korra sulgudesse panna, et keele eeltöötleja mõistaks, et tegemist on tõepoolest primaarvõtmega, mille järel järgivad kõik teised veerud - sissetulev võti. Samuti edastatakse need võrreldes selles järjekorras, milles need on. See tähendab, et esimene veerg on olulisem, teine - vähem oluline ja nii edasi. Nagu me kirjutame andmepäringute klasside puhul, näiteks võrreldes: loetleme veerud ja määrame, millised on olulisemad ja millised vähem. Cassandra's on see tinglikult öeldes andmepäringu klassi veerud, millele rakendatakse kirjutatud võrreldes.

Seame sorteerimise, rakendame piiranguid

Oluline on meeles pidada, et sorteerimisjärjekord (kas kasvav, kahanev või ükskõik milline) määratakse hetkel, mil luuakse võti, ja seda ei saa hiljem muuta. See määrab füüsiliselt, kuidas andmed järjestatakse ja kuhu need paigutatakse. Kui on vajalik muuta Clustering key või sorteerimisjärjekorda, tuleb luua uus tabel ja andmed sinna üle kanda. Niisuguse juba olemasolevaga ei saa nii teha.

Oleme täitnud oma tabeli kasutajatega ja näinud, et nad on järjestatud alguses sünniaja järgi ja siis sees igas sõlmes palga ja kasutaja ID järgi. Nüüd saame teha valikuid, seades piirangud.

Kordub taas meie töötav where, and, ja kasutajad saavad meile ning kõik on jälle hästi. Kuid kui proovime kasutada ainult osa Clustering key'ist, mis on vähem tähtis, siis Cassandra ütleb kohe, et ei leia meie kaardilt kohta, kus see objekt, millel on need väljad komparatorina null, ja kus on see, mille just määrasime, — kus see asub. Pean jälle kõik andmed sellest sõlmest üles tõstma ja need filtreerima. Ja see on analoogne Full Scan'iga sõlme piires, see on halb.

Igas olukorras loo uus tabel.

Kui soovime, et saaksime kasutajaid ID, vanuse või palga alusel leida, siis mida teha? Mitte midagi. Tuleb lihtsalt kasutada kahte tabelit. Kui kasutajaid tuleb leida kolme erineva meetodi järgi, siis on tabeleid kolm. Need ajad on möödas, kui püüdsime kettaruumi kokku hoida. See on odavaim ressurss. See maksab tunduvalt vähem kui vastusaeg, mis võib kasutajale saatuslikuks osutuda. Kasutajale on palju meeldivam saada midagi sekundiga, kui 10 minutiga.

Measime suuruse, denormaliseeritud andmete peale võimaldame paremat skaleerimist ja usaldusväärset toimimist. Tegelikult võib klaster, mis koosneb kolmest andmekeskusest, milles igas on viis sõlme, taluda ühe andmekeskuse täielikku kadumist, säilitades samas andmete vastuvõetava taseme (kui midagi kindlasti ei kaota). Ja veel kaks sõlme igas kahes ülejäänud. Ja alles pärast seda algavad probleemid. See on üsna hea varundamine, mis maksab paar-kolm liigsest SSD-diskist ja protsessorist. Seega, et kasutada Cassandrat, mis ei ole SQL, kus pole seoseid ega väliseid võtmeid, tuleb teadmisi omada lihtsatest reeglitest.

Kujundame kõik alates päringust. Peamine ei ole andmed, vaid see, kuidas rakendus nendega töötama hakkab. Kui rakendus vajab erinevate andmete saamist erinevates viisides või sama andme saamiseks erinevates viisides, peame need paigaldama selliselt, et see oleks rakendusele mugav. Vastasel juhul sattume Full Scan'i, ja Cassandra ei too meile mingit eelist.

Andmed denormeerida on normaalne. Unustame normaalsed vormid, meil ei ole enam relatsioonilisi andmebaase. Paneme midagi 100 korda ja see jääb 100 korda. See on ikka odavam kui puruneda.

Valime partitsioneerimiseks võtmed nii, et need oleks korralikult jaotatud. Me ei taha, et meie võtmete hash satuks kitsasse vahemikku. Ehkki, sünniaasta eeltoodud näites on halb näide. Tegelikult on see hea, kui meie kasutajad on sünniaasta järgi korralikult jaotatud, ja halb, kui tegemist on 5. klassi õpilastega — seal ei toimi partitsioneerimine hästi.

Sorteerimine valitakse üks kord Clustering Key loomise etapis. Kui seda on vaja muuta, tuleb meie tabel teise võtmega ümber tõsta.

Ja kõige tähtsam: kui meil on vaja andmeid 100 erineval viisil kätte saada, peame meil olema 100 erinevat tabelit.

Allikas: habr.com