Particionálás az Azure Cosmos DB-ben az Apache Cassandra-hoz

A KÖVETKEZŐKRE VONATKOZIK: Cassandra

Ez a cikk azt ismerteti, hogyan működik a particionálás az Apache Cassandra-hoz készült Azure Cosmos DB-ben.

A Cassandra API particionálással skálázza az egyes táblákat egy kulcstérben az alkalmazás teljesítményigényének megfelelően. A partíciók a tábla egyes rekordjaihoz társított partíciókulcs értéke alapján jönnek létre. A partíció összes rekordja ugyanazzal a partíciókulcs-értékkel rendelkezik. Az Azure Cosmos DB átláthatóan és automatikusan kezeli a partíciók fizikai erőforrások közötti elhelyezését, hogy hatékonyan kielégítse a tábla méretezhetőségét és teljesítményigényét. Az alkalmazások átviteli sebességének és tárolási követelményeinek növekedésével az Azure Cosmos DB áthelyezi és kiegyensúlyozza az adatokat több fizikai gép között.

Fejlesztői szempontból a particionálás ugyanúgy működik az Azure Cosmos DB for Apache Cassandra esetében, mint a natív Apache Cassandra esetében. Vannak azonban különbségek a színfalak mögött.

Az Apache Cassandra és az Azure Cosmos DB közötti különbségek

Az Azure Cosmos DB-ben minden olyan gép, amelyen a partíciók tárolódnak, magát fizikai partíciónak nevezzük. A fizikai partíció hasonló a virtuális géphez; egy dedikált számítási egység vagy fizikai erőforrások készlete. Az ebben a számítási egységben tárolt minden partíciót logikai partíciónak nevezünk az Azure Cosmos DB-ben. Ha már ismeri az Apache Cassandra-t, ugyanúgy gondolhat logikai partíciókra, mint a Cassandra normál partícióira.

Az Apache Cassandra 100 MB-os korlátot javasol a partíciókban tárolható adatok méretére vonatkozóan. Az Azure Cosmos DB-hez készült Cassandra API logikai partíciónként legfeljebb 20 GB, fizikai partíciónként pedig akár 30 GB adatot is lehetővé tesz. Az Azure Cosmos DB-ben az Apache Cassandrával ellentétben a fizikai partíción elérhető számítási kapacitás egyetlen , kérelemegységnek nevezett metrika használatával van kifejezve, amely lehetővé teszi, hogy a számítási feladatokat a magok, a memória vagy az IOPS helyett másodpercenkénti kérések (olvasások vagy írások) alapján gondolja. Ez a kapacitástervezést még egyszerűbbé teheti, ha már tisztában van az egyes kérések költségeinek költségével. Minden fizikai partícióhoz akár 10000 kérelemegység is rendelkezésre áll. A méretezhetőségi lehetőségekről a Cassandra API rugalmas skálázásáról szóló cikkünkben talál további információt.

Az Azure Cosmos DB-ben minden fizikai partíció replikakészletből, más néven replikakészletből áll, partíciónként legalább 4 replikával. Ez ellentétben áll az Apache Cassandrával, ahol 1-et lehet beállítani. Ez azonban alacsony rendelkezésre álláshoz vezet, ha az adatokkal rendelkező egyetlen csomópont leáll. A Cassandra API-ban mindig 4 replikációs tényező van (3 kvórum). Az Azure Cosmos DB automatikusan kezeli a replikakészleteket, ezeket azonban az Apache Cassandra különböző eszközeivel kell karbantartani.

Az Apache Cassandra rendelkezik a tokenek fogalmával, amely a partíciókulcsok kivonata. A jogkivonatok egy murmur3 64 bájtos kivonaton alapulnak, és -2^63 és -2^63 – 1 közötti értékeket tartalmaznak. Ezt a tartományt gyakran nevezik az Apache Cassandra "jogkivonat-gyűrűjének". A tokengyűrű tokentartományokba van osztva, és ezek a tartományok a natív Apache Cassandra-fürtön található csomópontok között vannak elosztva. Az Azure Cosmos DB particionálása hasonló módon történik, kivéve, ha egy másik kivonatoló algoritmust használ, és nagyobb belső tokengyűrűvel rendelkezik. Külsőleg azonban ugyanazt a jogkivonattartományt tesszük közzé, mint az Apache Cassandra, azaz -2^63–-2^63 – 1.

Elsődleges kulcs

A Cassandra API-ban minden táblának definiáltnak primary key kell lennie. Az elsődleges kulcs szintaxisa az alábbiakban látható:

column_name cql_type_definition PRIMARY KEY

Tegyük fel, hogy létre szeretnénk hozni egy felhasználói táblát, amely különböző felhasználók számára tárolja az üzeneteket:

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

Ebben a kialakításban a id mezőt elsődleges kulcsként definiáltuk. Az elsődleges kulcs a tábla rekordjának azonosítójaként működik, és partíciókulcsként is használatos az Azure Cosmos DB-ben. Ha az elsődleges kulcs a korábban leírt módon van definiálva, minden partícióban csak egyetlen rekord lesz. Ez tökéletesen vízszintes és méretezhető eloszlást eredményez, amikor adatokat ír az adatbázisba, és ideális kulcs-érték keresési használati esetekhez. Az alkalmazásnak meg kell adnia az elsődleges kulcsot, amikor adatokat olvas a táblából az olvasási teljesítmény maximalizálása érdekében.

Összetett elsődleges kulcs

Az Apache Cassandra a fogalmát compound keysis tartalmazza. A vegyület primary key egynél több oszlopból áll; az első oszlop a partition key, a további oszlopok pedig a clustering keys. Az a compound primary key szintaxisa az alábbiakban látható:

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

Tegyük fel, hogy módosítani szeretnénk a fenti kialakítást, és lehetővé szeretnénk tenni egy adott felhasználó üzeneteinek hatékony lekérését:

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

Ebben a kialakításban most partíciókulcsként és id fürtözési kulcsként definiáljukuser. Tetszőleges számú fürtözési kulcsot definiálhat, de a fürtözési kulcs minden értékének (vagy értékkombinációjának) egyedinek kell lennie ahhoz, hogy több rekordot is hozzáadhasson ugyanahhoz a partícióhoz, például:

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

Az adatok visszaadásakor a rendszer az Apache Cassandra várt fürtkulccsal rendezi az adatokat:

Figyelmeztetés

Összetett elsődleges kulccsal rendelkező táblában lévő adatok lekérdezésekor, ha a partíciókulcsra és a fürtözési kulcson kívül más nem indexelt mezőkre szeretne szűrni, győződjön meg arról, hogy explicit módon hozzáad egy másodlagos indexet a partíciókulcshoz:

CREATE INDEX ON uprofile.user (user);

Az Apache Cassandra-hoz készült Azure Cosmos DB alapértelmezés szerint nem alkalmaz indexeket a partíciókulcsokra, és ebben a forgatókönyvben az index jelentősen javíthatja a lekérdezési teljesítményt. További információért tekintse át a másodlagos indexelésről szóló cikkünket.

Az ilyen módon modellezett adatokkal több rekord rendelhető hozzá minden partícióhoz, felhasználó szerint csoportosítva. Így olyan lekérdezést adhatunk ki, amelyet hatékonyan irányít a (ebben az esetbenuser) az partition key adott felhasználó összes üzenetének lekéréséhez.

Összetett partíciókulcs

Az összetett partíciókulcsok lényegében ugyanúgy működnek, mint az összetett kulcsok, azzal a kivételrel, hogy több oszlopot is megadhat összetett partíciókulcsként. Az összetett partíciókulcsok szintaxisa az alábbiakban látható:

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

Például a következővel rendelkezhet, ahol a és lastname az egyedi kombinációja firstname alkotná a partíciókulcsot, és id a fürtkulccsal:

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

Következő lépések

• További információ a particionálásról és a horizontális skálázásról az Azure Cosmos DB-ben.
• Ismerje meg a kiosztott átviteli sebességet az Azure Cosmos DB-ben.
• Tudnivalók a globális terjesztésről az Azure Cosmos DB-ben.