Dela via

Förstå datalagermodeller

  • Artikel

Moderna affärssystem hanterar allt större mängder heterogena data. Den här heterogeniteten innebär att ett enda datalager vanligtvis inte är den bästa metoden. I stället är det ofta bättre att lagra olika typer av data i olika datalager, som var och en fokuserar på en specifik arbetsbelastning eller användningsmönster. Termen flerspråkig beständighet används för att beskriva lösningar som använder en blandning av datalagertekniker. Därför är det viktigt att förstå de viktigaste lagringsmodellerna och deras kompromisser.

Att välja rätt datalager för dina behov är ett viktigt designbeslut. Det finns bokstavligen hundratals implementeringar att välja mellan bland SQL- och NoSQL-databaser. Datalager kategoriseras ofta efter hur de strukturerar data och vilka typer av åtgärder de stöder. I den här artikeln beskrivs flera av de vanligaste lagringsmodellerna. Observera att en viss datalagerteknik kan ha stöd för flera lagringsmodeller. Till exempel kan ett hanteringssystem för relationsdatabaser (RDBMS) också ha stöd för nyckel-/värde- eller graflagring. Faktum är att det finns en allmän trend för så kallat multimodellstöd, där ett enda databassystem stöder flera modeller. Men det är fortfarande användbart att förstå de olika modellerna på en hög nivå.

Alla datalager i en viss kategori har inte samma funktionsuppsättning. De flesta datalager tillhandahåller funktioner på serversidan för att fråga och bearbeta data. Ibland är den här funktionen inbyggd i datalagringsmotorn. I andra fall separeras funktionerna för datalagring och bearbetning, och det kan finnas flera alternativ för bearbetning och analys. Datalager stöder också olika programmatiska gränssnitt och hanteringsgränssnitt.

I allmänhet bör du börja med att överväga vilken lagringsmodell som passar bäst för dina behov. Överväg sedan ett visst datalager inom den kategorin, baserat på faktorer som funktionsuppsättning, kostnad och enkel hantering.

Notera

Läs mer om att identifiera och granska dina datatjänstkrav för molnimplementering i Microsoft Cloud Adoption Framework för Azure. På samma sätt kan du också lära dig mer om att välja lagringsverktyg och tjänster.

Hanteringssystem för relationsdatabaser

Relationsdatabaser organiserar data som en serie tvådimensionella tabeller med rader och kolumner. De flesta leverantörer tillhandahåller en dialekt av SQL (Structured Query Language) för att hämta och hantera data. En RDBMS implementerar vanligtvis en transaktionsmässigt konsekvent mekanism som överensstämmer med ACID-modellen (Atomic, Consistent, Isolated, Durable) för uppdatering av information.

En RDBMS stöder vanligtvis en schema-on-write-modell, där datastrukturen definieras i förväg och alla läs- eller skrivåtgärder måste använda schemat.

Den här modellen är mycket användbar när starka konsekvensgarantier är viktiga – där alla ändringar är atomiska och transaktioner alltid lämnar data i ett konsekvent tillstånd. En RDBMS kan dock vanligtvis inte skalas ut horisontellt utan att partitionera data på något sätt. Dessutom måste data i en RDBMS normaliseras, vilket inte är lämpligt för varje datauppsättning.

Azure-tjänster

Arbetsbörda

  • Poster skapas och uppdateras ofta.
  • Flera åtgärder måste slutföras i en enda transaktion.
  • Relationer säkerställs med hjälp av databasbegränsningar.
  • Index används för att optimera frågeprestanda.

Datatyp

  • Data är mycket normaliserade.
  • Databasscheman krävs och framtvingas.
  • Många-till-många-relationer mellan dataentiteter i databasen.
  • Begränsningar definieras i schemat och tillämpas på alla data i databasen.
  • Data kräver hög integritet. Index och relationer måste upprätthållas korrekt.
  • Data kräver stark konsekvens. Transaktioner fungerar på ett sätt som säkerställer att alla data är 100% konsekventa för alla användare och processer.
  • Storleken på enskilda dataposter är liten till medelstor.

Exempel

  • Lagerhantering
  • Orderhantering
  • Rapporteringsdatabas
  • Redovisning

Nyckel-/värdelager

Ett nyckel-/värdelager associerar varje datavärde med en unik nyckel. De flesta nyckel-/värdelager stöder endast enkla åtgärder för frågor, infogning och borttagning. Om du vill ändra ett värde (antingen delvis eller helt) måste ett program skriva över befintliga data för hela värdet. I de flesta implementeringar är läsning eller skrivning av ett enda värde en atomisk åtgärd.

Ett program kan lagra godtyckliga data som en uppsättning värden. All schemainformation måste tillhandahållas av programmet. Nyckel-/värdearkivet hämtar eller lagrar bara värdet efter nyckel.

diagram över ett nyckelvärdeslager

Nyckel-/värdelager är mycket optimerade för program som utför enkla sökningar, men är mindre lämpliga om du behöver köra frågor mot data i olika nyckel-/värdelager. Nyckel-/värdelager är inte heller optimerade för frågor efter värde.

Ett enda nyckel-/värdelager kan vara extremt skalbart eftersom datalagret enkelt kan distribuera data över flera noder på separata datorer.

Azure-tjänster

Arbetsbörda

  • Data nås med en enda nyckel, till exempel en ordlista.
  • Inga kopplingar, lås eller unioner krävs.
  • Inga aggregeringsmekanismer används.
  • Sekundära index används vanligtvis inte.

Datatyp

  • Varje nyckel är associerad med ett enda värde.
  • Det finns inget schematvång.
  • Inga relationer mellan entiteter.

Exempel

  • Cachelagring av data
  • Sessionshantering
  • Användarinställningar och profilhantering
  • Produktrekommendations- och annonsvisning

Dokumentdatabaser

En dokumentdatabas lagrar en samling dokument, där varje dokument består av namngivna fält och data. Data kan vara enkla värden eller komplexa element som listor och underliggande samlingar. Dokument hämtas med unika nycklar.

Vanligtvis innehåller ett dokument data för en enskild entitet, till exempel en kund eller en beställning. Ett dokument kan innehålla information som skulle spridas över flera relationstabeller i en RDBMS. Dokument behöver inte ha samma struktur. Program kan lagra olika data i dokument när affärskraven ändras.

diagram över ett dokumentarkiv

Azure-tjänst

Arbetsbörda

  • Infognings- och uppdateringsåtgärder är vanliga.
  • Ingen objektrelationell impedanskonflikt. Dokument kan bättre matcha de objektstrukturer som används i programkoden.
  • Enskilda dokument hämtas och skrivs som ett enda block.
  • Data kräver index för flera fält.

Datatyp

  • Data kan hanteras på ett denormaliserat sätt.
  • Storleken på enskilda dokumentdata är relativt liten.
  • Varje dokumenttyp kan använda sitt eget schema.
  • Dokument kan innehålla valfria fält.
  • Dokumentdata är halvstrukturerade, vilket innebär att datatyperna för varje fält inte är strikt definierade.

Exempel

  • Produktkatalog
  • Innehållshantering
  • Lagerhantering

Grafdatabaser

En grafdatabas lagrar två typer av information, noder och kanter. Kanter anger relationer mellan noder. Noder och kanter kan ha egenskaper som ger information om noden eller kanten, ungefär som kolumner i en tabell. Kanter kan också ha en riktning som anger relationens natur.

Graph-databaser kan effektivt utföra frågor i nätverket med noder och kanter och analysera relationerna mellan entiteter. Följande diagram visar en organisations personaldatabas strukturerad som ett diagram. Entiteterna är anställda och avdelningar, och kanterna anger rapporteringsrelationer och de avdelningar där anställda arbetar.

diagram över en dokumentdatabas

Den här strukturen gör det enkelt att köra frågor som "Hitta alla anställda som rapporterar direkt eller indirekt till Sarah" eller "Vem arbetar på samma avdelning som John?" För stora grafer med många entiteter och relationer kan du utföra mycket komplexa analyser mycket snabbt. Många grafdatabaser tillhandahåller ett frågespråk som du kan använda för att effektivt korsa ett nätverk av relationer.

Azure-tjänster

Arbetsbörda

  • Komplexa relationer mellan dataobjekt som omfattar många hopp mellan relaterade dataobjekt.
  • Relationen mellan dataobjekt är dynamisk och ändras över tid.
  • Relationer mellan objekt är förstklassiga medborgare, utan att behöva sekundärnycklar och kopplingar för att passera.

Datatyp

  • Noder och relationer.
  • Noder liknar tabellrader eller JSON-dokument.
  • Relationer är lika viktiga som noder och exponeras direkt i frågespråket.
  • Sammansatta objekt, till exempel en person med flera telefonnummer, tenderar att delas upp i separata, mindre noder, i kombination med traverserbara relationer.

Exempel

  • Organisationsscheman
  • Sociala grafer
  • Bedrägeridetektion
  • Rekommendationsmotorer

Dataanalys

Dataanalyslager ger massivt parallella lösningar för att mata in, lagra och analysera data. Data distribueras över flera servrar för att maximera skalbarheten. Stora datafilformat som avgränsarfiler (CSV), parquetoch ORC- används ofta i dataanalys. Historiska data lagras vanligtvis i datalager som bloblagring eller Azure Data Lake Storage Gen2, som sedan används av Azure Synapse, Databricks eller HDInsight som externa tabeller. Ett typiskt scenario där data lagras som parquet-filer för att förbättra prestandan beskrivs i artikeln Använda externa tabeller med Synapse SQL.

Azure-tjänster

Arbetsbörda

  • Dataanalys
  • Företags-BI

Datatyp

  • Historiska data från flera källor.
  • Vanligtvis avnormaliseras i ett stjärn- eller snöflingeschema, bestående av fakta- och dimensionstabeller.
  • Läses vanligtvis in med nya data enligt schema.
  • Dimensionstabeller innehåller ofta flera historiska versioner av en entitet, som kallas för en långsamt föränderlig dimension.

Exempel

  • Informationslager för företag

Kolumnfamiljedatabaser

En kolumnfamiljdatabas organiserar data i rader och kolumner. I sin enklaste form kan en kolumnfamiljedatabas se ut ungefär som en relationsdatabas, åtminstone konceptuellt. Den verkliga kraften i en kolumnfamiljedatabas ligger i dess avnormaliserade metod för att strukturera glesa data.

Du kan tänka dig en kolumnfamiljedatabas som innehåller tabelldata med rader och kolumner, men kolumnerna är indelade i grupper som kallas kolumnfamiljer. Varje kolumnfamilj innehåller en uppsättning kolumner som är logiskt relaterade till varandra och som vanligtvis hämtas eller manipuleras som en enhet. Andra data som nås separat kan lagras i separata kolumnfamiljer. I en kolumnfamilj kan nya kolumner läggas till dynamiskt och rader kan vara glesa (det vill: en rad behöver inte ha något värde för varje kolumn).

Följande diagram visar ett exempel med två kolumnfamiljer, Identity och Contact Info. Data för en enskild entitet har samma radnyckel i varje kolumnfamilj. Den här strukturen, där raderna för ett visst objekt i en kolumnfamilj kan variera dynamiskt, är en viktig fördel med kolumnfamiljemetoden, vilket gör den här typen av datalager mycket lämplig för lagring av strukturerade, flyktiga data.

diagram över en kolumnfamiljedatabas

Till skillnad från ett nyckel-/värdelager eller en dokumentdatabas lagrar de flesta kolumnfamiljedatabaser data i nyckelordning i stället för genom att beräkna en hash. Med många implementeringar kan du skapa index över specifika kolumner i en kolumnfamilj. Med index kan du hämta data efter kolumnvärde i stället för radnyckel.

Läs- och skrivåtgärder för en rad är vanligtvis atomiska med en enda kolumnfamilj, även om vissa implementeringar ger atomitet över hela raden, som sträcker sig över flera kolumnfamiljer.

Azure-tjänster

Arbetsbörda

  • De flesta kolumnfamiljedatabaser utför skrivåtgärder extremt snabbt.
  • Uppdaterings- och borttagningsåtgärder är sällsynta.
  • Utformad för att ge åtkomst med högt dataflöde och låg latens.
  • Stöder enkel frågeåtkomst till en viss uppsättning fält i en mycket större post.
  • Massivt skalbar.

Datatyp

  • Data lagras i tabeller som består av en nyckelkolumn och en eller flera kolumnfamiljer.
  • Specifika kolumner kan variera beroende på enskilda rader.
  • Enskilda celler nås via get- och sätt-kommandon
  • Flera rader returneras med hjälp av ett genomsökningskommando.

Exempel

  • Rekommendationer
  • Personalisering
  • Sensordata
  • Telemetri
  • Meddelanden
  • Analys av sociala medier
  • Webbanalys
  • Aktivitetsövervakning
  • Väder och andra tidsseriedata

Sökmotordatabaser

Med en sökmotordatabas kan program söka efter information som lagras i externa datalager. En sökmotordatabas kan indexerar stora mängder data och ge nästan realtidsåtkomst till dessa index.

Index kan vara flerdimensionella och kan ha stöd för fritextsökningar över stora mängder textdata. Indexering kan utföras med hjälp av en pull-modell, som utlöses av sökmotordatabasen eller med hjälp av en push-modell som initieras av extern programkod.

Sökningen kan vara exakt eller suddig. En fuzzy-sökning hittar dokument som matchar en uppsättning termer och beräknar hur nära de matchar. Vissa sökmotorer stöder också språklig analys som kan returnera matchningar baserat på synonymer, genreexpansioner (till exempel matchning dogs till pets) och härstamning (matchande ord med samma rot).

Azure-tjänst

Arbetsbörda

  • Dataindex från flera källor och tjänster.
  • Frågor är ad hoc och kan vara komplexa.
  • Fulltextsökning krävs.
  • Ad hoc-självbetjäningsfråga krävs.

Datatyp

  • Halvstrukturerad eller ostrukturerad text
  • Text med referens till strukturerade data

Exempel

  • Produktkataloger
  • Webbplatssökning
  • Skogsavverkning

Tidsseriedatabaser

Tidsseriedata är en uppsättning värden ordnade efter tid. Tidsseriedatabaser samlar vanligtvis in stora mängder data i realtid från ett stort antal källor. Uppdateringar är sällsynta och borttagningar görs ofta som massåtgärder. Även om posterna som skrivs till en tidsseriedatabas i allmänhet är små finns det ofta ett stort antal poster och den totala datastorleken kan växa snabbt.

Azure-tjänst

Arbetsbörda

  • Poster läggs vanligtvis till sekventiellt i tidsordning.
  • En överväldigande andel av åtgärderna (95–99%) är skrivoperationer.
  • Uppdateringar är sällsynta.
  • Borttagningar sker bulkvis och tillämpas på sammanhängande block eller poster.
  • Data läss sekventiellt i antingen stigande eller fallande tidsordning, ofta parallellt.

Datatyp

  • En tidsstämpel används som primärnyckel och sorteringsmekanism.
  • Taggar kan definiera ytterligare information om typen, ursprunget och annan information om posten.

Exempel

  • Övervakning och händelsetelemetri.
  • Sensor eller andra IoT-data.

Objektlagring

Objektlagring är optimerat för lagring och hämtning av stora binära objekt (bilder, filer, video- och ljudströmmar, stora programdataobjekt och dokument, diskbilder för virtuella datorer). Stora datafiler används också populärt i den här modellen, till exempel avgränsarfil (CSV), parquetoch ORC. Objektlager kan hantera extremt stora mängder ostrukturerade data.

Azure-tjänst

Arbetsbörda

  • Identifierad med nyckel.
  • Innehåll är vanligtvis en tillgång, till exempel en avgränsare, bild eller videofil.
  • Innehållet måste vara beständigt och externt till alla programnivåer.

Datatyp

  • Datastorleken är stor.
  • Värdet är ogenomskinligt.

Exempel

  • Bilder, videor, office-dokument, PDF-filer
  • Statisk HTML, JSON, CSS
  • Logg- och granskningsfiler
  • Databassäkerhetskopior

Delade filer

Ibland kan användning av enkla flata filer vara det mest effektiva sättet att lagra och hämta information. Med hjälp av fildelningar kan filer nås över ett nätverk. Med lämpliga mekanismer för säkerhet och samtidig åtkomstkontroll kan delning av data på det här sättet göra det möjligt för distribuerade tjänster att ge mycket skalbar dataåtkomst för att utföra grundläggande åtgärder på låg nivå, till exempel enkla läs- och skrivbegäranden.

Azure-tjänst

Arbetsbörda

  • Migrering från befintliga appar som interagerar med filsystemet.
  • Kräver SMB-gränssnitt.

Datatyp

  • Filer i en hierarkisk uppsättning mappar.
  • Tillgänglig med standard-I/O-bibliotek.

Exempel

  • Äldre filer
  • Delat innehåll som är tillgängligt mellan ett antal virtuella datorer eller appinstanser

Med hjälp av den här förståelsen av olika datalagringsmodeller är nästa steg att utvärdera din arbetsbelastning och ditt program och bestämma vilket datalager som ska uppfylla dina specifika behov. Använd beslutsträdet för datalagring för att hjälpa till med den här processen.

Nästa steg