Odczytywanie zestawienia zmian w usłudze Azure Cosmos DB
DOTYCZY: 
NoSQL
Możesz pracować z zestawieniem zmian usługi Azure Cosmos DB przy użyciu modelu wypychania lub modelu ściągania. W przypadku modelu wypychania procesor zestawienia zmian wypycha działanie do klienta, który ma logikę biznesową do przetwarzania tej pracy. Jednak złożoność sprawdzania pracy i przechowywania stanu ostatniej przetworzonej pracy jest obsługiwana w procesorze zestawienia zmian.
W przypadku modelu ściągania klient musi ściągnąć pracę z serwera. W tym przypadku klient ma nie tylko logikę biznesową do przetwarzania pracy, ale także przechowywanie stanu ostatniej przetworzonej pracy, obsługę równoważenia obciążenia w wielu klientach przetwarzania pracy równoległej i obsługę błędów.
Podczas odczytywania ze źródła zmian usługi Azure Cosmos DB zwykle zalecamy użycie modelu wypychania, ponieważ nie trzeba się martwić:
- Sondowanie zestawienia zmian pod kątem przyszłych zmian.
- Przechowywanie stanu ostatniej przetworzonej zmiany. Jeśli odczytujesz z procesora zestawienia zmian, stan jest automatycznie przechowywany w kontenerze dzierżawy.
- Równoważenie obciążenia w wielu klientach korzystających ze zmian. Jeśli na przykład jeden klient nie może nadążyć za zmianami przetwarzania, a inny ma dostępną pojemność.
- Obsługa błędów. Na przykład automatyczne ponawianie próby nieudanych zmian, które nie zostały poprawnie przetworzone po nieobsługiwanym wyjątku w kodzie lub przejściowym problemie z siecią.
Większość scenariuszy korzystających ze zestawienia zmian usługi Azure Cosmos DB będzie używać jednej z opcji modelu wypychania. Istnieją jednak pewne scenariusze, w których można chcieć uzyskać dodatkową kontrolę niskiego poziomu nad modelem ściągania. Są to:
- Odczytywanie zmian z określonego klucza partycji
- Kontrolowanie tempa, w którym klient otrzymuje zmiany do przetwarzania
- Jednorazowe odczytywanie istniejących danych w kanale zmian (na przykład w celu przeprowadzenia migracji danych)
Odczytywanie zestawienia zmian za pomocą modelu wypychania
Użycie modelu wypychania to najprostszy sposób odczytywania ze źródła zmian. Istnieją dwa sposoby odczytywania ze źródła zmian za pomocą modelu wypychania: wyzwalacze usługi Azure Functions w usłudze Azure Cosmos DB i procesor zestawienia zmian. Usługa Azure Functions używa procesora zestawienia zmian w tle, więc są to oba podobne sposoby odczytywania zestawienia zmian. Usługa Azure Functions jest po prostu platformą hostingu dla procesora zestawienia zmian, a nie zupełnie innym sposobem odczytywania zestawienia zmian.
Azure Functions
Usługa Azure Functions jest najprostszą opcją, jeśli dopiero zaczynasz korzystać z zestawienia zmian. Ze względu na prostotę jest to również zalecana opcja dla większości przypadków użycia zestawienia zmian. Podczas tworzenia wyzwalacza usługi Azure Functions dla usługi Azure Cosmos DB wybierasz kontener do nawiązania połączenia, a funkcja platformy Azure jest wyzwalana za każdym razem, gdy nastąpi zmiana kontenera. Ponieważ usługa Azure Functions używa procesora zestawienia zmian w tle, automatycznie przetwarza zmiany w partycjach kontenera.
Programowanie za pomocą usługi Azure Functions jest łatwe i może być szybsze niż wdrażanie procesora zestawienia zmian samodzielnie. Wyzwalacze można tworzyć przy użyciu portalu usługi Azure Functions lub programowo przy użyciu zestawów SDK. Program Visual Studio i program VS Code zapewniają obsługę pisania usługi Azure Functions, a nawet możesz użyć interfejsu wiersza polecenia usługi Azure Functions do programowania międzyplatformowego. Możesz napisać i debugować kod na pulpicie, a następnie wdrożyć funkcję za pomocą jednego przycisku. Aby dowiedzieć się więcej, zobacz Przetwarzanie bezserwerowe bazy danych przy użyciu usługi Azure Functions i Używanie zestawienia zmian w usłudze Azure Functions .
Biblioteka procesora zestawienia zmian
Obsługiwane zestawy SDK
| .Net V3 | Java | Node.JS | Python |
|---|---|---|---|
| ✓ | ✓ | ✕ | ✕ |
Procesor zestawienia zmian zapewnia większą kontrolę nad kanałem informacyjnym zmian i nadal ukrywa największą złożoność. Biblioteka procesora zestawienia zmian jest zgodna ze wzorcem obserwatora, w którym funkcja przetwarzania jest wywoływana przez bibliotekę. Procesor zestawienia zmian automatycznie sprawdzi zmiany i, jeśli zmiany zostaną znalezione, "wypchnij" je do klienta. Jeśli masz źródło zmian o wysokiej przepływności, możesz utworzyć wystąpienie wielu klientów w celu odczytania zestawienia zmian. Procesor zestawienia zmian automatycznie podzieli obciążenie między różnych klientów. Nie trzeba implementować żadnej logiki do równoważenia obciążenia dla wielu klientów ani żadnej logiki w celu zachowania stanu dzierżawy.
Procesor zestawienia zmian gwarantuje "co najmniej jednokrotne" dostarczanie wszystkich zmian. Innymi słowy, jeśli używasz procesora zestawienia zmian, funkcja przetwarzania zostanie pomyślnie wywołana dla każdego elementu w zestawieniach zmian. Jeśli w funkcji przetwarzania występuje nieobsługiwany wyjątek w logice biznesowej, zmiany zakończone niepowodzeniem zostaną ponowione do momentu pomyślnego przetworzenia. Aby zapobiec ciągłemu ponawianiu próby tego samego zmiany przez procesor zestawienia zmian, dodaj logikę w funkcji przetwarzania, aby zapisywać dokumenty, z wyjątkiem, do kolejki utraconych komunikatów. Dowiedz się więcej o obsłudze błędów.
W usłudze Azure Functions zalecenie dotyczące obsługi błędów jest takie samo. Nadal należy dodać logikę w kodzie delegata, aby zapisywać dokumenty, z wyjątkiem, do kolejki utraconych komunikatów. Jeśli jednak w funkcji platformy Azure wystąpi nieobsługiwany wyjątek, zmiana, która wygenerowała wyjątek, nie zostanie automatycznie ponowiona. Jeśli w logice biznesowej wystąpi nieobsługiwany wyjątek, funkcja platformy Azure przejdzie do przetwarzania następnej zmiany. Funkcja platformy Azure nie ponowi próby tej samej zmiany, która nie powiodła się.
Podobnie jak usługa Azure Functions, programowanie za pomocą biblioteki procesora zestawienia zmian jest łatwe. Jednak odpowiadasz za wdrożenie jednego lub większej liczby hostów dla procesora zestawienia zmian. Host to wystąpienie aplikacji korzystające z procesora zestawienia zmian do nasłuchiwania zmian. Chociaż usługa Azure Functions ma możliwości automatycznego skalowania, odpowiadasz za skalowanie hostów. Aby dowiedzieć się więcej, zobacz korzystanie z procesora zestawienia zmian. Biblioteka procesora zestawienia zmian jest częścią zestawu SDK usługi Azure Cosmos DB w wersji 3.
Odczytywanie zestawienia zmian za pomocą modelu ściągania
Model ściągania zestawienia zmian umożliwia korzystanie z zestawienia zmian we własnym tempie. Zmiany muszą być wymagane przez klienta i nie ma automatycznego sondowania zmian. Jeśli chcesz trwale "oznacz zakładkę" ostatnią przetworzoną zmianą (podobną do kontenera dzierżawy modelu wypychania), musisz zapisać token kontynuacji.
Korzystając z modelu ściągania zestawienia zmian, uzyskujesz większą kontrolę niskiego poziomu nad zestawieniem zmian. Podczas odczytywania zestawienia zmian za pomocą modelu ściągania dostępne są trzy opcje:
- Odczytywanie zmian dla całego kontenera
- Odczytywanie zmian dla określonego elementu FeedRange
- Odczytywanie zmian dla określonej wartości klucza partycji
Przetwarzanie zmian w wielu klientach można zrównoleglić, podobnie jak w przypadku procesora zestawienia zmian. Jednak model ściągania nie obsługuje automatycznego równoważenia obciążenia między klientami. Gdy używasz modelu ściągania do równoległego przetwarzania zestawienia zmian, najpierw uzyskasz listę elementów FeedRanges. Element FeedRange obejmuje zakres wartości klucza partycji. Musisz mieć proces orkiestratora, który uzyskuje biblioteki FeedRanges i dystrybuuje je między maszynami. Następnie możesz użyć tych elementów FeedRanges, aby mieć wiele maszyn odczytywanych równolegle zestawienia zmian.
Nie ma wbudowanej gwarancji dostarczania "co najmniej raz" z modelem ściągania. Model ściągania zapewnia kontrolę niskiego poziomu, aby zdecydować, jak chcesz obsługiwać błędy.
Zestawienie zmian w interfejsach API dla baz danych Cassandra i MongoDB
Funkcje zestawienia zmian są udostępniane jako strumienie zmian w interfejsie API dla bazy danych MongoDB i zapytania z predykatem w interfejsie API dla bazy danych Cassandra. Aby dowiedzieć się więcej na temat szczegółów implementacji interfejsu API dla bazy danych MongoDB, zobacz Strumienie zmian w usłudze Azure Cosmos DB dla bazy danych MongoDB.
Natywny system Apache Cassandra zapewnia przechwytywanie zmian danych (CDC), mechanizm flagowania określonych tabel dla archiwizacji i odrzucania zapisów w tych tabelach po osiągnięciu konfigurowalnego rozmiaru na dysku dla dziennika CDC. Funkcja zestawienia zmian w usłudze Azure Cosmos DB dla systemu Apache Cassandra zwiększa możliwość wykonywania zapytań dotyczących zmian za pomocą predykatu za pośrednictwem języka CQL. Aby dowiedzieć się więcej na temat szczegółów implementacji, zobacz Zestawienie zmian w usłudze Azure Cosmos DB dla systemu Apache Cassandra.
Następne kroki
Teraz możesz dowiedzieć się więcej o kanale zmian w następujących artykułach: