Udostępnij za pośrednictwem

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

  • Artykuł

DOTYCZY: Kasandra

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 bazy danych Cassandra z minimalnymi zmianami.

W przypadku korzystania z interfejsu API dla rozwiązania Cassandra ważne jest, aby 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 ułatwić rozpoczęcie korzystania z usługi Azure Cosmos DB dla bazy danych Apache Cassandra.

Obsługa funkcji

Interfejs API dla bazy danych Cassandra obsługuje dużą liczbę funkcji apache Cassandra. Niektóre funkcje nie są obsługiwane lub mają ograniczenia. Przed migracją 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 bazy danych 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 lub 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 bazy danych 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 bazy danych 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 systemach Apache Cassandra i Azure Cosmos DB są podobne, ważne jest, aby zrozumieć, jak się różnią. Dokument mapowania porównuje podejścia Apache Cassandra i Azure Cosmos DB do spójności replikacji. Zdecydowanie zalecamy jednak przejrzenie ustawień 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 bazy danych Cassandra nie trzeba wprowadzać istotnych zmian w kodzie istniejących aplikacji z systemem Apache Cassandra. Zalecamy niektóre podejścia i ustawienia konfiguracji interfejsu API dla bazy danych Cassandra w usłudze Azure Cosmos DB. Zapoznaj się z wpisem w blogu API for Cassandra recommendations for Java (Interfejs API w blogu dla rekomendacji 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ć w istniejącym kodzie.

Mamy również bardziej szczegółowe przykłady dla 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 dokument. Usługa Azure Cosmos DB przechowuje 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 reliktó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ą w wielu regionach tylko do odczytu. Koncepcja przejścia w tryb failover na poziomie aplikacji do innego regionu dla zapisów jest nadmiarowa w systemie Apache Cassandra. Wszystkie węzły są niezależne i nie ma jednego punktu awarii. Jednak usługa Azure Cosmos DB zapewnia wbudowaną możliwość konfigurowania regionów jednowzorcowych lub wielowzorcowych na potrzeby zapisu.

Zaletą jednego regionu głównego dla zapisów 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 celem punktu odzyskiwania (RPO) zera 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 ramach jednej konfiguracji regionu zapisu. Jednak podobnie jak w przypadku natywnego systemu Apache Cassandra, nie można skonfigurować konta usługi Azure Cosmos DB skonfigurowanego z wieloma regionami zapisu w celu zapewnienia silnej spójności. System rozproszony 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 Java blog (Zasady równoważenia obciążenia w naszym interfejsie API dla zaleceń dotyczących rozwiązania Cassandra dla języka Java). Zobacz również scenariusze trybu failover w naszym oficjalnym przykładzie kodu dla sterownika Cassandra Java w wersji 4.

Jednostki żądania

Jedną z głównych różnic między uruchamianiem natywnego klastra Apache Cassandra a 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ę. Azure Cosmos DB to wielodostępna baza danych typu "platforma jako usługa". Pojemność jest wyrażana przy użyciu pojedynczej znormalizowanej metryki nazywanej jednostkami żądań. Każde żądanie wysyłane do bazy danych ma koszt jednostkowy żądania (koszt jednostek RU). Każde żądanie można profilować, aby określić jego koszt.

Zaletą używania jednostek żądań jako metryki jest to, że pojemność bazy danych może być aprowizowana deterministycznie 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ć. Wyzwanie związane z tym sposobem aprowizacji 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 żądań, które należy aprowizować. Oto kilka artykułów, które mogą pomóc w oszacowaniu:

Modele aprowizacji pojemności

W tradycyjnej aprowizacji bazy danych aprowizowana jest z góry stała pojemność w celu obsługi przewidywanej 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 autoskalowania 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 ze stałym stanem, 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ą większość z trybu automatycznego skalowania. Zalecamy zapoznanie się z następującymi artykułami w celu jasnego zrozumienia najlepszego modelu pojemności dla potrzeb dotyczących przepływności:

Partycjonowanie

Partycjonowanie w usłudze Azure Cosmos DB jest podobne do partycjonowania w systemie 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, która jest dostępna 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 sposobu działania partycjonowania logicznego i fizycznego oraz limitów pojemności przepływności na partycje, zobacz Partycjonowanie w usłudze Azure Cosmos DB dla bazy danych Apache Cassandra.

Skalowanie

W natywnym systemie 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ń aprowizowania 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 Partitioning in the Azure Cosmos DB for Apache Cassandra (Partycjonowanie w usłudze Azure Cosmos DB dla systemu Apache Cassandra).

Rate limiting (Ograniczanie szybkości)

Wyzwaniem aprowizacji jednostek żądań, szczególnie w przypadku korzystania z aprowizowanej przepływności, jest ograniczanie 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 ilość. Interfejs API dla bazy danych Cassandra w usłudze Azure Cosmos DB tłumaczy te wyjątki na przeciążone błędy w 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 usługi Apache Cassandra używa łącznika Apache Spark Cassandra do wykonywania zapytań dotyczących danych pod kątem potrzeb analitycznych 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 bazy danych Cassandra zapoznaj się z artykułem Nawiązywanie połączenia z usługą Azure Cosmos DB for 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 dla systemu Apache Cassandra.

Następne kroki