Gebruik het beste gegevensarchief voor de taak

Kies de opslagtechnologie die het meest geschikt is voor uw gegevens en hoe deze worden gebruikt

De tijd is voorbij dat u al uw gegevens in een grote, relationele SQL-database stopte. Relationele databases zijn heel goed in wat ze doen — het bieden van ACID-garanties voor transacties via relationele gegevens. Maar er zijn nadelen aan verbonden:

• Voor query's kunnen kostbare joins noodzakelijk zijn.
• Gegevens moeten worden genormaliseerd en voldoen aan een vooraf gedefinieerd schema (schema voor schrijven).
• Vergrendelingsconflicten kunnen de prestaties beïnvloeden.

Voor elk grote oplossing geldt dat één technologie voor gegevensopslag waarschijnlijk niet aan al uw eisen voldoet. Alternatieven voor relationele databases zijn sleutel-/waardearchieven, documentdatabases, zoekprogrammadatabases, tijdreeksdatabases, kolom-familiedatabases en grafiekendatabases. Elke database heeft voor- en nadelen, en verschillende typen gegevens passen beter in een bepaalde database.

U kunt bijvoorbeeld een productcatalogus opslaan in een documentdatabase, bijvoorbeeld Cosmos DB, dat een flexibel schema kent. In dat geval is elke productomschrijving een document op zich. Voor query's in de hele catalogus, kunt u de catalogus indexeren en de index opslaan in Azure Search. Een productvoorraad kan in een SQL-database worden opgeslagen, omdat hiervoor ACID-garanties zijn vereist.

Vergeet niet dat gegevens meer omvatten dan alleen maar persistente toepassingsgegevens. Er zijn ook toepassingslogboeken, gebeurtenissen, berichten en caches.

Aanbevelingen

Gebruik niet voor alles een relationele database. Overweeg andere archieven, indien dit geschikter is. Zie Het juiste gegevensarchief kiezen.

Gebruik meertalige persistentie. Voor elk grote oplossing geldt dat één technologie voor gegevensopslag waarschijnlijk niet aan al uw eisen voldoet.

Overweeg het soort gegevens. Plaats bijvoorbeeld transactiegegevens in SQL, JSON-documenten in een documentdatabase, telemetriegegevens in een tijdreeksdatabase, toepassingslogboeken in Elasticsearch en blobs in Azure Blob Storage.

Kies voor beschikbaarheid boven (sterke) consistentie. Het CAP-theorema impliceert dat een gedistribueerd systeem een afweging moet maken tussen beschikbaarheid en consistentie. (Netwerkpartities, het andere deel van het CAP-theorema, kunnen nooit volledig worden vermeden.) Vaak kunt u een hogere beschikbaarheid bereiken door een model voor uiteindelijke consistentie te gebruiken.

Kijk eens naar de vaardighedenset van het ontwikkelteam. Het gebruik van meertalige persistentie kent voordelen, maar u kunt ook te ver gaan. Het adopteren van een nieuwe technologie voor gegevensopslag vergt een nieuwe set vaardigheden. Het ontwikkelteam moet weten hoe het maximaal van de technologie kan profiteren. Het moet de juiste gebruikspatronen kennen, hoe query's en prestaties kunnen worden geoptimaliseerd enzovoort. Houd hier rekening mee als u gaat nadenken over opslagtechnologieën.

Compenserende transacties gebruiken. Een neveneffect van meertalige persistentie is dat een transactie gegevens mogelijk naar meerdere archieven wegschrijft. Als er iets fout gaat, gebruikt u compenserende transacties om reeds voltooide stappen ongedaan te maken.

Kijk naar contextgrenzen. Contextgrens is een term uit het domeingestuurde ontwerp. Een contextgrens is een expliciete grens rond een domeinmodel en definieert op welke onderdelen van het domein het model van toepassing is. In het ideale geval wordt een contextgrens toegewezen op een subdomein van het bedrijfsdomein. De contextgrenzen in uw systeem vormen een natuurlijke plek voor meertalige persistentie. 'Producten' bijvoorbeeld kan in zowel het subdomein Productcatalogus als in het subdomein Productvoorraad worden weergegeven. Het is echter goed mogelijk dat deze twee subdomeinen verschillende vereisten kennen voor het opslaan, bijwerken en het uitvoeren van query's van producten.