Bij het opzetten van een Apache Cassandra-tabelschema en anticiperen op hoe u de tabel gaat gebruiken, is het een best practice om tegelijkertijd een doordachte verdichtingsstrategie te formuleren. Terwijl de verdichtingsstrategie van een Cassandra-tafel wel worden aangepast nadat het is gemaakt, leidt dit tot dure boetes voor clusterprestaties, omdat Cassandra alle gegevens van die tabel moet herschrijven. De juiste benadering van verdichtingen – en dit zo vroeg mogelijk doen – is een doorslaggevende factor in efficiënte Cassandra-operaties. 

Het schrijfpad

Als u begrijpt hoe Cassandra gegevens naar schijf schrijft, wordt het belang van efficiënte verdichtingen duidelijk. Laten we eens kijken naar het schrijfpadproces:

1. Cassandra slaat recent op schrijft in het geheugen in de Memtafel.
2. Nadat een bepaald aantal schrijfbewerkingen heeft plaatsgevonden, stuurt Cassandra alle Memtable-gegevens naar schijf. Deze gegevens op schijf worden opgeslagen in Sorted String Tables (SSTables): eenvoudige datastructuren die gesorteerde arrays van strings zijn.
3. Cassandra voegt Memtable-gegevens samen en sorteert ze vooraf op primaire sleutel voordat ze een nieuwe SSTable schrijft. De primaire sleutel bevat een unieke partitiesleutel die verantwoordelijk is voor het bepalen van het knooppunt waar de gegevens zijn opgeslagen, en eventuele gedefinieerde clustersleutels.
4. De SSTable wordt vervolgens in een enkele schrijfbewerking op schijf gezet. Omdat SSTables onveranderlijk zijn en niet worden gewijzigd als ze eenmaal naar schijf zijn geschreven, worden alle gegevensupdates of -verwijderingen naar een nieuwe SSTable geschreven. In scenario's waarin gegevens vaak worden bijgewerkt, moet Cassandra mogelijk uit meerdere SSTables lezen om slechts één rij op te halen.
5. Verdichtingen ruimen deze omgeving op en voegen gegevens samen in nieuwe SSTables om schijfruimte vrij te maken en leesbewerkingen te optimaliseren.

Welke Cassandra-verdichtingsstrategie past bij uw use case?

Cassandra biedt vier verdichtingsstrategieën die geschikt zijn voor verschillende gebruikssituaties:

Grootte trapsgewijze verdichtingsstrategie (STCS)

Met deze standaardstrategie wordt een verdichting uitgevoerd wanneer meerdere SSTables van vergelijkbare grootte zijn. Parameterinstellingen kunnen deze strategie afstemmen om het aantal verdichtingen te regelen en hoe grafstenen worden behandeld. Deze strategie is geschikt voor algemene of zware workloads.

Niveaugerichte verdichtingsstrategie (LCS)

Deze verdichtingsstrategie plaatst SSTables in niveaus. Elk niveau heeft een vaste groottelimiet die 10 keer groter is dan het vorige. Qua grootte zijn SSTables relatief klein, met 160 MB als standaard. Neem een ​​scenario waarbij Level 1 maximaal 10 SSTables bevat: Level 2 zou dan maximaal 100 SSTables hebben. Wanneer niveau 1 vol raakt, worden alle nieuwe SSTables die aan niveau 1 worden toegevoegd, gecomprimeerd met bestaande tabellen die gegevensoverlappingen hebben. Als die verdichtingen ervoor zorgen dat niveau 1 meer tafels heeft dan is toegestaan, gaan de overtollige tafels naar niveau 2, enzovoort. SSTables kunnen dus niet overlappen binnen een level.

Gebruik deze verdichtingsstrategie om leesintensieve workloads te verwerken. Omdat de tabellen van elk niveau elkaar niet overlappen, zorgt deze strategie ervoor dat 90% van de leesbewerkingen kan worden voltooid met slechts één SSTable. Deze strategie is ook een sterke keuze voor workloads met meer updates dan inserts.

Tijdvensterverdichtingsstrategie (TWCS)

Deze strategie is op dezelfde manier ontworpen voor tijdreeksgegevens en dient als een bijgewerkte verbetering ten opzichte van de vorige strategie. Hier worden SSTables binnen een bepaald tijdvenster gecomprimeerd door gebruik te maken van STCS. Aan het einde van die periode worden alle SSTables gecomprimeerd tot één, waardoor er één SSTable overblijft voor het tijdvenster. Het tijdvenster waartoe een SSTable behoort, wordt bepaald door de maximale tijdstempel. Met TTL geconfigureerd, verwijdert deze aanpak gegevens door hele SSTables te verwijderen zodra hun tijd is verstreken. Het comprimeren van SSTables alleen tijdens de ingestelde tijdvensters voorkomt ook schrijfversterking.

Deze aanpak kan het beste worden gebruikt met Tijdreeksgegevens dat is onveranderlijk na een vaste hoeveelheid tijd. 

Datum gelaagde verdichtingsstrategie (DTCS)

Deze strategie (verouderd vanaf versie 3.8) is specifiek ontworpen voor tijdreeksgegevens en slaat gegevens op die in dezelfde tijdsperiode zijn geschreven in dezelfde SSTable. Groepen SSTables die in hetzelfde tijdvenster zijn geschreven, worden ook samen gecomprimeerd. SSTables zijn geconfigureerd om ook een Time to Live (TTL) op te nemen. SSTables die ouder zijn dan de TTL worden eenvoudig weggelaten en dragen niet bij aan verdichtingsoverhead.

Hoewel deze strategie efficiënt en performant is, werkt deze alleen als de werklast aan de strikte vereisten voldoet. Als een werk belasting updates bevat voor oudere gegevens of toevoegingen die niet in orde zijn, is deze strategie niet ontworpen om deze aspecten te verwerken. In die gevallen kan het inschakelen van STCS en een op tijd gebaseerde bucketing-sleutel om gegevens op te splitsen de betere aanpak zijn.

Opmerking: deze strategie is verouderd in Cassandra 3.8 en later en in die versies vervangen door de Time Window Compaction Strategy (TWCS) in deze lijst.

Configuratie Cassandra-verdichtingsstrategie

Nu om deze methoden in de praktijk te brengen. U kunt verdichtingsopties configureren op tafelniveau met behulp van CQLSH, waarbij elke tafel wordt geoptimaliseerd volgens de optimale strategie. Bijvoorbeeld:

STCS wordt standaard gebruikt als er geen verdichtingsstrategie is gespecificeerd. Ga voor meer informatie over de beschikbare opties voor elke strategie naar Cassandra's documentatie over de subeigenschappen van verdichting. Als aanbevolen praktijk is het ook verstandig om een ​​piepend wielbeleid toe te passen: laat de standaardopties op hun plaats tenzij een tabel prestatieproblemen vertoont en pas daarna de nodige wijzigingen aan.