Een overzicht van ACID-transacties met meerdere documenten in MongoDB en hoe ze te gebruiken

Databasesystemen hebben een mandaat om de consistentie en integriteit van gegevens te garanderen, vooral wanneer het om kritieke gegevens gaat. Deze aspecten worden afgedwongen via ACID-transacties in MongoDB. Een ACID-transactie moet voldoen aan een aantal gedefinieerde regels voor gegevensgeldigheid voordat er updates in de database worden aangebracht, anders moet deze worden afgebroken en mogen er geen wijzigingen in de database worden aangebracht. Alle databasetransacties worden beschouwd als een enkele logische bewerking en gedurende de uitvoeringstijd wordt de database in een inconsistente toestand gebracht totdat de wijzigingen zijn doorgevoerd. Bewerkingen die de status van de database met succes wijzigen, worden schrijftransacties genoemd, terwijl bewerkingen die de database niet bijwerken maar alleen gegevens ophalen, alleen-lezen transacties worden genoemd. ACID is een acroniem voor Atomiciteit, Consistentie, Isolatie en Duurzaamheid.

Een database is een gedeelde bron die door verschillende gebruikers tegelijk of op verschillende tijdstippen kan worden geopend. Om deze reden kunnen er gelijktijdige transacties plaatsvinden en als ze niet goed worden beheerd, kunnen ze leiden tot systeemcrashes, hardwarestoringen, impasses, trage databaseprestaties of herhaling van de uitvoering van dezelfde transactie.

Wat zijn ACID-regels?

Alle databasesystemen moeten voldoen aan de ACID-eigenschappen om de gegevensintegriteit te garanderen.

Atomiciteit

Een transactie wordt beschouwd als een enkele operatie die volledig kan slagen of volledig kan mislukken. Een transactie kan niet gedeeltelijk worden uitgevoerd. Als een voorwaarde die een transactie raadpleegt mislukt, zal de hele transactie volledig mislukken en blijft de database ongewijzigd. Als u bijvoorbeeld geld van rekening X naar Y wilt overboeken, zijn er twee transacties, de eerste is om geld van X te verwijderen en de tweede is om het geld op Y te registreren. Als de eerste transactie mislukt, wordt de hele transactie wordt afgebroken

Consistentie

Wanneer een bewerking wordt uitgevoerd, is de database vóór uitvoering in een consistente staat en dat zou zo moeten blijven na elke transactie. Zelfs als er een update is, moet de transactie de database altijd in een geldige staat brengen, waarbij de database-invarianten behouden blijven. U kunt bijvoorbeeld geen primaire sleutel verwijderen waarnaar in een andere verzameling als externe sleutel is verwezen. Alle gegevens moeten voldoen aan de gedefinieerde beperkingen om corruptie van gegevens door een illegale transactie te voorkomen.

Isolatie

Meerdere transacties die gelijktijdig worden uitgevoerd, worden uitgevoerd zonder elkaar te beïnvloeden en hun resultaat zou hetzelfde moeten zijn als ze opeenvolgend zouden worden uitgevoerd. Wanneer twee of meer transacties dezelfde documenten in MongoDB wijzigen, kan er een conflict ontstaan. De database detecteert een conflict onmiddellijk voordat het wordt gepleegd. De eerste handeling om het document te vergrendelen zal doorgaan, terwijl de andere zal mislukken en een conflictfoutmelding zal worden weergegeven.

Duurzaamheid

Dit dicteert dat, zodra de transactie is doorgevoerd, de wijzigingen te allen tijde moeten worden gehandhaafd, zelfs in het geval van een systeemstoring, bijvoorbeeld als gevolg van stroomuitval of het wegvallen van internet.

MongoDB ACID-transacties

MongoDB is een op documenten gebaseerde NoSQL-database met een flexibel schema. Transacties zijn geen bewerkingen die voor elke schrijfbewerking moeten worden uitgevoerd, omdat ze hogere prestatiekosten met zich meebrengen dan het schrijven van één document. Met een op documenten gebaseerde structuur en een gedenormaliseerd datamodel, zal er een minimale behoefte aan transacties zijn. Aangezien MongoDB het insluiten van documenten toestaat, hoeft u niet per se een transactie te gebruiken om aan een schrijfbewerking te voldoen.

MongoDB versie 4.0 biedt alleen ondersteuning voor transacties met meerdere documenten voor implementaties van replicasets en waarschijnlijk zal versie 4.2 de ondersteuning voor shard-implementaties uitbreiden (volgens hun release-opmerkingen).

Voorbeeld van een transactie:

Zorg dat je eerst een replicaset hebt. Ervan uitgaande dat u een database hebt met de naam app en een verzameling, voeren gebruikers in de Mongo Shell de volgende opdrachten uit:

$mongos en je zou zoiets moeten zien als gebruikersnaam:PRIMARY>

$use app

$db.users.insert([{_id:1, name: ‘Brian’}, {_id:2, name: ‘Sheila’}, {_id:3, name: ‘James’}])

We moeten een sessie starten voor onze transactie:

$db.getMongo().startSession() and you should see something like 

session { "id" : UUID("dcfa8de5-627d-3b1c-a890-63c9a355520c") }

Met deze sessie kunnen we meer gebruikers toevoegen via een transactie met de volgende opdrachten

$session.startTransaction()

session.getDatabase(‘app’).users.insert({_id:4, name:  ‘Hitler’})

Je krijgt WriteResult({“nInsterted”:2})

te zien

De transactie is nog niet uitgevoerd en de normale $db.users.find({}) geeft ons alleen de eerder opgeslagen gebruikers. Maar als we de

$session.getDatabase(“app”).users.find()

het laatst toegevoegde record zal beschikbaar zijn in de geretourneerde resultaten. Om deze transactie vast te leggen, voeren we de onderstaande opdracht uit

$session.commitTransaction()

De wijziging van de transactie wordt in het geheugen opgeslagen, daarom zijn de gegevens zelfs na een fout beschikbaar bij herstel.

Multi-document ACID-transacties in MongoDB

Dit zijn bewerkingen met meerdere instructies die opeenvolgend moeten worden uitgevoerd zonder elkaar te beïnvloeden. Voor het bovenstaande voorbeeld kunnen we twee transacties maken, een om een gebruiker toe te voegen en een andere om een gebruiker met een leeftijdsveld bij te werken. D.w.z.

$session.startTransaction()

   db.users.insert({_id:6, name “Ibrahim”})

   db.users.updateOne({_id:3 , {$set:{age:50}}})

session.commit_transaction()

Transacties kunnen worden toegepast op bewerkingen tegen meerdere documenten in één of meerdere verzamelingen/databases. Wijzigingen als gevolg van documenttransacties hebben geen invloed op de prestaties voor niet-gerelateerde werkbelastingen of vereisen deze niet. Totdat de transactie is vastgelegd, worden niet-vastgelegde schrijfbewerkingen niet gerepliceerd naar de secundaire knooppunten en zijn ze ook niet leesbaar buiten de transacties.

Beste praktijken voor MongoDB-transacties

De transacties met meerdere documenten worden alleen ondersteund in de WiredTiger-opslagengine. Zoals eerder vermeld, zouden maar heel weinig applicaties transacties vereisen en als dat zo is, moeten we proberen ze kort te houden. Anders, voor een enkele ACID-transactie, als u probeert een buitensporig aantal bewerkingen uit te voeren, kan dit resulteren in hoge druk op de WiredTiger-cache. De cache wordt altijd gedicteerd om de status te behouden voor alle volgende schrijfbewerkingen sinds de oudste momentopname is gemaakt. Dit betekent dat nieuwe schrijfacties zich in de cache ophopen tijdens de duur van de transactie en alleen worden gewist nadat transacties die momenteel op oude snapshots worden uitgevoerd, zijn vastgelegd of afgebroken. Voor de beste databaseprestaties op de transactie moeten ontwikkelaars het volgende overwegen:

Wijzig altijd een klein aantal documenten in een transactie. Anders moet u de transactie in verschillende delen opsplitsen en de documenten in verschillende batches verwerken. Verwerk maximaal 1000 documenten tegelijk.
Tijdelijke uitzonderingen, zoals wachten op primaire en tijdelijke netwerkstoringen, kunnen ertoe leiden dat de transactie wordt afgebroken. Ontwikkelaars moeten een logica ontwikkelen om de transactie opnieuw te proberen als de gedefinieerde fouten worden weergegeven.
Configureer de optimale duur voor de uitvoering van de transactie vanaf de standaard 60 seconden geleverd door MongoDB. Gebruik daarnaast indexering zodat het snelle gegevenstoegang binnen de transactie mogelijk maakt. U hebt ook de flexibiliteit om de transactie te verfijnen bij het aanpakken van time-outs door deze op te delen in batches die uitvoering binnen de tijdslimieten mogelijk maken.
Deel uw transactie op in een kleine reeks bewerkingen zodat deze past binnen de beperkingen van 16 MB. Anders, als de bewerking samen met de oplogbeschrijving deze limiet overschrijdt, wordt de transactie afgebroken.
Alle gegevens met betrekking tot een entiteit moeten worden opgeslagen in een enkele, uitgebreide documentstructuur. Dit is om het aantal documenten dat in de cache moet worden opgeslagen te verminderen wanneer verschillende velden worden gewijzigd.

Beperkingen van transacties

U kunt geen collectie maken of verwijderen binnen een transactie.
Transacties kunnen niet schrijven naar een gelimiteerde verzameling
Transacties nemen veel tijd in beslag om uit te voeren en op de een of andere manier kunnen ze de prestaties van de database vertragen.
De transactiegrootte is beperkt tot 16 MB, waardoor een transactie die deze grootte overschrijdt, moet worden opgesplitst in kleinere transacties.
Het onderwerpen van een groot aantal documenten aan een transactie kan buitensporige druk uitoefenen op de WiredTiger-engine en aangezien deze afhankelijk is van de snapshot-mogelijkheid, zullen grote niet-gespoelde bewerkingen in het geheugen worden bewaard. Dit brengt wat prestatiekosten met zich mee voor de database.

Conclusie

MongoDB versie 4.0 introduceerde de multi-document transactie-ondersteuning voor replicasets als een functie om de gegevensintegriteit en consistentie te verbeteren. Er zijn echter maar heel weinig applicaties waarvoor transacties nodig zijn bij het gebruik van MongoDB. Er zijn beperkingen tegen deze functie die het behoorlijk onvolwassen maken wat betreft het transactieconcept. Transacties voor een shard-cluster worden bijvoorbeeld niet ondersteund en mogen niet groter zijn dan de limiet van 16 MB. Gegevensmodellering biedt een betere structuur voor het verminderen van transacties in uw database. Tenzij u te maken heeft met speciale gevallen, is het een betere gewoonte om transacties in MongoDB te vermijden.