Vooraf ingevulde weergaven met de gegevens uit een of meer gegevensarchieven genereren wanneer de gegevens niet perfect zijn opgemaakt voor vereiste querybewerkingen. Dit kan helpen bij het efficiënt uitvoeren van query's en het extraheren van gegevens. Bovendien kunnen met dit patroon de prestaties van de toepassing worden verbeterd.
Context en probleem
Bij het opslaan van gegevens is de prioriteit van ontwikkelaars en gegevensbeheerders vaak de manier waarop gegevens worden opgeslagen en niet hoe deze worden gelezen. De gekozen opslagindeling is meestal nauw verweven met de indeling van de gegevens, de vereisten voor het beheren van de gegevensomvang en gegevensintegriteit en het soort archief dat wordt gebruikt. Als bijvoorbeeld het NoSQL-documentarchief wordt gebruikt, worden de gegevens vaak voorgesteld als een reeks combinaties, die elk alle gegevens voor die entiteit bevatten.
Dit kan echter een negatief effect op query's hebben. Wanneer een query voldoende heeft aan een subset van de gegevens uit sommige entiteiten, zoals een samenvatting van orders voor verschillende klanten zonder alle ordergegevens, moet de query toch alle gegevens voor de relevante entiteiten extraheren om over de vereiste gegevens te beschikken.
Oplossing
Een gangbare oplossing voor het ondersteunen van efficiënte query's is het vooraf genereren van een weergave die de gegevens bevat in een indeling die geschikt is voor de vereiste resultatenset. Het patroon Gerealiseerde weergave beschrijft het genereren van vooraf ingevulde weergaven van gegevens in omgevingen waar de brongegevens niet beschikbaar zijn in een indeling die geschikt is voor het uitvoeren van query's, waar het genereren van een geschikte query moeilijk is of waar de queryprestaties tegenvallen vanwege de aard van de gegevens of het gegevensarchief.
Deze gerealiseerde weergaven, die alleen gegevens bevatten die vereist zijn door een query, zorgen ervoor dat toepassingen snel kunnen beschikken over de gegevens die ze nodig hebben. Naast het samenvoegen van tabellen of het combineren van gegevensentiteiten, kunnen gerealiseerde weergaven de huidige waarden bevatten van berekende kolommen of gegevensitems, de resultaten van het combineren van waarden of het uitvoeren van transformaties op de gegevensitems en waarden die zijn opgegeven als onderdeel van de query. Een gerealiseerde weergave kan zelfs worden geoptimaliseerd voor één bepaalde query.
Een belangrijk punt is dat een gerealiseerde weergave en de daarin opgenomen gegevens zonder problemen kan worden verwijderd omdat de weergave volledig kan worden hersteld aan de hand van de archieven met brongegevens. Een gerealiseerde weergave wordt nooit rechtstreeks door een toepassing bijgewerkt, en is dus in feite een speciale cache.
Wanneer de brongegevens voor de weergave veranderen, moet de weergave worden bijgewerkt met de nieuwe gegevens. U kunt hiervoor een schema opstellen of dit doen zodra er een wijziging in de oorspronkelijke gegevens wordt gedetecteerd. In sommige gevallen kan het nodig zijn om de weergave handmatig opnieuw te genereren. In de afbeelding ziet u een voorbeeld van hoe het patroon Gerealiseerde weergave kan worden gebruikt.
Problemen en overwegingen
Beschouw de volgende punten als u besluit hoe u dit patroon wilt implementeren:
Hoe wordt de weergave bijgewerkt en wanneer? In het ideale geval wordt de weergave opnieuw gegenereerd in reactie op een gebeurtenis die aangeeft dat de brongegevens zijn gewijzigd. Dit kan echter overmatige overhead tot gevolg hebben als de brongegevens snel worden gewijzigd. U kunt de weergave ook opnieuw genereren via een geplande taak, een externe trigger of een handmatige actie.
In sommige systemen zijn gerealiseerde weergaven noodzakelijk, bijvoorbeeld wanneer het patroon Gebeurtenisbronnen wordt gebruikt om een archief bij te houden met alleen de gebeurtenissen waardoor de gegevens zijn gewijzigd. Het vooraf invullen van weergaven door alle gebeurtenissen te onderzoeken om de huidige status te bepalen, kan de enige manier zijn om gegevens op te halen uit het archief met gebeurtenissen. Als u het patroon Gebeurtenisbronnen niet gebruikt, is de afweging of een gerealiseerde weergave al dan niet zinvol is. Gerealiseerde weergaven zijn vaak specifiek afgestemd op één bepaalde query of een klein aantal query's. Als er veel query's worden gebruikt, kunnen gerealiseerde weergaven leiden tot onaanvaardbare vereisten ten aanzien van de opslagcapaciteit en opslagkosten.
Houd bij het genereren van de weergave rekening met de impact op de consistentie van gegevens. Dit is trouwens ook belangrijk als de weergave wordt bijgewerkt volgens een schema. Als de brongegevens veranderen op het moment dat de weergave wordt gegenereerd, zal de kopie van de gegevens in de weergave niet volledig consistent zijn met de oorspronkelijke gegevens.
Denk na over waar u de weergave wilt opslaan. De weergave hoeft zich niet te bevinden in hetzelfde archief of dezelfde partitie als de oorspronkelijke gegevens. Het kan een subset zijn uit enkele andere partities die zijn gecombineerd.
Een weergave kan opnieuw worden gemaakt als deze verloren is gegaan. Als de weergave tijdelijk is en alleen wordt gebruikt om de queryprestaties te verbeteren door de huidige status van de gegevens te weerspiegelen, of om de schaalbaarheid te verbeteren, kan de weergave dan ook worden opgeslagen in een cache of in een minder betrouwbaar locatie.
Maximaliseer de waarde van een gerealiseerde weergave door aan de definitie gegevensitems of kolommen toe te voegen op basis van berekening of transformatie van bestaande gegevensitems, op basis van waarden die worden doorgegeven in de query of op basis van combinaties van deze waarden indien van toepassing.
Als het opslagmechanisme hiervoor ondersteuning biedt, kunt u overwegen om de gerealiseerde weergave te indexeren om zo de prestaties verder te verbeteren. De meeste relationele databases ondersteunen indexering voor weergaven, evenals oplossingen voor big data op basis van Apache Hadoop.
Wanneer dit patroon gebruiken
Dit patroon is handig in de volgende situaties:
- Bij het maken van gerealiseerde weergaven van gegevens die moeilijk rechtstreeks zijn op te vragen, of waarbij query's zeer complex moeten zijn om gegevens op te halen die zijn opgeslagen op een genormaliseerde, semi-gestructureerde of ongestructureerde manier.
- Bij het maken van tijdelijke weergaven die de queryprestaties aanzienlijk kunnen verbeteren, of die rechtstreeks kunnen fungeren als bronweergaven of gegevensoverdrachtobjecten voor de gebruikersinterface, voor rapportage of voor weergave.
- Voor de ondersteuning van periodiek verbonden of niet-verbonden scenario's waarbij er niet altijd een verbinding met het gegevensarchief beschikbaar is. De weergave kan in dit geval in de lokale cache worden opgeslagen.
- Bij het vereenvoudigen van query's en het weergeven van gegevens voor experimenteren die geen kennis van de indeling van de gegevensbron vereist. Een voorbeeld hiervan is het samenvoegen van verschillende tabellen in een of meer databases, of een of meer domeinen in NoSQL-archieven, en de gegevens vervolgens opmaken voor het uiteindelijke gebruik ervan.
- Toegang verlenen tot specifieke subreeksen van de brongegevens die, voor beveiliging of privacy, niet algemeen toegankelijk mogen zijn, niet mogen worden gewijzigd of niet volledig zichtbaar mogen zijn voor gebruikers.
- Koppelingen maken tussen verschillende gegevensarchieven, om te profiteren van hun afzonderlijke mogelijkheden. Een voorbeeld is het inzetten van een archief in de cloud als het archief met naslaggegevens omdat dit efficiënter is voor schrijfbewerkingen en een relationele database die goede query- en leesprestaties biedt als de opslaglocatie voor de gerealiseerde weergaven.
- Wanneer u microservices gebruikt, wordt u aangeraden ze losjes gekoppeld te houden, inclusief hun gegevensopslag. Gerealiseerde weergaven kunnen u daarom helpen bij het samenvoegen van gegevens van uw services. Als gerealiseerde weergaven niet geschikt zijn in uw microservicesarchitectuur of specifiek scenario, kunt u overwegen om goed gedefinieerde grenzen te hebben die zijn afgestemd op DDD (Domain Driven Design) en de bijbehorende gegevens samen te voegen wanneer dit wordt aangevraagd.
Dit patroon wordt afgeraden in de volgende situaties:
- De brongegevens zijn eenvoudig en makkelijk te bevragen.
- De brongegevens veranderen zeer snel of zijn toegankelijk zonder gebruik van een weergave. In deze gevallen is het belangrijk om de verwerkingscapaciteit te voorkomen die nodig is voor het maken van weergaven.
- Consistentie heeft een hoge prioriteit. De weergaven zijn mogelijk niet altijd volledig consistent met de oorspronkelijke gegevens.
Workloadontwerp
Een architect moet evalueren hoe het gerealiseerde weergavepatroon kan worden gebruikt in het ontwerp van hun workload om de doelstellingen en principes te verhelpen die worden behandeld in de pijlers van het Azure Well-Architected Framework. Voorbeeld:
Pijler | Hoe dit patroon ondersteuning biedt voor pijlerdoelen |
---|---|
Prestatie-efficiëntie helpt uw workload efficiënt te voldoen aan de vereisten door optimalisaties in schalen, gegevens, code. | In de gerealiseerde weergaven worden de resultaten van complexe berekeningen of query's opgeslagen zonder dat de database-engine of client voor elke aanvraag opnieuw hoeft te worden gecomputeerd. Dit ontwerp vermindert het totale resourceverbruik. - PE:08 Gegevensprestaties |
Net als bij elke ontwerpbeslissing moet u rekening houden met eventuele compromissen ten opzichte van de doelstellingen van de andere pijlers die met dit patroon kunnen worden geïntroduceerd.
Opmerking
In de volgende afbeelding ziet u een voorbeeld waarin het patroon Gerealiseerde weergave wordt gebruikt om een overzicht van verkoopgegevens te genereren. Gegevens in de tabellen Order, OrderItem en Customer in afzonderlijke partities in een Azure-opslagaccount worden gecombineerd om een weergave te genereren met de totale verkoopwaarde voor elk product in de categorie Electronics, samen met een telling van het aantal klanten die elk item hebben gekocht.
Het maken van deze gerealiseerde weergave vereist complexe query's. Door het queryresultaat echter aan te bieden als een gerealiseerde weergave hebben gebruikers eenvoudig toegang tot de resultaten en kunnen ze deze rechtstreeks gebruiken of opnemen in een andere query. De weergave zal waarschijnlijk worden gebruikt in een rapportagesysteem of dashboard en kan volgens een schema worden bijgewerkt, bijvoorbeeld elke week.
Hoewel in dit voorbeeld gebruik wordt gemaakt van Azure Table Storage, bieden veel relationele databasebeheersystemen ook systeemeigen ondersteuning voor gerealiseerde weergaven.
Volgende stappen
- Inleiding over gegevensconsistentie. De overzichtsgegevens in een gerealiseerde weergave moeten worden onderhouden om ervoor te zorgen dat altijd de onderliggende gegevenswaarden worden weerspiegeld. Als de gegevenswaarden veranderen, is het mogelijk niet praktisch om de gegevens in realtime bij te werken en moet u misschien kiezen voor een aanpak waarbij de gegevens uiteindelijk consistent zijn. U vindt hier een overzicht van de problemen rondom het handhaven van de consistentie van gedistribueerde gegevens, evenals een beschrijving van de voor- en nadelen van verschillende consistentiemodellen.
Verwante resources
De volgende patronen zijn mogelijk ook relevant bij het implementeren van dit patroon:
- CQRS-patroon (Command and Query Responsibility Segregation). Gebruik dit patroon om de gegevens in een gerealiseerde weergave bij te werken door te reageren op gebeurtenissen die optreden als de onderliggende gegevenswaarden worden gewijzigd.
- Gebeurtenisbronnenpatroon. Gebruik dit patroon in combinatie met het CQRS-patroon om de gegevens in een gerealiseerde weergave te onderhouden. Wanneer de gegevenswaarden veranderen waarop een gerealiseerde weergave is gebaseerd, kan het systeem gebeurtenissen genereren die deze wijzigingen beschrijven en deze gebeurtenissen opslaan in een gebeurtenissenarchief.
- Indextabel-patroon. De gegevens in een gerealiseerde weergave zijn doorgaans geordend op een primaire sleutel, maar het kan zijn dat query's gegevens moeten ophalen uit deze weergave door gegevens in andere velden te onderzoeken. Gebruik dit patroon voor het maken van secundaire indexen van gegevenssets voor gegevensarchieven die geen ondersteuning bieden voor ingebouwde secundaire indexen.