Partitioneren in Azure Cosmos DB voor Apache Cassandra

VAN TOEPASSING OP: Cassandra

In dit artikel wordt beschreven hoe partitionering werkt in Azure Cosmos DB voor Apache Cassandra.

API voor Cassandra maakt gebruik van partitionering om de afzonderlijke tabellen in een keyspace te schalen om te voldoen aan de prestatiebehoeften van uw toepassing. Partities worden gevormd op basis van de waarde van een partitiesleutel die is gekoppeld aan elke record in een tabel. Alle records in een partitie hebben dezelfde partitiesleutelwaarde. Azure Cosmos DB beheert de plaatsing van partities in de fysieke resources transparant en automatisch om efficiënt te voldoen aan de schaalbaarheids- en prestatiebehoeften van de tabel. Naarmate de doorvoer- en opslagvereisten van een toepassing toenemen, verplaatst en balanceert Azure Cosmos DB de gegevens over een groter aantal fysieke machines.

Vanuit het perspectief van ontwikkelaars gedraagt partitioneren zich op dezelfde manier voor Azure Cosmos DB voor Apache Cassandra als in systeemeigen Apache Cassandra. Er zijn echter enkele verschillen achter de schermen.

Verschillen tussen Apache Cassandra en Azure Cosmos DB

In Azure Cosmos DB wordt elke machine waarop partities zijn opgeslagen zelf een fysieke partitie genoemd. De fysieke partitie is vergelijkbaar met een virtuele machine; een toegewezen rekeneenheid of een set fysieke resources. Elke partitie die op deze rekeneenheid is opgeslagen, wordt een logische partitie genoemd in Azure Cosmos DB. Als u al bekend bent met Apache Cassandra, kunt u logische partities op dezelfde manier beschouwen als normale partities in Cassandra.

Apache Cassandra raadt een limiet van 100 MB aan voor de grootte van gegevens die kunnen worden opgeslagen in een partitie. De API voor Cassandra voor Azure Cosmos DB staat maximaal 20 GB per logische partitie en maximaal 30 GB aan gegevens per fysieke partitie toe. In Azure Cosmos DB wordt, in tegenstelling tot Apache Cassandra, de rekencapaciteit die beschikbaar is in de fysieke partitie, uitgedrukt met behulp van één metrische waarde die aanvraageenheden wordt genoemd, zodat u uw workload kunt zien in termen van aanvragen (lees- of schrijfbewerkingen) per seconde, in plaats van kerngeheugens, geheugen of IOPS. Dit kan de capaciteitsplanning eenvoudiger maken, zodra u de kosten van elke aanvraag begrijpt. Elke fysieke partitie kan maximaal 10000 RU's aan rekenkracht hebben. Meer informatie over schaalbaarheidsopties vindt u in ons artikel over elastisch schalen in API voor Cassandra.

In Azure Cosmos DB bestaat elke fysieke partitie uit een set replica's, ook wel replicasets genoemd, met ten minste 4 replica's per partitie. Dit is in tegenstelling tot Apache Cassandra, waar het instellen van een replicatiefactor van 1 mogelijk is. Dit leidt echter tot een lage beschikbaarheid als het enige knooppunt met de gegevens uitvalt. In API voor Cassandra is er altijd een replicatiefactor van 4 (quorum van 3). Azure Cosmos DB beheert automatisch replicasets, terwijl deze moeten worden onderhouden met behulp van verschillende hulpprogramma's in Apache Cassandra.

Apache Cassandra heeft een concept van tokens. Dit zijn hashes van partitiesleutels. De tokens zijn gebaseerd op een murmur3 64 bytes hash, met waarden variërend van -2^63 tot -2^63 - 1. Dit bereik wordt meestal de 'tokenring' genoemd in Apache Cassandra. De tokenring wordt gedistribueerd in tokenbereiken en deze bereiken zijn verdeeld over de knooppunten die aanwezig zijn in een systeemeigen Apache Cassandra-cluster. Partitionering voor Azure Cosmos DB wordt op een vergelijkbare manier geïmplementeerd, behalve dat een ander hash-algoritme wordt gebruikt en een grotere interne tokenring heeft. Extern maken we echter hetzelfde tokenbereik beschikbaar als Apache Cassandra, dat wil zeggen -2^63 tot -2^63 - 1.

Primaire sleutel

Alle tabellen in DE API voor Cassandra moeten een primary key hebben gedefinieerd. De syntaxis voor een primaire sleutel wordt hieronder weergegeven:

column_name cql_type_definition PRIMARY KEY

Stel dat we een gebruikerstabel willen maken waarin berichten voor verschillende gebruikers worden opgeslagen:

CREATE TABLE uprofile.user ( 
   id UUID PRIMARY KEY, 
   user text,  
   message text);

In dit ontwerp hebben we het id veld gedefinieerd als de primaire sleutel. De primaire sleutel fungeert als de id voor de record in de tabel en wordt ook gebruikt als de partitiesleutel in Azure Cosmos DB. Als de primaire sleutel is gedefinieerd op de eerder beschreven manier, is er slechts één record in elke partitie. Dit resulteert in een perfect horizontale en schaalbare distributie bij het schrijven van gegevens naar de database en is ideaal voor use cases voor sleutel-waardezoekacties. De toepassing moet de primaire sleutel opgeven bij het lezen van gegevens uit de tabel om de leesprestaties te maximaliseren.

Samengestelde primaire sleutel

Apache Cassandra heeft ook een concept van compound keys. Een samengestelde primary key bestaat uit meer dan één kolom; de eerste kolom is de partition keyen eventuele extra kolommen zijn de clustering keys. De syntaxis voor een compound primary key wordt hieronder weergegeven:

PRIMARY KEY (partition_key_column_name, clustering_column_name [, ...])

Stel dat we het bovenstaande ontwerp willen wijzigen en het mogelijk willen maken om berichten voor een bepaalde gebruiker efficiënt op te halen:

CREATE TABLE uprofile.user (
   user text,  
   id int, 
   message text, 
   PRIMARY KEY (user, id));

In dit ontwerp definiëren user we nu als de partitiesleutel en id als de clustersleutel. U kunt zoveel clustersleutels definiëren als u wilt, maar elke waarde (of een combinatie van waarden) voor de clustersleutel moet uniek zijn om ervoor te zorgen dat meerdere records aan dezelfde partitie worden toegevoegd, bijvoorbeeld:

insert into uprofile.user (user, id, message) values ('theo', 1, 'hello');
insert into uprofile.user (user, id, message) values ('theo', 2, 'hello again');

Wanneer gegevens worden geretourneerd, worden deze gesorteerd op de clustersleutel, zoals verwacht in Apache Cassandra:

Waarschuwing

Wanneer u gegevens opvraagt in een tabel met een samengestelde primaire sleutel, moet u ervoor zorgen dat u expliciet een secundaire index toevoegt aan de partitiesleutelen andere niet-geïndexeerde velden die niet zijn geïndexeerd:

CREATE INDEX ON uprofile.user (user);

Azure Cosmos DB voor Apache Cassandra past standaard geen indexen toe op partitiesleutels en de index in dit scenario kan de queryprestaties aanzienlijk verbeteren. Lees ons artikel over secundaire indexering voor meer informatie.

Met gegevens die op deze manier zijn gemodelleerd, kunnen meerdere records worden toegewezen aan elke partitie, gegroepeerd op gebruiker. We kunnen dus een query uitgeven die efficiënt wordt gerouteerd door de partition key (in dit geval user) om alle berichten voor een bepaalde gebruiker op te halen.

Samengestelde partitiesleutel

Samengestelde partitiesleutels werken in wezen op dezelfde manier als samengestelde sleutels, behalve dat u meerdere kolommen kunt opgeven als een samengestelde partitiesleutel. De syntaxis van samengestelde partitiesleutels wordt hieronder weergegeven:

PRIMARY KEY (
   (partition_key_column_name[, ...]), 
    clustering_column_name [, ...]);

U kunt bijvoorbeeld het volgende hebben, waarbij de unieke combinatie van firstname en lastname de partitiesleutel zou vormen, en id de clustersleutel is:

CREATE TABLE uprofile.user ( 
   firstname text, 
   lastname text,
   id int,  
   message text, 
   PRIMARY KEY ((firstname, lastname), id) );

Volgende stappen

• Meer informatie over partitioneren en horizontaal schalen in Azure Cosmos DB.
• Meer informatie over ingerichte doorvoer in Azure Cosmos DB.
• Meer informatie over wereldwijde distributie in Azure Cosmos DB.