I databasesystemer lagrer en materialiseret view som et databaseobjekt de forudberegnede resultater af en forespørgsel som en fysisk tabel. Fordi dataene faktisk lagres på disk, kan komplicerede søgninger hentes hurtigere. En view er derimod en virtuel tabel, der definerer en forespørgsel, men lagrer faktisk ikke data. En view henter de seneste oplysninger fra de underliggende basistabeller, hver gang du forespørger den. Realtids-dataaadgang versus forudberegnede resultater er nogle af kriterierne, der bestemmer, om du skal bruge en materialiseret view eller en standard view.
Hvad er et materialized view?
En materialiseret view lagrer fysisk resultaterne af en SQL-forespørgsel i databasen. De lagrede data kan opdateres med angivne intervaller (manuelt, periodisk eller automatisk) for at holde viewet synkroniseret med ændringer i de underliggende basistabeller.
Hvordan fungerer materialiseret view?
Lad os sige, at du vil udføre en kompleks SQL-forespørgsel, der opsummerer salgsdata efter flere regioner. I stedet for at udføre denne komplekse forespørgsel hver gang en rapport skal genereres, opretter du en materialiseret view, der forudberegner og lagrer resultaterne. Når en bruger ønsker at se rapporten, hentes den direkte fra den materialiserede view i stedet for at skulle omberegne aggregeringerne under udførelsen af et computerprogram uden at afbryde kørslen.
Almindelige anvendelsestilfælde for materialiserede visninger
- Forudberegning af Aggregeringer: Materialiserede visninger er ideelle til rapportering og analyse. De forberegner og gemmer aggregerede data, så tidskrævende forespørgsler ikke skal køres igen og igen.
- Reduktion af belastning under komplekse joins: Materialiserede visninger oprettes for at joinde tabeller og gemme resultatet under forespørgselsudførelse, når databasen indeholder flere komplekse joins.
- Caching af hyppigt tilgåede data: Materialiserede visninger fungerer som et cache, der holder resultater, forbedrer forespørgselsydelsen og reducerer belastningen på basistabeller.
Hvad er en view?
En visning er en virtuel tabel, der ikke gemmer data i sig selv. Forespørgslen udføres flere gange mod basistabellerne, hver gang visningen tilgås, for at danne de mest aktuelle resultater.
Hvordan fungerer visninger?
Antag, at du har mange basistabeller med kundeoplysninger fra forskellige regioner. Du opretter en visning i stedet for at skrive en kompleks SQL-forespørgsel hver gang, du har brug for at se konsoliderede kundedata. Når du derefter forespørger visningen, henter og viser den data ved at joinde basistabellerne på stedet.
Almindelige anvendelsestilfælde for visninger
- Forenkling af komplekse forespørgsler: En visning kan indkapsle en kompleks serie af joins og filtre i én virtuel tabel, hvilket gør det muligt for slutbrugere at få enklere adgang til data.
- Øget sikkerhed: Ved at definere en visning til kun at vise bestemte kolonner eller rækker er det muligt at begrænse adgangen til følsomme data ved at holde de underliggende data skjulte.
- Oprettelse af et abstraktionslag: Du kan bruge en visning til at tilbyde et abstraktionslag over flere tabeller, hvilket gør det meget lettere at forstå og administrere dataene uden at skulle ændre de råbasistabeller.
Fordele og ulemper ved materialiserede visninger versus visninger
At vælge mellem en materialiseret visning og en visning kræver forståelse af kompromiserne. Nedenfor er detaljerede fordele og ulemper ved hver tilgang.
Fordele og ulemper ved materialiserede visninger
| Aspekt | Fordele | Ulemper |
| Ydeevne | forbedrer ydeevnen ved at gemme forberegnet resultater | bliver forældede, hvis de ikke opdateres |
| Hastighed | reducerer tiden brugt på komplekse forespørgsler | Mere lagerpladser er nødvendig for at vedligeholde visningen |
| Friskhed | kan opdateres regelmæssigt | Data er ikke altid ajourført, medmindre de opdateres |
| Ressourceforbrug | for gentagne forespørgsler bruges mindre CPU- og hukommelsesressourcer | kræver yderligere ressourcer til vedligeholdelse og lagring |
| Fleksibilitet | praktisk til analyser og rapporter | ikke det bedste valg til real-time-applikationer, der har brug for nye data |
| Vedligeholdelse | kan opdateres automatisk (inkrementelt eller fuldt) | opfriskelse kan være dyr for store databaser |
| Komplekse forespørgsler | hjælper slutbrugere med at forstå komplekse forespørgsler | viewet skal opdateres for at ændringer i de underliggende tabeller bliver synlige |
| Samtidighed | ved at cache resultater reduceres belastningen på databasen | høje opdateringshastigheder påvirker databasens ydeevne negativt |
Fordele og ulemper ved view
| Aspekt | Fordele | Ulemper |
| Ydeevne | praktisk til at forenkle dataadgang | hvis forespørgslen involverer flere joins eller aggregeringer, bliver den langsom |
| Hastighed | adgang til real-time data med de nyeste informationer og ingen forsinkelser | langsomme forespørgsler, især når viewet er komplekst |
| Friskhed | altid synkroniseret med de underliggende tabeller | kan give dårlig ydeevne ved komplekse forespørgsler |
| Ressourceforbrug | kræver ikke ekstra lagring, da den kun gemmer en definition af forespørgslen | hver forespørgsel genberegner resultaterne |
| Fleksibilitet | kan behandles som en normal tabel i forespørgsler | ikke egnet til ressourcekrævende analyser |
| Vedligeholdelse | ingen genindlæsning nødvendig, da den henter real-time data automatisk | ydeevnen kan blive påvirket negativt ved hyppig adgang med store datamængder |
| Komplekse forespørgsler | gør det lettere i forespørgselslogik ved at give en struktureret abstraktion | forudberegnede resultater kan ikke gemmes som en materialized view |
| Samtidighed | afspejler altid real-time-ændringer i de underliggende tabeller | høj belastning kan lægge ekstra pres på databasen |
Vigtige forskelle mellem View og Materialized View
Moderne applikationer er afhængige af databaser som grundlag, og datakontrol opnås gennem to vigtige værktøjer: materialized view og view. De findes primært for at forenkle dataadgang og optimere forespørgselsydelse, men de adskiller sig i deres formål. Her er nogle afgørende forskelle mellem materialized view og view.
Lagring
- Materialiseret Visning Gemmer faktiske data i databasen.
- View: gemmer ikke data, gemmer kun forespørgselsdefinitionen.
Forespørgselsudførelse
- Materialiseret Visning Forudberegnede data hentes, hvilket forbedrer forespørgselsydelsen.
- Visning: Forespørgselsudførelse initieres ved hver adgang.
Dataopdatering
- Materialiseret Visning Data kan blive forældet, medmindre de eksplicit opdateres.
- Visning: Den henter altid de nyeste data fra de underliggende tabeller.
Ydeevne
- Materialiseret Visning Den er hurtigere, da de tidligere beregnede data er blevet gemt.
- Visning: Hvis forespørgslen er kompleks, kan den være langsommere, da den er on-demand.
Genopfriskningsmekanisme
- Materialiseret Visning Det kræver en manuel eller planlagt refresh at opdatere indholdet.
- Visning: Ingen genindlæsning er nødvendig, da real-time data altid hentes.
Lagerkrav
- Materialiseret Visning Kræver ekstra lagerplads til vedligeholdelse af de forudberegnede resultater.
- Visning: Bruger i princippet ingen lagerplads undtagen for forespørgselsmetadata.
Anvendelsestilfælde
- Materialiseret Visning Egnet til rapportering, analytics og performance-tunge forespørgsler.
- Visning: Et valg når tæt på realtidsdata er afgørende.
Kompleksitet
- Materialiseret Visning Vedligeholdelse og opdateringsstyring nødvendig.
- Visning: Enkelt at konfigurere og bruge, men kan være ressourcekrævende.
Hvornår skal man bruge Materialized View mod View
Brug Materialized View når:
Materialized view kommer på banen når forespørgselsydelsen skal forbedres for enhver pris, især hvis forespørgslen involverer mange beregninger inden resultater returneres med betydelig aggregering, joins eller behandlingsoperationer. Det kan være særligt nyttigt når forudberegnede resultater gør væsentlig forskel på belastningen på databasen eller hastigheden hvorpå forespørgsler returneres. Selvom materialized view kræver periodisk opdatering for at få de seneste data, tjener de et formål i rapporterings- og analysescenarier hvor realtidsdataadgang ikke er kritisk, men hurtig udførelse stadig er vigtig.
Brug View når:
Brug view når forespørgslen altid skal hente de mest aktuelle data, når dataadgang skal være realtid og forespørgselskompleksitet kan styres, og husk at view ikke gemmer data fysisk i databasen, hvilket kræver mindre lagerplads. Husk dog at for meget komplekse forespørgsler kan view bremse systemet når det udføres flere gange.
Konklusion
Hvor forskellig en materialiseret view er fra en regulær view er et vigtigt koncept, når man skal tune databasens ydeevne. En materialiseret view er en view, der gemmer forudberegnede resultater for at fremskynde forespørgsler ved tunge operationer. Men de kan være besværlige at vedligeholde, da de kan blive forældet, hvis de ikke opdateres regelmæssigt. En regulær view opdateres derimod automatisk, når data i de underliggende tabeller ændres, hvilket sikrer aktuelle data - men det kan påvirke ydeevnen.
Når du skal vælge mellem dem, skal du overveje din databases arbejdsbelastning, forespørgslens kompleksitet og hvor vigtig realtidsdata er for dig. Hvis det drejer sig om rapporter eller analyser, hvor ydeevne har høj prioritet, er en materialiseret view et stærkt valg. Omvendt, hvis du har brug for de seneste data, er en regulær view at foretrække.
Det endelige valg afhænger også af, hvilket databasesystem du bruger. Forskellige databasesystemer, herunder PostgreSQL, Oracle, og MySQL har varieret understøttelse af og muligheder for materialiserede views.
