Partitionering i Azure Cosmos DB API för Cassandra
GÄLLER för: 
API för Cassandra
Den här artikeln beskriver hur partitionering fungerar i Azure Cosmos DB API för Cassandra.
API för Cassandra använder partitionering för att skala enskilda tabeller i ett nyckelutrymme för att uppfylla programmets prestandabehov. Partitioner skapas baserat på värdet för en partitionsnyckel som är associerad med varje post i en tabell. Alla poster i en partition har samma partitionsnyckelvärde. Azure Cosmos DB transparent och hanterar automatiskt placeringen av partitioner över de fysiska resurserna för att effektivt uppfylla skalbarhets- och prestandabehoven i tabellen. När dataflödes- och lagringskraven för ett program ökar Azure Cosmos DB flyttar och balanserar data över ett större antal fysiska datorer.
Från utvecklarens perspektiv fungerar partitionering på samma sätt för Azure Cosmos DB API för Cassandra det gör i interna Apache Cassandra. Det finns dock vissa skillnader i bakgrunden.
Skillnader mellan Apache Cassandra och Azure Cosmos DB
I Azure Cosmos DB kallas varje dator som partitioner lagras på själv som en fysisk partition. Den fysiska partitionen liknar en virtuell dator. en dedikerad beräkningsenhet eller en uppsättning fysiska resurser. Varje partition som lagras på den här beräkningsenheten kallas för en logisk partition i Azure Cosmos DB. Om du redan är bekant med Apache Cassandra kan du tänka på logiska partitioner på samma sätt som du tänker på vanliga partitioner i Cassandra.
Apache Cassandra rekommenderar en gräns på 100 MB för storleken på data som kan lagras i en partition. Den API för Cassandra för Azure Cosmos DB tillåter upp till 20 GB per logisk partition och upp till 30 GB data per fysisk partition. I Azure Cosmos DB till skillnad från Apache Cassandra uttrycks beräkningskapaciteten som är tillgänglig i den fysiska partitionen med hjälp av ett enda mått som kallas enheter för programbegäran, vilket gör att du kan tänka på din arbetsbelastning när det gäller begäranden (läsningar eller skrivningar) per sekund, i stället för kärnor, minne eller IOPS. Detta kan göra kapacitetsplaneringen mer direkt när du förstår kostnaden för varje begäran. Varje fysisk partition kan ha upp till 1 0 000 RU:er med beräkning tillgänglig. Du kan lära dig mer om skalbarhetsalternativ genom att läsa vår artikel om elastisk skalning i API för Cassandra.
I Azure Cosmos DB består varje fysisk partition av en uppsättning repliker, även kallade replikuppsättningar, med minst 4 repliker per partition. Detta skiljer sig från Apache Cassandra, där det är möjligt att ange replikeringsfaktorn 1. Detta leder dock till låg tillgänglighet om den enda noden med data går ned. I API för Cassandra finns det alltid replikeringsfaktorn 4 (kvorum 3). Azure Cosmos DB hanterar replikuppsättningar automatiskt, medan dessa måste underhållas med hjälp av olika verktyg i Apache Cassandra.
Apache Cassandra har ett koncept med token, som är hash-värden för partitionsnycklar. Token baseras på en mur token3 64 byte-hash, med värden från -2^63 till -2^63 - 1. Det här intervallet kallas ofta för "token ring" i Apache Cassandra. Tokenringen distribueras i tokenintervall och dessa intervall delas upp mellan noderna som finns i ett inbyggt Apache Cassandra-kluster. Partitionering för Azure Cosmos DB implementeras på ett liknande sätt, förutom att den använder en annan hash-algoritm och har en större intern tokenring. Externt exponerar vi dock samma tokenintervall som Apache Cassandra, dvs. -2^63 till -2^63 - 1.
Primärnyckel
Alla tabeller i API för Cassandra måste ha en primary key definierad. Syntaxen för en primärnyckel visas nedan:
column_name cql_type_definition PRIMARY KEY
Anta att vi vill skapa en användartabell som lagrar meddelanden för olika användare:
CREATE TABLE uprofile.user (
id UUID PRIMARY KEY,
user text,
message text);
I den här designen har vi definierat id fältet som primärnyckel. Primärnyckeln fungerar som identifierare för posten i tabellen och används också som partitionsnyckel i Azure Cosmos DB. Om den primära nyckeln definieras på det tidigare beskrivna sättet finns det bara en post i varje partition. Detta resulterar i en perfekt horisontell och skalbar distribution när du skriver data till databasen och är perfekt för användningsfall för nyckel/värde-sökning. Programmet bör tillhandahålla den primära nyckeln när du läser data från tabellen för att maximera läsprestanda.
Sammansatt primärnyckel
Apache Cassandra har också konceptet compound keys . En sammansatt primary key består av mer än en kolumn. Den första kolumnen är , och eventuella ytterligare kolumner är partition key clustering keys . Syntaxen för compound primary key en visas nedan:
PRIMARY KEY (partition_key_column_name, clustering_column_name [, ...])
Anta att vi vill ändra ovanstående design och göra det möjligt att effektivt hämta meddelanden för en viss användare:
CREATE TABLE uprofile.user (
user text,
id int,
message text,
PRIMARY KEY (user, id));
I den här designen definierar vi user nu som partitionsnyckel id och som klustringsnyckel. Du kan definiera så många klustringsnycklar du vill, men varje värde (eller en kombination av värden) för klusternyckeln måste vara unikt för att flera poster ska läggas till i samma partition, till exempel:
insert into uprofile.user (user, id, message) values ('theo', 1, 'hello');
insert into uprofile.user (user, id, message) values ('theo', 2, 'hello again');
När data returneras sorteras de efter klusternyckeln, som förväntat i Apache Cassandra:
Varning
Om du bara vill filtrera på partitionsnyckelvärdeelementet för en sammansatt primärnyckel (som är fallet ovan) när du frågar efter data ska du uttryckligen lägga till ett sekundärt index på partitionsnyckeln:
CREATE INDEX ON uprofile.user (user);
Azure Cosmos DB API för Cassandra inte tillämpar index på partitionsnycklar som standard, och indexet i det här scenariot kan förbättra frågeprestanda avsevärt. Läs vår artikel om sekundär indexering för mer information.
När data modelleras på det här sättet kan flera poster tilldelas till varje partition, grupperade efter användare. Vi kan därför utfärda en fråga som dirigeras effektivt av (i det här fallet ) för att partition key hämta alla meddelanden för en viss user användare.
Sammansatt partitionsnyckel
Sammansatta partitionsnycklar fungerar i stort sett på samma sätt som sammansatta nycklar, förutom att du kan ange flera kolumner som en sammansatt partitionsnyckel. Syntaxen för sammansatta partitionsnycklar visas nedan:
PRIMARY KEY (
(partition_key_column_name[, ...]),
clustering_column_name [, ...]);
Du kan till exempel ha följande, där den unika kombinationen av och utgör firstname lastname partitionsnyckeln och är id klusternyckeln:
CREATE TABLE uprofile.user (
firstname text,
lastname text,
id int,
message text,
PRIMARY KEY ((firstname, lastname), id) );