Hållbarhet är "D" i "ACID"-egenskaperna (A – Atomicity, C – Consistency, I – Isolation), populariserad av traditionella relationsdatabashanteringssystem (RDBMS). Hållbarhet är garantin för att skrivna data har sparats och kommer att överleva permanent. NoSQL-databaser som MongoDB ger utvecklare finkornig kontroll över hållbarheten för sina skrivsamtal. Detta gör det möjligt för utvecklare att välja olika modeller för hållbarhet, säkerhet och prestanda för olika klasser av data. Detta lägger emellertid också bördan på utvecklaren att urskilja och förstå nyanserna i de olika skrivsäkerhetsalternativen. I det här inlägget kommer vi att titta på de olika alternativen för skrivsäkerhet som finns i Java-drivrutinen.
I MongoDB-språk kallas detta "Write Concern". Skrivproblem varierar från "svag" till "stark". Svaga skrivproblem kan leda till högre genomströmning men ger mindre datasäkerhet och starka skrivproblem är vice versa.
Java-drivrutinen låter dig specificera dina skrivsäkerhetsalternativ med hjälp av flera teleskopkonstruktörer. Här är konstruktören med alla alternativ:
WriteConcern(int w, int wtimeout, boolean fsync, boolean j, boolean continueOnError)
Som du kan se har den här konstruktören många alternativ. För att göra det enklare för utvecklare tillhandahålls "Tags" för vanliga skrivproblem - Unacknowledged, Acknowledged, Journalled, Fsynced och Replica Acknowledged. Varje tagg mappas till en viss anrop av ovanstående konstruktor.
Obekräftat MongoDB-läge
Detta är "eld och glöm"-läget. MongoDB-drivrutinen försöker inte bekräfta mottagandet av skrivoperationer. Till exempel, om din MongoDB-tjänst är nere och du använder det här läget ignoreras alla fel tyst och dina data går förlorade. Uppenbarligen bör du bara använda det här läget för data med lågt värde där skrivkapacitet är viktigare än förlust av en viss mängd data. Detta läge kan specificeras enligt följande:
new WriteConcern(0) / WriteConcern.UNACKNOWLEDGED
Erkänt MongoDB-läge
Detta är standardskrivläget för MongoDB. I det här läget försöker MongoDB-drivrutinen att bekräfta mottagandet av skrivoperationer på servern, vilket gör att drivrutinen kan fånga eventuella nätverksfel, dubbletter av nycklar etc. Detta garanterar dock inte att data sparas på disken. Om MongoDB-servern kraschar efter att ha bekräftat skrivningen, men innan den överförs till disk, går data förlorad. Detta läge kan specificeras enligt följande:
new WriteConcern(1) / WriteConcern.ACKNOWLEDGED
Journaled MongoDB-läge
I det här läget bekräftar MongoDB-servern skrivningen först efter att ha skickat data till journalen. När du använder det här läget, även om servern kraschar vid omstart av servern, appliceras data igen från journalen. Uppenbarligen måste journalföring vara aktiverat för att detta ska fungera. Alla produktionssystem bör ha journalföring aktiverat, och du kan lära dig mer om detta i vårt inlägg Ska du aktivera MongoDB-journalföring?
I ett replikuppsättningsscenario gäller journalskrivningsproblemen endast den primära. Som standard är journalen ansluten till disk var 100:e ms. När du anger en skrivning med alternativet journalad, läggs journalen på disk på 30 ms. Så, om du anger j:true för varje skrivning, kommer din genomströmning att vara maximalt 1000/30 =33,3 skrivningar/sek. Om du vill ha bättre genomströmning måste du batcha dina uppdateringar och ställa in j:true för den senaste uppdateringen av batchen. Detta läge kan specificeras enligt följande:
WriteConcern( 1, 0, false, true ) / WriteConcern.JOURNALLED
Fsynced MongoDB Mode
I det här läget bekräftar MongoDB-servern skrivningen först efter att skrivningen har skrivits till disken. Detta läge kan specificeras enligt följande:
new WriteConcern(true) / WriteConcern.FSYNCED
Replica Acknowledged MongoDB Mode
De tidigare skrivsäkerhetslägena gäller endast för en enda server. När du kör replikuppsättningar har du möjlighet att styra hur många repliker din skrivning behöver skrivas innan den anses vara framgångsrik. Till exempel, med skrivproblemet "w:2", måste skrivningen skrivas till en primär och minst en sekundär innan den anses vara framgångsrik. Detta minskar genomströmningen men ger dig bättre säkerhet. Om du inte är medveten om antalet repliker i förväg kan du använda WriteConcern.MAJORITY-taggen för att säkerställa att data sparas i majoriteten av replikerna. Detta är det säkraste alternativet i MongoDB. Om du ska använda det här alternativet, se också till att ställa in "wtimeout"-värdet för att indikera hur länge kommandot ska vänta innan fel returneras:
new WriteConcern(2)/ REPLICA_ACKNOWLEDGED new Majority()/ WriteConcern.MAJORITY
Följande taggar har fasats ut (eller planerar att bli det) – ERRORS_IGNORED, NORMAL, SAFE, FSYNC_SAFE, JOURNAL_SAFE, REPLICAS_SAFE. Använd de nyare alternativen istället för dessa alternativ. Som alltid, om du har några kommentarer eller frågor vänligen kontakta oss på [email protected].