Sdílet prostřednictvím

Jak se přizpůsobit službě Azure Cosmos DB pro Apache Cassandra, pokud pocházíte z Apache Cassandra

  • Článek

PLATÍ PRO: Cassandra

Azure Cosmos DB for Apache Cassandra poskytuje kompatibilitu přenosového protokolu se stávajícími sadami SDK a nástroji Cassandra. Můžete spouštět aplikace navržené pro připojení k Apache Cassandře pomocí rozhraní API pro Cassandra s minimálními změnami.

Když používáte rozhraní API pro Cassandru, je důležité vědět o rozdílech mezi Apache Cassandra a Službou Azure Cosmos DB. Pokud znáte nativní Apache Cassandra, pomůže vám tento článek začít používat Službu Azure Cosmos DB pro Apache Cassandra.

Podpora funkcí

Rozhraní API pro Cassandra podporuje velký počet funkcí Apache Cassandra. Některé funkce nejsou podporované nebo mají omezení. Před migrací se ujistěte, že jsou podporované funkce Azure Cosmos DB for Apache Cassandra, které potřebujete.

Replikace

Při plánování replikace je důležité se podívat na migraci i konzistenci.

I když můžete komunikovat s rozhraním API pro Cassandra prostřednictvím binárního protokolu CQL (Cassandra Query Language) v4, Azure Cosmos DB implementuje svůj vlastní interní replikační protokol. Pro migraci nebo replikaci za provozu nemůžete použít protokol Gossip Cassandra. Další informace najdete v tématu Migrace za provozu z Apache Cassandra do rozhraní API pro Cassandra pomocí duálních zápisů.

Informace o offline migraci najdete v tématu Migrace dat z Cassandra do účtu Azure Cosmos DB for Apache Cassandra pomocí Azure Databricks.

I když jsou přístupy k konzistenci replikace v Apache Cassandře a Azure Cosmos DB podobné, je důležité pochopit, jak se liší. Dokument mapování porovnává přístupy Apache Cassandra a Azure Cosmos DB k konzistenci replikace. Důrazně ale doporučujeme, abyste si konkrétně zkontrolovali nastavení konzistence služby Azure Cosmos DB nebo se podívejte na stručného videokusu, ve které se seznámíte s nastavením konzistence na platformě Azure Cosmos DB.

Pokud používáte rozhraní API pro Cassandru, nemusíte provádět podstatné změny kódu ve stávajících aplikacích, na kterých běží Apache Cassandra. Pro rozhraní API pro Cassandru ve službě Azure Cosmos DB doporučujeme několik přístupů a nastavení konfigurace. Projděte si doporučení k rozhraní API blogového příspěvku pro Cassandra pro Javu.

Ukázky kódu

Rozhraní API pro Cassandra je navržené tak, aby fungovalo s existujícím kódem aplikace. Pokud narazíte na chyby související s připojením, použijte ukázky rychlého startu jako výchozí bod ke zjištění menších změn nastavení, které možná budete muset provést ve stávajícím kódu.

Máme také podrobnější ukázky pro ovladače Java v3 a Java v4 . Tyto ukázky kódu implementují vlastní rozšíření, která následně implementují doporučené konfigurace klientů.

Můžete také použít ukázky pro Javu Spring Boot (ovladač v3) a Java Spring Boot (ovladač v4).

Úložiště

Rozhraní API pro Cassandra je podporováno službou Azure Cosmos DB, což je databázový stroj NoSQL orientovaný na dokument. Azure Cosmos DB udržuje metadata, což může vést ke změně množství fyzického úložiště požadovaného pro konkrétní úlohu.

Rozdíl v požadavcích na úložiště mezi nativní službou Apache Cassandra a Azure Cosmos DB je nejvýraznější v malých velikostech řádků. V některých případech může být rozdíl posunut, protože Azure Cosmos DB neimplementuje komprimace ani náhrobky. Tento faktor závisí výrazně na úloze. Pokud si nejste jistí požadavky na úložiště, doporučujeme nejprve vytvořit testování konceptu.

Nasazení do více oblastí

Nativní Apache Cassandra je ve výchozím nastavení multi-master systém. Apache Cassandra nemá možnost pro jednoúčelovou replikaci s replikací s více oblastmi jen pro čtení. Koncept převzetí služeb při selhání na úrovni aplikace do jiné oblasti pro zápisy je redundantní v Apache Cassandře. Všechny uzly jsou nezávislé a neexistuje žádný kritický bod selhání. Azure Cosmos DB ale nabízí možnost konfigurovat pro zápisy buď jednosměrové, nebo více-hlavní oblasti.

Výhodou použití jedné hlavní oblasti pro zápisy je vyhnout se konfliktům mezi oblastmi. Nabízí možnost udržovat silnou konzistenci napříč více oblastmi a současně udržovat úroveň vysoké dostupnosti.

Poznámka:

Pro nativní Apache Cassandra není možné zajistit silnou konzistenci napříč oblastmi a cílem bodu obnovení (RPO) nuly, protože všechny uzly dokážou obsluhovat zápisy. Azure Cosmos DB můžete nakonfigurovat pro silnou konzistenci napříč oblastmi v konfiguraci jedné oblasti zápisu. Stejně jako u nativní Apache Cassandra ale nemůžete nakonfigurovat účet služby Azure Cosmos DB, který je nakonfigurovaný s více oblastmi zápisu pro silnou konzistenci. Distribuovaný systém nemůže poskytnout cíl bodu obnovení nuly a plánovanou dobu obnovení (RTO) nula.

Další informace najdete v tématu Zásady vyrovnávání zatížení v našem rozhraní API pro doporučení Cassandra pro blog o Javě. Podívejte se také na scénáře převzetí služeb při selhání v naší oficiální ukázce kódu pro ovladač Cassandra Java v4.

Jednotky žádostí

Jedním z hlavních rozdílů mezi spuštěním nativního clusteru Apache Cassandra a zřízením účtu služby Azure Cosmos DB je způsob zřízení kapacity databáze. V tradičních databázích se kapacita vyjadřuje z hlediska jader procesoru, paměti RAM a IOPS. Azure Cosmos DB je databáze s více tenanty jako služba. Kapacita se vyjadřuje pomocí jedné normalizované metriky označované jako jednotky žádostí. Každá žádost odeslaná do databáze má náklady na jednotku žádosti (náklady na RU). Každý požadavek je možné profilovat a určit jeho náklady.

Výhodou použití jednotek žádostí jako metriky je to, že kapacitu databáze je možné zřídit deterministicky pro vysoce předvídatelný výkon a efektivitu. Po profilaci nákladů na jednotlivé žádosti můžete pomocí jednotek žádostí přímo přidružit počet žádostí odeslaných do databáze ke kapacitě, kterou potřebujete zřídit. Problém s tímto způsobem zřizování kapacity spočívá v tom, že potřebujete mít solidní přehled o charakteristikách propustnosti vaší úlohy.

Důrazně doporučujeme profilovat vaše požadavky. Tyto informace vám pomůžou odhadnout počet jednotek žádostí, které budete muset zřídit. Tady je několik článků, které vám můžou pomoct s odhadem:

Modely zřizování kapacity

V tradičním zřizování databází se předem zřídí pevná kapacita, aby zvládla očekávanou propustnost. Azure Cosmos DB nabízí model založený na kapacitě označovaný jako zřízená propustnost. Jako služba s více tenanty nabízí Azure Cosmos DB také modely založené na spotřebě v režimu automatického škálování a bezserverovém režimu. Rozsah, do kterého může úloha těžit z některého z těchto modelů zřizování založených na spotřebě, závisí na předvídatelnosti propustnosti pro úlohu.

Obecně platí, že úlohy stabilního stavu, které mají předvídatelnou propustnost, využívají většinu zřízené propustnosti. Úlohy, které mají velké období nečinnosti, využívají bezserverový režim. Úlohy, které mají nepřetržitou úroveň minimální propustnosti, ale s nepředvídatelnými špičkami, využívají většinu z režimu automatického škálování. Doporučujeme, abyste si prostudovali následující články, abyste jasně pochopili nejlepší model kapacity pro vaše potřeby propustnosti:

dělení na části

Dělení ve službě Azure Cosmos DB se podobá dělení v Apache Cassandře. Jedním z hlavních rozdílů je, že služba Azure Cosmos DB je optimalizovanější pro horizontální škálování. Ve službě Azure Cosmos DB se omezení umisťují na velikost vertikální kapacity propustnosti , která je dostupná v libovolném fyzickém oddílu. Účinek této optimalizace je nejvýraznější, pokud má stávající datový model významnou nerovnoměrnou distribuci propustnosti.

Proveďte kroky, abyste zajistili, že návrh klíče oddílu vede k relativně jednotné distribuci požadavků. Další informace o tom, jak logické a fyzické dělení funguje a omezuje kapacitu propustnosti na oddíl, najdete v tématu Dělení ve službě Azure Cosmos DB pro Apache Cassandra.

Škálování

V nativní Apache Cassandře zahrnuje zvýšení kapacity a škálování přidání nových uzlů do clusteru a zajištění správného přidání uzlů do okruhu Cassandra. Ve službě Azure Cosmos DB je přidávání uzlů transparentní a automatické. Škálování je funkce toho, kolik jednotek žádostí se zřizuje pro váš prostor klíčů nebo tabulku. Škálování ve fyzických počítačích nastane, když fyzické úložiště nebo požadovaná propustnost dosáhne limitů povolených pro logický nebo fyzický oddíl. Další informace najdete v tématu Dělení ve službě Azure Cosmos DB pro Apache Cassandra.

Omezování rychlosti

Problém se zřizováním jednotek žádostí, zejména pokud používáte zřízenou propustnost, je omezování rychlosti. Azure Cosmos DB vrací chyby s omezením rychlosti, pokud klienti spotřebovávají více prostředků, než kolik jste zřídili. Rozhraní API pro Cassandra ve službě Azure Cosmos DB tyto výjimky překládá na přetížené chyby v nativním protokolu Cassandra. Informace o tom, jak se vyhnout omezování rychlosti ve vaší aplikaci, najdete v tématu Prevence chyb omezování rychlosti pro operace Azure Cosmos DB pro Apache Cassandra.

Konektor Apache Spark

Mnoho uživatelů Apache Cassandra používá konektor Apache Spark Cassandra k dotazování dat na potřeby analytického a přesunu dat. K rozhraní API pro Cassandru se můžete připojit stejným způsobem a pomocí stejného konektoru. Než se připojíte k rozhraní API pro Cassandra, přečtěte si téma Připojení ke službě Azure Cosmos DB for Apache Cassandra ze Sparku. Konkrétně si přečtěte část Optimalizace konfigurace propustnosti konektoru Spark.

Řešení běžných potíží

Řešení běžných problémů najdete v tématu Řešení běžných problémů ve službě Azure Cosmos DB pro Apache Cassandra.

Další kroky