Zmaterializowane widoki w usłudze Azure Cosmos DB dla systemu Apache Cassandra (wersja zapoznawcza)

DOTYCZY: Kasandra

Zmaterializowane widoki, po zdefiniowaniu, ułatwiają efektywne wykonywanie zapytań względem tabeli podstawowej (lub kontenera w usłudze Azure Cosmos DB) za pomocą filtrów, które nie są kluczami podstawowymi. Gdy użytkownicy zapisują w tabeli podstawowej, zmaterializowany widok jest tworzony automatycznie w tle. Ten widok może mieć inny klucz podstawowy do wydajnego wyszukiwania. Widok będzie zawierać tylko kolumny, które są explicitnie wybierane z tabeli bazowej. Ten widok będzie tabelą tylko do odczytu.

Możesz wykonywać zapytania dotyczące magazynu kolumn bez określania klucza partycji, korzystając z indeksów pomocniczych. Jednak zapytanie nie będzie skuteczne w przypadku kolumn o wysokiej lub niskiej kardynalności. Zapytanie może skanować wszystkie dane dla małego zestawu wyników. Takie zapytania stają się kosztowne, ponieważ są nieumyślnie wykonywane jako zapytania obejmujące wiele partycji.

Za pomocą zmaterializowanego widoku można wykonywać następujące czynności:

• Użyj tabeli odnośników lub mapowania, aby utrwalić skanowanie między partycjami, które w przeciwnym razie byłyby kosztowne.
• Podaj predykat warunkowy oparty na języku SQL, aby wypełnić tylko niektóre kolumny i dane spełniające warunek wstępny.
• Twórz widoki w czasie rzeczywistym, które upraszczają scenariusze oparte na zdarzeniach, często przechowywane jako oddzielne kolekcje, przy wykorzystaniu wyzwalaczy przepływu zmian.

Zalety zmaterializowanych widoków

Zmaterializowane widoki mają wiele korzyści, które obejmują, ale nie są ograniczone do:

• Denormalizację po stronie serwera można zaimplementować przy użyciu zmaterializowanych widoków. Dzięki denormalizacji po stronie serwera można uniknąć wielu niezależnych tabel i obliczeniowej złożonej denormalizacji w aplikacjach klienckich.
• Zmaterializowane widoki są automatycznie aktualizowane, aby zapewnić spójność z tabelą bazową. Ta automatyczna aktualizacja upraszcza obowiązki aplikacji klienckich, które zwykle implementują logikę niestandardową, aby wykonywać podwójne zapisy w tabeli podstawowej i widoku.
• Zmaterializowane widoki optymalizują wydajność odczytu, odczytując z pojedynczego widoku.
• Przepustowość zmaterializowanego widoku można określić niezależnie.
• Warstwę konstruktora widoku materializowanego można skonfigurować do dopasowania do Twoich wymagań w celu zasilenia widoku.
• Zmaterializowane widoki zwiększają wydajność zapisu, ponieważ operacje zapisu muszą być zapisywane tylko w tabeli podstawowej.
• Ponadto implementacja zmaterializowanych widoków w usłudze Azure Cosmos DB jest oparta na modelu ściągania. Ta implementacja nie ma wpływu na wydajność zapisu.

Rozpocznij pracę z zmaterializowanymi widokami

Utwórz nowe API dla kont Cassandra, korzystając z interfejsu wiersza polecenia Azure, aby włączyć funkcję widoków materializowanych za pomocą natywnego polecenia lub operacji REST API.

Pod maską

API dla bazy danych Cassandra używa warstwy obliczeniowej konstruktora widoków zmaterializowanych do utrzymywania widoków.

Uzyskasz elastyczność konfigurowania wystąpień obliczeniowych twórcy widoku na podstawie wymagań dotyczących latencji i opóźnień w celu zasilenia widoków. Z technicznego punktu widzenia ta warstwa obliczeniowa ułatwia zarządzanie połączeniami między partycjami w bardziej wydajny sposób, nawet jeśli rozmiar danych jest duży, a liczba partycji jest wysoka.

Kontenery obliczeniowe są współużytkowane przez wszystkie zmaterializowane widoki na koncie usługi Azure Cosmos DB. Każdy skonfigurowany kontener obliczeniowy generuje wiele zadań, które odczytują strumień zmian z partycji tabeli podstawowej i zapisują dane w docelowych zmaterializowanych widokach. Kontener obliczeniowy przekształca dane zgodnie z definicją zmaterializowanego widoku dla każdego zmaterializowanego widoku na koncie.

Tworzenie zmaterializowanego konstruktora widoków

Utwórz zmaterializowanego konstruktora widoków, aby automatycznie przekształcać dane i zapisywać je w zmaterializowanym widoku.

Tworzenie zmaterializowanego widoku

Po skonfigurowaniu konta i zmaterializowanego konstruktora widoków powinno być możliwe utworzenie zmaterializowanych widoków przy użyciu protokołu CQLSH.

Oto kilka przykładowych poleceń do utworzenia zmaterializowanego widoku:

1. Najpierw utwórz przestrzeń kluczy o nazwie uprofile.

   CREATE KEYSPACE IF NOT EXISTS uprofile WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'datacenter1' : 1 };
   

2. Następnie utwórz tabelę o nazwie user w przestrzeni kluczy.

   CREATE TABLE IF NOT EXISTS uprofile.USER (user_id INT PRIMARY KEY, user_name text, user_bcity text);
   

3. Teraz utwórz zmaterializowany widok o nazwie user_by_bcity w ramach tej samej przestrzeni kluczy. Określ sposób projekcji danych w widoku z tabeli bazowej przy użyciu zapytania.

   CREATE MATERIALIZED VIEW uprofile.user_by_bcity AS 
   SELECT
       user_id,
       user_name,
       user_bcity 
   FROM
       uprofile.USER 
   WHERE
       user_id IS NOT NULL 
       AND user_bcity IS NOT NULL PRIMARY KEY (user_bcity, user_id);
   

4. Wstaw wiersze do tabeli podstawowej.

   INSERT INTO
       uprofile.USER (user_id, user_name, user_bcity) 
   VALUES
       (
           101, 'johnjoe', 'New York' 
       );
   
   INSERT INTO
       uprofile.USER (user_id, user_name, user_bcity) 
   VALUES
       (
           102, 'james', 'New York' 
       );
   

5. Wykonaj zapytanie względem zmaterializowanego widoku.

   SELECT * FROM user_by_bcity; 
   

6. Obserwuj dane wyjściowe zmaterializowanego widoku.

    user_bcity | user_id | user_name 
   ------------+---------+----------- 
      New York |     101 |   johnjoe 
      New York |     102 |     james 
   
   (2 rows) 
   

Opcjonalnie możesz również użyć dostawcy zasobów do utworzenia lub zaktualizowania zmaterializowanego widoku.

• Tworzenie lub aktualizowanie widoku w interfejsie API dla bazy danych Cassandra
• Uzyskaj widok w API dla Cassandry
• Wyświetlanie listy widoków w interfejsie API dla bazy danych Cassandra
• Usuń widok w API Cassandry
• Zaktualizuj przepustowość widoku w interfejsie API dla Cassandry

Bieżące ograniczenia

Z wersją zapoznawczą implementacji zmaterializowanych widoków dla bazy danych Cassandra w interfejsie API wiążą się pewne ograniczenia.

• Zmaterializowane widoki nie można utworzyć w tabeli, która istniała przed włączeniem obsługi zmaterializowanych widoków na koncie. Aby użyć zmaterializowanych widoków, utwórz nową tabelę po włączeniu funkcji.
• W przypadku definicji zmaterializowanego widoku, obecnie dozwolone są tylko filtry WHERE w klauzuli IS NOT NULL.
• Po utworzeniu zmaterializowanego widoku na bazowej tabeli ALTER TABLE ADD operacje związane ze schematem tej tabeli nie są dozwolone. ALTER TABLE APP jest dozwolony tylko wtedy, gdy żaden z zmaterializowanych widoków nie zawiera * w swojej definicji.
• Istnieją limity rozmiaru klucza partycji (2 Kb) i łączna długość rozmiaru klucza klastrowania (1 KB). Jeśli ten limit rozmiaru zostanie przekroczony, dany komunikat trafi do kolejki z wiadomościami odrzuconymi.
• Jeśli tabela podstawowa ma typy zdefiniowane przez użytkownika (UDT), a definicja zmaterializowanego widoku zawiera SELECT * FROM lub ma UDT w jednej z kolumn projekcji, aktualizacje UDT nie są dozwolone dla konta.
• Zmaterializowane widoki mogą stać się niespójne z tabelą podstawową dla kilku wierszy po automatycznym przełączeniu w tryb failover w regionie. Aby uniknąć tej niespójności, odbuduj zmaterializowany widok po awarii.
• Tworzenie zmaterializowanych wystąpień konstruktora widoków z 32 rdzeniami nie jest obsługiwane. W razie potrzeby można utworzyć wiele instancji konstruktora z mniejszą liczbą rdzeni.

Oprócz powyższych ograniczeń należy wziąć pod uwagę następujące dodatkowe ograniczenia:

• Strefy dostępności
  • Nie można włączyć zmaterializowanych widoków na koncie z regionami, w których włączono strefy dostępności.
  • Dodanie nowego regionu ze strefą dostępności nie jest obsługiwane po ustawieniu wartości enableMaterializedViews na "true" na koncie.
• Okresowe tworzenie kopii zapasowej i przywracanie
  • Zmaterializowane widoki nie są automatycznie przywracane przy użyciu procesu przywracania. Po zakończeniu procesu przywracania należy ponownie utworzyć zmaterializowane widoki. Następnie należy skonfigurować enableMaterializedViews ich przywrócone konto przed ponownym utworzeniem zmaterializowanych widoków i konstruktorów.
• Apache Cassandra
  • Definiowanie zasad rozwiązywania konfliktów dla zmaterializowanych widoków nie jest dozwolone.
  • Operacje zapisu nie są dozwolone w zmaterializowanych widokach.
  • Zapytania między dokumentami i korzystanie z funkcji agregujących nie są obsługiwane w zmaterializowanych widokach.
  • Nie można zmodyfikować schematu zmaterializowanego widoku po utworzeniu.
  • Usunięcie tabeli podstawowej jest niedozwolone, jeśli zdefiniowany jest co najmniej jeden zmaterializowany widok. Wszystkie widoki muszą zostać najpierw usunięte, a następnie można usunąć tabelę podstawową.
  • Definiowanie materializowanych widoków w kontenerach ze statycznymi kolumnami nie jest dozwolone.

Następne kroki