Share via

Jak dostosować się do usługi Azure Cosmos DB dla bazy danych Apache Cassandra, jeśli pochodzisz z usługi Apache Cassandra

  • Artykuł

DOTYCZY: Cassandra

Usługa Azure Cosmos DB for Apache Cassandra zapewnia zgodność protokołu przewodowego z istniejącymi zestawami SDK i narzędziami Cassandra. Aplikacje przeznaczone do nawiązywania połączenia z usługą Apache Cassandra można uruchamiać przy użyciu interfejsu API dla rozwiązania Cassandra z minimalnymi zmianami.

W przypadku korzystania z interfejsu API dla rozwiązania Cassandra należy pamiętać o różnicach między usługą Apache Cassandra i usługą Azure Cosmos DB. Jeśli znasz natywną bazę danych Apache Cassandra, ten artykuł może pomóc w rozpoczęciu korzystania z usługi Azure Cosmos DB dla usługi Apache Cassandra.

Obsługa funkcji

Interfejs API dla rozwiązania Cassandra obsługuje dużą liczbę funkcji apache Cassandra. Niektóre funkcje nie są obsługiwane lub mają ograniczenia. Przed przeprowadzeniem migracji upewnij się, że potrzebne funkcje usługi Azure Cosmos DB dla systemu Apache Cassandra są obsługiwane.

Replikacja

Podczas planowania replikacji ważne jest, aby przyjrzeć się zarówno migracji, jak i spójności.

Mimo że można komunikować się z interfejsem API dla rozwiązania Cassandra za pośrednictwem protokołu binarnego Cassandra Query Language (CQL) w wersji 4, usługa Azure Cosmos DB implementuje własny wewnętrzny protokół replikacji. Nie można użyć protokołu plotek Cassandra do migracji na żywo ani replikacji. Aby uzyskać więcej informacji, zobacz Live-migrate from Apache Cassandra to the API for Cassandra by using dual writes (Migrowanie na żywo z systemu Apache Cassandra do interfejsu API dla systemu Cassandra przy użyciu podwójnych zapisów).

Aby uzyskać informacje na temat migracji w trybie offline, zobacz Migrowanie danych z rozwiązania Cassandra do konta usługi Azure Cosmos DB for Apache Cassandra przy użyciu usługi Azure Databricks.

Chociaż podejścia do spójności replikacji w usługach Apache Cassandra i Azure Cosmos DB są podobne, ważne jest, aby zrozumieć, jak różnią się. Dokument mapowania porównuje podejścia Apache Cassandra i Azure Cosmos DB do spójności replikacji. Zdecydowanie zalecamy jednak zapoznanie się z ustawieniami spójności usługi Azure Cosmos DB lub zapoznanie się z krótkim przewodnikiem wideo w celu zrozumienia ustawień spójności na platformie Azure Cosmos DB.

W przypadku korzystania z interfejsu API dla rozwiązania Cassandra nie trzeba wprowadzać znaczących zmian w kodzie istniejących aplikacji z systemem Apache Cassandra. Zalecamy kilka podejść i ustawień konfiguracji interfejsu API dla rozwiązania Cassandra w usłudze Azure Cosmos DB. Zapoznaj się z wpisem w blogu api for Cassandra recommendations for Java (Interfejs API w blogu dla zaleceń rozwiązania Cassandra dla języka Java).

Przykłady kodu

Interfejs API dla rozwiązania Cassandra jest przeznaczony do pracy z istniejącym kodem aplikacji. Jeśli wystąpią błędy związane z łącznością, użyj przykładów szybkiego startu jako punktu wyjścia, aby odnaleźć drobne zmiany konfiguracji, być może trzeba będzie wprowadzić istniejący kod.

Mamy również bardziej szczegółowe przykłady sterowników Java w wersji 3 i Java w wersji 4 . Te przykłady kodu implementują niestandardowe rozszerzenia, które z kolei implementują zalecane konfiguracje klienta.

Możesz również użyć przykładów dla sterownika Java Spring Boot (sterownik v3) i Java Spring Boot (sterownik v4).

Storage

Interfejs API dla bazy danych Cassandra jest wspierany przez usługę Azure Cosmos DB, która jest aparatem bazy danych NoSQL zorientowanym na dokumenty. Usługa Azure Cosmos DB utrzymuje metadane, co może spowodować zmianę ilości magazynu fizycznego wymaganego dla określonego obciążenia.

Różnica w wymaganiach dotyczących magazynu między natywnym rozwiązaniem Apache Cassandra i usługą Azure Cosmos DB jest najbardziej zauważalna w małych rozmiarach wierszy. W niektórych przypadkach różnica może być przesunięta, ponieważ usługa Azure Cosmos DB nie implementuje kompaktowania ani nagrobków. Ten czynnik zależy znacząco od obciążenia. Jeśli nie masz pewności co do wymagań dotyczących magazynu, zalecamy najpierw utworzenie weryfikacji koncepcji.

Wdrożenia w wielu regionach

Natywny system Apache Cassandra jest domyślnie wielowzorcowym systemem. Usługa Apache Cassandra nie ma opcji pojedynczego wzorca z replikacją z wieloma regionami tylko do odczytu. Koncepcja przejścia w tryb failover na poziomie aplikacji do innego regionu zapisu jest nadmiarowa w usłudze Apache Cassandra. Wszystkie węzły są niezależne i nie ma jednego punktu awarii. Jednak usługa Azure Cosmos DB zapewnia możliwość konfigurowania pojedynczych lub wielowzorcowych regionów na potrzeby zapisu.

Zaletą jednego regionu głównego na potrzeby zapisu jest unikanie scenariuszy konfliktów między regionami. Zapewnia ona możliwość utrzymania silnej spójności w wielu regionach przy zachowaniu poziomu wysokiej dostępności.

Uwaga

Silna spójność między regionami i cel punktu odzyskiwania (RPO) zero nie jest możliwa dla natywnego systemu Apache Cassandra, ponieważ wszystkie węzły mogą obsługiwać zapisy. Usługę Azure Cosmos DB można skonfigurować pod kątem silnej spójności między regionami w jednej konfiguracji regionu zapisu . Jednak podobnie jak w przypadku natywnego serwera Apache Cassandra, nie można skonfigurować konta usługi Azure Cosmos DB skonfigurowanego z wieloma regionami zapisu w celu zapewnienia silnej spójności. Rozproszony system nie może zapewnić celu punktu odzyskiwania zera i celu czasu odzyskiwania (RTO) zera.

Aby uzyskać więcej informacji, zobacz Artykuł Load balancing policy in our API for Cassandra recommendations for Cassandra for Java blog (Zasady równoważenia obciążenia w naszym interfejsie API dla zaleceń cassandra dla języka Java). Zobacz również scenariusze trybu failover w naszym oficjalnym przykładzie kodu dla sterownika Java v4 Cassandra.

Jednostki żądania

Jedną z głównych różnic między uruchomieniem natywnego klastra Apache Cassandra i aprowizowaniem konta usługi Azure Cosmos DB jest sposób aprowizowania pojemności bazy danych. W tradycyjnych bazach danych pojemność jest wyrażona pod względem rdzeni procesora CPU, pamięci RAM i liczby operacji we/wy na sekundę. Usługa Azure Cosmos DB to wielodostępna baza danych typu "platforma jako usługa". Pojemność jest wyrażona przy użyciu pojedynczej znormalizowanej metryki nazywanej jednostkami żądania. Każde żądanie wysłane do bazy danych ma koszt jednostkowy żądania (koszt ru). Każde żądanie można profilować, aby określić jego koszt.

Zaletą korzystania z jednostek żądań jako metryki jest to, że pojemność bazy danych może być aprowizowana determinicznie w celu zapewnienia wysoce przewidywalnej wydajności i wydajności. Po profilowaniu kosztów każdego żądania można użyć jednostek żądań, aby bezpośrednio skojarzyć liczbę żądań wysyłanych do bazy danych z pojemnością, którą należy aprowizować. To wyzwanie związane z aprowizowaniem pojemności polega na tym, że musisz mieć solidną wiedzę na temat charakterystyk przepływności obciążenia.

Zdecydowanie zalecamy profilowanie żądań. Użyj tych informacji, aby ułatwić oszacowanie liczby jednostek żądania, które należy aprowizować. Poniżej przedstawiono kilka artykułów, które mogą pomóc w oszacowaniu:

Modele aprowizacji pojemności

W tradycyjnej aprowizacji bazy danych z góry jest aprowizowana stała pojemność w celu obsługi oczekiwanej przepływności. Usługa Azure Cosmos DB oferuje model oparty na pojemności nazywany aprowizowaną przepływnością. Jako usługa wielodostępna usługa Azure Cosmos DB oferuje również modele oparte na użyciu w trybie automatycznego skalowania i trybie bezserwerowym . Zakres, w jakim obciążenie może korzystać z jednego z tych modeli aprowizacji opartych na użyciu, zależy od przewidywalności przepływności dla obciążenia.

Ogólnie rzecz biorąc, obciążenia o stałym stanie, które mają przewidywalną przepływność, korzystają najbardziej z aprowizowanej przepływności. Obciążenia, które mają duże okresy uśpienia, korzystają z trybu bezserwerowego. Obciążenia, które mają ciągły poziom minimalnej przepływności, ale z nieprzewidywalnymi skokami korzystają z trybu automatycznego skalowania. Zalecamy zapoznanie się z następującymi artykułami w celu jasnego zrozumienia najlepszego modelu pojemności dla potrzeb twojej przepływności:

Partycjonowanie

Partycjonowanie w usłudze Azure Cosmos DB jest podobne do partycjonowania w usłudze Apache Cassandra. Jedną z głównych różnic jest to, że usługa Azure Cosmos DB jest bardziej zoptymalizowana pod kątem skali poziomej. W usłudze Azure Cosmos DB limity są nakładane na ilość pojemności przepływności pionowej dostępnej w dowolnej partycji fizycznej. Efekt tej optymalizacji jest najbardziej zauważalny, gdy istniejący model danych ma znaczną niesymetryczność przepływności.

Wykonaj kroki, aby upewnić się, że projekt klucza partycji powoduje stosunkowo jednolitą dystrybucję żądań. Aby uzyskać więcej informacji na temat działania partycjonowania logicznego i fizycznego oraz limitów pojemności przepływności na partycję, zobacz Partycjonowanie w usłudze Azure Cosmos DB dla systemu Apache Cassandra.

Skalowanie

W natywnej usłudze Apache Cassandra zwiększenie pojemności i skalowania obejmuje dodanie nowych węzłów do klastra i upewnienie się, że węzły są prawidłowo dodawane do pierścienia Cassandra. W usłudze Azure Cosmos DB dodawanie węzłów jest przezroczyste i automatyczne. Skalowanie to funkcja liczby jednostek żądań aprowizowanych dla przestrzeni kluczy lub tabeli. Skalowanie na maszynach fizycznych występuje, gdy magazyn fizyczny lub wymagana przepływność osiągnie limity dozwolone dla partycji logicznej lub fizycznej. Aby uzyskać więcej informacji, zobacz Partycjonowanie w usłudze Azure Cosmos DB for Apache Cassandra.

Rate limiting (Ograniczanie szybkości)

Wyzwaniem dla aprowizacji jednostek żądań, szczególnie w przypadku korzystania z aprowizowanej przepływności, jest ograniczenie szybkości. Usługa Azure Cosmos DB zwraca błędy ograniczone do szybkości, jeśli klienci zużywają więcej zasobów niż aprowizowana kwota. Interfejs API dla bazy danych Cassandra w usłudze Azure Cosmos DB tłumaczy te wyjątki na przeciążone błędy na natywnym protokole Cassandra. Aby uzyskać informacje na temat unikania ograniczania szybkości w aplikacji, zobacz Zapobieganie błędom ograniczania szybkości dla operacji usługi Apache Cassandra w usłudze Azure Cosmos DB.

Łącznik Apache Spark

Wielu użytkowników platformy Apache Cassandra używa łącznika Apache Spark Cassandra do wykonywania zapytań dotyczących danych na potrzeby analizy i przenoszenia danych. Możesz nawiązać połączenie z interfejsem API dla bazy danych Cassandra w taki sam sposób i przy użyciu tego samego łącznika. Przed nawiązaniem połączenia z interfejsem API dla rozwiązania Cassandra zapoznaj się z artykułem Nawiązywanie połączenia z usługą Azure Cosmos DB dla platformy Apache Cassandra z platformy Spark. W szczególności zobacz sekcję Optymalizowanie konfiguracji przepływności łącznika Spark.

Rozwiązywanie typowych problemów

Aby uzyskać rozwiązania typowych problemów, zobacz Rozwiązywanie typowych problemów w usłudze Azure Cosmos DB for Apache Cassandra.

Następne kroki