Model materializovaného zobrazení

Vygenerujte předem vyplněná zobrazení nad daty v jednom nebo několika úložištích dat, pokud nejsou data ideálně naformátovaná pro požadované operace dotazů. Tento přístup může podporovat efektivní dotazování a extrakci dat a zlepšit výkon aplikace.

Kontext a problém

Při ukládání dat vývojáři a správci dat často upřednostňují způsob ukládání dat místo toho, jak se čtou. Zvolený formát úložiště obvykle odráží formát dat, požadavky na správu velikosti dat a integrity dat a druh používaného úložiště. Když například použijete úložiště dokumentů NoSQL, často představujete data jako řadu agregací, z nichž každá obsahuje všechny informace pro danou entitu.

Tento přístup ale může mít negativní vliv na dotazy. Když dotaz potřebuje pouze podmnožinu dat z některých entit, jako je například souhrn objednávek pro několik zákazníků bez všech podrobností každé objednávky, musí se extrahovat všechna data příslušných entit, aby bylo možné požadované informace získat.

Při přidávání indexů nebo přetváření dotazů v době čtení se tato neefektivita nevyřeší vždy. Řada úložišť se nedá znovu indexovat pro vzory libovolného čtení, aniž by to mělo vliv na výkon zápisu. Agregace napříč entitou zůstává v době dotazu náročná. Některé obchody mají omezené možnosti dotazů podle návrhu. Kvůli těmto omezením není optimalizace cesty ke čtení ve zdrojovém úložišti často dostatečná.

Solution

Pro podporu efektivního dotazování je běžným řešením vygenerovat předem zobrazení, které materializuje data ve formátu vhodném pro požadovanou sadu výsledků. Model materializovaného zobrazení popisuje generování předem vyplněných zobrazení dat v prostředích, ve kterých zdrojová data nejsou vhodným formátem pro dotazování, generování vhodného dotazu je obtížné nebo výkon dotazu je vzhledem k povaze dat nebo úložiště dat nízký.

V tomto modelu je materializované zobrazení model čtení nebo projekce, která uchovává data odvozená z jednoho nebo více zdrojových úložišť. Vyhrazená komponenta aplikace nebo datová pipeline může udržovat projekci, a to i napříč hranicemi úložišť. Klienti dotazů považují projekci za pouze pro čtení. Tento architektonický koncept je širší než objekt materializovaného pohledu nativní pro databázi, který databázový stroj definuje, ukládá a obnovuje podle omezení svých funkcí.

Tato materializovaná zobrazení, která obsahují pouze data požadovaná dotazem, umožňují aplikacím rychle získat potřebné informace. Mimo spojování tabulek nebo kombinování datových entit mohou materializovaná zobrazení obsahovat aktuální hodnoty počítaných sloupců nebo datových položek, výsledky kombinování hodnot nebo provádění transformací na datových položkách a hodnoty zadané jako část dotazu. Materializované zobrazení lze dokonce optimalizovat pro jeden dotaz.

Klíčovým bodem je, že materializované zobrazení a data, která obsahuje, jsou zcela uvolnitelné, protože je lze zcela znovu vytvořit ze zdrojových úložišť dat. Příjemci dotazů neaktualizují zobrazení přímo. Místo toho ji udržuje vyhrazená komponenta, datová pipeline nebo databázový engine, takže jde o specializovanou mezipaměť.

Když se zdrojová data zobrazení změní, musí se zobrazení aktualizovat, aby obsahovalo nové informace. Tuto aktualizaci můžete naplánovat tak, aby se stala automaticky nebo když systém zjistí změnu původních dat. V některých případech může být potřeba zobrazení ručně znovu vygenerovat. Následující obrázek znázorňuje příklad použití modelu materializovaného zobrazení.

Diagram znázorňující model materializovaného zobrazení Zdrojová datová úložiště jsou vstupem do procesu generování materializovaného pohledu, který tento pohled naplní daty a na který se aplikace dotazují přímo namísto přímého dotazování zdrojových úložišť.

Problémy a důležité informace

Při rozhodování o implementaci tohoto modelu zvažte následující body:

• Zobrazit strategii aktualizace V ideálním případě se zobrazení znovu vygeneruje v reakci na událost označující změnu zdrojových dat, i když tento přístup může vést k nadměrné režii, pokud se zdrojová data rychle změní. Další možností pro vygenerování nového zobrazení je zvážit použití plánované úlohy, externí aktivační události nebo manuální akce.

• Chování aktualizace Určete, zda implementace provádí úplné opětovné sestavení nebo aplikuje změny přírůstkově. Musíte se také rozhodnout, zda operace aktualizace blokují čtení.

  Tato rozhodnutí určují, jestli dotazy vrací potenciálně zastaralá materializovaná data, kombinují materializovaná data s nezpracovanými zdrojovými změnami, aby vrátily aktuální výsledky, nebo aby pokračovaly v poskytování poslední úplné verze, dokud se aktualizace nedokončí.

• Aktualizujte spolehlivost signálu. Pokud se aktivační signál, který spouští regeneraci zobrazení, ztratí nebo opozdí – například kvůli vynechané události ze streamu změn nebo neúspěšné naplánované úloze – zobrazení tiše vrací neaktuální výsledky. Sledujte aktuálnost obnovení a upozorněte, když stáří zobrazení překročí povolenou dobu neaktuálnosti.

• Aktualizujte náklady na výpočetní prostředky. Opětovné vygenerování zobrazení využívá výpočetní prostředky úměrné objemu zdrojových dat a složitosti transformací. U aktualizace řízené událostmi při rychlé změně zdrojových dat nebo při úplném opětovném sestavení velkých analytických zobrazení můžou být náklady na výpočetní výkon aktualizace významným nákladovým faktorem. Nastavení správné velikosti frekvence aktualizace a rozsahu pro vyvážení aktuálnosti dat oproti útratě výpočetních prostředků

• Závislost Event Sourcing V některých systémech, například když používáte vzor Event Sourcing k udržování úložiště obsahujícího pouze události, které změnily data, jsou materializované pohledy obvykle nezbytné. Jediný způsob, jak získat informace z úložiště událostí, může být předvyplnění zobrazení prověřením všech událostí pro určení aktuálního stavu. Pokud nepoužíváte Event Sourcing, zvažte, jestli je užitečné materializované zobrazení. Materializovaná zobrazení jsou obvykle přizpůsobená jednomu nebo malému počtu dotazů. Když se používá mnoho dotazů, materializovaná zobrazení mohou mít ve výsledku nepřijatelné požadavky na úložnou kapacitu a náklady úložiště.

• Konzistence dat Při generování zobrazení zvažte dopad na konzistenci dat a při aktualizaci zobrazení, pokud k tomuto procesu dochází podle plánu. Pokud se zdrojová data změní současně s vygenerovaným zobrazením, kopie dat v zobrazení není plně konzistentní s původními daty. Okno maximální neaktuálnosti je přímým důsledkem intervalu aktualizace nebo prodlevy zpracování událostí, proto před výběrem mezi událostmi řízenými, plánovanými nebo ručními aktualizacemi definujte přijatelnou neaktuálnost.

• Zobrazit umístění úložiště. Zobrazení se nemusí nacházet ve stejném úložišti nebo oddílu jako původní data. Můžete kombinovat podmnožiny z několika různých oddílů.

• Znovu sestavte při ztrátě. Zobrazení lze znovu vytvořit, pokud dojde ke ztrátě. Proto pokud je zobrazení přechodné a používá se pouze ke zlepšení výkonu dotazů tím, že odráží aktuální stav dat nebo ke zlepšení škálovatelnosti, můžete ho uložit do mezipaměti nebo do méně spolehlivého umístění.

  Pokud ale samotný proces aktualizace selže uprostřed – například pokud dojde k chybovému ukončení naplánované úlohy regenerace – určete, jestli má úloha sloužit předchozímu úplnému zobrazení, částečně aktualizované zobrazení nebo vůbec žádné zobrazení, dokud se regenerace nezdaří.

  Nejbezpečnějším přístupem je obvykle atomická publikace nebo nahrazení verzí, kde vaše úloha bude dál obsluhovat a používat poslední úplné zobrazení při sestavování a ověřování nového zobrazení. Po dokončení ověření se přehodí na nové zobrazení.

• Vypočítané sloupce. Při definování materializovaného zobrazení maximalizujte jeho hodnotu přidáním datových položek nebo sloupců na základě výpočtu nebo transformace existujících datových položek, hodnot předaných v dotazu nebo kombinací těchto hodnot, pokud je to vhodné.

• Zobrazení indexování Kde to mechanismus úložiště podporuje, zvažte indexování materializovaného zobrazení, abyste dále zvýšili výkon. Mnoho relačních databází podporuje indexování zobrazení. Údržba indexu u zobrazení však během každého cyklu aktualizace zvyšuje režii zápisu, takže je třeba zvážit přínosy vyššího výkonu při čtení oproti delší době aktualizace a vyšším nárokům na výpočetní prostředky.

• Řízení přístupu v zobrazeních Pokud se materializované zobrazení používá k omezení toho, která podmnožina dat jsou viditelná určitým uživatelům, například z důvodů zabezpečení nebo ochrany osobních údajů, musí úložiště zobrazení vynutit stejné nebo přísnější řízení přístupu jako zdrojová data. Kanál aktualizace musí vyloučit nezamýšlené sloupce nebo řádky, protože zobrazení, které omylem zahrnuje data mimo zamýšlený obor, může zpřístupnit chráněná data.

• Životní cyklus dat v zobrazeních U každého materializovaného zobrazení použijte požadavky na uchovávání a odstranění zdrojových dat. Propagujte odstranění a redakce ze zdroje v požadované lhůtě a zahrňte každé zobrazení do monitorování dodržování předpisů. Další informace najdete v tématu Zásady správného řízení dat a standardní hodnoty zabezpečení s Microsoft Purview.

• Zobrazení správy životního cyklu Považovat definice zobrazení za nasaditelné artefakty spravované prostřednictvím správy zdrojového kódu a kanálů CI/CD, zejména pokud jsou zobrazení definována deklarativním způsobem. Bez správy životního cyklu se mohou definice pohledů mezi prostředími rozcházet, což vede k nekonzistentnímu chování dotazů napříč vývojem, stagingem a produkcí.

Kdy použít tento vzor

Tento model použijte v těchto případech:

• Potřebujete vytvořit zobrazení dat, která se obtížně dotazují přímo, nebo pokud dotazy musí být velmi složité pro extrakci dat uložených v normalizovaném, částečně strukturovaném nebo nestrukturovaném způsobu.
• Chcete vytvořit znovu vytvořitelné nebo dočasné projekce v mezipaměti, které zlepšují výkon dotazů nebo upravují data používaná k vytváření objektů pro přenos dat pro uživatelské rozhraní, sestavu nebo zobrazení.
• Potřebujete podporovat občas připojené nebo odpojené scénáře, kdy připojení k úložišti dat není vždy dostupné. V tomto případě můžete zobrazení uložit do mezipaměti místně.
• Chcete zjednodušit dotazy a vystavit data pro experimentování způsobem, který nevyžaduje znalost zdrojového formátu dat. Například spojením různých tabulek v jedné či více databázích nebo jedné či více doménách v úložištích NoSQL a následným formátování dat, aby byla vhodná pro jejich případné použití.
• Chcete poskytnout přístup ke konkrétním podmnožinám zdrojových dat, která by z důvodů zabezpečení nebo ochrany osobních údajů neměla být obecně přístupná, otevřená pro úpravy nebo plně přístupná uživatelům.
• Chcete propojit různá datová úložiště, abyste mohli využít jejich specifické možnosti. Můžete například použít cloudové úložiště, které je efektivní pro zápis jako referenční úložiště dat, a relační databázi, která nabízí dobrý výkon dotazů a čtení pro uložení materializovaných zobrazení.
• Když používáte mikroslužby, nechte je volně svázané, včetně jejich úložiště dat. Materializovaná zobrazení vám můžou pomoct s konsolidací dat z vašich služeb. Pokud materializovaná zobrazení nejsou v architektuře mikroslužeb nebo konkrétním scénáři vhodná, zvažte, jestli máte dobře definované hranice, které odpovídají návrhu řízenému doménou (DDD) a agregují data na vyžádání.

Tento vzor nemusí být vhodný v těchto případech:

• Zdrojová data jsou jednoduchá a snadno dotazatelná.
• Zdrojová data se velmi rychle mění nebo je možné k nim získat přístup bez použití zobrazení. V těchto případech se vyhněte režijním nákladům na zpracování při vytváření zobrazení.
• Konzistence dat má vysokou prioritu. Zobrazení nemusí být vždy plně konzistentní s původními daty.

Návrh úloh

Architekt by měl vyhodnotit způsob použití modelu materializovaného zobrazení v návrhu úlohy k řešení cílů a principů zahrnutých v pilířích architektury Azure Well-Architected Framework. Příklady:

Pilíř	Jak tento model podporuje cíle pilíře
efektivita výkonu pomáhá vašim úlohám efektivně splňovat požadavky prostřednictvím optimalizací škálování, dat a kódu.	Materializovaná zobrazení ukládají výsledky složitých výpočtů nebo dotazů bez nutnosti překompilace databázového stroje nebo klienta pro každou žádost. Tento návrh snižuje celkovou spotřebu prostředků. - Datový výkon PE:08

Pokud tento model představuje kompromisy v rámci pilíře, zvažte je proti cílům ostatních pilířů.

Example

Představte si prodejní aplikaci, která ukládá entity Order, OrderItem a Customer v Azure Table Storage. Objednávky jsou rozdělené podle ID zákazníka, položek objednávek podle ID objednávky a zákazníků podle oblasti. Tyto klíče podporují provozní vzory přístupu aplikace, ale prodejní sestava seskupená podle produktu musí číst data napříč oddíly a spojovat je v aplikačním kódu.

Následující obrázek znázorňuje materializované zobrazení, které ukládá celkovou hodnotu prodeje a počet jedinečných nákupních zákazníků pro každý produkt v kategorii Elektronika. Zdrojové řádky a souhrnné hodnoty jsou ilustrativní, nikoli úplná vstupní datová sada pro zobrazené součty.

Vlevo se zobrazují tři tabulky: Order nahoře, OrderItem uprostřed a Customer dole. Jejich klíče oddílu jsou ID zákazníka, ID objednávky a oblast, v uvedeném pořadí. Velká šipka vede ze zdrojových tabulek na materializovanou tabulku zobrazení vpravo. Toto zobrazení používá kategorii produktu jako klíč oddílu a ID produktu jako klíč řádku. Každý řádek obsahuje název produktu, celkovou prodejní hodnotu a počet zákazníků. V ilustračním zobrazení jsou v sekci Elektronika dvě řádky produktů.

Proces na pozadí čte požadované zdrojové entity, přidruží položky objednávek ke svým objednávkám a zákazníkům a agreguje prodeje podle produktů. Každého zákazníka započítá pro každý produkt pouze jednou, i když má daný zákazník více objednávek nebo položek objednávky. Proces zapíše výsledky do samostatné souhrnné tabulky s kategorií produktů jako PartitionKey a ID produktu jako RowKey. Tato souhrnná tabulka je projekce udržovaná aplikací, nikoli zobrazení materializované nativní pro databázi.

Řídicí panel se pak může dotazovat na oddíl Electronics místo opakování čtení a agregace napříč oddíly pro každý požadavek. Vyhledávání pro jeden produkt poskytuje oba klíče. Informace o dopadech těchto klíčů na výkon dotazů najdete v tématu Návrh pro dotazování.

Aktualizujte souhrn v intervalu, který odpovídá přijatelné době zastaralosti sestavy. Před publikováním sestavujte a ověřte novou verzi, takže čtenáři budou během opětovného sestavení nadále používat předchozí úplnou verzi. Aktualizace stále způsobuje náklady na čtení a agregaci napříč oddíly, ale opakované dotazy sestav znovu používají výsledek. Změny zdroje se nezobrazují, dokud je následující aktualizace neobsahuje.

Další kroky

• Vytváření indexovaných zobrazení popisuje, jak můžou databáze SQL uchovávat vypočítané výsledky zobrazení vytvořením indexu v zobrazení.
• Vzory návrhu kanálu změn v Azure Cosmos DB pro NoSQL popisují, jak můžou spotřebitelé kanálu změn udržovat materializovaná zobrazení.
• Přehled materializovaných zobrazení popisuje materializovaná zobrazení v Azure Data Explorer.
• Azure Managed Redis může ukládat předem vypočítané výsledky dotazů do mezipaměti jako vrstvu optimalizovanou pro čtení před trvalými úložišti dat.
• Azure Table Storage může ukládat předem vypočítaná data zobrazení generovaná logikou aplikace nebo procesem na pozadí.

Související zdroje informací

Při implementaci tohoto modelu můžou být relevantní také následující vzory:

• Model dělení zodpovědnosti příkazů a dotazů (CQRS): používá se k aktualizaci informací v materializovaném zobrazení a funguje tak, že reaguje na události, ke kterým dochází, když se podkladové hodnoty dat mění.
• Vzorec Event Sourcing. Používejte spolu se vzorem CQRS k udržování informací v materializovaném zobrazení. Pokud jsou hodnoty dat materializovaného zobrazení založené na změně, systém může vyvolat události, které tyto změny popisují, a uložit je do úložiště událostí.
• Model tabulky indexů: data v materializovaném zobrazení se obvykle uspořádávají podle primárního klíče, ale dotazy mohou z tohoto zobrazení potřebovat načíst informace prozkoumáním dat v jiných polích. Tento model použijte k vytvoření sekundárních indexů nad datovými sadami pro úložiště dat, která nepodporují nativní sekundární indexy.