Dělení ve službě Azure Cosmos DB for Apache Cassandra

  • Článek

PLATÍ PRO: Cassandra

Tento článek popisuje, jak funguje dělení ve službě Azure Cosmos DB pro Apache Cassandra.

Rozhraní API pro Cassandra používá dělení ke škálování jednotlivých tabulek v prostoru klíčů tak, aby splňovaly požadavky vaší aplikace na výkon. Oddíly se vytvářejí na základě hodnoty klíče oddílu, který je přidružený ke každému záznamu v tabulce. Všechny záznamy v oddílu mají stejnou hodnotu klíče oddílu. Azure Cosmos DB transparentně a automaticky spravuje umístění oddílů mezi fyzickými prostředky, aby efektivně uspokojila požadavky na škálovatelnost a výkon tabulky. Se zvyšujícími požadavky aplikace na propustnost a úložiště azure Cosmos DB přesouvá a vyrovnává data na větším počtu fyzických počítačů.

Z pohledu vývojáře se dělení chová stejně jako v nativní službě Apache Cassandra ve službě Azure Cosmos DB for Apache Cassandra. Na pozadí jsou ale určité rozdíly.

Rozdíly mezi Apache Cassandra a Azure Cosmos DB

Ve službě Azure Cosmos DB se každý počítač, na kterém jsou oddíly uložené, sám označuje jako fyzický oddíl. Fyzický oddíl se podobá virtuálnímu počítači. vyhrazenou výpočetní jednotku nebo sadu fyzických prostředků. Každý oddíl uložený v této výpočetní jednotce se ve službě Azure Cosmos DB označuje jako logický oddíl . Pokud už apache Cassandra znáte, můžete logické oddíly představit stejným způsobem jako běžné oddíly v Cassandře.

Apache Cassandra doporučuje 100 MB omezení velikosti dat, která se dají uložit do oddílu. Rozhraní API pro Cassandra pro Azure Cosmos DB umožňuje až 20 GB na logický oddíl a až 30 GB dat na fyzický oddíl. Na rozdíl od Apache Cassandry se výpočetní kapacita dostupná ve fyzickém oddílu ve službě Azure Cosmos DB vyjadřuje pomocí jedné metriky označované jako jednotky žádostí, která umožňuje uvažovat o úlohách z hlediska požadavků (čtení nebo zápisů) za sekundu místo jader, paměti nebo IOPS. Díky tomu se plánování kapacity zpřísní, jakmile porozumíte nákladům na jednotlivé požadavky. Každý fyzický oddíl může mít k dispozici až 10000 RU výpočetních prostředků. Další informace o možnostech škálovatelnosti najdete v našem článku o elastickém škálování v rozhraní API pro Cassandra.

Ve službě Azure Cosmos DB se každý fyzický oddíl skládá ze sady replik, označovaných také jako sady replik, s minimálně 4 replikami na oddíl. To je na rozdíl od Apache Cassandry, kde je možné nastavit faktor replikace 1. To však vede k nízké dostupnosti, pokud dojde k výpadku jediného uzlu s daty. V rozhraní API pro Cassandra je vždy faktor replikace 4 (kvorum 3). Azure Cosmos DB automaticky spravuje sady replik, které je ale potřeba udržovat pomocí různých nástrojů v Apache Cassandře.

Apache Cassandra má koncept tokenů, což jsou hodnoty hash klíčů oddílů. Tokeny jsou založené na hodnotě hash murmur3 64 bajtů s hodnotami v rozsahu -2^63 až -2^63 -1. Tento rozsah se v Apache Cassandře běžně označuje jako "token ring". Okruh tokenů se distribuuje do rozsahů tokenů a tyto oblasti jsou rozdělené mezi uzly, které jsou přítomné v nativním clusteru Apache Cassandra. Dělení pro Službu Azure Cosmos DB se implementuje podobným způsobem, ale používá jiný hashovací algoritmus a má větší okruh interních tokenů. Externě však zveřejňujeme stejný rozsah tokenů jako Apache Cassandra, tj. -2^63 až -2^63-1.

Primární klíč

Všechny tabulky v rozhraní API pro Cassandra musí mít definovanou primary key . Syntaxe primárního klíče je znázorněna níže:

column_name cql_type_definition PRIMARY KEY

Předpokládejme, že chceme vytvořit tabulku uživatelů, která ukládá zprávy pro různé uživatele:

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

V tomto návrhu jsme definovali id pole jako primární klíč. Primární klíč funguje jako identifikátor záznamu v tabulce a používá se také jako klíč oddílu ve službě Azure Cosmos DB. Pokud je primární klíč definován výše popsaným způsobem, bude v každém oddílu pouze jeden záznam. Výsledkem bude dokonale vodorovná a škálovatelná distribuce při zápisu dat do databáze a je ideální pro případy použití hledání klíč-hodnota. Aplikace by měla poskytnout primární klíč při každém čtení dat z tabulky, aby se maximalizoval výkon čtení.

oddíly

Složený primární klíč

Apache Cassandra má také koncept compound keys. Složená složka primary key se skládá z více než jednoho sloupce; prvním sloupcem partition keyje a všechny další sloupce jsou clustering keys. Syntaxe objektu compound primary key je znázorněna níže:

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

Předpokládejme, že chceme změnit výše uvedený návrh a umožnit efektivní načítání zpráv pro daného uživatele:

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

V tomto návrhu teď definujeme user jako klíč oddílu a id jako klíč clusteringu. Můžete definovat libovolný počet klíčů clusteringu, ale každá hodnota (nebo kombinace hodnot) klíče clusteringu musí být jedinečná, aby se do stejného oddílu přidalo více záznamů, například:

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

Když se data vrátí, seřadí se podle klíče clusteringu podle očekávání v Apache Cassandře:

Snímek obrazovky znázorňující vrácená data seřazená podle klíče clusteringu

Upozornění

Pokud chcete při dotazování na data v tabulce se složeným primárním klíčem filtrovat klíč oddílu a všechna další neindexovaná pole kromě klíče clusteringu, ujistěte se, že jste k klíči oddílu explicitně přidali sekundární index:

CREATE INDEX ON uprofile.user (user);

Azure Cosmos DB for Apache Cassandra ve výchozím nastavení nepoužívá indexy na klíče oddílů a index v tomto scénáři může výrazně zlepšit výkon dotazů. Další informace najdete v našem článku o sekundárním indexování .

S daty modelovanými tímto způsobem lze každému oddílu přiřadit více záznamů seskupených podle uživatele. Můžeme proto vydat dotaz, který je efektivně směrován partition key (v tomto případě user) a získat všechny zprávy pro daného uživatele.

Diagram znázorňující, jak lze přiřadit více záznamů ke každému oddílu seskupené podle uživatele

Složený klíč oddílu

Složené klíče oddílů fungují v podstatě stejně jako složené klíče s tím rozdílem, že jako klíč složeného oddílu můžete zadat více sloupců. Syntaxe složených klíčů oddílů je znázorněná níže:

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

Můžete mít například následující, kde jedinečná kombinace firstname a lastname vytvoří klíč oddílu a id je klíč clusteringu:

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

Další kroky