Duurzaamheid is de 'D' in de 'ACID'-eigenschappen (A - Atomiciteit, C - Consistentie, I - Isolatie), populair door traditionele relationele databasebeheersystemen (RDBMS). Duurzaamheid is de garantie dat geschreven gegevens zijn opgeslagen en permanent zullen blijven bestaan. NoSQL-databases zoals MongoDB geven ontwikkelaars gedetailleerde controle over de duurzaamheid van hun schrijfaanroepen. Hierdoor kunnen ontwikkelaars verschillende duurzaamheids-, veiligheids- en prestatiemodellen kiezen voor verschillende gegevensklassen. Dit legt echter ook de last op de ontwikkelaar om de nuances van de verschillende schrijfbeveiligingsopties te onderscheiden en te begrijpen. In dit bericht zullen we kijken naar de verschillende opties voor schrijfbeveiliging in het Java-stuurprogramma.
In MongoDB-taal heet dit "Write Concern". Schrijfproblemen variëren van 'zwak' tot 'sterk'. Zwakke schrijfproblemen kunnen leiden tot een hogere doorvoer, maar bieden minder gegevensveiligheid en sterke schrijfproblemen zijn omgekeerd.
Met het Java-stuurprogramma kunt u uw schrijfbeveiligingsopties specificeren met behulp van verschillende telescopische constructors. Hier is de constructor met alle opties:
WriteConcern(int w, int wtimeout, boolean fsync, boolean j, boolean continueOnError)
Zoals je kunt zien, heeft deze constructor veel opties. Om het voor ontwikkelaars gemakkelijker te maken, zijn er "Tags" voor veelvoorkomende schrijfproblemen:Unacknowledged, Acknowledged, Journalled, Fsynced en Replica Acknowledged. Elke tag verwijst naar een bepaalde aanroep van de bovenstaande constructor.
Niet-bevestigde MongoDB-modus
Dit is de modus "vuren en vergeten". Het MongoDB-stuurprogramma probeert niet de ontvangst van schrijfbewerkingen te bevestigen. Als uw MongoDB-service bijvoorbeeld niet beschikbaar is en u deze modus gebruikt, worden alle fouten stil genegeerd en gaan uw gegevens verloren. Het is duidelijk dat u deze modus alleen moet gebruiken voor gegevens met een lage waarde, waarbij de schrijfsnelheid belangrijker is dan het verlies van een bepaalde hoeveelheid gegevens. Deze modus kan als volgt worden gespecificeerd:
new WriteConcern(0) / WriteConcern.UNACKNOWLEDGED
Erkende MongoDB-modus
Dit is de standaard schrijfmodus voor MongoDB. In deze modus probeert het MongoDB-stuurprogramma de ontvangst van schrijfbewerkingen op de server te bevestigen, waardoor het stuurprogramma netwerkfouten, fouten met dubbele sleutels, enz. kan opvangen. Dit garandeert echter niet dat gegevens op de schijf worden opgeslagen. Als de MongoDB-server crasht nadat het schrijven is bevestigd, maar voordat het op schijf wordt vastgelegd, gaan de gegevens verloren. Deze modus kan als volgt worden gespecificeerd:
new WriteConcern(1) / WriteConcern.ACKNOWLEDGED
MongoDB-modus met dagboek
In deze modus bevestigt de MongoDB-server het schrijven pas nadat de gegevens in het journaal zijn vastgelegd. Als u deze modus gebruikt, worden de gegevens opnieuw toegepast vanuit het journaal, zelfs als de server crasht bij het opnieuw opstarten van de server. Het is duidelijk dat journaling moet zijn ingeschakeld om dit te laten werken. Op alle productiesystemen moet logboekregistratie zijn ingeschakeld, en u kunt hier meer over lezen in ons bericht Moet u MongoDB-logboekregistratie inschakelen?
In een scenario met een replicaset zijn de schrijfproblemen bij journaling alleen van toepassing op de primaire. Standaard wordt het journaal elke 100 ms op schijf vastgelegd. Wanneer u een schrijfbewerking opgeeft met de journaaloptie, wordt het journaal binnen 30 ms op schijf vastgelegd. Dus als u j:true opgeeft voor elke schrijfbewerking, is uw doorvoer maximaal 1000/30 =33,3 schrijfbewerkingen/sec. Als u een betere doorvoer wilt, moet u uw updates batchgewijs en j:true instellen voor de laatste update van de batch. Deze modus kan als volgt worden gespecificeerd:
WriteConcern( 1, 0, false, true ) / WriteConcern.JOURNALLED
Fgesynchroniseerde MongoDB-modus
In deze modus bevestigt de MongoDB-server het schrijven pas nadat het schrijven naar de schijf is geschreven. Deze modus kan als volgt worden gespecificeerd:
new WriteConcern(true) / WriteConcern.FSYNCED
Replica-bevestigde MongoDB-modus
De vorige schrijfbeveiligingsmodi zijn alleen van toepassing op een enkele server. Wanneer u replicasets uitvoert, hebt u de mogelijkheid om te bepalen hoeveel replica's uw schrijfbewerkingen moeten worden geschreven voordat deze als succesvol worden beschouwd. Met een schrijfprobleem van 'w:2' moet het schrijven bijvoorbeeld naar één primair en ten minste één secundair worden geschreven voordat het als succesvol wordt beschouwd. Dit vermindert de doorvoer, maar geeft u meer veiligheid. Als u het aantal replica's niet van tevoren weet, kunt u de WriteConcern.MAJORITY-tag gebruiken om ervoor te zorgen dat de gegevens in de meeste replica's worden opgeslagen. Dit is de veiligste optie in MongoDB. Als u deze optie gaat gebruiken, zorg er dan ook voor dat u de waarde "wtimeout" instelt om aan te geven hoe lang de opdracht moet wachten voordat de fout terugkeert:
new WriteConcern(2)/ REPLICA_ACKNOWLEDGED new Majority()/ WriteConcern.MAJORITY
De volgende tags zijn verouderd (of zijn van plan dit te worden):ERRORS_IGNORED, NORMAL, SAFE, FSYNC_SAFE, JOURNAL_SAFE, REPLICAS_SAFE. Gebruik de nieuwere opties in plaats van deze opties. Als je opmerkingen of vragen hebt, neem dan zoals altijd contact met ons op via [email protected].