Zmaterializowane widoki

  • Artykuł

Zmaterializowane widoki uwidaczniają zapytanie agregacji w tabeli źródłowej lub w innym zmaterializowanym widoku.

Zmaterializowane widoki zawsze zwracają aktualny wynik zapytania agregacji (zawsze świeże). Wykonywanie zapytań względem zmaterializowanego widoku jest bardziej wydajne niż uruchamianie agregacji bezpośrednio nad tabelą źródłową.

Uwaga

Dlaczego warto używać zmaterializowanych widoków?

Inwestując zasoby (magazyn danych, cykle procesora CPU w tle) dla zmaterializowanych widoków często używanych agregacji, uzyskujesz następujące korzyści:

  • Poprawa wydajności: Wykonywanie zapytań względem zmaterializowanego widoku zwykle działa lepiej niż wykonywanie zapytań względem tabeli źródłowej dla tych samych funkcji agregacji.

  • Świeżość: Zmaterializowane zapytanie widoku zawsze zwraca najbardziej aktualne wyniki, niezależnie od czasu ostatniego zmaterializacji. Zapytanie łączy zmaterializowaną część widoku z rekordami w tabeli źródłowej, które nie zostały jeszcze zmaterializowane (część delta ), zawsze dostarczając najbardziej aktualne wyniki.

  • Obniżenie kosztów:wykonywanie zapytań względem zmaterializowanego widoku zużywa mniej zasobów z klastra niż agregacja w tabeli źródłowej. Zasady przechowywania tabeli źródłowej można zmniejszyć, jeśli wymagana jest tylko agregacja. Ta konfiguracja zmniejsza koszty gorącej pamięci podręcznej dla tabeli źródłowej.

Na przykład przypadki użycia można znaleźć w temacie Materialized view use cases (Zmaterializowane przypadki użycia widoku).

Jak działają zmaterializowane widoki

Zmaterializowany widok składa się z dwóch składników:

  • Zmaterializowana część — tabela zawierająca zagregowane rekordy z tabeli źródłowej, które zostały już przetworzone. Ta tabela zawsze zawiera pojedynczy rekord dla kombinacji grup agregacji.
  • Delta — nowo pozyskane rekordy w tabeli źródłowej, które nie zostały jeszcze przetworzone.

Wykonywanie zapytań względem zmaterializowanego widoku łączy zmaterializowaną część z częścią różnicową, zapewniając aktualny wynik zapytania agregacji. Proces materializacji w trybie offline pozyskuje nowe rekordy z delty do zmaterializowanej tabeli i aktualizuje istniejące rekordy. Jeśli część wspólna między różnicą a zmaterializowaną częścią jest duża, a wiele rekordów wymaga aktualizacji, może to mieć negatywny wpływ na proces materializacji. Zobacz monitorowanie zmaterializowanych widoków na temat rozwiązywania takich sytuacji.

Zmaterializowane zapytania dotyczące widoków

Istnieją 2 sposoby wykonywania zapytań dotyczących zmaterializowanego widoku:

  • Wykonaj zapytanie dotyczące całego widoku: podczas wykonywania zapytania względem zmaterializowanego widoku według jego nazwy, podobnie jak w przypadku wykonywania zapytań dotyczących tabeli, zmaterializowane zapytanie widoku łączy zmaterializowaną część widoku z rekordami w tabeli źródłowej, które nie zostały jeszcze zmaterializowane ().delta

    • Wykonywanie zapytań względem zmaterializowanego widoku zawsze zwraca najbardziej aktualne wyniki na podstawie wszystkich rekordów pozyskanych do tabeli źródłowej. Aby uzyskać więcej informacji na temat zmaterializowanych i niezmaterializowanych części w zmaterializowanym widoku, zobacz jak działają zmaterializowane widoki.
    • Ta opcja może nie działać najlepiej, ponieważ musi zmaterializować delta część w czasie zapytania. Wydajność w tym przypadku zależy od wieku widoku i filtrów zastosowanych w zapytaniu. Sekcja zmaterializowanego optymalizatora zapytań zawiera możliwe sposoby poprawy wydajności zapytań podczas wykonywania zapytań względem całego widoku.

  • Wykonaj zapytanie tylko w zmaterializowanej części: innym sposobem wykonywania zapytań względem widoku jest użycie materialized_view() funkcji . Ta opcja obsługuje wykonywanie zapytań tylko zmaterializowanej części widoku, określając maksymalne opóźnienie, które użytkownik chce tolerować.

    • Ta opcja nie gwarantuje zwrócenia najbardziej aktualnych rekordów, ale zawsze powinna być bardziej wydajna niż wykonywanie zapytań względem całego widoku.
    • Ta funkcja jest przydatna w scenariuszach, w których chcesz poświęcić pewną świeżość pod kątem wydajności, na przykład w przypadku pulpitów nawigacyjnych telemetrii.

Porada

Zapytania dotyczące zmaterializowanej części zawsze działają lepiej niż wykonywanie zapytań względem całego widoku. Zawsze używaj materialized_view() funkcji, jeśli ma zastosowanie do przypadku użycia.

  • Zmaterializowane widoki uczestniczą w zapytaniach między klastrami lub między bazami danych, ale nie są uwzględniane w związkach wieloznacznych ani wyszukiwaniach.

    • Wszystkie poniższe przykłady obejmują zmaterializowane widoki według nazwy ViewName:
    cluster('cluster1').database('db').ViewName
cluster('cluster1').database('*').ViewName
database('*').ViewName
database('DB*').ViewName
database('*').materialized_view('ViewName')
database('DB*').materialized_view('ViewName')
    • Następujące przykłady nie obejmują rekordów zmaterializowanych widoków:
    cluster('cluster1').database('db').*
database('*').View*
search in (*)
search *

Zmaterializowany optymalizator zapytań widoku

Podczas wykonywania zapytań dotyczących całego widoku zmaterializowana część jest połączona z elementem delta w czasie wykonywania zapytania. Obejmuje to agregowanie delta i łączenie go ze zmaterializowaną częścią.

  • Wykonywanie zapytań względem całego widoku działa lepiej, jeśli zapytanie zawiera filtry w grupie według kluczy zmaterializowanego zapytania widoku. Zobacz więcej wskazówek dotyczących tworzenia zmaterializowanego widoku na podstawie wzorca zapytania w .create materialized-view sekcji porady dotyczące wydajności .
  • Optymalizator zapytań wybiera strategie sumowania/dołączania, które mają poprawić wydajność zapytań. Na przykład decyzja o tym, czy tasować zapytanie, jest oparta na liczbie rekordów po delta części. Następujące właściwości żądania klienta zapewniają pewną kontrolę nad zastosowanymi optymalizacjami. Te właściwości można przetestować za pomocą zmaterializowanych zapytań widoku i ocenić ich wpływ na wydajność zapytań.
Nazwa właściwości żądania klienta Typ Opis
materialized_view_query_optimization_costbased_enabled bool Jeśli jest ustawiona wartość false, wyłącza optymalizacje sumowania/sprzężenia w zmaterializowanych zapytaniach widoku. Używa strategii domyślnych. Wartość domyślna to true.
materialized_view_shuffle dynamic Wymuś mieszanie zmaterializowanego zapytania widoku, a (opcjonalnie) podaj określone klucze do mieszania. Zobacz przykłady poniżej.

Przykłady

  1. Wykonaj zapytanie dotyczące całego widoku. Najnowsze rekordy w tabeli źródłowej są uwzględniane:

    ViewName

  2. Wykonaj zapytanie dotyczące zmaterializowanej części widoku tylko niezależnie od tego, kiedy został on ostatnio zmaterializowany.

    materialized_view("ViewName")

  3. Wykonaj zapytanie względem całego widoku i podaj "wskazówkę", aby użyć shuffle strategii. Najnowsze rekordy w tabeli źródłowej są uwzględniane:

    • Przykład nr 1: mieszanie na Id podstawie kolumny (podobnie jak przy użyciu polecenia hint.shufflekey=Id):
    set materialized_view_shuffle = dynamic([{"Name" : "ViewName", "Keys" : [ "Id" ] }]);
ViewName
    • Przykład nr 2: mieszanie na podstawie wszystkich kluczy (podobnie jak przy użyciu polecenia hint.strategy=shuffle):
    set materialized_view_shuffle = dynamic([{"Name" : "ViewName" }]);
ViewName

Zagadnienia dotyczące wydajności

Głównymi współautorami, które mogą mieć wpływ na zmaterializowaną kondycję widoku, są:

  • Zasoby klastra: Podobnie jak każdy inny proces uruchomiony w klastrze, zmaterializowane widoki zużywają zasoby (procesor CPU, pamięć) z klastra. Jeśli klaster jest przeciążony, dodanie zmaterializowanych widoków może spowodować obniżenie wydajności klastra. Monitorowanie kondycji klastra przy użyciu metryk kondycji klastra. Zoptymalizowane autoskalowanie obecnie nie uwzględnia zmaterializowanej kondycji widoków w ramach reguł autoskalowania.

  • Nakładanie się na zmaterializowane dane: Podczas materializacji wszystkie nowe rekordy pozyskane do tabeli źródłowej od czasu ostatniej materializacji (różnicy) są przetwarzane i zmaterializowane w widoku. Im większa część między nowymi rekordami a już zmaterializowanymi rekordami, tym gorzej będzie wydajność zmaterializowanego widoku. Zmaterializowany widok działa najlepiej, jeśli liczba rekordów aktualizowanych (na przykład w arg_max widoku) jest małym podzbiorem tabeli źródłowej. Jeśli wszystkie lub większość zmaterializowanych rekordów widoku muszą zostać zaktualizowane w każdym cyklu materializacji, zmaterializowany widok może nie działać prawidłowo.

  • Szybkość pozyskiwania: W tabeli źródłowej zmaterializowanego widoku nie ma żadnych zakodowanych limitów ilości danych ani szybkości pozyskiwania. Jednak zalecana szybkość pozyskiwania dla zmaterializowanych widoków wynosi nie więcej niż 1–2 GB/s. Wyższe wskaźniki pozyskiwania mogą nadal działać dobrze. Wydajność zależy od rozmiaru klastra, dostępnych zasobów i ilości skrzyżowania z istniejącymi danymi.

  • Liczba zmaterializowanych widoków w klastrze: Powyższe zagadnienia dotyczą każdego zmaterializowanego widoku zdefiniowanego w klastrze. Każdy widok używa własnych zasobów, a wiele widoków konkuruje ze sobą nawzajem na dostępnych zasobach. Chociaż w klastrze nie ma ustalonych limitów liczby zmaterializowanych widoków, klaster może nie być w stanie obsłużyć wszystkich zmaterializowanych widoków, jeśli istnieje wiele zdefiniowanych. Zasady pojemności można dostosować, jeśli w klastrze istnieje więcej niż jeden zmaterializowany widok. Zwiększ wartość ClusterMinimumConcurrentOperations w zasadach, aby jednocześnie uruchamiać bardziej zmaterializowane widoki.

  • Zmaterializowana definicja widoku: zmaterializowana definicja widoku musi być zdefiniowana zgodnie z najlepszymi rozwiązaniami dotyczącymi zapytań w celu uzyskania najlepszej wydajności zapytań. Aby uzyskać więcej informacji, zobacz tworzenie porad dotyczących wydajności poleceń.

Zmaterializowany widok w zmaterializowanym widoku

Zmaterializowany widok można utworzyć za pośrednictwem innego zmaterializowanego widoku, jeśli zmaterializowany widok źródłowy jest widokiem deduplikacji. W szczególności agregacja zmaterializowanego widoku źródłowego musi być take_any(*) w celu deduplikacji rekordów źródłowych. Drugi zmaterializowany widok może używać dowolnych obsługiwanych funkcji agregacji. Aby uzyskać szczegółowe informacje na temat tworzenia zmaterializowanego widoku w zmaterializowanym widoku, zobacz .create materialized-view polecenie .

Porada

Podczas wykonywania zapytań dotyczących zmaterializowanego widoku zdefiniowanego w innym zmaterializowanym widoku zalecamy wykonywanie zapytań dotyczących zmaterializowanej materialized_view() części tylko przy użyciu funkcji . Wykonywanie zapytań względem całego widoku nie jest wydajne, gdy oba widoki nie są w pełni zmaterializowane. Aby uzyskać więcej informacji, zobacz zmaterializowane zapytania dotyczące widoków.

Zawartość pokrewna