Partitioneren in Azure Cosmos DB Cassandra-API

VAN TOEPASSING OP: Cassandra-API

In dit artikel wordt beschreven hoe partitionering werkt in Azure Cosmos DB Cassandra-API.

Cassandra-API 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 aan elke record in een tabel is gekoppeld. Alle records in een partitie hebben dezelfde partitiesleutelwaarde. Azure Cosmos DB en beheert automatisch de plaatsing van partities over de fysieke resources om efficiënt te voldoen aan de schaalbaarheids- en prestatiebehoeften van de tabel. Naarmate de doorvoer- en opslagvereisten van een toepassing toenemen, worden Azure Cosmos DB gegevens verplaatst en verdeeld over een groter aantal fysieke machines.

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

Verschillen tussen Apache Cassandra en Azure Cosmos DB

In Azure Cosmos DB wordt elke computer waarop partities worden opgeslagen zelf aangeduid als een fysieke partitie. De fysieke partitie is vergelijkbaar met een virtuele machine; een toegewezen rekeneenheid of een set fysieke resources. Elke partitie die in 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 zien als gewone 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 Cassandra-API voor Azure Cosmos DB maakt maximaal 20 GB per logische partitie en maximaal 30 GB aan gegevens per fysieke partitie mogelijk. In Azure Cosmos DB, in tegenstelling tot Apache Cassandra, wordt de beschikbare rekencapaciteit in de fysieke partitie uitgedrukt met behulp van één metrisch gegeven, aanvraageenheden genoemd,waarmee u uw workload kunt zien in termen van aanvragen (lees- of schrijftaken) per seconde, in plaats van kernen, geheugen of IOPS. Dit kan ervoor zorgen dat de capaciteitsplanning beter wordt, zodra u de kosten van elke aanvraag begrijpt. Elke fysieke partitie kan maximaal 10000 BESCHIKBARE REKENKRACHT hebben. Meer informatie over schaalbaarheidsopties vindt u in ons artikel over elastisch schalen in Cassandra-API.

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 lage beschikbaarheid als het enige knooppunt met de gegevens uitgaat. In Cassandra-API 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, wat hashes van partitiesleutels zijn. De tokens zijn gebaseerd op een hash van 64 byte met waarden van -2^63 tot -2^63 - 1. Dit bereik wordt vaak de 'tokenring' genoemd in Apache Cassandra. De tokenring wordt gedistribueerd in tokenbereiken en deze reeksen worden verdeeld over de knooppunten die aanwezig zijn in een native Apache Cassandra-cluster. Partitionering voor Azure Cosmos DB wordt op een vergelijkbare manier geïmplementeerd, behalve dat er een ander hash-algoritme wordt gebruikt en een grotere interne tokenring heeft. Extern geven we echter hetzelfde tokenbereik weer als Apache Cassandra, dat wil zeggen -2^63 tot -2^63 - 1.

Primaire sleutel

Alle tabellen in Cassandra-API 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 op slaat:

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

In dit ontwerp hebben we het veld id 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 op de eerder beschreven manier is gedefinieerd, 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 gebruiksgevallen voor het opzoeken van sleutel-waarden. De toepassing moet de primaire sleutel leveren 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 primary key samengestelde kolom bestaat uit meer dan één kolom. De eerste kolom is de en eventuele partition key 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 we nu als de user 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 clusteringsleutel moet uniek zijn om ervoor te kunnen staan dat er meerdere records worden toegevoegd aan dezelfde partitie, 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:

CREATE INDEX ON uprofile.user (user);

Als gegevens 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 (in dit geval ) om alle berichten voor een partition key bepaalde gebruiker op te user 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 en de partitiesleutel firstname lastname vormt en de id clusteringsleutel 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 inrichtende doorvoer in Azure Cosmos DB.
• Meer informatie over wereldwijde distributie in Azure Cosmos DB.