ProHoster > Blogs > Administrācija > Kasandra. Kā nenomirt, ja pazīsti tikai Oracle

Kasandra. Kā nenomirt, ja pazīsti tikai Oracle

Čau, Habr.

Mani sauc MiÅ”a Butrimovs, es gribētu jums nedaudz pastāstÄ«t par Kasandru. Mans stāsts noderēs tiem, kuri nekad nav saskāruÅ”ies ar NoSQL datu bāzēm ā€“ tajā ir daudz ievieÅ”anas funkciju un nepilnÄ«bu, par kurām jāzina. Un, ja jÅ«s neesat redzējis neko citu kā Oracle vai jebkuru citu relāciju datu bāzi, Ŕīs lietas izglābs jÅ«su dzÄ«vÄ«bu.

Kas ir tik labs Kasandrā? Tā ir NoSQL datu bāze, kas izstrādāta bez viena kļūmes punkta, un tā ir labi mērogojama. Ja kādai datubāzei jāpievieno pāris terabaiti, gredzenam vienkārÅ”i jāpievieno mezgli. Vai paplaÅ”ināt to citā datu centrā? Pievienojiet kopai mezglus. Vai palielināt apstrādāto IPS? Pievienojiet kopai mezglus. Tas darbojas arÄ« pretējā virzienā.

Kasandra. Kā nenomirt, ja pazīsti tikai Oracle

Kas vēl viņai padodas? Tas attiecas uz daudzu pieprasÄ«jumu apstrādi. Bet cik ir daudz? 10, 20, 30, 40 tÅ«kstoÅ”i pieprasÄ«jumu sekundē nav daudz. 100 tÅ«kstoÅ”i pieprasÄ«jumu sekundē ierakstÄ«Å”anai - arÄ«. Ir uzņēmumi, kas teica, ka saglabā 2 miljonus pieprasÄ«jumu sekundē. Viņiem droÅ”i vien bÅ«s jātic.

Un principā Kasandrai ir viena liela atŔķirÄ«ba no relāciju datiem - tas viņiem nemaz nav lÄ«dzÄ«gs. Un tas ir ļoti svarÄ«gi atcerēties.

Ne viss, kas izskatās vienādi, darbojas tāpat

Reiz pie manis pienāca kolēģis un jautāja: ā€œÅ eit ir CQL Cassandra vaicājumu valoda, un tai ir atlases priekÅ”raksts, ir kur, tai ir un. Es rakstu vēstules un tas nedarbojas. Kāpēc?". Cassandra uztverÅ”ana kā relāciju datubāze ir ideāls veids, kā izdarÄ«t vardarbÄ«gu paÅ”nāvÄ«bu. Un es to nereklamēju, Krievijā tas ir aizliegts. JÅ«s vienkārÅ”i izstrādāsit kaut ko nepareizi.

Piemēram, pie mums pienāk klients un saka: ā€œVeidosim datubāzi seriāliem vai datubāzi recepÅ”u direktorijai. Mums tur bÅ«s ēdiena ēdieni vai seriālu un aktieru saraksts tajā. Mēs priecÄ«gi sakām: "Ejam!" VienkārÅ”i nosÅ«tiet divus baitus, pāris zÄ«mes un esat pabeidzis, viss darbosies ļoti ātri un uzticami. Un viss ir kārtÄ«bā, lÄ«dz atnāk klienti un saka, ka saimnieces risina arÄ« pretēju problēmu: viņām ir produktu saraksts, un viņas grib zināt, kādu ēdienu grib pagatavot. Tu esi miris.

Tas ir tāpēc, ka Cassandra ir hibrÄ«da datu bāze: tā vienlaikus nodroÅ”ina atslēgas vērtÄ«bu un saglabā datus plaŔās kolonnās. Java vai Kotlin to varētu aprakstÄ«t Ŕādi:

Map<RowKey, SortedMap<ColumnKey, ColumnValue>>

Tas ir, karte, kurā ir arÄ« sakārtota karte. Pirmā Ŕīs kartes atslēga ir rindas atslēga vai nodalÄ«juma atslēga ā€” sadalÄ«Å”anas atslēga. Otrā atslēga, kas ir atslēga uz jau sakārtotu karti, ir klasterizācijas atslēga.

Lai ilustrētu datu bāzes sadalÄ«jumu, uzzÄ«mēsim trÄ«s mezglus. Tagad jums ir jāsaprot, kā sadalÄ«t datus mezglos. Jo, ja mēs visu sabāzam vienā (starp citu, var bÅ«t tÅ«kstotis, divi tÅ«kstoÅ”i, pieci - cik vien vēlaties), Å”eit nav runa par izplatÄ«Å”anu. Tāpēc mums ir nepiecieÅ”ama matemātiska funkcija, kas atgriezÄ«s skaitli. Tikai skaitlis, garÅ” int, kas ietilps kādā diapazonā. Un mums bÅ«s viens mezgls, kas atbild par vienu diapazonu, otrs par otro, n-tais par n-to.

Kasandra. Kā nenomirt, ja pazīsti tikai Oracle

Å is numurs tiek ņemts, izmantojot jaucējfunkciju, kas tiek piemērota tam, ko mēs saucam par nodalÄ«juma atslēgu. Å Ä« ir kolonna, kas norādÄ«ta primārās atslēgas direktÄ«vā, un Ŕī ir kolonna, kas bÅ«s pirmā un visvienkārŔākā kartes atslēga. Tas nosaka, kurÅ” mezgls saņems kādus datus. Cassandra tiek izveidota tabula ar gandrÄ«z tādu paÅ”u sintaksi kā SQL: 

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

)

Primārā atslēga Å”ajā gadÄ«jumā sastāv no vienas kolonnas, un tā ir arÄ« nodalÄ«juma atslēga.

Kā mÅ«su lietotāji veiksies? Daži nokļūs vienā mezglā, daži uz citu un daži uz treÅ”o. Rezultāts ir parasta hash tabula, kas pazÄ«stama arÄ« kā karte, kas pazÄ«stama arÄ« kā vārdnÄ«ca Python, vai vienkārÅ”a atslēgas vērtÄ«bu struktÅ«ra, no kuras mēs varam lasÄ«t visas vērtÄ«bas, lasÄ«t un rakstÄ«t pēc atslēgas.

Kasandra. Kā nenomirt, ja pazīsti tikai Oracle

Izvēlieties: kad atļaut filtrÄ“Å”anu pārvērÅ”as par pilnu skenÄ“Å”anu vai ko nedarÄ«t

UzrakstÄ«sim dažus atlasÄ«tus paziņojumus: select * from users where, userid = . Iznāk kā Oracle: rakstām select, norādām nosacÄ«jumus un viss strādā, lietotāji to saņem. Bet, ja izvēlaties, piemēram, lietotāju ar noteiktu dzimÅ”anas gadu, Kasandra sÅ«dzas, ka nevar izpildÄ«t pieprasÄ«jumu. Tā kā viņa vispār neko nezina par to, kā mēs izplatām datus par dzimÅ”anas gadu - viņai kā atslēga ir norādÄ«ta tikai viena kolonna. Tad viņa saka: ā€œLabi, es joprojām varu izpildÄ«t Å”o pieprasÄ«jumu. Pievienot atļaut filtrÄ“Å”anu." Pievienojam direktÄ«vu, viss darbojas. Un Å”ajā brÄ«dÄ« notiek kaut kas Å”ausmÄ«gs.

Kad mēs izmantojam testa datus, viss ir kārtÄ«bā. Un, kad jÅ«s izpildāt vaicājumu ražoÅ”anā, kur mums ir, piemēram, 4 miljoni ierakstu, tad mums viss nav Ä«paÅ”i labi. Jo atļaut filtrÄ“Å”anu ir direktÄ«va, kas ļauj Cassandra savākt visus datus no Ŕīs tabulas no visiem mezgliem, visiem datu centriem (ja to Å”ajā klasterÄ« ir daudz) un tikai pēc tam tos filtrēt. Å is ir Full Scan analogs, un gandrÄ«z neviens ar to nav sajÅ«smā.

Ja mums bÅ«tu nepiecieÅ”ami tikai lietotāji ar ID, mēs ar to bÅ«tu labi. Bet dažreiz mums ir jāraksta citi vaicājumi un jāuzliek citi atlases ierobežojumi. Tāpēc mēs atceramies: Ŕī ir visa karte, kurai ir sadalÄ«Å”anas atslēga, bet tās iekÅ”pusē ir sakārtota karte.

Un viņai ir arÄ« atslēga, ko mēs saucam par klasteru atslēgu. Å Ä« atslēga, kas, savukārt, sastāv no mÅ«su atlasÄ«tajām kolonnām, ar kuru palÄ«dzÄ«bu Kasandra saprot, kā tās dati tiek fiziski sakārtoti un atradÄ«sies katrā mezglā. Tas nozÄ«mē, ka kādai nodalÄ«juma atslēgai klasterizācijas atslēga precÄ«zi pateiks, kā ievietot datus Å”ajā kokā, kādu vietu tie tur ieņems.

Tas tieŔām ir koks, tur vienkārŔi tiek izsaukts salīdzinājums, kuram objekta formā nododam noteiktu kolonnu kopu, un tas ir norādīts arī kā kolonnu saraksts. 

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

Pievērsiet uzmanÄ«bu primārās atslēgas direktÄ«vai; tās pirmais arguments (mÅ«su gadÄ«jumā gads) vienmēr ir nodalÄ«juma atslēga. Tas var sastāvēt no vienas vai vairākām kolonnām, tas nav svarÄ«gi. Ja ir vairākas kolonnas, tā ir vēlreiz jānoņem iekavās, lai valodas priekÅ”apstrādātājs saprastu, ka Ŕī ir primārā atslēga, un aiz tās visas pārējās kolonnas ir klasterizācijas atslēga. Å ajā gadÄ«jumā tie tiks pārsÅ«tÄ«ti salÄ«dzinātājā tādā secÄ«bā, kādā tie parādās. Tas ir, pirmā kolonna ir nozÄ«mÄ«gāka, otrā ir mazāk nozÄ«mÄ«ga utt. Piemēram, tas, kā mēs rakstām, ir vienāds ar laukiem datu klasēm: mēs uzskaitām laukus, un tiem rakstām, kuri no tiem ir lielāki un kuri mazāki. Kasandrā tie, nosacÄ«ti runājot, ir datu klases lauki, kuriem tiks piemēroti tai rakstÄ«tie vienādi.

Nosakām ŔķiroŔanu un uzliekam ierobežojumus

Jāatceras, ka kārtoÅ”anas secÄ«ba (dilstoŔā, augoŔā, jebkas) tiek iestatÄ«ta atslēgas izveides brÄ«dÄ«, un vēlāk to nevar mainÄ«t. Tas fiziski nosaka, kā dati tiks kārtoti un kā tie tiks uzglabāti. Ja jums ir jāmaina klasterizācijas atslēga vai kārtoÅ”anas secÄ«ba, jums bÅ«s jāizveido jauna tabula un jāpārsÅ«ta tajā dati. Tas nedarbosies ar esoÅ”u.

Kasandra. Kā nenomirt, ja pazīsti tikai Oracle

Mēs piepildÄ«jām savu tabulu ar lietotājiem un redzējām, ka viņi iekrita gredzenā, vispirms pēc dzimÅ”anas gada un pēc tam katrā mezglā pēc algas un lietotāja ID. Tagad mēs varam izvēlēties, uzliekot ierobežojumus.

Atkal parādās mÅ«su strādājoÅ”ais where, and, un mēs iegÅ«stam lietotājus, un viss atkal ir kārtÄ«bā. Bet, ja mēs mēģināsim izmantot tikai daļu no klasterizācijas atslēgas un mazāk nozÄ«mÄ«gu, tad Kasandra uzreiz sÅ«dzēsies, ka nevar atrast vietu mÅ«su kartē, kur Å”is objekts, kuram ir Å”ie lauki nulles salÄ«dzinātājam, un Å”is. kas tikko tika uzstādÄ«ts , - kur viņŔ guļ. Man bÅ«s vēlreiz jāizņem visi dati no Ŕī mezgla un jāfiltrē. Un tas ir pilnas skenÄ“Å”anas analogs mezglā, tas ir slikti.

Jebkurā neskaidrā situācijā izveidojiet jaunu tabulu

Ja mēs vēlamies, lai lietotāji varētu atlasÄ«t mērÄ·auditoriju pēc ID, vecuma vai algas, kas mums jādara? Nekas. VienkārÅ”i izmantojiet divas tabulas. Ja vēlaties sasniegt lietotājus trÄ«s dažādos veidos, bÅ«s trÄ«s tabulas. Ir pagājuÅ”i tie laiki, kad mēs ietaupÄ«jām vietu uz skrÅ«ves. Å is ir lētākais resurss. Tas maksā daudz mazāk nekā reakcijas laiks, kas var kaitēt lietotājam. Lietotājam ir daudz patÄ«kamāk kaut ko saņemt sekundē nekā 10 minÅ«tēs.

Mēs tirgojam nevajadzÄ«gu vietu un denormalizētus datus, lai varētu labi mērogot un darboties uzticami. Galu galā klasteris, kas sastāv no trim datu centriem, no kuriem katrā ir pieci mezgli, ar pieņemamu datu saglabāŔanas lÄ«meni (kad nekas netiek zaudēts), spēj pilnÄ«bā pārdzÄ«vot viena datu centra nāvi. Un vēl divi mezgli katrā no atlikuÅ”ajiem diviem. Un tikai pēc tam sākas problēmas. Å Ä« ir diezgan laba atlaiÅ”ana, ir vērts iegādāties pāris papildu SSD diskus un procesorus. Tāpēc, lai izmantotu Cassandra, kas nekad nav SQL, kurā nav attiecÄ«bu, ārējās atslēgas, jums jāzina vienkārÅ”i noteikumi.

Izstrādājam visu pēc JÅ«su pieprasÄ«juma. Galvenais nav dati, bet gan tas, kā lietojumprogramma ar tiem strādās. Ja tai ir jāsaņem dažādi dati dažādos veidos vai tie paÅ”i dati dažādos veidos, mums tie ir jāievieto lietojumprogrammai ērtā veidā. Pretējā gadÄ«jumā mēs cietÄ«sim neveiksmi Full Scan, un Cassandra mums nedos nekādas priekÅ”rocÄ«bas.

Datu denormalizācija ir norma. Mēs aizmirstam par parastajām formām, mums vairs nav relāciju datu bāzes. Ja mēs kaut ko noliksim 100 reizes, tas noguls 100 reizes. Tas joprojām ir lētāk nekā apstāŔanās.

Mēs izvēlamies sadalÄ«Å”anas atslēgas, lai tās tiktu izplatÄ«tas normāli. Mēs nevēlamies, lai mÅ«su atslēgu sajaukums nonāktu vienā Å”aurā diapazonā. Tas ir, dzimÅ”anas gads iepriekÅ” minētajā piemērā ir slikts piemērs. PrecÄ«zāk sakot, ir labi, ja mÅ«su lietotāji ir normāli sadalÄ«ti pēc dzimÅ”anas gadiem, un slikti, ja mēs runājam par 5. klases skolēniem - nodalÄ«jums tur nebÅ«s Ä«paÅ”i labs.

Klasterizācijas atslēgas izveides posmā kārtoÅ”ana tiek atlasÄ«ta vienreiz. Ja tas ir jāmaina, mums bÅ«s jāatjaunina tabula ar citu atslēgu.

Un pats galvenais: ja mums ir nepiecieŔams izgūt vienus un tos paŔus datus 100 dažādos veidos, tad mums būs 100 dažādas tabulas.

Avots: www.habr.com

Pievieno komentāru