Wzorce projektowe zestawienia zmian w usłudze Azure Cosmos DB

DOTYCZY: NoSQL

Źródło zmian usługi Azure Cosmos DB umożliwia wydajne przetwarzanie dużych zestawów danych, które mają dużą liczbę zapisów. Kanał informacyjny zmian oferuje również alternatywę dla wykonywania zapytań dotyczących całego zestawu danych w celu zidentyfikowania zmian. Ten artykuł koncentruje się na typowych wzorcach projektowania zestawienia zmian, kompromisach projektowych i ograniczeniach zestawienia zmian.

Usługa Azure Cosmos DB jest odpowiednia dla aplikacji IoT, gier, handlu detalicznego i rejestrowania operacyjnego. Typowym wzorcem projektowym w tych aplikacjach jest użycie zmian w danych w celu wyzwolenia innych akcji. Przykłady tych akcji to:

• Wyzwalanie powiadomienia lub wywołania interfejsu API po wstawieniu, zaktualizowaniu lub usunięciu elementu.
• Przetwarzanie strumienia w czasie rzeczywistym na potrzeby przetwarzania analiz w czasie rzeczywistym na danych operacyjnych.
• Przenoszenie danych, takie jak synchronizowanie z pamięcią podręczną, aparatem wyszukiwania, magazynem danych lub zimnym magazynem.

Zestawienie zmian w usłudze Azure Cosmos DB umożliwia tworzenie wydajnych i skalowalnych rozwiązań dla każdego z tych wzorców, jak pokazano na poniższej ilustracji:

Przetwarzanie zdarzeń i powiadomienia

Źródło zmian usługi Azure Cosmos DB może uprościć scenariusze, które muszą wyzwolić powiadomienie lub wysłać wywołanie do interfejsu API na podstawie określonego zdarzenia. Procesor zestawienia zmian umożliwia automatyczne sondowanie kontenera pod kątem zmian, a następnie wywoływanie zewnętrznego interfejsu API za każdym razem, gdy istnieje zapis, aktualizacja lub usunięcie.

Możesz również selektywnie wyzwolić powiadomienie lub wysłać wywołanie do interfejsu API na podstawie określonych kryteriów. Jeśli na przykład odczytujesz ze źródła zmian przy użyciu usługi Azure Functions, możesz umieścić logikę w funkcji w celu wysłania powiadomienia tylko wtedy, gdy warunek zostanie spełniony. Mimo że kod funkcji platformy Azure zostanie wykonany dla każdej zmiany, powiadomienie zostanie wysłane tylko wtedy, gdy warunek zostanie spełniony.

Przetwarzanie strumienia w czasie rzeczywistym

Źródło zmian usługi Azure Cosmos DB może służyć do przetwarzania strumienia w czasie rzeczywistym na potrzeby przetwarzania danych operacyjnych IoT lub analizy w czasie rzeczywistym. Można na przykład odbierać i przechowywać dane zdarzeń z urządzeń, czujników, infrastruktury i aplikacji, a następnie przetwarzać te zdarzenia w czasie rzeczywistym przy użyciu platformy Spark. Na poniższej ilustracji przedstawiono sposób implementowania architektury lambda przy użyciu zestawienia zmian usługi Azure Cosmos DB:

W wielu przypadkach implementacje przetwarzania strumieniowego najpierw otrzymują dużą ilość danych przychodzących do tymczasowej kolejki komunikatów, takiej jak Azure Event Hubs lub Apache Kafka. Źródło zmian to świetna alternatywa ze względu na zdolność usługi Azure Cosmos DB do obsługi trwałego wysokiego współczynnika pozyskiwania danych z gwarantowanym małym opóźnieniem odczytu i zapisu. Zalety zestawienia zmian usługi Azure Cosmos DB w kolejce komunikatów obejmują:

Stan trwały danych

Dane zapisywane w usłudze Azure Cosmos DB są wyświetlane w kanale informacyjnym zmian. Dane są zachowywane w kanale informacyjnym zmian, dopóki nie zostaną usunięte w przypadku odczytu przy użyciu trybu najnowszej wersji. Kolejki komunikatów zwykle mają maksymalny okres przechowywania. Na przykład usługa Azure Event Hubs oferuje maksymalny czas przechowywania danych wynoszący 90 dni.

Możliwość wykonywania zapytań

Oprócz odczytywania ze źródła zmian kontenera usługi Azure Cosmos DB można uruchamiać zapytania SQL dotyczące danych przechowywanych w usłudze Azure Cosmos DB. Źródło zmian nie jest duplikacją danych, które są już w kontenerze, ale jest to po prostu inny mechanizm odczytywania danych. W związku z tym, jeśli odczytujesz dane ze źródła zmian, dane są zawsze zgodne z zapytaniami tego samego kontenera usługi Azure Cosmos DB.

Wysoka dostępność

Usługa Azure Cosmos DB oferuje do 99,999% dostępności odczytu i zapisu. W przeciwieństwie do wielu kolejek komunikatów dane usługi Azure Cosmos DB można łatwo dystrybuować globalnie i konfigurować przy użyciu celu czasu odzyskiwania (RTO) zera.

Po przetworzeniu elementów w kanale informacyjnym zmian można utworzyć zmaterializowany widok i utrwalać zagregowane wartości z powrotem w usłudze Azure Cosmos DB. Jeśli używasz usługi Azure Cosmos DB do tworzenia gry, możesz na przykład użyć zestawienia zmian, aby zaimplementować rankingi w czasie rzeczywistym na podstawie wyników z ukończonych gier.

Przenoszenie danych

Możesz również odczytać ze zestawienia zmian na potrzeby przenoszenia danych w czasie rzeczywistym.

Na przykład kanał informacyjny zmian ułatwia wydajne wykonywanie następujących zadań:

• Aktualizowanie pamięci podręcznej, indeksu wyszukiwania lub magazynu danych przy użyciu danych przechowywanych w usłudze Azure Cosmos DB.

• Przeprowadź migracje bez przestojów do innego konta usługi Azure Cosmos DB lub do innego kontenera usługi Azure Cosmos DB, który ma inny klucz partycji logicznej.

• Implementowanie warstw danych na poziomie aplikacji i archiwizowanie. Możesz na przykład przechowywać "gorące dane" w usłudze Azure Cosmos DB i starzeć się z "zimnymi danymi" do innych systemów magazynowania, takich jak Azure Blob Storage.

Jeśli musisz zdenormalizować dane między partycjami i kontenerami, możesz odczytać ze źródła zmian kontenera jako źródła dla tej replikacji danych. Replikacja danych w czasie rzeczywistym ze źródłem zmian może zagwarantować tylko spójność ostateczną. Możesz monitorować , jak daleko procesor zestawienia zmian pozostaje w tyle w przetwarzaniu zmian w kontenerze usługi Azure Cosmos DB.

Określanie źródła zdarzeń

Wzorzec określania źródła zdarzeń obejmuje użycie magazynu tylko do dołączania w celu zarejestrowania pełnej serii akcji na tych danych. Źródło zmian usługi Azure Cosmos DB to doskonały wybór jako centralny magazyn danych w architekturach określania źródła zdarzeń, w których wszystkie pozyskiwanie danych jest modelowane jako zapisy (brak aktualizacji ani usuwania). W takim przypadku każdy zapis w usłudze Azure Cosmos DB jest "zdarzeniem", więc istnieje pełny rekord przeszłych zdarzeń w kanale informacyjnym zmian. Typowe zastosowania zdarzeń publikowanych przez centralny magazyn zdarzeń to utrzymywanie zmaterializowanych widoków lub integrowanie z systemami zewnętrznymi. Ponieważ nie ma limitu czasu przechowywania w trybie najnowszej wersji zestawienia zmian, możesz odtworzyć wszystkie wcześniejsze zdarzenia, odczytując od początku zestawienia zmian kontenera usługi Azure Cosmos DB. Możesz nawet mieć wielu odbiorców zestawienia zmian subskrybowanych do tego samego kanału informacyjnego zmian kontenera.

Usługa Azure Cosmos DB jest doskonałym centralnym magazynem danych trwałym tylko do dołączania we wzorcu określania źródła zdarzeń ze względu na jego mocne strony w zakresie skalowalności poziomej i wysokiej dostępności. Ponadto procesor zestawienia zmian oferuje gwarancję "co najmniej raz" , zapewniając, że nie przegapisz przetwarzania żadnych zdarzeń.

Bieżące ograniczenia

Kanał informacyjny zmian ma wiele trybów, z których każdy ma ważne ograniczenia, które należy zrozumieć. Istnieje kilka obszarów, które należy wziąć pod uwagę podczas projektowania aplikacji, która używa zestawienia zmian w trybie najnowszej wersji lub wszystkich wersji i usuwa tryb.

Aktualizacje pośrednie

Usunięcia

Okres przetrzymywania

Gwarantowana kolejność

Wszystkie tryby zestawienia zmian mają gwarantowaną kolejność w ramach wartości klucza partycji, ale nie między wartościami klucza partycji. Należy wybrać klucz partycji, który daje gwarancję znaczącej kolejności.

Rozważmy na przykład aplikację handlu detalicznego, która używa wzorca projektowania określania źródła zdarzeń. W tej aplikacji różne akcje użytkownika to "zdarzenia", które są modelowane jako zapisy w usłudze Azure Cosmos DB. Wyobraź sobie, że niektóre przykładowe zdarzenia wystąpiły w następującej sekwencji:

1. Klient dodaje element A do koszyka zakupów.
2. Klient dodaje element B do koszyka zakupów.
3. Klient usuwa element A z koszyka.
4. Wyewidencjonowane przez klienta i zawartość koszyka są wysyłane.

Zmaterializowany widok bieżącej zawartości koszyka zakupów jest utrzymywany dla każdego klienta. Ta aplikacja musi upewnić się, że te zdarzenia są przetwarzane w kolejności, w której występują. Jeśli na przykład wyewidencjonowanie koszyka miało zostać przetworzone przed usunięciem elementu A, prawdopodobnie element A zostałby wysłany do klienta, a nie element, którego klient chciał, element B. Aby zagwarantować, że te cztery zdarzenia są przetwarzane w kolejności ich wystąpienia, powinny należeć do tej samej wartości klucza partycji. W przypadku wybrania username opcji (każdy klient ma unikatową nazwę użytkownika) jako klucz partycji, możesz zagwarantować, że te zdarzenia pojawią się w kanale informacyjnym zmian w tej samej kolejności, w jakiej są zapisywane w usłudze Azure Cosmos DB.

Przykłady

Oto kilka rzeczywistych przykładów kodu zestawienia zmian dla najnowszego trybu wersji wykraczających poza zakres podanych przykładów:

• Wprowadzenie do zestawienia zmian
• Przypadek użycia IoT koncentruje się wokół zestawienia zmian
• Przypadek użycia sprzedaży detalicznej koncentruje się wokół zestawienia zmian

Powiązana zawartość

• Omówienie zestawienia zmian
• Tryby zestawienia zmian
• Opcje odczytywania zestawienia zmian