Dela via

Kriterier för val av datalager

I den här artikeln beskrivs jämförelsevillkor som du kan använda när du utvärderar ett datalager. Målet är att hjälpa dig att avgöra vilka datalagringstyper som kan uppfylla din lösnings krav.

Allmänna överväganden

Tänk på följande när du gör ditt val.

Funktionskrav

  • Dataformat: Vilken typ av data tänker du lagra? Vanliga typer är transaktionsdata, JSON-objekt, telemetri, sökindex eller flata filer.
  • Datastorlek: Hur stora är de entiteter som du behöver lagra? Måste dessa entiteter underhållas som ett enda dokument, eller kan de delas upp i flera dokument, tabeller och samlingar?
  • Skala och struktur: Vad är den totala mängden lagringskapacitet som du behöver? Förväntar du dig partitionering av dina data?
  • Datarelationer: Behöver dina data ha stöd för en-till-många- eller många-till-många-relationer? Är själva relationerna en viktig del av data? Behöver du ansluta eller på annat sätt kombinera data från samma datauppsättning eller från externa datauppsättningar?
  • Konsekvensmodell: Hur viktigt är det för uppdateringar som görs i en nod att visas i andra noder innan ytterligare ändringar kan göras? Kan du acceptera eventuell konsistens? Behöver du ACID-garantier för transaktioner?
  • Schemaflexitet: Vilken typ av scheman ska du använda för dina data? Kommer du att använda ett fast schema, en schema-on-write-metod eller en schema-on-read-metod?
  • Samtidighet: Vilken typ av samtidighetsmekanism vill du använda när du uppdaterar och synkroniserar data? Kommer programmet att utföra många uppdateringar som potentiellt kan vara i konflikt? I så fall kan du kräva postlåsning och pessimistisk samtidighetskontroll. Kan du också stödja optimistiska samtidighetskontroller? I så fall räcker det med enkel tidsstämpelbaserad samtidighetskontroll, eller behöver du den tillagda funktionen för samtidighetskontroll i multiversion?
  • Dataflytt: Behöver din lösning utföra ETL-uppgifter för att flytta data till andra lager eller informationslager?
  • Datalivscykel: Är datan skriva en gång, läsa flera gånger? Kan den flyttas till lågfrekvent eller kall lagring?
  • Andra funktioner som stöds: Behöver du andra specifika funktioner, till exempel schemavalidering, aggregering, indexering, fulltextsökning, MapReduce eller andra frågefunktioner?

Icke-funktionella krav

  • Prestanda och skalbarhet: Vilka är dina krav på dataprestanda? Har du specifika krav för datainmatningshastigheter och databehandlingsfrekvenser? Vilka är de acceptabla svarstiderna för att fråga och aggregera data när de har matats in? Hur stort behöver du datalagret för att skala upp? Är din arbetsbelastning mer läsintensiv eller skrivintensiv?
  • Tillförlitlighet: Vilket övergripande serviceavtal behöver du stöd för? Vilken nivå av feltolerans behöver du tillhandahålla för datakonsumenter? Vilken typ av säkerhetskopierings- och återställningsfunktioner behöver du?
  • Replikering: Måste dina data distribueras mellan flera repliker eller regioner? Vilken typ av datareplikeringsfunktioner behöver du?
  • Gränser: Kommer gränserna för ett visst datalager att stödja dina krav på skalning, antal anslutningar och dataflöde?

Hantering och kostnad

  • Hanterad tjänst: Använd när det är möjligt en hanterad datatjänst, såvida du inte behöver specifika funktioner som bara finns i en infrastruktur som en tjänst (IaaS)-värdbaserad datalagring.
  • Regiontillgänglighet: Är tjänsten tillgänglig i alla Azure-regioner för hanterade tjänster? Måste din lösning finnas i vissa Azure-regioner?
  • Portabilitet: Måste dina data migreras till lokala, externa datacenter eller andra molnvärdmiljöer?
  • Licensiering: Föredrar du en proprietär eller OSS-licenstyp? Finns det några andra externa begränsningar för vilken typ av licens du kan använda?
  • Total kostnad: Vad är den totala kostnaden för att använda tjänsten i din lösning? Hur många instanser behöver köras för att stödja dina krav på drifttid och dataflöde? Överväg driftkostnader i den här beräkningen. En anledning till att föredra hanterade tjänster är den minskade driftskostnaderna.
  • Kostnadseffektivitet: Kan du partitionera dina data för att lagra dem mer kostnadseffektivt? Kan du till exempel flytta stora objekt från en dyr relationsdatabas till ett objektlager?

Säkerhet

  • Säkerhet: Vilken typ av kryptering behöver du? Behöver du kryptering i vila? Vilken autentiseringsmekanism vill du använda för att ansluta till dina data?
  • Granskning: Vilken typ av granskningslogg behöver du generera?
  • Nätverkskrav: Behöver du begränsa eller på annat sätt hantera åtkomsten till dina data från andra nätverksresurser? Behöver data endast vara tillgängliga inifrån Azure-miljön? Måste data vara tillgängliga från specifika IP-adresser eller undernät? Måste den vara tillgänglig från program eller tjänster som finns lokalt eller i andra externa datacenter?

DevOps

  • Kunskapsuppsättning: Finns det programmeringsspråk, operativsystem eller annan teknik som ditt team är skickliga på att använda? Finns det andra som skulle vara svåra för ditt team att arbeta med?
  • Klienter: Finns det bra klientstöd för dina utvecklingsspråk?

Nästa steg