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

  • Artykuł

DOTYCZY: Cassandra

Ważne

Zmaterializowane widoki w usłudze Azure Cosmos DB dla bazy danych Cassandra są obecnie dostępne w wersji zapoznawczej. Tę funkcję można włączyć przy użyciu Azure Portal. Ta wersja zapoznawcza zmaterializowanych widoków jest udostępniana bez umowy dotyczącej poziomu usług. Obecnie zmaterializowane widoki nie są zalecane w przypadku obciążeń produkcyjnych. Niektóre funkcje tej wersji zapoznawczej mogą nie być obsługiwane lub mogą mieć ograniczone możliwości. Aby uzyskać więcej informacji, zobacz dodatkowe warunki użytkowania dla wersji zapoznawczych platformy Microsoft Azure.

Zmaterializowane widoki, gdy są zdefiniowane, ułatwiają efektywne wykonywanie zapytań względem tabeli podstawowej (lub kontenera w usłudze Azure Cosmos DB) przy użyciu filtrów, które nie są kluczami podstawowymi. Gdy użytkownicy zapisują dane w tabeli podstawowej, zmaterializowany widok jest automatycznie kompilowany w tle. Ten widok może mieć inny klucz podstawowy do wydajnego wyszukiwania. Widok będzie również zawierać tylko kolumny jawnie wyświetlane z tabeli bazowej. Ten widok będzie tabelą tylko do odczytu.

Magazyn kolumn można wykonywać zapytania bez określania klucza partycji przy użyciu indeksów pomocniczych. Jednak zapytanie nie będzie skuteczne w przypadku kolumn o wysokiej lub niskiej kardynalności. Zapytanie może przeskanować wszystkie dane dla małego zestawu wyników. Takie zapytania stają się kosztowne, ponieważ w końcu przypadkowo są wykonywane jako zapytanie obejmujące wiele partycji.

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

  • Użyj jako tabeli odnośników lub mapowań, aby utrwały skanowanie między partycjami, które w przeciwnym razie byłyby kosztowne zapytania.
  • 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, które są często przechowywane jako oddzielne kolekcje przy użyciu wyzwalaczy zestawienia zmian.

Zalety zmaterializowanych widoków

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

  • Denormalizacja 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 złożonej denormalizacji obliczeniowej w aplikacjach klienckich.
  • Zmaterializowane widoki są automatycznie aktualizowane, aby zachować ich spójność z tabelą bazową. Ta automatyczna aktualizacja stanowi abstrakcję obowiązków aplikacji klienckich, które zwykle implementują logikę niestandardową w celu wykonywania podwójnych zapisów w tabeli podstawowej i widoku.
  • Zmaterializowane widoki optymalizują wydajność odczytu, odczytując z pojedynczego widoku.
  • Przepływność zmaterializowanego widoku można określić niezależnie.
  • Warstwę konstruktora zmaterializowanego widoku można skonfigurować do mapowania na wymagania w celu nawodnienia 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.

Wprowadzenie do zmaterializowanych widoków

Utwórz nowy interfejs API dla kont Cassandra przy użyciu interfejsu wiersza polecenia platformy Azure, aby włączyć zmaterializowaną funkcję widoków za pomocą natywnego polecenia lub operacji interfejsu API REST.

  1. Zaloguj się do Azure portal.

  2. Przejdź do interfejsu API dla konta Cassandra.

  3. W menu zasobów wybierz pozycję Ustawienia.

  4. W sekcji Ustawienia wybierz pozycję Zmaterializowany widok dla interfejsu API Cassandra (wersja zapoznawcza).

  5. W nowym oknie dialogowym wybierz pozycję Włącz , aby włączyć tę funkcję dla tego konta.

    Zrzut ekranu przedstawiający funkcję zmaterializowane widoki włączoną w Azure Portal.

Kulisy

Interfejs API dla bazy danych Cassandra używa zmaterializowanej warstwy obliczeniowej konstruktora widoku do obsługi widoków.

Możesz uzyskać elastyczność konfigurowania wystąpień obliczeniowych konstruktora widoku na podstawie wymagań dotyczących opóźnień i opóźnień w celu nawodnienia widoków. Z technicznego punktu widzenia ta warstwa obliczeniowa ułatwia zarządzanie połączeniami między partycjami w bardziej wydajny sposób nawet wtedy, gdy 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 aprowizowany kontener obliczeniowy generuje wiele zadań, które odczytują zestawienie zmian z partycji tabeli podstawowej i zapisuje dane w docelowym zmaterializowanym widoku[s]. Kontener obliczeniowy przekształca dane zgodnie z materializowaną definicją 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.

  1. Zaloguj się do Azure portal.

  2. Przejdź do interfejsu API dla konta Cassandra.

  3. W menu zasobów wybierz pozycję Zmaterializowany konstruktor widoków.

  4. Na zmaterializowane widoki Konstruktor skonfiguruj jednostkę SKU i liczbę wystąpień dla konstruktora.

    Uwaga

    Ta opcja menu zasobów i strona będą wyświetlane tylko po włączeniu funkcji zmaterializowane widoki dla konta.

  5. Wybierz pozycję Zapisz.

Tworzenie zmaterializowanego widoku

Po skonfigurowaniu konta i zmaterializowanego narzędzia View Builder powinno być możliwe tworzenie zmaterializowanych widoków przy użyciu protokołu CQLSH.

Uwaga

Jeśli nie masz jeszcze zainstalowanego autonomicznego narzędzia CQLSH, zobacz instalowanie narzędzia CQLSH. Należy również zaktualizować parametry połączenia w narzędziu.

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

  1. Najpierw utwórz nazwę uprofileprzestrzeni kluczy .

    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 tej samej przestrzeni kluczy. Określ, używając zapytania, jak dane są rzutowane do widoku z tabeli podstawowej.

    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 dotyczące 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.

Bieżące ograniczenia

Istnieje kilka ograniczeń dotyczących implementacji podglądu interfejsu API dla zmaterializowanych widoków cassandra:

  • 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 klauzuli zmaterializowanej WHERE definicji widoku tylko IS NOT NULL filtry są obecnie dozwolone.
  • Po utworzeniu zmaterializowanego widoku względem tabeli ALTER TABLE ADD podstawowej operacje nie są dozwolone w schemacie tabeli podstawowej. ALTER TABLE APP jest dozwolone tylko wtedy, gdy żaden z zmaterializowanych widoków nie został wybrany * w definicji.
  • Istnieją limity rozmiaru klucza partycji (2 Kb) i łączna długość rozmiaru klucza klastrowania (1 Kb). Jeśli ten limit rozmiaru zostanie przekroczony, komunikat odpowiedzialny zostanie wyświetlony w kolejce komunikatów otrucia.
  • Jeśli tabela podstawowa ma zdefiniowane przez użytkownika typy (UDT) i zmaterializowaną definicję widoku ma wartość SELECT * FROM lub ma wartość UDT w jednej z przewidywanych kolumn, aktualizacje udT nie są dozwolone na koncie.
  • Zmaterializowane widoki mogą stać się niespójne z tabelą podstawową dla kilku wierszy po automatycznym regionalnym przejściu w tryb failover. Aby uniknąć tej niespójności, ponownie skompiluj zmaterializowany widok po przejściu w tryb failover.
  • Tworzenie zmaterializowanych wystąpień konstruktora widoków z 32 rdzeniami nie jest obsługiwane. W razie potrzeby można utworzyć wiele wystąpień 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 włączonymi regionami strefy dostępności.
    • Dodanie nowego regionu ze strefą dostępności nie jest obsługiwane po enableMaterializedViews ustawieniu wartości true na koncie.
  • Okresowe wykonywanie 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 na ich przywróconym koncie przed ponownym utworzeniem zmaterializowanych widoków i konstruktorów.
  • Apache Cassandra
    • Definiowanie zasad rozwiązywania konfliktów w przypadku zmaterializowanych widoków nie jest dozwolone.
    • Operacje zapisu nie są dozwolone w zmaterializowanych widokach.
    • Zapytania między dokumentami i korzystanie z funkcji agregacji nie są obsługiwane w zmaterializowanych widokach.
    • Nie można zmodyfikować schematu zmaterializowanego widoku po utworzeniu.
    • Usunięcie tabeli podstawowej nie jest dozwolone, jeśli na nim zdefiniowano co najmniej jeden zmaterializowany widok. Wszystkie widoki muszą zostać najpierw usunięte, a następnie można usunąć tabelę podstawową.
    • Definiowanie zmaterializowanych widoków w kontenerach z kolumnami statycznymi nie jest dozwolone.

Następne kroki

Zapoznaj się z często zadawanymi pytaniami dotyczącymi zmaterializowanych widoków w interfejsie API dla rozwiązania Cassandra