Wzorzec zmaterializowanego widoku

Generuj widoki z danymi wstępnie załadowanymi dla danych w co najmniej jednym repozytorium danych, gdy dane nie są w formacie odpowiednim do wymaganych operacji zapytań. Takie podejście może obsługiwać wydajne wykonywanie zapytań i wyodrębnianie danych oraz poprawiać wydajność aplikacji.

Kontekst i problem

Podczas przechowywania danych deweloperzy i administratorzy danych często ustalają priorytety sposobu przechowywania danych, a nie sposobu ich odczytywania. Wybrany format magazynu zwykle odzwierciedla format danych, wymagania dotyczące zarządzania rozmiarem danych i integralnością danych oraz rodzajem używanego magazynu. Na przykład w przypadku korzystania z magazynu dokumentów NoSQL często dane są reprezentowane jako seria agregacji, z których każda zawiera wszystkie informacje dla tej jednostki.

Jednak takie podejście może mieć negatywny wpływ na zapytania. Gdy zapytanie wymaga tylko podzbioru danych z niektórych jednostek, takich jak podsumowanie zamówień dla wielu klientów bez wszystkich szczegółów zamówień, musi wyodrębnić wszystkie dane odpowiednich jednostek w celu uzyskania wymaganych informacji.

Dodawanie indeksów lub ponowne kształtowanie zapytań w czasie odczytu nie zawsze rozwiązuje tę nieefektywność. Wielu systemów przechowywania danych nie można ponownie zaindeksować pod kątem dowolnych wzorców odczytu bez pogorszenia wydajności zapisu. Agregacja między jednostkami pozostaje kosztowna w czasie wykonywania zapytania. Niektóre sklepy celowo mają ograniczoną obsługę zapytań. Ze względu na te ograniczenia optymalizacja ścieżki odczytu w samym magazynie źródłowym jest często niewystarczająca.

Rozwiązanie

Aby zapewnić wydajną obsługę zapytań, typowym rozwiązaniem jest wygenerowanie z wyprzedzeniem widoku, który zmaterializuje dane w formacie dostosowanym do wymaganego zestawu wyników. Wzorzec zmaterializowanego widoku opisuje generowanie wstępnie wypełnionych widoków danych w środowiskach, gdzie źródło danych nie ma formatu odpowiedniego do wykonywania zapytań, gdzie generowanie odpowiednich zapytań jest trudne lub gdzie wydajność zapytań jest niska z powodu rodzaju danych lub magazynu danych.

W tym wzorcu zmaterializowany widok jest modelem odczytu lub projekcją, która utrwala dane pochodzące z co najmniej jednego magazynu źródłowego. Dedykowany składnik aplikacji lub potok danych może obsługiwać projekcję, w tym między granicami sklepu. Odbiorcy zapytań traktują projekcję jako obiekt tylko do odczytu. Ta koncepcja architektoniczna jest szersza niż natywny dla bazy danych obiekt widoku zmaterializowanego, który silnik bazy danych definiuje, przechowuje i odświeża zgodnie z własnymi ograniczeniami funkcjonalnymi.

Te zmaterializowane widoki, które zawierają tylko dane wymagane przez zapytanie, umożliwiają aplikacjom szybkie uzyskiwanie potrzebnych informacji. Oprócz dołączania tabel lub łączenia jednostek danych, zmaterializowane widoki mogą obejmować bieżące wartości kolumn obliczeniowych lub elementów danych, wyniki łączenia wartości lub wykonania przekształceń elementów danych oraz wartości określone jako część zapytania. Zmaterializowany widok można nawet zoptymalizować pod kątem pojedynczego zapytania.

Kluczowym punktem jest to, że zmaterializowany widok i zawarte w nim dane są całkowicie jednorazowe, ponieważ można je całkowicie odtworzyć z źródłowych magazynów danych. Użytkownicy zapytań nie aktualizują widoku bezpośrednio. Zamiast tego dedykowany komponent, potok danych lub silnik bazy danych utrzymuje ją, więc jest to wyspecjalizowana pamięć podręczna.

Gdy dane źródłowe widoku zmienią się, widok musi zostać zaktualizowany, aby uwzględnić nowe informacje. Tę aktualizację można zaplanować automatycznie lub gdy system wykryje zmianę oryginalnych danych. W niektórych przypadkach może być konieczne ponowne wygenerowanie widoku ręcznie. Na poniższej ilustracji przedstawiono przykład użycia wzorca zmaterializowanego widoku.

Diagram przedstawiający wzorzec widoku zmaterializowanego. Magazyny danych źródłowych stanowią dane wejściowe dla procesu generowania widoku zmaterializowanego, który tworzy i wypełnia widok zmaterializowany, odpytywany przez aplikacje bezpośrednio zamiast magazynów źródłowych.

Problemy i zagadnienia

Podczas podejmowania decyzji o zaimplementowaniu tego wzorca należy wziąć pod uwagę następujące kwestie:

• Wyświetl strategię odświeżania. W idealnym przypadku widok jest ponownie wygenerowany w odpowiedzi na zdarzenie wskazujące zmianę danych źródłowych, chociaż takie podejście może prowadzić do nadmiernego obciążenia, jeśli dane źródłowe szybko się zmieniają. W celu ponownego wygenerowania widoku można również rozważyć użycie zaplanowanego zadania, wyzwalacza zewnętrznego lub akcji ręcznej.

• Sposób odświeżania. Ustal, czy implementacja wykonuje pełną ponowną kompilację, czy stosuje zmiany przyrostowo. Należy również zdecydować, czy operacje odświeżania blokują odczyty.

  Decyzje te określają, czy zapytania zwracają potencjalnie nieaktualne zmaterializowane dane, łączą zmaterializowane dane z nieprzetworzonymi zmianami w danych źródłowych, aby zwrócić aktualne wyniki, czy nadal udostępniają ostatnią kompletną wersję aż do zakończenia odświeżania.

• Odśwież niezawodność sygnału. Jeśli sygnał aktywacji, który wyzwala ponowne generowanie widoku, zostanie utracony lub opóźniony — na przykład pominięte zdarzenie zestawienia zmian lub zaplanowane zadanie nie powiodło się — widok w trybie dyskretnym obsługuje nieaktualne wyniki. Monitoruj aktualność odświeżania i generuj alert, gdy wiek widoku przekracza dopuszczalne okno nieaktualności.

• Odśwież koszt zasobów obliczeniowych. Ponowne generowanie widoku zużywa zasoby obliczeniowe proporcjonalne do ilości danych źródłowych i złożoności przekształceń. W przypadku odświeżania opartego na zdarzeniach na szybko zmieniających się danych źródłowych lub pełnego ponownego kompilowania dużych widoków analitycznych koszt obliczeniowy odświeżania może być znaczącym czynnikiem kosztowym. Określ odpowiedni rozmiar częstotliwości odświeżania i zakresu, aby zrównoważyć świeżość danych względem wydatków obliczeniowych.

• Zależność określania źródła zdarzeń. W niektórych systemach, na przykład gdy stosuje się wzorzec Event Sourcing do utrzymywania repozytorium zawierającego wyłącznie zdarzenia, które zmieniły dane, widoki zmaterializowane są zwykle niezbędne. Wstępne wypełnianie widoków poprzez analizę wszystkich zdarzeń w celu określenia bieżącego stanu może być jedynym sposobem uzyskania informacji z repozytorium zdarzeń. Jeśli nie używasz pozyskiwania zdarzeń, rozważ, czy widok zmaterializowany będzie pomocny. Zmaterializowane widoki są zwykle dostosowane do jednej lub niewielkiej liczby zapytań. W przypadku użycia wielu zapytań zmaterializowane widoki mogą spowodować powstanie niemożliwych do zaakceptowania wymagań dotyczących pojemności magazynu oraz kosztów magazynowania.

• Spójność danych. Rozważ wpływ na spójność danych podczas generowania widoku i podczas aktualizowania widoku, jeśli ten proces występuje zgodnie z harmonogramem. Jeśli dane źródłowe zmieniają się w tym samym czasie co widok, kopia danych w widoku nie jest w pełni spójna z oryginalnymi danymi. Maksymalne okno nieaktualności jest bezpośrednią konsekwencją interwału odświeżania lub opóźnienia przetwarzania zdarzeń, dlatego przed wybraniem między sterowanymi zdarzeniami, zaplanowanym lub ręcznym odświeżaniem należy zdefiniować akceptowalną nieaktualność.

• Wyświetl lokalizację magazynu. Widok nie musi być umiejscowiony w tym samym magazynie lub partycji co dane źródłowe. Można łączyć podzbiory z kilku różnych partycji.

• Odbudowa po utracie. Widok można odbudować w przypadku utraty. W związku z tym, jeśli widok jest przejściowy i jest używany tylko do poprawy wydajności zapytań, odzwierciedlając bieżący stan danych lub zwiększając skalowalność, można przechowywać go w pamięci podręcznej lub w mniej niezawodnej lokalizacji.

  Jeśli jednak sam proces odświeżania zakończy się niepowodzeniem w trakcie — na przykład gdy ulegnie awarii zaplanowane zadanie regeneracji — ustal, czy system powinien udostępniać poprzedni pełny widok, częściowo zaktualizowany widok, czy też nie udostępniać żadnego widoku do czasu pomyślnego zakończenia regeneracji.

  Najbezpieczniejszym podejściem jest zazwyczaj publikacja atomowa lub zastąpienie wersjonowane, w ramach których obciążenie robocze nadal korzysta z ostatniego kompletnego widoku, podczas gdy tworzysz i weryfikujesz nowy widok. Zamień na nowy widok po zakończeniu walidacji.

• Kolumny obliczeniowe. Podczas definiowania zmaterializowanego widoku zmaksymalizuj swoją wartość, dodając elementy danych lub kolumny na podstawie obliczeń lub przekształcania istniejących elementów danych, wartości przekazanych w zapytaniu lub kombinacji tych wartości, jeśli są one odpowiednie.

• Wyświetl indeksowanie. Jeśli mechanizm magazynowania obsługuje indeksowanie zmaterializowanego widoku, zastanów się nad jego użyciem w celu dalszego zwiększenia wydajności. Wiele relacyjnych baz danych obsługuje indeksowanie widoków. Jednak utrzymywanie indeksu dla widoku zwiększa obciążenie operacji zapisu podczas każdego cyklu odświeżania, dlatego należy wyważyć korzyści w zakresie wydajności odczytu względem dodatkowego czasu odświeżania i kosztu zasobów obliczeniowych.

• Kontrola dostępu w widokach. Gdy zmaterializowany widok jest używany do ograniczania, które podzestawy danych są widoczne dla niektórych konsumentów, takich jak ze względów bezpieczeństwa lub prywatności, magazyn widoków musi wymuszać te same lub bardziej rygorystyczne mechanizmy kontroli dostępu co dane źródłowe. Potok odświeżania musi wykluczać niezamierzone kolumny lub wiersze, ponieważ widok, który przypadkowo zawiera dane poza zamierzonym zakresem, może uwidocznić chronione dane.

• Cykl życia danych w widokach. Zastosuj wymagania dotyczące przechowywania i usuwania danych źródłowych do każdego zmaterializowanego widoku. Rozpropaguj usunięcia i zaczernienia ze źródła w wymaganym terminie oraz uwzględnij każdy widok w monitorowaniu zgodności. Aby uzyskać więcej informacji, zobacz Zarządzanie danymi i punkty odniesienia zabezpieczeń za pomocą Microsoft Purview.

• Wyświetlanie zarządzania cyklem życia. Traktuj definicje widoków jako artefakty wdrożeniowe zarządzane w systemie kontroli wersji oraz za pomocą potoków CI/CD, zwłaszcza gdy widoki są definiowane deklaratywnie. Bez zarządzania cyklem życia definicje widoków mogą dryfować między środowiskami, powodując niespójne zachowanie zapytań w środowisku deweloperskim, przejściowym i produkcyjnym.

Kiedy należy używać tego wzorca

Użyj tego wzorca, gdy:

• Musisz utworzyć widoki na danych, które trudno bezpośrednio odpytywać, albo w przypadku których zapytania muszą być bardzo złożone, aby wydobyć dane przechowywane w sposób znormalizowany, półustrukturyzowany lub nieustrukturyzowany.
• Chcesz utworzyć projekcje buforowane w pamięci podręcznej, które można odbudować lub które są przejściowe, aby zwiększyć wydajność zapytań albo przygotować dane używane do tworzenia obiektów transferu danych na potrzeby interfejsu użytkownika, raportu lub widoku.
• Należy obsługiwać scenariusze pracy z połączeniem sporadycznym lub bez połączenia, w których połączenie z magazynem danych nie zawsze jest dostępne. W tym przypadku można buforować widok lokalnie.
• Chcesz uprościć zapytania i uwidocznić dane do eksperymentowania w sposób, który nie wymaga znajomości formatu danych źródłowych. Na przykład przez dołączenie różnych tabel do co najmniej jednej bazy danych lub co najmniej jednej domeny w magazynach NoSQL, a następnie sformatowanie danych na potrzeby ewentualnego użycia.
• Chcesz zapewnić dostęp do określonych podzbiorów danych źródłowych, które ze względów bezpieczeństwa lub prywatności nie powinny być ogólnie dostępne, otwarte na modyfikacje ani w pełni widoczne dla użytkowników.
• Chcesz połączyć różne magazyny danych, aby skorzystać z ich indywidualnych możliwości. Na przykład możesz użyć magazynu w chmurze, który jest wydajny do zapisywania jako magazynu danych referencyjnych, oraz relacyjnej bazy danych, która oferuje dobre zapytania i wydajność odczytu do przechowywania zmaterializowanych widoków.
• Gdy używasz mikrousług, zadbaj o to, aby były luźno powiązane, w tym również w warstwie przechowywania danych. Zmaterializowane widoki mogą pomóc w konsolidacji danych z usług. Jeśli zmaterializowane widoki nie są odpowiednie w architekturze mikrousług lub konkretnym scenariuszu, rozważ zastosowanie dobrze zdefiniowanych granic, które są zgodne z projektem opartym na domenie (DDD) i agregują swoje dane na żądanie.

Ten wzorzec może nie być odpowiedni w następujących przypadkach:

• Wykonywanie zapytań dotyczących źródła danych jest proste i łatwe.
• Źródło danych zmienia się bardzo szybko lub można uzyskać dostęp do niego bez korzystania z widoku. W takich przypadkach należy unikać nakładu pracy związanego z przetwarzaniem tworzenia widoków.
• Spójność ma wysoki priorytet. Widoki nie zawsze mogą być w pełni spójne z oryginalnymi danymi.

Projektowanie obciążenia pracy

Architekt powinien ocenić, w jaki sposób wzorzec zmaterializowanego widoku może być używany w projekcie obciążenia, aby sprostać celom i zasadom opisanym w filarach platformy Azure Well-Architected Framework. Przykład:

Filar	Jak ten wzorzec obsługuje cele filaru
Efektywność wydajności pomaga wydajnie sprostać wymaganiom dzięki optymalizacjom skalowania, danych i kodu.	Zmaterializowane widoki przechowują wyniki złożonych obliczeń lub zapytań, co eliminuje konieczność ponownego obliczania wyników przez silnik bazy danych lub klienta dla każdego żądania. Ten projekt zmniejsza ogólne zużycie zasobów. - PE:08 Wydajność danych

Jeśli ten wzorzec wprowadza kompromisy w ramach filaru, rozważ je przed celami innych filarów.

Example

Rozważmy aplikację sprzedażową, która przechowuje jednostki Order, OrderItem i Customer w Azure Table Storage. Zamówienia są partycjonowane według identyfikatora klienta, elementów zamówienia według identyfikatora zamówienia i klientów według regionu. Klucze te obsługują wzorce dostępu operacyjnego aplikacji, ale raport sprzedaży pogrupowany według produktu musi odczytywać dane między partycjami i łączyć je w kodzie aplikacji.

Na poniższej ilustracji przedstawiono zmaterializowany widok, który przechowuje łączną wartość sprzedaży i liczbę odrębnych klientów zakupów dla każdego produktu w kategorii Elektronika. Wiersze źródłowe i wartości podsumowania mają charakter ilustracyjny i nie stanowią pełnego zestawu danych wejściowych dla przedstawionych sum końcowych.

Po lewej stronie są wyświetlane trzy tabele: Zamówienie u góry, OrderItem w środku i Customer w dolnej części. Ich kluczami partycji są odpowiednio identyfikator klienta, identyfikator zamówienia i region. Duża strzałka prowadzi od tabel źródłowych do tabeli widoku zmaterializowanego po prawej stronie. W tym widoku użyto kategorii produktu jako klucza partycji oraz identyfikatora produktu jako klucza wiersza. Każdy wiersz zawiera nazwę produktu, łączną wartość sprzedaży i liczbę klientów. Zilustrowany widok zawiera dwa wiersze produktów w partycji Electronics.

Proces w tle odczytuje wymagane jednostki źródłowe, kojarzy elementy zamówień ze swoimi zamówieniami i klientami oraz agreguje sprzedaż według produktu. Zlicza każdego klienta tylko raz dla każdego produktu, nawet jeśli ten klient ma wiele zamówień lub pozycji zamówienia. Proces zapisuje wyniki w oddzielnej tabeli podsumowania z kategorią produktu jako PartitionKey i identyfikatorem produktu jako RowKey. Ta tabela podsumowania to projekcja utrzymywana przez aplikację, a nie natywny widok zmaterializowany w bazie danych.

Następnie pulpit nawigacyjny może wykonywać zapytania dotyczące partycji Electronics zamiast powtarzać operacje odczytu i agregacji między partycjami dla każdego żądania. Wyszukiwanie jednego produktu dostarcza oba klucze. Aby uzyskać wpływ tych kluczy na wydajność zapytań, zobacz Projektowanie pod kątem wykonywania zapytań.

Odśwież podsumowanie według harmonogramu, który mieści się w dopuszczalnym okresie nieaktualności raportu. Skompiluj i zweryfikuj nową wersję przed jej opublikowaniem, aby czytelnicy nadal używali poprzedniej pełnej wersji podczas ponownego kompilowania. Odświeżanie nadal wiąże się z kosztami międzypartycyjnego odczytu i agregacji, ale kolejne zapytania raportowe ponownie wykorzystują wynik. Zmiany źródłowe nie są widoczne, dopóki kolejne odświeżanie nie zostanie ich uwzględnione.

Następne kroki

• Tworzenie indeksowanych widoków opisuje sposób utrwalania wyników widoku obliczeniowego baz danych SQL przez utworzenie indeksu w widoku.
• Wzorce projektowe strumienia zmian w usłudze Azure Cosmos DB dla bazy NoSQL opisują, jak konsumenci strumienia zmian mogą utrzymywać widoki zmaterializowane.
• Zmaterializowane widoki — omówienie opisuje zmaterializowane widoki w Azure Data Explorer.
• Usługa Azure Managed Redis może buforować wcześniej obliczone wyniki zapytań jako warstwę zoptymalizowaną pod kątem odczytu przed trwałymi magazynami danych.
• Azure Table Storage może przechowywać wstępnie skompilowane dane widoku generowane przez logikę aplikacji lub proces w tle.

Powiązane zasoby

Podczas implementowania tego wzorca mogą być również istotne następujące wzorce:

• Wzorzec podziału odpowiedzialności polecenia i zapytania (CQRS). Służy do aktualizowania informacji w zmaterializowanym widoku poprzez reagowanie na zdarzenia pojawiające się, gdy zmieniają się wartości danych źródłowych.
• Wzorzec określania źródła zdarzeń. Użyj razem ze wzorcem CQRS, aby zachować informacje w zmaterializowanym widoku. Gdy wartości danych, na których opiera się widok zmaterializowany, ulegną zmianie, system może generować zdarzenia opisujące te zmiany i zapisywać je w magazynie zdarzeń.
• Wzorzec tabeli indeksowej Dane w zmaterializowanym widoku są zwykle organizowane według klucza podstawowego, ale zapytania mogą potrzebować informacji pobranych z tego widoku przez zbadanie danych w innych polach. Ten wzorzec służy do tworzenia indeksów pomocniczych w zestawach danych dla magazynów danych, które nie obsługują natywnych indeksów pomocniczych.