Dělení ve službě Azure Cosmos DB rozhraní API Cassandra

  • Článek
  • 4 min ke čtení

PLATÍ PRO: rozhraní API Cassandra

Tento článek popisuje, jak funguje dělení v Azure Cosmos DB rozhraní API Cassandra.

rozhraní API Cassandra používá dělení k škálování jednotlivých tabulek v prostoru klíčů, 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ě vyhověl požadavkům tabulky na škálovatelnost a výkon. S tím, jak se zvyšuje propustnost a požadavky na úložiště aplikace, azure Cosmos DB přesouvá a vyvažuje data napříč větším počtem fyzických počítačů.

Z hlediska vývojářů se dělení chová stejně jako u azure Cosmos DB rozhraní API Cassandra stejně jako v nativní apache cassandře. Na pozadí ale existují 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 uložené oddíly, označuje jako fyzický oddíl. Fyzický oddíl je něco jako virtuální počítač. vyhrazenou výpočetní jednotku nebo sadu fyzických prostředků. Každý oddíl uložený na této výpočetní jednotce se v Azure Cosmos DB označuje jako logický oddíl. Pokud už znáte Apache Cassandra, můžete si logické oddíly promyslet stejným způsobem jako běžné oddíly v Cassandře.

Apache Cassandra doporučuje omezení velikosti dat, která je možné uložit v oddílu, na 100 MB. Úložiště rozhraní API Cassandra Azure Cosmos DB umožňuje až 20 GB na logický oddíl a až 30 GB dat na fyzický oddíl. Ve službě Azure Cosmos DB se výpočetní kapacita dostupná ve fyzickém oddílu na rozdíl od Apache Cassandry vyjadřuje pomocí jedné metriky nazývané jednotky žádostí,která vám umožní zamyslet se nad úlohou z hlediska požadavků (čtení nebo zápisů) za sekundu, nikoli jader, paměti nebo IOPS. Plánování kapacity tak může být přímočarější, jakmile pochopíte náklady na jednotlivé požadavky. Každý fyzický oddíl může mít k dispozici až 1 0000 REZERVOVANÝCH 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 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 nejméně 4 replikami na oddíl. To je na rozdíl od Apache Cassandry, kde je možné nastavit faktor replikace 1. To ale vede k nízké dostupnosti, pokud dojde k vypnutí jediného uzlu s daty. V rozhraní API Cassandra je vždy faktor replikace 4 (kvorum 3). Azure Cosmos DB automaticky spravuje sady replik, zatímco sady replik je potřeba udržovat pomocí různých nástrojů v Apache Cassandře.

Apache Cassandra má koncept tokenů, což jsou hash klíče oddílů. Tokeny jsou založené na 364 byte hash s hodnotami od -2^63 do -2^63 - 1. Tento rozsah se v Apache Cassandře běžně označuje jako "okruh tokenů". Okruh tokenů se distribuuje do rozsahů tokenů a tyto rozsahy jsou rozdělené mezi uzly přítomné v nativním clusteru Apache Cassandra. Dělení pro Azure Cosmos DB se implementuje podobným způsobem s tím rozdílem, že používá jiný hashovací algoritmus a má větší interní okruh tokenů. Externě ale 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 Cassandra musí mít primary key definovanou hodnotu . 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 uživatelskou tabulku, 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 v Azure Cosmos DB. Pokud je primární klíč definovaný 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í vyhledávání klíč-hodnota. Aplikace by měla při čtení dat z tabulky poskytnout primární klíč, aby se maximalizoval výkon čtení.

oddíly

Složený primární klíč

Apache Cassandra má také koncept compound keys . Složená se skládá z více než jednoho sloupce; první sloupec je a všechny primary key partition key další sloupce jsou clustering keys . Syntaxe pro je compound primary key uvedená níže:

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

Předpokládejme, že chceme výše uvedený návrh změnit a zajistit 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 jako klíč oddílu a user id jako klíč clusteringu. Můžete definovat tolik klíčů clusteringu, kolik chcete, ale každá hodnota (nebo kombinace hodnot) pro klíč 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');

Po vrácení se data seřadí 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 při dotazování dat chcete filtrovat pouze prvek hodnoty klíče oddílu složeného primárního klíče (jako v případě výše), ujistěte se, že ke klíči oddílu explicitně přidáte sekundární index:

CREATE INDEX ON uprofile.user (user);

Azure Cosmos DB rozhraní API Cassandra ve výchozím nastavení nepoužije 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í.

Při takto modelovaných datech je možné ke každému oddílu přiřadit více záznamů seskupených podle uživatele. Můžeme proto zadat dotaz, který je efektivně směrován (v tomto případě ) k získání všech zpráv partition key user pro daného uživatele.

Diagram znázorňuje, jak lze ke každému oddílu přiřadit více záznamů seskupených 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 složený klíč oddílu můžete zadat více sloupců. Syntaxe složených klíčů oddílů je uvedená níže:

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

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

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

Další kroky