sql >> Database teknologi >  >> NoSQL >> MongoDB

Forstå holdbarhed og skrivesikkerhed i MongoDB

Holdbarhed er "D" i "ACID"-egenskaberne (A – Atomicitet, C – Konsistens, I – Isolation), populært af traditionelle relationelle databasestyringssystemer (RDBMS). Holdbarhed er garantien for, at skrevne data er blevet gemt og vil overleve permanent. NoSQL-databaser som MongoDB giver udviklere finmasket kontrol over holdbarheden af ​​deres skriveopkald. Dette gør det muligt for udviklere at vælge forskellige modeller for holdbarhed, sikkerhed og ydeevne for forskellige dataklasser. Dette lægger dog også byrden på udvikleren til at gennemskue og forstå nuancerne i de forskellige skrivesikkerhedsmuligheder. I dette indlæg vil vi se på de forskellige muligheder for skrivesikkerhed i Java-driveren.

I MongoDB-sprog kaldes dette "Write Concern". Skriveproblemer varierer fra "svag" til "stærk". Svag skrivebekymring kan føre til højere gennemløb, men giver mindre datasikkerhed og stærke skrivebekymringer er omvendt.

Java-driveren giver dig mulighed for at angive dine skrivesikkerhedsindstillinger ved hjælp af flere teleskop-konstruktører. Her er konstruktøren med alle muligheder:

WriteConcern(int w, int wtimeout, boolean fsync, boolean j, boolean continueOnError)

Som du kan se, har denne konstruktør en masse muligheder. For at gøre det nemmere for udviklere er "Tags" tilvejebragt for almindelige skrivebekymringsværdier - Ikke-bekræftet, Bekræftet, Journalført, Fsynkroniseret og Replika Bekræftet. Hvert tag er knyttet til en bestemt påkaldelse af ovenstående konstruktør.

Ikke anerkendt MongoDB-tilstand

Dette er "ild og glem"-tilstanden. MongoDB-driveren forsøger ikke at bekræfte modtagelsen af ​​skriveoperationer. For eksempel, hvis din MongoDB-tjeneste er nede, og du bruger denne tilstand, ignoreres alle fejlene stille, og dine data går tabt. Det er klart, at du kun skal bruge denne tilstand til data med lav værdi, hvor skrivegennemstrømning er vigtigere end tab af en vis mængde data. Denne tilstand kan specificeres som følger:

new WriteConcern(0) / WriteConcern.UNACKNOWLEDGED

Anerkendt MongoDB-tilstand

Dette er standard skrivetilstand for MongoDB. I denne tilstand forsøger MongoDB-driveren at bekræfte modtagelsen af ​​skriveoperationer på serveren, hvilket giver driveren mulighed for at fange eventuelle netværksfejl, duplikatnøglefejl osv. Dette garanterer dog ikke, at data er gemt på disken. Hvis MongoDB-serveren går ned efter at have bekræftet skrivningen, men før den er overført til disken, går dataene tabt. Denne tilstand kan specificeres som følger:

new WriteConcern(1) / WriteConcern.ACKNOWLEDGED

Journal MongoDB-tilstand

I denne tilstand anerkender MongoDB-serveren kun skrivningen efter at have overført dataene til journalen. Når du bruger denne tilstand, bliver dataene genanvendt fra journalen, selvom serveren går ned ved genstart af serveren. Det er klart, at journalføring skal være aktiveret for at dette kan fungere. Alle produktionssystemer bør have journalføring aktiveret, og du kan lære mere om dette i vores indlæg Skal du aktivere MongoDB-journalisering?

I et scenarie med replikaer gælder journaliseringsskrivningen kun for den primære. Som standard er journalen forpligtet til disk hver 100 ms. Når du angiver en skrivning med indstillingen journaliseret, er journalen forpligtet til disk på 30 ms. Så hvis du angiver j:true for hver skrivning, vil din gennemstrømning maksimalt være 1000/30 =33,3 skrivninger/sek. Hvis du vil have bedre gennemløb, skal du batch dine opdateringer og indstille j:true for den sidste opdatering af batchen. Denne tilstand kan specificeres som følger:

WriteConcern( 1, 0, false, true ) / WriteConcern.JOURNALLED

Fsynced MongoDB Mode

I denne tilstand anerkender MongoDB-serveren kun skrivningen efter skrivningen er skrevet til disken. Denne tilstand kan specificeres som følger:

new WriteConcern(true) / WriteConcern.FSYNCED

Replica Acknowledged MongoDB Mode

De tidligere skrivesikkerhedstilstande gælder kun for en enkelt server. Når du kører replikasæt, har du mulighed for at kontrollere, hvor mange replikaer din skrivning skal skrives, før den anses for at være vellykket. For eksempel, med skriveproblemet "w:2", skal skrivningen skrives til én primær og mindst én sekundær, før den anses for vellykket. Dette reducerer gennemløbet, men giver dig bedre sikkerhed. Hvis du ikke på forhånd er klar over antallet af replikaer, kan du bruge WriteConcern.MAJORITY-tagget til at sikre, at dataene gemmes i størstedelen af ​​replikaerne. Dette er den sikreste mulighed i MongoDB. Hvis du vil bruge denne mulighed, skal du også sørge for at indstille "wtimeout"-værdien for at angive, hvor længe kommandoen skal vente, før den returnerer fejl:

new WriteConcern(2)/ REPLICA_ACKNOWLEDGED
new Majority()/ WriteConcern.MAJORITY

Følgende tags er blevet forældet (eller planlægger at blive det) – ERRORS_IGNORED, NORMAL, SAFE, FSYNC_SAFE, JOURNAL_SAFE, REPLICAS_SAFE. Brug venligst de nyere muligheder i stedet for disse muligheder. Som altid, hvis du har kommentarer eller spørgsmål, bedes du kontakte os på [email protected].


  1. MongoDB PHP UTF-8 problemer

  2. Redis:Summen af ​​SCORES i sorteret sæt

  3. MongoDB Date() metode

  4. Integration af ClusterControl med SNMP:Anden del