Generera förifyllda vyer över data i ett eller flera datalager när data inte har ett optimalt format för de frågeåtgärder som ska utföras. Det kan ge stöd för effektiva frågor och extrahering av data, och även förbättra programmets prestanda.
Kontext och problem
Vid datalagring fokuserar utvecklare och dataadministratörer ofta på hur data lagras och inte på hur informationen läses. Det valda lagringsformatet är ofta nära relaterat till dataformatet, kraven för hantering av datastorlek och dataintegritet, samt vilken typ av lagring som används. När du till exempel använder NoSQL-dokumentarkivet visas dina data ofta som en serie samlingar, där varje samling innehåller all information för den entiteten.
Detta kan emellertid ha en negativ inverkan på frågor. När en fråga endast behöver en delmängd data från vissa enheter, till exempel en ordersammanfattning för flera kunder, utan all orderinformation, så måste alla data för de relevanta entiteterna extraheras för att det ska gå att få fram den information som krävs.
Lösning
En vanlig lösning för att effektivisera frågeprocessen är att i förväg generera en vy som materialiserar data i ett format som passar den resultatuppsättning som krävs. Mönstret för den materialiserade vyn beskriver generering av förifyllda datavyer i miljöer där datakällan inte är i ett lämpligt format för frågor, där det är svårt att generera en lämplig fråga eller där frågeprestandan är dålig på grund av datautformningen eller utformningen av datalagret.
De här materialiserade vyerna, som endast innehåller data som krävs av en fråga, gör det möjligt för programmen att snabbt få den information som de behöver. Utöver funktioner för att koppla samman tabeller och kombinera dataentiteter kan materialiserade vyer innehålla de aktuella värdena för beräknade kolumner eller dataobjekt, resultatet av kombinerade värden eller transformeringskörningar på dataobjekten och värden som anges som en del av frågan. En materialiserad vy kan även optimeras för endast en enskild fråga.
En viktig aspekt är att en materialiserad vy och de data som den innehåller är helt disponibla eftersom de kan återbyggas fullständigt från källdatalagren. En materialiserad vy uppdateras aldrig direkt av ett program. Det är därför ett specialiserat cacheminne.
När vyns källdata ändras måste du uppdatera vyn så att den innefattar den nya informationen. Du kan schemalägga detta så att det sker automatiskt eller när systemet identifierar en ändring av ursprungliga data. Ibland kan det vara nödvändigt att återskapa vyn manuellt. Figuren visar ett exempel på hur mönstret för den materialiserade vyn kan användas.
Problem och överväganden
Tänk på följande när du bestämmer hur du ska implementera mönstret:
Hur och när vyn uppdateras. Det bästa är om den återskapas som ett svar på en händelse som indikerar en ändring av källdata, även om det kan leda till höga omkostnader om dessa källdata ändras ofta. Du kan även överväga att använda en schemalagd uppgift, en extern utlösare eller en manuell åtgärd för att återskapa vyn.
Materialiserade vyer är nödvändiga i vissa system, som till exempel när du använder mönstret Händelsekällor för att ha ett arkiv för endast de händelser som användes för att ändra data. Det enda sättet att få information från händelsearkivet kan vara att fylla i vyer i förväg genom att undersöka alla händelser och fastställa det aktuella läget. Om du inte använder Händelsekällor bör du överväga om en materialiserad vy är till hjälp eller inte. Materialiserade vyer brukar vara skräddarsydda specifikt för en eller ett litet antal frågor. Om många frågor används kan materialiserade vyer leda till oacceptabla krav på lagringskapacitet och lagringskostnader.
Fundera över effekten på datakonsekvensen när du genererar vyn och när du uppdaterar vyn om det utförs enligt ett schema. Kopierade data i vyn stämmer inte helt överens med dina ursprungliga data om källdata ändras när vyn genereras.
Fundera över var du ska lagra vyn. Den behöver inte finnas i samma arkiv eller partition som dina ursprungliga data. Den kan vara en delmängd från ett antal olika kombinerade partitioner.
En vy kan återskapas om den förloras. Om vyn är tillfällig och endast används för att förbättra frågeprestanda genom att visa det aktuella datatillståndet, eller endast används för att förbättra skalbarheten, så kan den på grund av detta lagras i ett cacheminne eller på en mindre tillförlitlig plats.
När du definierar en materialiserad vy kan du maximera dess värde genom att lägga till dataobjekt eller kolumner utifrån en beräkning eller omvandling av befintliga dataobjekt, utifrån värden som skickas i frågan eller utifrån kombinationer av dessa värden när det är lämpligt.
Överväg att indexera den materialiserade vyn för att öka prestanda ytterligare om detta stöds av lagringsmekanismen. De flesta relationsdatabaser har stöd för indexering för vyer och det har även stordatalösningar som baseras på Apache Hadoop.
När du ska använda det här mönstret
Det här mönstret är användbart om du vill göra följande:
- Skapa materialiserade vyer för data som är svåra att fråga direkt, eller där frågorna måste vara mycket komplexa för att extrahera data som lagras på ett normaliserat, delvis strukturerat eller ostrukturerat sätt.
- Skapa tillfälliga vyer som avsevärt kan förbättra frågeprestanda eller kan fungera direkt som källvyer eller dataöverföringsobjekt för användargränssnittet, för rapportering eller för visning.
- Få stöd för scenarier med tidvis anslutning eller frånkoppling där en anslutning till datalagret inte alltid är tillgänglig. Vyn kan cachelagras lokalt i det här fallet.
- Förenkla frågor och exponera data för experimentering på ett sätt som inte kräver kunskaper om källdataformatet. Detta görs till exempel genom att koppla samman olika tabeller i en eller flera databaser eller en eller flera domäner på NoSQL-lagringsplatser och sedan formatera informationen för att anpassa den till dess slutliga användning.
- Tillhandahålla åtkomst till specifika delmängder av källdata som inte ska vara allmänt tillgängliga, redigerbara eller visas helt för användarna på grund av säkerhets- eller sekretesshänsyn.
- Sammankoppla olika datalager för att utnyttja deras enskilda funktioner. Du kanske till exempel vill använda ett molnlager som är effektivt för skrivningar som referensdatalager och en relationsdatabas som erbjuder bra fråge- och läsprestanda för de materialiserade vyerna.
- När du använder mikrotjänster rekommenderar vi att du håller dem löst kopplade, inklusive deras datalagring. Därför kan materialiserade vyer hjälpa dig att konsolidera data från dina tjänster. Om materialiserade vyer inte är lämpliga i din mikrotjänstarkitektur eller ett specifikt scenario bör du överväga att ha väldefinierade gränser som överensstämmer med domändriven design (DDD) och aggregerar deras data när så begärs.
Det här mönstret är inte användbart i följande situationer:
- Datakällan är enkel och lätt att fråga.
- Källdatan ändras mycket snabbt eller kan nås utan att använda en vy. I de här fallen bör du undvika omkostnaderna för den bearbetning som tillkommer när vyer skapas.
- Konsekvens prioriteras högt. Vyerna kanske inte alltid överensstämmer helt med dina ursprungsdata.
Design av arbetsbelastning
En arkitekt bör utvärdera hur mönstret Materialiserad vy kan användas i arbetsbelastningens design för att uppfylla de mål och principer som beskrivs i grundpelarna i Azure Well-Architected Framework. Till exempel:
| Grundpelare | Så här stöder det här mönstret pelarmål |
|---|---|
| Prestandaeffektivitet hjälper din arbetsbelastning att effektivt uppfylla kraven genom optimeringar inom skalning, data och kod. | De materialiserade vyerna lagrar resultatet av komplexa beräkningar eller frågor utan att databasmotorn eller klienten behöver beräknas om för varje begäran. Den här designen minskar den totala resursförbrukningen. - PE:08 Dataprestanda |
Som med alla designbeslut bör du överväga eventuella kompromisser mot målen för de andra pelarna som kan införas med det här mönstret.
Exempel
Följande figur visar ett exempel på hur du använder mönstret för materialiserad vy för att generera en försäljningssammanfattning. Data i tabellerna Order, OrderItem och Customer i olika partitioner i ett Azure-lagringskonto kombineras för att generera en vy som innehåller de totala försäljningssiffrorna för varje produkt i kategorin Electronics tillsammans med antalet kunder som gjort inköp av varje objekt.
Det krävs komplexa frågor för att skapa den här materialiserade vyn. Men genom att exponera frågeresultatet som en materialiserad vy kan användarna enkelt få resultaten och använda dem direkt, eller lägga till dem i en annan fråga. Det är sannolikt att vyn kommer att användas i ett rapporteringssystem eller en instrumentpanel och den kan uppdateras enligt ett schema, till exempel varje vecka.
Även om det här exemplet använder Azure-tabelllagring ger många hanteringssystem för relationsdatabaser också inbyggt stöd för materialiserade vyer.
Nästa steg
- Datakonsekvensprimer. Sammanfattningen i en materialiserad vy måste bibehållas så att den visar de underliggande datavärdena. När datavärdena ändras är det inte alltid så praktiskt att uppdatera dina sammanfattningsdata i realtid. Du kan istället behöva använda en konsekvent metod. Sammanfattar problem med att bibehålla konsekvens över distribuerade data och beskriver fördelar och nackdelar med olika konsekvensmodeller.
Relaterade resurser
Följande mönster kan också vara relevanta när du implementerar det här mönstret:
- CQRS-mönster (Command and Query Responsibility Segregation). Använd detta för att uppdatera informationen i en materialiserad vy genom att svara på händelser som inträffar när de underliggande datavärdena ändras.
- Mönstret Händelsekällor. Använd detta tillsammans med CQRS-mönster för att bibehålla informationen i en materialiserad vy. När de datavärden som en materialiserad vy baseras på ändras så kan systemet aktivera händelser som beskriver dessa ändringar och spara dem i ett händelsearkiv.
- Indextabellmönster. Data i en materialiserad vy är vanligtvis organiserade efter en primär nyckel, men frågor kan behöva hämta information från den här vyn genom att undersöka data i andra fält. Använd detta för att skapa sekundärindex över datamängder för datalager som inte stöder interna sekundärindex.