ACID-garanties in een gedistribueerde documentopslag
U brengt de vier ACID-eigenschappen in verband met de storage engine van MongoDB en begrijpt welke eigenschappen standaard op documentniveau worden geboden.
ACID-garanties in een gedistribueerde documentopslag is een gratis MongoDB Academy-les op CoddyKit. Dit is les 1 van 4. Je kunt de volledige les hieronder gratis lezen en daarna in de browser praktisch oefenen met een ingebouwde code-editor en een AI-begeleider die 24/7 beschikbaar is. Deze les maakt deel uit van het leertraject MongoDB Academy. Je voortgang wordt gesynchroniseerd op het web en in de CoddyKit-app. De cursus MongoDB Academy bevat in totaal 4 lessen.
Wat ACID betekent voor databases
ACID staat voor Atomicity, Consistency, Isolation en Durability: vier eigenschappen die een betrouwbare verwerking van databasebewerkingen garanderen. Deze eigenschappen zijn oorspronkelijk gedefinieerd voor traditionele relationele databases, maar zijn even belangrijk in documentdatabases. Als je begrijpt hoe MongoDB elke eigenschap biedt (of er concessies aan doet), kun je datamodellen en bewerkingen ontwerpen die voldoen aan de betrouwbaarheidsvereisten van je applicatie.
Atomiciteit: alles of niets
Atomiciteit garandeert dat een reeks bewerkingen volledig slaagt of volledig mislukt: er ontstaat geen gedeeltelijke toestand. In MongoDB zijn bewerkingen op één document altijd atomair. Wanneer je updateOne aanroept met meerdere update-operatoren, wordt de volledige wijziging als één atomair geheel toegepast. Dit is mogelijk omdat alle gegevens voor één document doorgaans samen op schijf worden opgeslagen in BSON-indeling.
// This entire updateOne is atomic — both fields change together or neither does
db.accounts.updateOne(
{ _id: accountId },
{
$inc: { balance: -100 },
$push: { transactions: { type: 'debit', amount: 100, date: new Date() } }
}
)Atomiciteit van één document versus meerdere documenten
MongoDB garandeert atomiciteit standaard op het niveau van één document. Omdat een document ingesloten arrays en geneste objecten kan bevatten, kun je wat in SQL meerdere rijen zouden zijn vaak als één document modelleren en gratis profiteren van atomaire updates. Atomiciteit voor meerdere documenten vereist expliciete transacties voor meerdere documenten (beschikbaar sinds MongoDB 4.0 op replicasets). Als je dit onderscheid begrijpt, helpt dat bij beslissingen over je datamodellering.
// No transaction needed: order + line items in one document = atomic
db.orders.insertOne({
_id: orderId,
customerId: customerId,
status: 'pending',
items: [
{ productId: 'P1', qty: 2, price: 29.99 },
{ productId: 'P2', qty: 1, price: 49.99 }
],
total: 109.97
})Consistentie: geldige toestandsovergangen
Consistentie betekent dat de database altijd van de ene geldige toestand naar een andere gaat. In MongoDB wordt consistentie afgedwongen via JSON Schema-validators (veldtypen, vereiste velden, enumwaarden), unieke indexen (geen dubbele waarden) en invarianten op applicatieniveau. In tegenstelling tot traditionele RDBMS'en dwingt MongoDB geen foreign keys van nature af: je applicatiecode of schemadesign moet de referentiële integriteit bewaken.
// JSON Schema validator enforces consistency constraints
db.createCollection('users', {
validator: {
$jsonSchema: {
bsonType: 'object',
required: ['email', 'role'],
properties: {
email: { bsonType: 'string' },
role: { enum: ['admin', 'user', 'guest'] }
}
}
}
})Isolatie: gedrag van gelijktijdige bewerkingen
Isolatie bepaalt hoe gelijktijdige bewerkingen elkaars wijzigingen zien. MongoDB gebruikt snapshot-isolatie voor transacties met meerdere documenten: een transactie ziet een consistente momentopname van de gegevens zoals die waren toen de transactie begon. Buiten transacties kunnen afzonderlijke leesbewerkingen vastgelegde wijzigingen van andere bewerkingen onmiddellijk zien; dit heet isolatie op basis van read committed. Leesvoorkeuren op replicasets bepalen uit welke momentopname je leest.
// Inside a transaction, a consistent snapshot is maintained
const session = client.startSession();
session.startTransaction();
try {
// These two reads see the SAME snapshot even if other writers commit between them
const inventory = await db.collection('inventory').findOne({ _id: itemId }, { session });
const order = await db.collection('orders').findOne({ _id: orderId }, { session });
// ...
await session.commitTransaction();
} finally {
await session.endSession();
}Duurzaamheid: storingen overleven
Duurzaamheid garandeert dat een bewerking, zodra deze is bevestigd, blijft bestaan, zelfs als het systeem crasht. MongoDB bereikt duurzaamheid via het WiredTiger-journal: schrijfbewerkingen worden in een journal vastgelegd voordat ze op gegevensbestanden worden toegepast. Met de optie writeConcern kun je het duurzaamheidsniveau instellen: w:1 bevestigt nadat één node heeft geschreven, terwijl w:majority wacht totdat de meerderheid van de leden van de replicaset de schrijfbewerking heeft opgeslagen.
// w:majority ensures write survives even if the primary fails
db.payments.insertOne(
{ orderId: orderId, amount: 99.99, status: 'completed' },
{ writeConcern: { w: 'majority', j: true } }
// j:true = wait for journal flush on disk
)Schrijfbewerkingen op één document zijn altijd duurzaam
Voor bewerkingen op één document op een replicaset met de standaard schrijfvereiste wacht MongoDB tot de primaire node de schrijfbewerking heeft bevestigd voordat deze antwoordt. Als de bewerking j:true heeft, wacht MongoDB ook totdat het journal naar schijf is weggeschreven. Dit betekent dat schrijfbewerkingen op één document bestand zijn tegen zowel crashes van de primaire node (failover van de replicaset) als schijfstoringen (het journal voorkomt gegevensverlies bij het opnieuw opstarten).
// Default write concern on Atlas: {w: 'majority'} — already durable
// Explicitly requesting journal flush:
await db.collection('criticalAuditLog').insertOne(
{ event: 'payment', userId: userId, timestamp: new Date(), amount: 500 },
{ writeConcern: { w: 'majority', j: true } }
);Het voordeel van ingesloten documenten voor ACID
Een belangrijk inzicht in het ontwerp van MongoDB is dat het insluiten van gerelateerde gegevens in één document in veel gevallen de behoefte aan transacties voor meerdere documenten wegneemt. Een bestelling met haar orderregels, een blogbericht met zijn reacties en een gebruikersprofiel met zijn adressen zijn allemaal afzonderlijke documenten en krijgen daardoor automatisch atomaire, consistente, geïsoleerde en duurzame updates, zonder de overhead van een transactie.
// Updating shipping address + logging the change:
// One atomic write — no transaction needed
await db.collection('users').updateOne(
{ _id: userId },
{
$set: { 'address.street': '123 Main St', 'address.city': 'Austin' },
$push: {
addressHistory: {
changedAt: new Date(),
previous: oldAddress
}
}
}
)Wanneer je ACID voor meerdere documenten nodig hebt
Er zijn situaties waarin insluiten niet werkt en ACID voor meerdere documenten nodig is. Financiële overschrijvingen tussen twee afzonderlijke accountdocumenten (het ene debiteren en het andere crediteren) vereisen atomiciteit over twee documenten. Voorraadreservering (voorraad in één collectie verlagen en een bestelling in een andere aanmaken) vereist isolatie. Updates van een gedistribueerd grootboek over veel records vereisen garanties van alles of niets. Voor deze patronen zijn transacties voor meerdere documenten in MongoDB 4.0+ de oplossing.
// Without a transaction, a crash between these two writes
// leaves the database in an inconsistent state (money debited but not credited):
await db.collection('accounts').updateOne({ _id: fromId }, { $inc: { balance: -100 } });
// <--- system crash here means money is lost!
await db.collection('accounts').updateOne({ _id: toId }, { $inc: { balance: 100 } });
// With a transaction, both succeed or both roll back.ACID versus BASE: een spectrum
Niet alle NoSQL-databases bieden ACID-garanties. Veel vroege NoSQL-systemen kozen voor BASE (Basically Available, Soft state, Eventually consistent) om een hogere schrijfcapaciteit en beschikbaarheid over gedistribueerde nodes te bereiken. MongoDB positioneert zichzelf als een systeem dat standaard ACID op documentniveau biedt en op verzoek volledige ACID voor transacties met meerdere documenten: een middenweg tussen strikte RDBMS'en en databases met uitsluitend uiteindelijke consistentie.
Je eigen schrijfbewerkingen lezen: causale consistentie
In gedistribueerde replicasets ziet een schrijfbewerking op de primaire node en een daaropvolgende leesbewerking vanaf een secundaire node de schrijfbewerking mogelijk nog niet: dit is een consistentieafwijking. De functie causale consistentie van MongoDB (beschikbaar via sessies) garandeert dat bewerkingen binnen een sessie de effecten zien van alle eerdere bewerkingen in diezelfde sessie, zelfs op verschillende servers. Dit is cruciaal voor correct applicatiegedrag na schrijfbewerkingen.
// Causal consistency: guaranteed to read your own writes within a session
const session = client.startSession({ causalConsistency: true });
await db.collection('settings').updateOne(
{ _id: userId }, { $set: { theme: 'dark' } }, { session }
);
// This read is guaranteed to see the update above, even on a secondary:
const settings = await db.collection('settings').findOne({ _id: userId }, { session });
await session.endSession();Korte controle
Test je begrip van de concepten van MongoDB en NoSQL-databases uit deze les.
Samenvatting van de les
In deze les heb je geleerd dat alle bewerkingen op één document in MongoDB standaard volledig ACID-compliant zijn, dat atomiciteit op documentniveau in veel gevallen de behoefte aan transacties wegneemt en dat ACID-transacties voor meerdere documenten (MongoDB 4.0+) situaties afhandelen waarin insluiten niet praktisch is, zoals financiële overschrijvingen tussen afzonderlijke documenten. Hierna bekijken we hoe je sessies opent en transacties voor meerdere documenten schrijft.
Leer JavaScript met een AI-tutor — gratis
Schrijf echte code en voer die uit in je browser, krijg direct hulp van een AI-tutor die 24/7 beschikbaar is en ga verder waar je gebleven bent op het web of in de app.
- Cursussen
- 30
- Lessen
- 120
Veelgestelde vragen
Is de les “ACID-garanties in een gedistribueerde documentopslag” gratis?
Ja — de volledige tekst van “ACID-garanties in een gedistribueerde documentopslag” kun je hier gratis op het web lezen. Als je interactief wilt oefenen met een ingebouwde code-editor en een AI-begeleider die 24/7 beschikbaar is, en de rest van de cursus MongoDB Academy wilt ontgrendelen, kun je upgraden naar CoddyKit PRO. De cursus MongoDB Academy bevat in totaal 4 lessen.
Wat leer ik in “ACID-garanties in een gedistribueerde documentopslag”?
U brengt de vier ACID-eigenschappen in verband met de storage engine van MongoDB en begrijpt welke eigenschappen standaard op documentniveau worden geboden. Je oefent met MongoDB Academy door code rechtstreeks in de browser uit te voeren. Een AI-begeleider die 24/7 beschikbaar is beantwoordt je vragen terwijl je de les doorwerkt.
Heb ik ervaring nodig om met MongoDB Academy te beginnen?
Ervaring vooraf is niet nodig. MongoDB Academy op CoddyKit is opgebouwd voor beginners tot gevorderden, zodat je hier of bij het begin kunt starten en in je eigen tempo kunt leren. Dit is les 1 van 4.
Hoe lang duurt de les “ACID-garanties in een gedistribueerde documentopslag”?
De meeste lessen van CoddyKit duren ongeveer 5–10 minuten. Elke les is kort en interactief, zodat je gestaag vooruitgaat en op het web en in de app precies verdergaat waar je was gebleven.
Kan ik code schrijven en uitvoeren in deze les over MongoDB Academy?
Ja. Elke les over MongoDB Academy bevat een ingebouwde code-editor, zodat je rechtstreeks in je browser echte code kunt schrijven en uitvoeren en direct feedback van AI krijgt — lokale installatie is niet nodig.
Alle lessen in deze cursus
- ACID-garanties in een gedistribueerde documentopslag
- Een sessie en transactie voor meerdere documenten starten
- Foutafhandeling en retrylogica
- Aandachtspunten voor transactieprestaties