Dela via

Kriterier för val av datalager

  • Artikel

Den här artikeln beskriver jämförelsekriterier som du kan använda när du utvärderar ett datalager. Tanken är att hjälpa dig avgöra vilka datalagringstyper som kan uppfylla din lösnings krav.

Generella saker att tänka på

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 att behöva partitionera data?
  • Datarelationer: Behöver dina data ha stöd för en-till-många- eller många-till-många-relationer? Är relationer i sig 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 att uppdateringar som görs i en nod visas i andra noder innan ytterligare ändringar kan göras? Kan du godta eventuell konsekvens? 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 metod med schema vid skrivning eller en metod med schema vid läsning?
  • 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 behöva postlåsning och pessimistisk samtidighetskontroll. Eller så kanske du kan ha stöd för optimistisk samtidighetsstyrning? 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: Skrivs data en gång, läs-många? Kan de 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 dataprestandakrav? Har du särskilda krav för datainmatnings- och databearbetningshastighet? Vilka är de godkända svarstiderna för att fråga och aggregera data när de har matats in? Hur stort behöver datalagret skalas upp till? Är arbetsbelastningen mer inriktad på skrivning eller läsning?
  • Tillförlitlighet: Vilket övergripande serviceavtal behöver du stödja? Vilken nivå av feltolerans behöver du tillhandahålla för datakonsumenter? Vilka typer 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å skala, antal anslutningar och dataflöde?

Hantering och kostnad

  • Hanterad tjänst: När det är möjligt använder du en hanterad datatjänst, såvida du inte behöver specifika funktioner som bara finns i ett IaaS-värdbaserat datalager (infrastruktur som en tjänst).
  • Regionstillgänglighet: Är tjänsten tillgänglig i alla Azure-regioner för hanterade tjänster? Måste lösningen ha sin värd i särskilda Azure-regioner?
  • Portabilitet: Måste dina data migreras till lokala, externa datacenter eller andra molnvärdmiljöer?
  • Licensiering: Har du en företrädesrätt jämfört med OSS-licenstyp? Finns det några andra externa begränsningar vad gäller 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 måste köras för att stödja dina krav på drifttid och dataflöde? Ta med driftskostnader i den här beräkningen. Ett skäl att föredra hanterade tjänster är de lägre 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 objektarkiv?

Säkerhet

  • Säkerhet: Vilken typ av kryptering behöver du? Behöver du kryptering i vila? Vilken autentiseringsmetod 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? Får data endast vara tillgängliga från insidan av Azure-miljön? Måste det gå att komma åt data från särskilda IP-adresser eller undernät? Måste data vara tillgängliga från program eller tjänster som ligger lokalt eller i andra externa datacenter?

DevOps

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

Nästa steg