Cassandra. Kuidas ellu jääda, kui tead ainult Oracle'it

Tere, Habr.

Minu nimi on Misha Butrimov ja ma tahaksin rääkida Cassandra'st. Minu jutt on kasulik neile, kes pole kunagi NoSQL andmebaasidega kokku puutunud — nende eripära ja peidetud probleemid, millest tuleks teada, on väga olulised. Ja kui oled näinud ainult Oracle'it või mõnda muud relatsioonilist andmebaasi, võivad need teadmised sind päästa.

Milles on Cassandra hea? See on NoSQL andmebaas, mis on projekteeritud ilma ühegi tõrkepunktita ja mis skaleerub hästi. Kui vajad mingeid terabaiti andmeid, siis lihtsalt lisad sõlmed ringi. Tahtsid laiendada veel ühte andmekeskust? Lisad sõlmed klastrisse. Tahad suurendada töödeldavat RPS-i? Lisad sõlmed klastrisse. See töötab ka tagasi.

Milles veel on see hea? Sellel on suur võime käsitleda hulgaliselt päringuid. Aga kui palju on palju? 10, 20, 30, 40 tuhat päringut sekundis — see on vähe. 100 tuhat päringut sekundis kirjutamiseks — ka see on vähe. On ettevõtteid, kes ütlevad, et nad suudavad pidada 2 miljonit päringut sekundis. Talle peab vist uskuma.

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

Kõik, mis näeb välja sama, ei tööta sama moodi

Kord küsis minult kolleeg: „Siin on CQL Cassandra päringute keel, kus on select lause, kus on where ja kus on and. Ma kirjutan tähti, ja see ei tööta. Miks?“. Kui suhelda Cassandra'ga nagu relatsioonilise andmebaasiga, siis on see ideaalne viis oma elu lõpetamiseks. Ja ma ei propageeri seda, see on Venemaal keelatud. Lihtsalt projekteerid midagi valesti.

Näiteks tuleb meile klient ja ütleb: „Ehitage andmebaas seriaale või andmebaas retseptide kogumikuks. Meil on seal toidud koostisosadega või nimekiri seriaalidest ja nende näitlejatest“. Me vastame rõõmsalt: „Teeme!“. See on vaid kaks baitit edasi saata, paar tabelit ja kõik on valmis, kõik töötab väga kiiresti ja usaldusväärselt. Kõik on suurepärane, kuni kliendid ei tule ja ütle, et koduperenaised lahendavad ka vastupidist ülesannet: neil on nimekiri koostisosadest ja nad tahavad teada, millise toidu nad saavad valmistada. Siis oled sa hukkunud.

Kõik on tingitud sellest, et Cassandra on hübriidne andmebaas: see on samal ajal nii key-value kui ka salvestab andmeid laias veergudes. Kui rääkida Java või Kotlin keeles, siis saaksime seda kirjeldada nii:

Map<RowKey, SortedMap>

See tähendab kaarti, mille sees on veel üks sorteeritud kaart. Esimene võtmeosa selles kaardis on Row key või Partition key — partitsioneerimisvõti. Teine võti, mis on võtmeosa juba sorteeritud kaardist, on Clustering key.

Jaotuse illustreerimiseks joonistame kolm sõlme. Nüüd on vaja mõista, kuidas andmeid sõlmedesse jaotada. Sest kui me surume kõik ühte (neid võib olla näiteks tuhat, kaks tuhat, viis — kuivõrd soovite), siis see ei ole just väga jaotuse moodi. Seepärast on meil vajalik matemaatiline funktsioon, mis tagastab arvu. Lihtsalt arvu, pika int, mis sureb mingisse vahemikku. Ja meil on üks sõlm, mis vastutab ühe vahemiku eest, teine — teise, n-nes — n-nda.

See number saadakse hash-funktsiooni abil, mis rakendatakse just sellele, mida me nimetame Partition key. See on see veerg, mis on määratud Primary key direktiivis, ja see on see veerg, mis on esimene ja kõige olulisem võtmeosa kaardis. See määrab, millised andmed lähedusse satuvad. Tabel luuakse Cassandrasse 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 samuti partitsioneerimisvõti.

Kuidas meil kasutajad jaotuvad? Osa läheb ühte sõlmesse, osa teise ja osa kolmandasse. Saame tavalise hash-tabeli, mis on ehk map, või siis Pythonis — sõnaraamat, aga ka lihtne Key-value struktuur, millest saame lugeda kõiki väärtusi, lugeda ja kirjutada võtme järgi.

Select: kui allow filtering muutub full scaniks, või kuidas mitte teha

Kirjutame mingi select lause: select * from users where userid = . Tundub, et see on midagi sarnast Oracle'iga: kirjutame select, määrame tingimused ja kõik töötab, kasutajad tulevad välja. Kuid kui valida näiteks kasutaja kindla sünniaasta järgi, kurdab Cassandra, et ta ei saa päringut täita. Sest tal ei ole aimugi, kuidas meil sünniaastaga seotud andmed jaotuvad — tal on võtmena ainult üks tegevus. Siis ütleb ta: "Olgu, ma saan ikkagi selle päringu täita. Lisage allow filtering." Me lisame direktiivi, kõik töötab. Ja sel hetkel juhtub midagi kohutavat.

Kui testime testandmetega, siis kõik on suurepärane. Kuid kui teete päringu tootmises, kus meil on näiteks 4 miljonit kirjet, siis pole meiega hästi. Sest allow filtering on direktiiv, mis lubab Cassandral koguda kõik andmed sellest tabelist kõigilt sõlmedelt, kõikelt andmekeskustes (kui neid on palju selles klastris), ja alles siis filtreerida. See on analoogne Full Scan'iga ja ilmselt pole keegi sellest vaimustuses.

Kui me vajaksime kasutajaid ainult identifikaatorite järgi, siis see sobiks meile. Kuid mõnikord peame kirjutama teisi päringuid ja seadma muud piirangud andmete valikule. Seega meenutame: kõik see on meile kaart, millel on partitseerimise võti, kuid selle sees on sorteeritud kaart.

Ja sellel on ka võti, mida me nimetame Clustering Key'iks. See võti koosneb omakorda veergudest, mille me valime, mille abil Cassandra mõistab, kuidas tema andmed füüsiliselt järjestatakse ja paigutatakse igasse sõlme. Teisisõnu, mingi Partition key Clustering key ütleb, kuidas andmed selle puu sisse paigutada, millisesse kohta nad seal asuvad.

See on tõeliselt puu, seal kutsutakse lihtsalt võrdlejate funktsiooni, millele anname teatud veergude komplekti objektina, ja see määratakse ka veergude loendi kujul.

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 Primary key direktiivile, mille esimeseks argumendiks (meie puhul aasta) on alati Partition key. See võib koosneda ühest või mitmest veerust, see pole oluline. Kui veerge on mitu, tuleks see uuesti sulgudesse panna, et keele eelprotsessor saaks aru, et see on just Primary key, ja kõik teised veerud on Clustering key. Samuti edastatakse need võrdlejana selles järjekorras, milles nad on. See tähendab, et esimene veerg on olulisem, teine - vähem oluline ja nii edasi. Nagu me data class'ide puhul kirjutame, näiteks equals väljad: loetleme väljad ja määrame, millised on suuremad ja millised väiksemad. Cassandrases on see hüpoteetiliselt data class'i väljad, millele rakendatakse kirjutatud equals.

Määrame sorteerimise, rakendame piiranguid

Peame meeles pidama, et sorteerimise järjekord (kahanev, kasvav, ei ole oluline) määratakse samal hetkel, kui võti luuakse, ja hiljem seda muuta ei saa. See määrab füüsiliselt, kuidas andmed sorteeritakse ja kus nad asuvad. Kui Clustering key või sorteerimise järjekorda tuleb muuta, tuleb luua uus tabel ja, üle kanda andmed. Praeguse tabeli puhul pole see võimalik.

Me oleme täitnud meie tabeli kasutajatega ja näinud, et nad on esialgu järjestatud sünniaasta järgi, ja siis iga sõlme sees palga ja kasutaja ID järgi. Nüüd saame valida, rakendades piiranguid.

Meie töötav where, ja, ja kasutajad jäävad meile kätte, ja kõik on jälle hästi. Kuid kui proovime kasutada ainult osa Clustering key'st, veel vähem olulist, siis Cassandra annab kohe teada, et ei leia meie mapis kohta, kus see objekt, millel need väljad võrreldes on null, ja see, mille just määrasime - kus see asub. Pean jälle kõik andmed sellelt sõlmelt üles tooma ja filtreerima. See on analoogne Full Scan'iga sõlmes, see on halb.

Igas segaduses olukorras loo uus tabel

Kui soovime kasutajaid hankida ID, vanuse või palga järgi, siis mida teha? Mitte midagi. Lihtsalt kasutage kahte tabelit. Kui on vaja hankida kasutajaid kolme erineva meetodi järgi, siis tabelite arv on kolm. Need ajad, mil me itahtsid ruumi kõvakettal säästa, on möödas. See on kõige odavam ressurss. See maksab palju vähem kui vastusaeg, mis võib kasutajale saatuslik olla. Kasutajale on palju meeldivam saada midagi sekundi jooksul kui kümne minutiga.

Vahetame liigse ruumi, denormaliseeritud andmete vastu võimaluse hästi skaleeruda ja usaldusväärselt töötada. Tegelikult suudab klaster, mis koosneb kolmest andmekeskusest, milles igas on viis nodi, taluda ühe andmekeskuse täielikku kadumist, säilitades andmete vastuvõetava taseme (kui midagi ei kao kindlalt). Ja veel kaks nodi igas kahes ülejäänud. Ainult siis hakkavad probleemid ilmuma. See on üsna hea varundamine, see maksab paar-kolm liigset SSD-d ja protsessorit. Seetõttu, et kasutada Cassandra't, mis ei ole kunagi SQL ja kus pole suhteid ega välisvõtmeid, tuleb teada lihtsaid reegleid.

Kujundame kõik päringu järgi. Peamine ei ole andmed, vaid see, kuidas rakendus nendega töötama hakkab. Kui tal on vaja erinevaid andmeid erinevate meetodite kaudu või samu andmeid erinevate meetodite kaudu saada, peame need panema niimoodi, et see sobiks rakendusele. Vastasel juhul läheme Full Scan'i ja Cassandra ei too meile mingit eelist.

Denormaliseeritud andmete kasutamine on norm. Unustame normaalsed vormid, meil ei ole enam relatsionaalseid baase. Paneme midagi 100 korda, see on 100 korda seal. See on ikkagi odavam kui lõksu jääda.

Valime partitsioneerimise võtmed nii, et need jaotuksid normaalselt. Me ei vaja, et meie võtmete hulk satuks kitsasse vahemikku. Niisiis, sünniaasta eespooltoodud näites on halb näide. Tegelikult on see hea, kui meie kasutajad on sünniaasta järgi normaalselt jaotunud, ja halb, kui räägime 5. klassi õpilastest - seal ei toimi partitsioneerimine väga hästi.

Sorteerimine valitakse kord ühel Clustering Key loomise etapil. Kui seda on vaja muuta, tuleb meie tabel teise võtmega üle kanda.

Ja kõige olulisem: kui meil on vaja 100 erinevat viisi samade andmete saamiseks, tähendab see, et meil on 100 erinevat tabelit.

Allikas: habr.com