Uzlabota galda apstrāde Kasandrā

Iepriekšējās apmācībās mēs pilnībā piedalījāmies CQL un veids, kā tas palīdz mums pārvaldīt Kasandra, mēs redzējām pamatdarbības atslēgu telpas un tabulas Kasandrā, mēs varētu tās pielietot, lai izveidotu sākotnējo struktūru datu bāzē, tomēr ir ievērojams daudzums progresīvu koncepciju, kas mums jāzina, lai gūtu maksimālu labumu no Kasandras.
Šie jēdzieni vai īpašības, lai tos kaut kādā veidā sauktu, ļauj mums tabulās sasniegt dažādas funkcijas, sniedzot mums daudz plašākas iespējas nekā pārējās. NoSQL datu bāze.
Iepriekš mēs izveidojām dažas tabulas un kolonnās izmantojām tādas vērtības kā teksts vai datums, taču tas vēl nav viss CQL ir pieejams, apskatīsim mūsu rīcībā esošo datu veidus:
asciiUS-ASCII rakstzīmju virkne.
bigint64 bitu garš vesels skaitlis.
lāseDatu tips, kas komandkonsolā ir izteikts kā heksadecimāls CQLTurklāt tam nav validācijas, un tas ir balstīts uz patvaļīgiem baitiem.
BūlaKlasiskais Būla datu tips, kura vērtības var būt patiesas vai nepatiesas.
skaitītājsskaitītājs ir jauns datu veids tiem no mums, kas nāk no relāciju pasaules, un norāda, ka tas ir izplatīts 64 bitu.
decimālskaitlisCits datu veids, ko mēs varam atpazīt, kas mums sniedz mūsu informācijai decimālo precizitāti.
dubultāPeldošā komata datu tips, bet balstīts uz 64 bitiem.
peldētTāpat kā iepriekšējais, tas ir peldošā komata datu tips, bet balstīts uz 32 bitiem.
inetŠis veids ir diezgan īpašs un vienlaikus ļoti noderīgs un ļauj mums saglabāt IP adreses rakstzīmju virkni, tas atbalsta gan formātu IPV4 Kas IPV6.
intKlasiskais veselu skaitļu datu tips, kas atbalsta skaitļus līdz 32 bitiem.
sarakstuCits datu veids, kas debitē Kasandrā un ļauj mums saglabāt pasūtītu elementu kolekciju.
karteTāpat kā saraksts, tas ir vēl viens jaunu datu veids, un tas ļauj mums saglabāt asociatīvu masīvu, kas ir ļoti noderīgs lietojumprogrammu izstrādei.
komplektsLīdzīgi kā saraksta datu tips, tajā tiek saglabāta vienumu kolekcija, bet ne noteiktā secībā.
tekstsSaglabā kodētu rakstzīmju virkni.
laika zīmogsDatu veids, kurā tiek saglabāts datums un laiks, kodēts kā 8 baitu vesels skaitlis.
lakaPrecīzs datu tips patvaļīgiem veseliem skaitļiem.
Kā redzam, ir daudz veidu datu, kurus mēs varam atpazīt, ja esam nākuši no attiecību pasaules, piemēram, citi, kurus redzēsim pirmo reizi. Kasandra izceļas pār citām datu bāzēm.
In Kasandra mums ir ne tikai datu veidi mūsu tabulām, pateicoties CQL Mēs varam piešķirt tabulām mūsu datu bāzes rekvizītos, kas mums ļoti palīdz apkopes un izstrādes uzdevumos, paskatīsimies, kas mums ir pieejams.
KešatmiņāŠis īpašums ļauj mums optimizēt kešatmiņu. Šim īpašumam pieejamie līmeņi ir tur vai visiem, tikai atslēgas vai tikai atslēgas, rows_only vai tikai rindas un neviena vai neviena. Tomēr visas iespējas ir diezgan noderīgas tikai_rindā jālieto piesardzīgi kā Kasandra Ievietojiet atmiņā ievērojamu datu apjomu, kad tiek izmantota šī opcija.
KomentētOpcija, kas ir relāciju modelī un ko izmanto administratori vai izstrādātāji, lai piezīmētu un tabulās izceltu svarīgu informāciju.
BlīvēšanaŠis īpašums ļauj definēt stratēģiju, kā pārvaldīt piparmētra, var būt šādi veidi: Pirmais Izmēru šķēres kas tiek aktivizēts, kad tabula pārsniedz ierobežojumu, šīs stratēģijas izmantošanas priekšrocība ir tā, ka tā nepasliktina rakstīšanas veiktspēju, taču tai ir trūkums, ka tā laiku pa laikam izmanto divreiz lielāku diskā esošo datu apjomu, kā rezultātā tiek pasliktināta veiktspēja lasīšana. Otra stratēģija ir LeveledCompaction un tas laika gaitā darbojas dažādos līmeņos, savienojot tabulas ar garākām, kā rezultātā tiek iegūta diezgan laba lasīšanas veiktspēja.
SaspiešanaŠis rekvizīts nosaka, kā informācija tiks saspiesta. Mēs varam izvēlēties, lai iegūtu priekšrocības ātrumā vai telpā, kur, jo lielāks ātrums, jo mazāk vietas diskā.
Gc_grace_secondsŠis īpašums nosaka gaidīšanas laiku, lai noņemtu informāciju no kapa pieminekļiem. Pēc noklusējuma tas ir 10 dienas.
Aizpildīt skalošanuŠis īpašums pēc noklusējuma ir atspējots, un mums tas jāaktivizē tikai tad, ja ceram, ka visa informācija ietilps kešatmiņā.
Read_repair_chanceĻoti interesants īpašums, kas norāda skaitli no 0 līdz 1,0, norādot varbūtību labot informāciju, kad kvorums nav sasniegts. Noklusējuma vērtība ir 0,1.
Replicate_on_writeŠis rekvizīts attiecas tikai uz šāda veida tabulām skaitītājs. Kad tas ir definēts, kopijas raksta uz visām ietekmētajām kopijām, ignorējot norādīto konsekvences līmeni.
Tātad mēs jau zinām, kas mums ir gan datu tipu, gan rekvizītu līmenī, tad ir pienācis laiks piemērot dažas no apgūtajām lietām mūsu tabulās Kasandra.
Vispirms mēs izveidosim vienkāršu tabulu, kurai piemērosim komentāru īpašumu, apskatīsim sintaksi, ko tam izmantosim:

 CREATE TABLE raksti (teksta nosaukums, teksta saturs, teksta kategorija, PRIMARY KEY (title)) WITH comment = 'Tabula raksta informācijas glabāšanai';

Mēs atveram komandu konsoli CQL un mēs izveidojam savu tabulu ar minēto īpašumu, redzēsim, kā tas izskatās:

Kā mēs jau zinām, komandu konsole neko neatgriež, izņemot to, ka nav kļūdas, bet, ja vēlamies redzēt šīs izmaiņas, mēs varam doties uz OpsCenter un pārbaudiet, vai viss ir noticis pareizi:

PALIELINĀT

Kā redzam, mēs varam redzēt mūsu komentāru un citus rekvizītus ar to noklusējuma vērtībām. Ir svarīgi pieminēt, ka pārējo īpašumu definīcija Kasandra tas ir pavisam vienkārši, kā mēs varējām redzēt iepriekšējā piemērā, izmantojot sintaksi AR mēs to varam izdarīt bez problēmām.
Mēs veiksim vēl vienu piemēru, kurā mēs definēsim īpašības saspiešana Y blīvēšana taču šim nolūkam ir svarīgi zināt, ka to izmantošanai ir vairākas apakšsadaļas saspiešana kas mums būtu jāzina:
Stabila saspiešanaŠī opcija nosaka izmantojamo saspiešanas algoritmu, tā vērtības ir: LY4Compressor, SnappyCompressor, Y DeflateCompressor.
Chunck_length_kbTabulas ir saspiestas ar blokiem. Garākas vērtības parasti nodrošina labāku saspiešanu, bet palielina lasāmās informācijas apjomu. Pēc noklusējuma šī opcija ir iestatīta uz 64 kb.
Manipulējot saspiešanas opcijas, var ievērojami palielināties veiktspēja, ieskaitot daudzas ieviešanas iespējas Kasandra Tie ir ar šīm noklusējuma vērtībām, taču pilnībai ir jāizmanto šīs vērtības. Tagad redzēsim, kas mums jāzina blīvēšana:
IespējotsNosaka, vai rekvizīts darbosies tabulā, lai gan pēc noklusējuma visiem rekvizītiem ir blīvēšana iespējots.
KlaseŠeit mēs definēsim tabulas apstrādes stratēģijas veidu.
min_ slieksnisŠī vērtība ir pieejama kopā ar stratēģiju Izmēru šķēres y apzīmē minimālo tabulu skaitu, kas nepieciešams, lai sāktu blīvēšanas procesu. Pēc noklusējuma tas ir noteikts 4.
max_thresholdPieejams tādā pašā veidā stratēģijā Izmēru šķēres y nosaka maksimālo tabulā apstrādāto tabulu skaitu. Pēc noklusējuma tas ir noteikts 32.
Šīs ir dažas no vissvarīgākajām šo īpašību iespējām, un ir svarīgi pieminēt, ka šo opciju definēšanai jāizmanto sintakse JSON Lai tas būtu derīgs, aplūkosim piemēru šo divu rekvizītu iekļaušanai:

 CREATE TABLE table_for_properties (int id, teksta nosaukums, teksta rekvizīts, varinta numurs, PRIMARY KEY (id)) WITHcompression = {'sstable_compression': 'DeflateCompressor', 'chunk_length_kb': 64} ANDcompaction = {'class': 'SizeTieredCompactionSt, 'min_threshold': 6};

Kā redzam, esam mainījuši saspiešanas veidu un esam definējuši tā izmēru, papildus blīvēšana mēs esam atstājuši parasto stratēģiju ar vērtību klase un mēs esam definējuši min_ slieksnis piemēram, 6 palielināja noklusējuma vērtību šādi, lai pabeigtu, redzēsim, kā tas izskatās, kad mēs to izpildām savā komandu konsolē:

Pēdējā apmācībā mēs redzējām, ka vairāk nekā vienas primārās atslēgas definēšanas rezultātā tās tiek izveidotas kā klasteru atslēgas un pastāstiet mums ceļu Kasandra kārto informāciju, pēc noklusējuma secība ir definēta augošā secībā, un vaicājuma veikšana dilstošā secībā var radīt veiktspējas problēmas, tomēr Kasandrai ir risinājums jebkurai problēmai, un tas ir ar teikumu KLASTRĒŠANA *****. Apskatīsim, kā to izmantot.

 IZVEIDOT TABULU pasūtīti_lietotāji (lietotāja teksts, datuma laikspiedols, algas pielikums, nodaļas teksts, supervizora teksts, PRIMARY KEY (lietotājs, datums)) AR KLASTRĒŠANU ***** BY (datums DESC);

Palaidīsim mūsu sintaksi komandu konsolē un redzēsim, kā tā izskatās:

Kā redzējām, šo problēmu bija diezgan viegli atrisināt ar vienkāršu līniju, bet vēl svarīgāk - mēs varējām paplašināt zināšanas par tabulu apstrādi Kasandra, ar kuru mēs pabeidzam šo apmācību, kurā mēs esam aptvēruši visu, kas mums jāzina, lai izveidotu optimālu tabulu Kasandra.