ACID-garantier i ett distribuerat dokumentlager
Ni kopplar de fyra ACID-egenskaperna till MongoDB:s lagringsmotor och förstår vilka som tillhandahålls som standard på enskild dokumentnivå.
ACID-garantier i ett distribuerat dokumentlager är en gratis lektion i MongoDB Academy på CoddyKit. Detta är lektion 1 av 4. Ni kan läsa hela lektionen gratis nedan och sedan öva praktiskt i webbläsaren med en inbyggd kodredigerare och en AI-handledare som är tillgänglig dygnet runt. Den ingår i lärvägen för MongoDB Academy, och Era framsteg synkroniseras mellan webben och CoddyKit-appen. Kursen i MongoDB Academy innehåller totalt 4 lektioner.
Vad ACID innebär för databaser
ACID står för Atomicity, Consistency, Isolation och Durability – fyra egenskaper som garanterar tillförlitlig bearbetning av databasoperationer. Dessa egenskaper definierades först för traditionella relationsdatabaser, men är lika viktiga i dokumentdatabaser. Genom att förstå hur MongoDB tillhandahåller (eller gör avvägningar kring) varje egenskap kan du utforma datamodeller och operationer som uppfyller applikationens krav på tillförlitlighet.
Atomicitet: allt eller inget
Atomicitet garanterar att en uppsättning operationer antingen lyckas helt eller misslyckas helt – det finns inget partiellt tillstånd. I MongoDB är operationer på ett enskilt dokument alltid atomära. När du anropar updateOne med flera uppdateringsoperatorer tillämpas hela ändringen som en enda atomär enhet. Detta är möjligt eftersom all data för ett dokument vanligtvis lagras tillsammans på disken i BSON-format.
// 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() } }
}
)Atomicitet för ett dokument jämfört med flera dokument
MongoDB garanterar atomicitet som standard på nivån för ett enskilt dokument. Eftersom ett dokument kan innehålla inbäddade arrayer och nästlade objekt kan du ofta modellera det som skulle ha varit flera SQL-rader som ett enda dokument och få atomära uppdateringar utan extra arbete. Atomicitet för flera dokument kräver explicita transaktioner för flera dokument (tillgängliga sedan MongoDB 4.0 i replikuppsättningar). Att förstå denna skillnad vägleder dina beslut om 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
})Konsistens: giltiga tillståndsövergångar
Konsistens innebär att databasen alltid går från ett giltigt tillstånd till ett annat. I MongoDB upprätthålls konsistensen genom JSON Schema-validerare (fält- och obligatoriska fält, fälttyper och enum-värden), unika index (inga dubblettvärden) och invarianter på applikationsnivå. Till skillnad från traditionella RDBMS tillämpar MongoDB inte främmande nycklar inbyggt – applikationskoden eller schemadesignen måste upprätthålla referensintegriteten.
// 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'] }
}
}
}
})Isolering: beteende vid samtidiga operationer
Isolering styr hur samtidiga operationer ser varandras ändringar. MongoDB använder snapshot-isolering för transaktioner med flera dokument: en transaktion ser en konsekvent ögonblicksbild av data så som den såg ut när transaktionen startade. Utanför transaktioner kan enskilda läsningar omedelbart se ändringar som andra operationer har committat – detta kallas isolering med read committed. Läsinställningar i replikuppsättningar påverkar vilken ögonblicksbild du läser från.
// 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();
}Beständighet: att överleva fel
Beständighet garanterar att en operation finns kvar när den väl har bekräftats, även om systemet kraschar. MongoDB uppnår beständighet genom WiredTiger-journalen – skrivningar registreras i en journal innan de tillämpas på datafilerna. Alternativet writeConcern låter dig styra beständighetsnivån: w:1 bekräftar efter att en nod har skrivit, medan w:majority väntar tills en majoritet av replikuppsättningens medlemmar har sparat skrivningen.
// 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
)Skrivningar av ett enskilt dokument är alltid beständiga
För operationer på ett enskilt dokument i en replikuppsättning med standardinställningen för write concern väntar MongoDB på att primärnoden ska bekräfta skrivningen innan ett svar skickas. Om operationen har j:true väntar den även på att journalen ska spolas till disken. Det innebär att skrivningar av ett enskilt dokument är beständiga både vid krascher i primärnoden (failover för replikuppsättningen) och vid diskfel (journalen säkerställer att inga data går förlorade vid omstart).
// 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 } }
);Fördelen med inbäddade dokument för ACID
En av MongoDB:s viktigaste designinsikter är att inbäddning av relaterade data i ett enda dokument i många fall eliminerar behovet av transaktioner för flera dokument. En order med sina orderrader, ett blogginlägg med sina kommentarer eller en användarprofil med sina adresser – allt detta är enskilda dokument och får därför atomära, konsekventa, isolerade och beständiga uppdateringar utan extra arbete och utan transaktionens overhead.
// 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
}
}
}
)När ACID för flera dokument behövs
Det finns scenarier där inbäddning inte fungerar och ACID för flera dokument är nödvändigt. Ekonomiska överföringar mellan två separata kontodokument (debitera det ena och kreditera det andra) kräver atomicitet över två dokument. Reservering av lager (minska lagersaldot i en samling och skapa en order i en annan) kräver isolering. Uppdateringar av distribuerade liggare över många poster kräver garantier om allt eller inget. För dessa mönster är transaktioner för flera dokument i MongoDB 4.0 eller senare lösningen.
// 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 kontra BASE: ett spektrum
Alla NoSQL-databaser tillhandahåller inte ACID-garantier. Många tidiga NoSQL-system valde BASE (Basically Available, Soft state, Eventually consistent) för att uppnå högre skrivgenomströmning och tillgänglighet över distribuerade noder. MongoDB positionerar sig som en databas som som standard tillhandahåller ACID på dokumentnivå och fullständig ACID för transaktioner med flera dokument på begäran – en medelväg mellan strikta RDBMS och databaser som är helt eventual-consistent.
Läs dina egna skrivningar: kausal konsistens
I distribuerade replikuppsättningar kan en skrivning på primärnoden följas av en läsning från en sekundärnod som ännu inte ser skrivningen – detta är en konsistensavvikelse. MongoDB:s funktion för kausal konsistens (tillgänglig via sessioner) garanterar att operationer i en session ser effekterna av alla tidigare operationer i samma session, även mellan olika servrar. Detta är avgörande för att applikationen ska fungera korrekt efter skrivningar.
// 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();Snabbtest
Testa dina kunskaper om begreppen MongoDB och NoSQL Databases från den här lektionen.
Sammanfattning av lektionen
I den här lektionen lärde du dig att alla operationer på enskilda dokument i MongoDB som standard är fullt ACID-kompatibla, att atomicitet på dokumentnivå eliminerar behovet av transaktioner i många fall och att ACID-transaktioner för flera dokument (MongoDB 4.0 eller senare) hanterar fall där inbäddning inte är praktiskt, till exempel ekonomiska överföringar mellan separata dokument. Härnäst utforskar vi hur du öppnar sessioner och skriver transaktioner för flera dokument.
Lär dig JavaScript med en AI-lärare – gratis
Skriv och kör riktig kod i webbläsaren, få omedelbar hjälp av en AI-lärare dygnet runt och fortsätt där du slutade – på webben eller i appen.
- Kurser
- 30
- Lektioner
- 120
Vanliga frågor
Är lektionen ”ACID-garantier i ett distribuerat dokumentlager” gratis?
Ja – hela texten till ”ACID-garantier i ett distribuerat dokumentlager” kan läsas gratis här på webben. Om Ni vill öva interaktivt med en inbyggd kodredigerare och en AI-handledare som är tillgänglig dygnet runt och låsa upp resten av kursen i MongoDB Academy, kan Ni uppgradera till CoddyKit PRO. Kursen i MongoDB Academy innehåller totalt 4 lektioner.
Vad lär jag mig i ”ACID-garantier i ett distribuerat dokumentlager”?
Ni kopplar de fyra ACID-egenskaperna till MongoDB:s lagringsmotor och förstår vilka som tillhandahålls som standard på enskild dokumentnivå. Ni övar på MongoDB Academy med praktisk kod som körs direkt i webbläsaren, medan en AI-handledare som är tillgänglig dygnet runt svarar på Era frågor under lektionen.
Behöver jag någon erfarenhet för att börja lära mig MongoDB Academy?
Du behöver inga förkunskaper. Utbildningen i MongoDB Academy på CoddyKit är upplagd för allt från nybörjare till avancerade elever, så att du kan börja här eller från början och gå fram i din egen takt. Detta är lektion 1 av 4.
Hur lång tid tar lektionen ”ACID-garantier i ett distribuerat dokumentlager”?
De flesta CoddyKit-lektioner tar cirka 5–10 minuter. Varje lektion är kort och interaktiv, så att du gör stadiga framsteg och kan fortsätta precis där du slutade – på webben eller i appen.
Kan jag skriva och köra kod i den här MongoDB Academy-lektionen?
Ja. Varje MongoDB Academy-lektion innehåller en inbyggd kodredigerare, så att du kan skriva och köra riktig kod direkt i webbläsaren och få omedelbar AI-feedback – utan lokal installation.
Alla lektioner i den här kursen
- ACID-garantier i ett distribuerat dokumentlager
- Starta en session och en transaktion med flera dokument
- Felhantering och logik för nya försök
- Prestandaöverväganden för transaktioner