Często zadawane pytania dotyczące usługi Azure Cosmos DB dla bazy danych Apache Cassandra

Poniżej przedstawiono kilka kluczowych różnic między interfejsem API dla usługi Cassandra i apache Cassandra:

• Apache Cassandra zaleca ograniczenie rozmiaru klucza partycji o rozmiarze 100 MB. Interfejs API dla bazy danych Cassandra dla usługi Azure Cosmos DB umożliwia do 20 GB na partycję.
• Apache Cassandra umożliwia wyłączenie trwałych zatwierdzeń. Możesz pominąć zapisywanie w dzienniku zatwierdzania i przejść bezpośrednio do struktury danych w pamięci. Może to prowadzić do utraty danych, jeśli węzeł ulegnie awarii, zanim struktury danych w pamięci zostaną opróżnione do tabel SSTable na dysku. Usługa Azure Cosmos DB zawsze wykonuje trwałe zatwierdzenia, aby zapobiec utracie danych.
• Usługa Apache Cassandra może zobaczyć zmniejszoną wydajność, jeśli obciążenie obejmuje wiele zamian lub usunięcia. Przyczyną jest to, że obciążenie odczytu musi przejść, aby pobrać najnowsze dane. Interfejs API dla bazy danych Cassandra nie będzie widzieć zmniejszonej wydajności odczytu, gdy obciążenie ma wiele zamian lub usunięcia.
• W scenariuszach dużych obciążeń zastępczych kompaktowanie musi zostać uruchomione, aby scalić tabele SSTable na dysku. (Scalanie jest wymagane, ponieważ zapisy apache Cassandra są dołączane tylko. Wiele aktualizacji jest przechowywanych jako pojedyncze wpisy tabeli SSTable, które muszą być okresowo scalane). Taka sytuacja może również prowadzić do obniżenia wydajności odczytu podczas kompaktowania. Ten wpływ na wydajność nie występuje w interfejsie API dla bazy danych Cassandra, ponieważ interfejs API nie implementuje kompaktowania.
• Ustawienie współczynnika replikacji o wartości 1 jest możliwe w przypadku systemu Apache Cassandra. Jednak prowadzi to do niskiej dostępności, jeśli jedyny węzeł z danymi ulegnie awarii. Nie jest to problem z interfejsem API dla bazy danych Cassandra dla usługi Azure Cosmos DB, ponieważ zawsze występuje współczynnik replikacji 4 (kworum 3).
• Dodawanie lub usuwanie węzłów w systemie Apache Cassandra wymaga ręcznej interwencji wraz z wysokim użyciem procesora CPU w nowym węźle, podczas gdy istniejące węzły przenoszą niektóre z ich zakresów tokenów do nowego węzła. Ta sytuacja jest taka sama, gdy likwidujesz istniejący węzeł. Jednak interfejs API dla bazy danych Cassandra jest skalowany w poziomie bez żadnych problemów zaobserwowanych w usłudze lub aplikacji.
• Nie ma potrzeby ustawiania num_tokens w każdym węźle w klastrze, tak jak w systemie Apache Cassandra. Usługa Azure Cosmos DB w pełni zarządza węzłami i zakresami tokenów.
• Interfejs API dla bazy danych Cassandra jest w pełni zarządzany. Nie potrzebujesz poleceń, takich jak naprawa i likwidacja, które są używane w systemie Apache Cassandra.

Interfejs API dla bazy danych Cassandra dla usługi Azure Cosmos DB obsługuje język zapytań Cassandra (CQL) m w wersji 3.x. Zgodność języka CQL jest oparta na publicznym repozytorium GitHub apache Cassandra. Jeśli masz opinię na temat obsługi innych protokołów, wyślij wiadomość e-mail na adres askcosmosdbcassandra@microsoft.com.

Usługa Azure Cosmos DB ustawia domyślną przepływność kontenera na podstawie lokalizacji tworzenia tabeli z witryny Azure Portal lub języka CQL.

Usługa Azure Cosmos DB zapewnia gwarancje dotyczące wydajności i opóźnień wraz z górnymi granicami operacji. Gwarancje te są możliwe, gdy aparat może wymusić nadzór nad operacjami dzierżawy. Ustawienie przepływności zapewnia gwarantowaną przepływność i opóźnienie, ponieważ platforma rezerwuje tę pojemność i gwarantuje powodzenie operacji. Możesz elastycznie zmienić przepływność, aby skorzystać z sezonowości aplikacji i obniżyć koszty.

Koncepcja przepływności jest objaśniona w artykule Request Units in Azure Cosmos DB (Jednostki żądań w usłudze Azure Cosmos DB ). Przepływność tabeli jest równomiernie rozłożona na bazowe partycje fizyczne.

Usługa Azure Cosmos DB używa jednostek żądań na sekundę (RU/s) jako waluty do zapewnienia przepływności. Tabele utworzone za pomocą języka CQL domyślnie mają 400 JEDNOSTEK RU. Ru można zmienić w witrynie Azure Portal.

CQL

CREATE TABLE keyspaceName.tablename (user_id int PRIMARY KEY, lastname text) WITH cosmosdb_provisioned_throughput=1200

.NET

int provisionedThroughput = 400;
var simpleStatement = new SimpleStatement($"CREATE TABLE {keyspaceName}.{tableName} (user_id int PRIMARY KEY, lastname text)");
var outgoingPayload = new Dictionary<string, byte[]>();
outgoingPayload["cosmosdb_provisioned_throughput"] = Encoding.UTF8.GetBytes(provisionedThroughput.ToString());
simpleStatement.SetOutgoingPayload(outgoingPayload);

Usługa Azure Cosmos DB zapewnia gwarancje dotyczące wydajności i opóźnień wraz z górnymi granicami operacji. Gwarancje te są możliwe, gdy aparat może wymusić nadzór nad operacjami dzierżawy. Ustawienie przepływności zapewnia gwarantowaną przepływność i opóźnienie, ponieważ platforma rezerwuje tę pojemność i gwarantuje powodzenie operacji.

Po przejściu przez tę pojemność zostanie wyświetlony następujący komunikat o błędzie wskazujący, że pojemność została użyta:

0x1001 przeciążony: nie można przetworzyć żądania, ponieważ "Szybkość żądań jest duża"

Ważne jest, aby zobaczyć, jakie operacje (i ich wolumin) powodują ten problem. Aby dowiedzieć się, jak korzystać z pojemności, możesz przejść przez aprowizowaną pojemność za pomocą metryk w witrynie Azure Portal. Następnie należy upewnić się, że pojemność jest zużywana prawie tak samo we wszystkich partycjach bazowych. Jeśli zobaczysz, że jedna partycja zużywa większość przepływności, masz niesymetryczność obciążenia.

Dostępne są metryki, które pokazują, jak przepływność jest używana w godzinach, w ciągu kilku dni i na siedem dni w partycjach lub w agregacji. Aby uzyskać więcej informacji, zobacz Monitorowanie i debugowanie za pomocą metryk w usłudze Azure Cosmos DB.

Dzienniki diagnostyczne zostały wyjaśnione w artykule dotyczącym rejestrowania diagnostycznego usługi Azure Cosmos DB.

Tak, klucz partycji służy do umieszczania jednostki w odpowiedniej lokalizacji. W usłudze Azure Cosmos DB jest używana do znajdowania odpowiedniej partycji logicznej przechowywanej na partycji fizycznej. Koncepcja partycjonowania jest dobrze wyjaśniona w artykule Partition and scale in Azure Cosmos DB (Partycjonowanie i skalowanie w usłudze Azure Cosmos DB ). Najważniejsze jest to, że partycja logiczna nie powinna przekraczać limitu 20 GB.

Azure Cosmos DB to system oparty na umowie dotyczącej poziomu usług (SLA). Zapewnia nieograniczoną skalę z gwarancjami opóźnienia, przepływności, dostępności i spójności. Ten nieograniczony magazyn jest oparty na poziomie skalowania w poziomie danych przy użyciu partycjonowania jako kluczowego pojęcia. Koncepcja partycjonowania jest dobrze wyjaśniona w artykule Partition and scale in Azure Cosmos DB (Partycjonowanie i skalowanie w usłudze Azure Cosmos DB ).

Należy przestrzegać limitu 20 GB dla liczby jednostek lub elementów na partycję logiczną. Aby upewnić się, że aplikacja działa prawidłowo, zalecamy, aby nie utworzyć gorącej partycji, przechowując wszystkie informacje w jednej partycji i wykonując względem niej zapytanie. Ten błąd może pojawić się tylko wtedy, gdy dane są niesymetryczne: oznacza to, że masz dużo danych dla jednego klucza partycji (więcej niż 20 GB). Rozkład danych można znaleźć za pomocą portalu magazynu. Rozwiązanie tego błędu polega na ponownym utworzeniu tabeli i wybraniu szczegółowego podstawowego (klucza partycji), który umożliwia lepszą dystrybucję danych.

Usługa Azure Cosmos DB może przechowywać nieograniczone dane, skalując magazyn w górę. Ten magazyn jest niezależny od przepływności. Tak, zawsze możesz użyć interfejsu API dla bazy danych Cassandra tylko do przechowywania i pobierania kluczy i wartości, określając odpowiedni klucz podstawowy/klucz partycji. Te poszczególne klucze uzyskują własną partycję logiczną i znajdują się na szczycie partycji fizycznej bez problemów.

Tak, można utworzyć więcej niż jedną tabelę za pomocą interfejsu API dla bazy danych Cassandra. Każda z tych tabel jest traktowana jako jednostka przepływności i magazynu.

Usługa Azure Cosmos DB jest systemem zarządzanym przez zasoby zarówno dla działań płaszczyzny danych, jak i płaszczyzny sterowania. Kontenery, takie jak kolekcje i tabele, to jednostki środowiska uruchomieniowego aprowidowane dla danej pojemności przepływności. Tworzenie tych kontenerów w krótkim odstępie czasu nie jest oczekiwanym działaniem i może zostać ograniczone. Jeśli masz testy, które natychmiast upuszczają lub tworzą tabele, spróbuj je zwolnić.

Nie ma fizycznego limitu liczby tabel. Jeśli masz dużą liczbę tabel (gdzie całkowity stały rozmiar przekroczy 10 TB danych), które należy utworzyć, a nie zwykłych dziesiątek lub setek, wyślij wiadomość e-mail na adres askcosmosdbcassandra@microsoft.com.

Nie ma fizycznego limitu liczby przestrzeni kluczy, ponieważ są to kontenery metadanych. Jeśli masz dużą liczbę przestrzeni kluczy, wyślij wiadomość e-mail na adres askcosmosdbcassandra@microsoft.com.

Tak. Przy założeniu równomiernie rozproszonych partycji pojemność magazynu jest automatycznie zarządzana i zwiększa się w miarę wypychania większej ilości danych. Dzięki temu możesz bezpiecznie zaimportować tyle danych, ile potrzebujesz, bez zarządzania węzłami i nie tylko. Jeśli jednak przewidujesz wiele natychmiastowych wzrostów danych, bardziej sensowne jest bezpośrednie aprowizowanie przewidywanej przepływności , a nie rozpoczęcie niższej i natychmiastowe zwiększenie jej.

Interfejs API dla bazy danych Cassandra dla usługi Azure Cosmos DB zapewnia zgodność na poziomie protokołu na potrzeby wykonywania operacji. Ukrywa złożoność zarządzania, monitorowania i konfiguracji. Jako deweloper/użytkownik nie musisz martwić się o dostępność, grobowce, pamięć podręczną kluczy, pamięć podręczną wierszy, filtr bloom i wiele innych ustawień. Interfejs API dla rozwiązania Cassandra koncentruje się na zapewnieniu wymaganej wydajności odczytu i zapisu bez konieczności wprowadzania obciążeń związanych z konfiguracją i zarządzaniem.

Interfejs API dla rozwiązania Cassandra upraszcza planowanie pojemności i odpowiadanie na wymagania dotyczące elastyczności przepływności i magazynu. W usłudze Azure Cosmos DB aprowizujesz potrzebną przepływność. Następnie można skalować ją w górę i w dół dowolną liczbę razy w ciągu dnia, nie martwiąc się o dodawanie, usuwanie lub zarządzanie węzłami. Nie musisz używać narzędzi do zarządzania węzłami i klastrami.

Usługa Azure Cosmos DB zapewnia globalną dystrybucję z racji dostępności i małych opóźnień. Nie trzeba konfigurować replik ani innych elementów. Zapisy są zawsze trwale zatwierdzane kworum w dowolnym regionie, w którym zapisujesz, jednocześnie zapewniając gwarancje wydajności.

Usługa Azure Cosmos DB zapewnia gwarancje wydajności odczytu, zapisu i przepływności. Nie musisz martwić się o dotykanie żadnych ustawień konfiguracji i przypadkowe manipulowanie nimi. Te ustawienia obejmują filtr blooma, buforowanie, prawdopodobieństwo naprawy odczytu, gc_grace i memtable_flush_period kompresji.

Tak, czas wygaśnięcia jest obsługiwany.

Azure Cosmos DB to usługa platformy, która pomaga zwiększyć produktywność i nie martwić się o zarządzanie infrastrukturą i monitorowanie jej. Na przykład nie trzeba monitorować stanu węzła, stanu repliki, gc i parametrów systemu operacyjnego wcześniej przy użyciu różnych narzędzi. Wystarczy zadbać o przepływność dostępną w metrykach portalu, aby sprawdzić, czy przepływność jest ograniczona, a następnie zwiększyć lub zmniejszyć przepływność. Masz następujące możliwości:

• Monitorowanie umów SLA
• Korzystanie z metryk
• Korzystanie z dzienników diagnostycznych

Sterowniki klienta zestawu APACHE Cassandra SDK, które używają języka CQLv3, były używane dla programów klienckich. Jeśli masz inne sterowniki, których używasz lub jeśli masz problemy, wyślij wiadomość e-mail na askcosmosdbcassandra@microsoft.comadres .

Tak, można użyć regularnej składni do tworzenia kluczy partycji złożonych.

Nie, sstableloader nie jest obsługiwany.

Teraz usługa Azure Cosmos DB ma zoptymalizowane środowisko dla środowiska chmury bez obciążeń związanych z operacjami. Jeśli potrzebujesz parowania, wyślij wiadomość askcosmosdbcassandra@microsoft.com e-mail z opisem scenariusza. Pracujemy nad ofertą, która ułatwia parowanie klastra lokalnego lub w chmurze Cassandra z interfejsem API dla bazy danych Cassandra dla usługi Azure Cosmos DB.

Usługa Azure Cosmos DB udostępnia dwie bezpłatne pełne kopie zapasowe wykonywane w czterech godzinach we wszystkich interfejsach API. Nie musisz więc konfigurować harmonogramu tworzenia kopii zapasowych.

Możesz samodzielnie zarządzać przechowywaniem i częstotliwością tworzenia kopii zapasowych.

Jeśli chcesz przywrócić kopię zapasową, wyślij wiadomość e-mail na askcosmosdbcassandra@microsoft.com adres lub zgłoś zgłoszenie do pomocy technicznej. Informacje o możliwości tworzenia kopii zapasowych są dostępne w artykule Automatyczne tworzenie kopii zapasowych online i przywracanie za pomocą usługi Azure Cosmos DB .

Interfejs API dla rozwiązania Cassandra pożycza się z globalnie rozproszonej platformy usługi Azure Cosmos DB. Aby zapewnić, że aplikacja może tolerować przestoje centrum danych, włącz co najmniej jeden region dla konta w witrynie Azure Portal. Aby uzyskać więcej informacji, zobacz Wysoka dostępność w usłudze Azure Cosmos DB.

Możesz dodać dowolną liczbę regionów dla konta i kontrolować, do którego można przejść w tryb failover, zapewniając priorytet trybu failover. Aby użyć bazy danych, musisz również podać aplikację. W tym przypadku klienci nie będą napotykać przestojów.

L.p. Interfejs API dla bazy danych Cassandra obsługuje indeksy pomocnicze, które zachowują się podobnie do bazy danych Apache Cassandra. Interfejs API domyślnie nie indeksuje każdego atrybutu.

Tak, takie rozwiązanie jest obsługiwane. Szczegółowe informacje na temat włączania tej funkcji można znaleźć w artykule Korzystanie z emulatora usługi Azure Cosmos DB na potrzeby lokalnego programowania i testowania .

Informacje o opcjach migracji można przeczytać w samouczku Migrowanie danych do interfejsu API dla konta Cassandra w usłudze Azure Cosmos DB .

Powiązana zawartość

• Rozpoczynanie pracy z elastycznym skalowaniem konta usługi Azure Cosmos DB dla usługi Apache Cassandra

Następny krok