Geavanceerde tafelafhandeling in Cassandra

In eerdere tutorials zijn we volledig ingegaan met CQL en de manier waarop het ons helpt om te managen Cassandra, zagen we de basishandelingen voor de sleutelruimten en de tabellen in Cassandra, we zouden ze kunnen toepassen om een ​​initiële structuur in de Database te creëren, maar er zijn een aanzienlijke hoeveelheid geavanceerde concepten die we moeten kennen om het meeste uit Cassandra te halen.
Deze concepten of kenmerken om ze op de een of andere manier te noemen, stellen ons in staat om verschillende functionaliteiten in onze tabellen te bereiken, waardoor we een reeks mogelijkheden hebben die veel groter zijn dan de rest van de andere. Geen SQL-database.
Eerder hebben we enkele tabellen gemaakt en waarden zoals tekst of datum voor onze kolommen gebruikt, maar dit is niet alles CQL beschikbaar heeft, laten we eens kijken welke soorten gegevens we hebben voor onze activiteiten:
asciiUS-ASCII-tekenreeks.
bigintEen 64-bits lange integerwaarde.
klodderGegevenstype uitgedrukt als een hexadecimaal in de opdrachtconsole van CQLBovendien heeft het geen validatie en is het gebaseerd op willekeurige bytes.
booleaansHet klassieke Booleaanse gegevenstype waarbij de waarden waar of onwaar kunnen zijn.
baliecounter is een nieuw gegevenstype voor degenen onder ons die uit de relationele wereld komen en geeft aan dat het 64-bits gedistribueerd is.
decimaleEen ander type gegevens dat we kunnen herkennen, wat ons decimale precisie geeft voor onze informatie.
dubbeleGegevenstype met drijvende komma maar gebaseerd op 64 bits.
vlotNet als de vorige is het een gegevenstype met drijvende komma, maar gebaseerd op 32 bits.
inetDit type is vrij bijzonder en tegelijkertijd erg handig en stelt ons in staat een reeks tekens van een IP-adres op te slaan, het ondersteunt zowel het formaat IPV4 Wat IPV6.
intHet klassieke integer-gegevenstype dat getallen tot 32 bits ondersteunt.
lijstEen ander type gegevens dat zijn debuut maakt in Cassandra en ons in staat stelt een geordende verzameling elementen op te slaan.
kaartNet als lijst, is het een ander type nieuwe gegevens, en het stelt ons in staat om een ​​associatieve array op te slaan, wat erg handig is voor applicatie-ontwikkeling.
setVergelijkbaar met het gegevenstype lijst, slaat het een verzameling items op, maar in geen specifieke volgorde.
tekstSlaat een gecodeerde tekenreeks op.
tijdstempelGegevenstype waarin datum en tijd worden opgeslagen, gecodeerd als een geheel getal van 8 bytes.
variantPrecisiegegevenstype voor willekeurige gehele getallen.
Zoals we kunnen zien, zijn er veel soorten gegevens die we kunnen herkennen als we uit de relationele wereld komen, zoals andere die we voor het eerst zullen zien en die Cassandra onderscheidt zich boven andere databases.
In Cassandra we hebben niet alleen datatypes voor onze tabellen, dankzij CQL We kunnen toewijzen aan de tabellen in onze database-eigenschappen die ons enorm helpen bij onderhouds- en ontwikkelingstaken, laten we eens kijken wat we beschikbaar hebben.
CachingDeze eigenschap geeft ons cachegeheugenoptimalisatie. De beschikbare niveaus voor deze woning zijn: daar of iedereen, keys_only of gewoon sleutels, rows_only of alleen rijen en geen of geen. Alle opties zijn echter best handig row_only moet met zorg worden gebruikt als: Cassandra zet een aanzienlijke hoeveelheid gegevens in het geheugen wanneer die optie wordt gebruikt.
CommentaarEen optie die aanwezig is in het relationele model en wordt gebruikt door beheerders of ontwikkelaars om aantekeningen te maken en belangrijke details in tabellen te markeren.
verdichtingMet deze eigenschap kunt u de strategie definiëren voor het beheer van de munt, kan van de volgende typen zijn: De eerste MaatGelaagd die wordt geactiveerd wanneer de tabel een limiet overschrijdt, het voordeel van het gebruik van deze strategie is dat het de schrijfprestaties niet verslechtert, maar het heeft als nadeel dat het af en toe twee keer de grootte van de gegevens op de schijf gebruikt, wat resulteert in slechte prestaties lezing. De tweede strategie is: Niveauverdichting en het werkt in de loop van de tijd op verschillende niveaus, waarbij tabellen worden samengevoegd met langere, wat resulteert in behoorlijk goede leesprestaties.
CompressieDeze eigenschap bepaalt hoe de informatie wordt gecomprimeerd. We kunnen ervoor kiezen om voordelen in snelheid of ruimte te verkrijgen, waarbij hoe hoger de snelheid, hoe minder schijfruimte wordt bespaard.
Gc_grace_secondsDeze eigenschap definieert de wachttijd om de informatie van de grafstenen te verwijderen. Standaard is dit 10 dagen.
Populate_io_cache_on_flushDeze eigenschap is standaard uitgeschakeld en we zouden deze alleen moeten activeren als we hopen dat alle informatie in het cachegeheugen past.
Read_repair_chanceEen zeer interessante eigenschap die een getal tussen 0 en 1,0 aangeeft dat de waarschijnlijkheid aangeeft van het herstellen van de informatie wanneer het quorum niet wordt bereikt. De standaardwaarde is 0,1.
Replicate_on_writeDeze eigenschap is alleen van toepassing op tabellen van het type balie. Wanneer gedefinieerd, schrijven replica's naar alle betrokken replica's, waarbij het opgegeven consistentieniveau wordt genegeerd.
Dus we weten al wat we hebben, zowel op het niveau van gegevenstypen als eigenschappen, het is dan tijd om enkele van de geleerde dingen toe te passen op onze tabellen in Cassandra.
Eerst gaan we een eenvoudige tabel maken waarop we de eigenschap comments zullen toepassen, laten we de syntaxis bekijken die we ervoor zullen gebruiken:

 MAAK TABEL-artikelen (teksttitel, tekstinhoud, tekstcategorie, PRIMAIRE SLEUTEL (titel)) MET commentaar = 'Tabel om artikelinformatie op te slaan';

We openen onze opdrachtconsole CQL en we maken onze tabel met de genoemde eigenschap, laten we eens kijken hoe het eruit ziet:

Zoals we al weten, retourneert de opdrachtconsole niets behalve dat er geen fout is, maar als we deze wijzigingen willen zien, kunnen we naar onze OpsCenter en controleer of alles correct is verlopen:

VERGROTEN

Zoals we kunnen zien, kunnen we onze opmerking en andere eigenschappen zien met hun standaardwaarden. Het is belangrijk om te vermelden dat de definitie van de rest van de eigenschappen in Cassandra het is vrij eenvoudig, zoals we in het vorige voorbeeld konden zien, met behulp van de syntaxis MET we kunnen het zonder enig probleem.
We gaan nog een voorbeeld uitvoeren waarin we de eigenschappen gaan definiëren compressie Y verdichting maar hiervoor is het belangrijk om te weten dat ze een reeks subopties hebben voor hun gebruik, laten we eens kijken voor compressie dat we moeten weten:
Stabiele_compressieDeze optie specificeert het te gebruiken compressie-algoritme, de waarden zijn: LY4Compressor, SnappyCompressor, Y DeflateCompressor.
Chunck_length_kbTabellen worden gecomprimeerd door blokken. Langere waarden zorgen over het algemeen voor een betere compressie, maar vergroten de omvang van de te lezen informatie. Standaard is deze optie ingesteld op 64 kb.
Het manipuleren van compressie-opties kan leiden tot een aanzienlijke prestatieverbetering, waaronder veel implementaties van Cassandra Ze zijn met die standaardwaarden, maar voor perfectie is het noodzakelijk om deze waarden te gebruiken. Laten we nu eens kijken wat we moeten weten om verdichting:
IngeschakeldBepaalt of de eigenschap in de tabel wordt uitgevoerd, hoewel standaard alle eigenschappen: verdichting ingeschakeld.
KlasHier zullen we het type strategie definiëren voor het omgaan met de tabellen.
min_thresholdDeze waarde is beschikbaar bij de strategie MaatGelaagd y staat voor het minimum aantal tabellen dat nodig is om een ​​verdichtingsproces te starten. Het is standaard gedefinieerd op 4.
max_thresholdOp dezelfde manier beschikbaar in de strategie MaatGelaagd y definieert het maximale aantal tabellen dat in de compact wordt verwerkt. Het is standaard gedefinieerd op 32.
Dit zijn enkele van de belangrijkste opties voor deze eigenschappen, wat belangrijk is om te vermelden is dat we voor de definitie van deze opties een syntaxis moeten gebruiken JSON Laten we om geldig te zijn een voorbeeld bekijken van de opname van deze twee eigenschappen:

 CREATE TABLE table_for_properties (int id, tekstnaam, teksteigenschap, variantnummer, PRIMARY KEY (id)) WITHcompression = {'sstable_compression': 'DeflateCompressor', 'chunk_length_kb': 64} ANDcompaction = {'class': 'SizeTieredCompactionStrategy', 'min_drempel': 6};

Zoals we kunnen zien, hebben we het type compressie gewijzigd en hebben we de grootte ervoor gedefinieerd, bovendien voor verdichting we hebben de gebruikelijke strategie verlaten met de waarde klas en we hebben de . gedefinieerd min_threshold zoals 6 verhoogde de standaardwaarde op deze manier, om af te sluiten, laten we eens kijken hoe dit eruit ziet wanneer we het uitvoeren in onze opdrachtconsole:

In de laatste zelfstudie konden we zien dat als gevolg van het definiëren van meer dan één primaire sleutel, deze worden gemaakt als: clustering sleutels en vertel ons de weg Cassandra sorteert de informatie, standaard is de volgorde gedefinieerd in oplopende volgorde en het maken van een zoekopdracht in aflopende volgorde kan prestatieproblemen veroorzaken, maar Cassandra heeft een oplossing voor elk probleem en het is met de zin CLUSTERING ***** DOOR. Laten we eens kijken hoe het te gebruiken.

 MAAK TABEL bestelde_gebruikers (gebruikerstekst, datumtijdstempel, salaris float, afdelingstekst, supervisortekst, PRIMAIRE SLEUTEL (gebruiker, datum)) MET CLUSTERING ***** BY (datum DESC);

Laten we onze syntaxis in de opdrachtconsole uitvoeren en kijken hoe het eruit ziet:

Zoals we konden zien, was het vrij eenvoudig om dit probleem op te lossen met slechts een simpele regel, maar wat nog belangrijker is, we waren in staat om onze kennis uit te breiden als het gaat om het omgaan met tabellen in Cassandra, waarmee we deze tutorial afronden, waar we alles hebben behandeld wat we moeten weten voor een optimale tabelcreatie in Cassandra.