Zmaterializowane widoki

Dotyczy: ✅Microsoft Fabric✅Azure Data Explorer

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

• Aby zdecydować, czy zmaterializowane widoki są odpowiednie dla Ciebie, przejrzyj zmaterializowane przypadki użycia widoków.
• Zmaterializowane widoki mają pewne ograniczenia. Przed rozpoczęciem pracy z funkcją zapoznaj się z zagadnieniami dotyczącymi wydajności.
• W razie potrzeby rozważ użycie zasad aktualizacji. Aby uzyskać więcej informacji, zobacz zmaterializowane widoki a zasady aktualizacji.
• Monitoruj kondycję zmaterializowanych widoków na podstawie zaleceń w temacie Monitorowanie zmaterializowanych widoków.

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 jest zwykle lepsze 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 ( delta część), zawsze dostarczając najbardziej aktualne wyniki.

• Obniżenie kosztów: wykonywanie zapytań względem zmaterializowanego widoku zużywa mniej zasobów 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 według kombinacji grup agregacji.
• Delta — nowo pozyskane rekordy w tabeli źródłowej, które nie zostały jeszcze przetworzone.

Wykonywanie zapytań w zmaterializowanym widoku łączy zmaterializowaną część z częścią różnicową, zapewniając aktualny wynik zapytania agregacji. Proces materializacji offline pozyskuje nowe rekordy z różnicy do zmaterializowanej tabeli i aktualizuje istniejące rekordy. Jeśli przecięcie między różnicą a zmaterializowaną częścią jest duże, 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 problemów z takimi sytuacjami.

Zmaterializowane zapytania dotyczące widoków

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

• Wykonaj zapytanie względem 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. Zmaterializowana sekcja optymalizatora zapytań zawiera możliwe sposoby poprawy wydajności zapytań podczas wykonywania zapytań w całym 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ń dotyczących całego widoku.
  • Ta funkcja jest przydatna w scenariuszach, w których chcesz poświęcić pewną świeżość wydajności, na przykład w przypadku pulpitów nawigacyjnych telemetrii.

Napiwek

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 twojego przypadku użycia.

• Zmaterializowane widoki uczestniczą w zapytaniach obejmujących wiele zdarzeń 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("<serviceURL>").database('db').ViewName
  cluster("<serviceURL>").database('*').ViewName
  database('*').ViewName
  database('DB*').ViewName
  database('*').materialized_view('ViewName')
  database('DB*').materialized_view('ViewName')
  

  • Następujące przykłady nie zawierają rekordów z zmaterializowanych widoków:

  cluster("<serviceURL>").database('db').*
  database('*').View*
  search in (*)
  search * 
  

Zmaterializowany optymalizator zapytań widoku

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

• Wykonywanie zapytań dotyczących 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 należy pomisować zapytanie, jest oparta na liczbie rekordów w 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	Type	Opis
materialized_view_query_optimization_costbased_enabled	bool	Jeśli ustawiono 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ś przetasowanie zmaterializowanego zapytania widoku, a (opcjonalnie) podaj określone klucze do przetasowania. Zobacz przykłady poniżej.

ingestion_time() funkcja w kontekście zmaterializowanych widoków

funkcja ingestion_time() zwraca wartości null, jeśli są używane w kontekście zmaterializowanego widoku, jeśli wysyła zapytanie do całego widoku. Podczas wykonywania zapytań względem zmaterializowanej części widoku wartość zwracana zależy od typu zmaterializowanego widoku:

• W zmaterializowanych widokach, które obejmują pojedynczą arg_max()/arg_min()take_any()/agregację, ingestion_time() wartość jest równa ingestion_time() odpowiadającemu rekordowi w tabeli źródłowej.
• We wszystkich innych zmaterializowanych widokach wartość ingestion_time() jest w przybliżeniu czasem materializacji (zobacz , jak działają zmaterializowane widoki).

Przykłady

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

   ViewName
   

2. Wykonaj zapytanie o zmaterializowaną część widoku tylko niezależnie od tego, kiedy został 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 podstawie kolumny (podobnie jak w przypadku używania Id elementu hint.shufflekey=Id):

   set materialized_view_shuffle = dynamic([{"Name" : "ViewName", "Keys" : [ "Id" ] }]);
   ViewName
   

   • Przykład nr 2: mieszanie na podstawie wszystkich kluczy (podobnie jak w przypadku używania 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ą:

• Nakładaj się na zmaterializowane dane: podczas materializacji wszystkie nowe rekordy pozyskane do tabeli źródłowej od czasu przetworzenia i zmaterializowania 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 aktualizowanych rekordów (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ą być aktualizowane 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 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 bazy danych, dostępnych zasobów i ilości skrzyżowania z istniejącymi danymi.

• 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 create command performance tips (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 źródłowy zmaterializowany widok 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.

Napiwek

Podczas wykonywania zapytań względem 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 wykonywane, gdy oba widoki nie są w pełni zmaterializowane. Aby uzyskać więcej informacji, zobacz zmaterializowane zapytania dotyczące widoków.

Powiązana zawartość

• Zmaterializowane zasady widoków
• Ograniczenia i znane problemy dotyczące zmaterializowanych widoków
• Zmaterializowane przypadki użycia widoków
• Monitorowanie zmaterializowanych widoków
• .create materialized view
• .alter materialized-view
• {.disable | .enable} materialized-view