Sdílet prostřednictvím

Čtení z kanálu změn služby Azure Cosmos DB

  • Článek

PLATÍ PRO: NoSQL

S kanálem změn služby Azure Cosmos DB můžete pracovat buď pomocí modelu nabízených oznámení, nebo modelu vyžádané replikace. S modelem nabízených oznámení procesor kanálu změn nasdílí práci klientovi, který má obchodní logiku pro zpracování této práce. Složitost při kontrole práce a ukládání stavu poslední zpracované práce se ale zpracovává v procesoru kanálu změn.

S modelem vyžádané replikace musí klient vyžádat práci ze serveru. Klient v tomto případě má nejen obchodní logiku pro zpracování práce, ale také ukládání stavu pro poslední zpracovanou práci, zpracování vyrovnávání zatížení napříč více klienty zpracování práce paralelně a zpracování chyb.

Při čtení z kanálu změn azure Cosmos DB obvykle doporučujeme použít model nabízených oznámení, protože se nemusíte starat o:

  • Dotazování kanálu změn na budoucí změny
  • Uložení stavu poslední zpracované změny Pokud čtete z procesoru kanálu změn, stav se automaticky uloží do kontejneru zapůjčení.
  • Vyrovnávání zatížení napříč několika klienty, kteří využívají změny. Pokud například jeden klient nemůže držet krok se zpracováním změn a druhý má dostupnou kapacitu.
  • Zpracování chyb Například automatické opakování neúspěšných změn, které nebyly správně zpracovány po neošetřené výjimce v kódu nebo přechodném problému se sítí.

Většina scénářů, které používají kanál změn služby Azure Cosmos DB, bude používat jednu z možností modelu nabízených oznámení. Existují však některé scénáře, ve kterých můžete chtít další kontrolu nad modelem vyžádání obsahu na nízké úrovni. Tady jsou některé z nich:

  • Čtení změn z konkrétního klíče oddílu
  • Řízení tempa, jakým klient přijímá změny ke zpracování
  • Jednorázové čtení existujících dat v kanálu změn (například migrace dat)

Čtení kanálu změn pomocí modelu nabízených oznámení

Použití modelu nabízených oznámení je nejjednodušší způsob, jak číst z kanálu změn. Kanál změn můžete číst dvěma způsoby pomocí modelu nabízených oznámení: triggery Azure Functions Azure Cosmos DB a procesor kanálu změn. Azure Functions používá procesor kanálu změn na pozadí, takže se podobají oběma způsobům čtení kanálu změn. Azure Functions si můžete představit jako jednoduše hostitelská platforma pro procesor kanálu změn, nikoli úplně jiný způsob čtení kanálu změn.

Azure Functions

Azure Functions je nejjednodušší možnost, pokud teprve začínáte používat kanál změn. Vzhledem k jeho jednoduchosti je to také doporučená možnost pro většinu případů použití kanálu změn. Když vytvoříte trigger Azure Functions pro službu Azure Cosmos DB, vyberete kontejner, ke kterému se chcete připojit, a funkce Azure Functions se aktivuje při každé změně kontejneru. Vzhledem k tomu, že Azure Functions používá procesor kanálu změn na pozadí, automaticky paralelizuje zpracování změn napříč oddíly kontejneru.

Vývoj pomocí Azure Functions je snadný a může být rychlejší než nasazení procesoru kanálu změn sami. Triggery je možné vytvořit pomocí portálu Azure Functions nebo programově pomocí sad SDK. Visual Studio a VS Code poskytují podporu pro psaní azure Functions a můžete dokonce použít Azure Functions CLI pro vývoj pro různé platformy. Kód můžete na počítači napsat a ladit a pak funkci nasadit jedním tlačítkem. Další informace najdete v článcích o bezserverové databázi s využitím Azure Functions a používání kanálu změn.

Knihovna procesoru kanálu změn

Podporované sady SDK

.Net V3 Java Node.JS Python
✓ ✓ ✕ ✕

Procesor kanálu změn vám dává větší kontrolu nad kanálem změn a stále skrývá většinu složitosti. Knihovna procesoru kanálu změn se řídí vzorem pozorovatele, kde knihovna volá vaši funkci zpracování. Procesor kanálu změn automaticky zkontroluje změny a pokud se změny najdou, nasdílí je klientovi. Pokud máte kanál změn s vysokou propustností, můžete vytvořit instanci více klientů pro čtení kanálu změn. Procesor kanálu změn automaticky rozdělí zatížení mezi různé klienty. Abyste zachovali stav zapůjčení, nebudete muset implementovat žádnou logiku pro vyrovnávání zatížení napříč více klienty ani žádnou logikou.

Procesor kanálu změn zaručuje "alespoň jednou" doručení všech změn. Jinými slovy, pokud použijete procesor kanálu změn, bude funkce zpracování volána úspěšně pro každou položku v kanálu změn. Pokud ve vaší funkci zpracování dojde k neošetřené výjimce, budou neúspěšné změny opakovat, dokud nebudou úspěšně zpracovány. Pokud chcete zabránit tomu, aby procesor kanálu změn neustále zasekál stejné změny, přidejte do fronty nedoručených zpráv logiku ve funkci zpracování pro zápis dokumentů, na výjimku. Přečtěte si další informace o zpracování chyb.

Ve službě Azure Functions je doporučení pro zpracování chyb stejné. Do fronty nedoručených zpráv byste stále měli do kódu delegáta přidat logiku pro zápis dokumentů. Pokud ale ve funkci Azure Functions dojde k neošetřené výjimce, změna, která vygenerovala výjimku, se automaticky nezopakuje. Pokud je v obchodní logice neošetřená výjimka, funkce Azure Functions přejde ke zpracování další změny. Funkce Azure Functions nebude opakovat stejnou neúspěšnou změnu.

Stejně jako Azure Functions je vývoj s využitím knihovny procesorů kanálu změn snadný. Zodpovídáte však za nasazení jednoho nebo více hostitelů pro procesor kanálu změn. Hostitel je instance aplikace, která pomocí procesoru kanálu změn naslouchá změnám. Azure Functions má sice možnosti automatického škálování, ale zodpovídáte za škálování hostitelů. Další informace najdete v procesoru kanálu změn. Knihovna procesoru kanálu změn je součástí sady SDK služby Azure Cosmos DB verze 3.

Čtení kanálu změn pomocí modelu vyžádané replikace

Model vyžádání kanálu změn umožňuje využívat kanál změn vlastním tempem. Klient musí požadovat změny a žádné automatické dotazování na změny. Pokud chcete trvale "záložku" poslední zpracované změny (podobně jako kontejner zapůjčení modelu push), budete muset uložit token pokračování.

Pomocí modelu vyžádání kanálu změn získáte větší kontrolu nad kanálem změn na nízké úrovni. Při čtení kanálu změn s modelem vyžádání změn máte tři možnosti:

  • Čtení změn pro celý kontejner
  • Čtení změn pro konkrétní feedRange
  • Čtení změn pro konkrétní hodnotu klíče oddílu

Zpracování změn ve více klientech můžete paralelizovat stejně jako u procesoru kanálu změn. Model vyžádané replikace ale automaticky nezpracuje vyrovnávání zatížení mezi klienty. Když použijete model vyžádání změn k paralelizaci zpracování kanálu změn, nejprve získáte seznam FeedRanges. FeedRange zahrnuje rozsah hodnot klíče oddílu. Budete muset mít proces orchestrátoru, který získá FeedRanges a distribuuje je mezi vaše počítače. Pomocí těchto kanálů FeedRanges pak můžete mít více počítačů, které čtou kanál změn paralelně.

U modelu vyžádané replikace neexistuje žádná integrovaná záruka doručení "alespoň jednou". Model vyžádání obsahu vám dává řízení nízké úrovně, abyste se mohli rozhodnout, jak chcete zpracovávat chyby.

Kanál změn v rozhraních API pro Cassandra a MongoDB

Funkce kanálu změn se zobrazí jako streamy změn v rozhraní API pro MongoDB a dotazování s predikátem v rozhraní API for Cassandra. Další informace o podrobnostech implementace rozhraní API pro MongoDB najdete v datových proudech změn ve službě Azure Cosmos DB pro MongoDB.

Nativní Apache Cassandra poskytuje zachytávání dat změn (CDC), mechanismus označení konkrétních tabulek pro archivaci a odmítnutí zápisů do těchto tabulek po dosažení konfigurovatelné velikosti na disku pro protokol CDC. Funkce kanálu změn ve službě Azure Cosmos DB pro Apache Cassandra vylepšuje schopnost dotazovat se na změny pomocí predikátu prostřednictvím jazyka CQL. Další informace o podrobnostech implementace najdete v kanálu změn ve službě Azure Cosmos DB pro Apache Cassandra.

Další kroky

Další informace o kanálu změn teď najdete v následujících článcích: