Använd den bästa datalagringen för jobbet
Välj den lagringsteknik som passar bäst för dina data och användningsbehov
Den tid är förbi då du kunde lagra alla dina data i en enda, stor SQL-relationsdatabas. Relationsdatabaser är mycket bra på vad de gör – att tillhandahålla ACID-garantier för transaktioner över relationsdata. De medför dock vissa kostnader:
- Frågor kan kräva kostsamma kopplingar.
- Data måste normaliseras och överensstämma med ett fördefinierat schema (schema vid skrivning).
- Låskonkurrens kan påverka prestanda.
För större lösningar är det troligt att en enda datalagringsteknik inte tillgodoser alla dina behov. Bland alternativen till relationsdatabaser finns nyckel-värde-databaser, dokumentdatabaser, sökmotordatabaser, tidseriedatabaser, kolumndatabaser och grafdatabaser. Var och en har sina för- och nackdelar och passar mer eller mindre bra för olika datatyper.
Du kan till exempel lagra en produktkatalog i en dokumentdatabas som Cosmos DB, som möjliggör ett flexibelt schema. Då lagras varje produktbeskrivning som ett självständigt dokument. Du kan indexera katalogen och lagra indexet i Azure Search för att möjliggöra sökningar i hela katalogen. Produktlagret kan lagras i en SQL-databas, eftersom sådana data kräver ACID-garantier.
Kom ihåg att data innehåller mer än bara beständiga programdata. De innehåller också programloggar, händelser, meddelanden och cacheminnen.
Rekommendationer
Använd inte en relationsdatabas för alla behov. Överväg andra datalager när det är lämpligt. Se Välja rätt datalager.
Satsa på flerspråkig beständighet. För större lösningar är det troligt att en enda datalagringsteknik inte tillgodoser alla dina behov.
Ta hänsyn till datatypen. Du kan till exempel lagra transaktionsdata i SQL, JSON-dokument i en dokumentdatabas, telemetridata i en tidseriedatabas, programloggar i Elastisearch och blobbar i Azure blobblagring.
Prioritera tillgänglighet framför (stark) konsekvens. Enligt CAP-satsen måste ett distribuerat system kompromissa mellan tillgänglighet och konsekvens. (Nätverkspartitioner, den andra delen i CAP-satsen, kan aldrig undvikas helt och hållet.) Ofta kan du uppnå högre tillgänglighet genom att införa en modell för eventuell konsekvens.
Överväg utvecklingsteamets kompetensuppsättning. Det finns fördelar med att använda flerspråkig beständighet, men det kan också gå överstyr. Att införa en ny teknik för datalagring kräver en ny uppsättning kompetenser. Utvecklingsteamet måste förstå hur tekniken kan utnyttjas på bästa sätt. De måste förstå lämpliga användningsmönster, hur de kan optimera frågor och finjustera prestanda, och så vidare. Ta hänsyn till det när du överväger lagringstekniker.
Använd kompenserande transaktioner. En sidoeffekt av flerspråkig beständighet är att enstaka transaktioner kan skriva data till flera datalager. Om något inte fungerar kan du använda kompenserande transaktioner för att ångra redan slutförda steg.
Titta på begränsade kontexter. Begränsad kontext är ett begrepp inom domändriven design. En begränsad kontext är en explicit gräns runt en domänmodell och definierar för vilka delar av domänen modellen gäller. Vi rekommenderar att en begränsad kontext mappas till en underdomän till affärsdomänen. Begränsade kontexter i systemet är en naturlig plats att överväga för flerspråkig beständighet. Till exempel kanske ”produkter” visas i både underdomänen Produktkatalog och underdomänen Produktlager, men det är mycket sannolikt att dessa två underdomäner har olika krav för lagring, uppdatering och frågor gällande produkter.