La durabilità è la "D" nelle proprietà "ACID" (A – Atomicity, C – Consistency, I – Isolation), rese popolari dai tradizionali sistemi di gestione di database relazionali (RDBMS). La durabilità è la garanzia che i dati scritti sono stati salvati e sopravviveranno in modo permanente. I database NoSQL come MongoDB offrono agli sviluppatori un controllo granulare sulla durabilità delle loro chiamate di scrittura. Ciò consente agli sviluppatori di scegliere diversi modelli di durabilità, sicurezza e prestazioni per diverse classi di dati. Tuttavia, questo pone anche l'onere per lo sviluppatore di discernere e comprendere le sfumature delle diverse opzioni di sicurezza in scrittura. In questo post, esamineremo le diverse opzioni per la sicurezza in scrittura fornite nel driver Java.
Nel gergo di MongoDB, questo si chiama "Write Concern". I problemi di scrittura variano da "deboli" a "forti". I problemi di scrittura deboli possono portare a un throughput più elevato, ma forniscono una minore sicurezza dei dati e i problemi di scrittura forti sono viceversa.
Il driver Java consente di specificare le opzioni di sicurezza in scrittura utilizzando diversi costruttori telescopici. Ecco il costruttore con tutte le opzioni:
WriteConcern(int w, int wtimeout, boolean fsync, boolean j, boolean continueOnError)
Come puoi vedere, questo costruttore ha molte opzioni. Per facilitare gli sviluppatori, vengono forniti "Tag" per i valori comuni di preoccupazione per la scrittura:Non riconosciuto, Acknowledged, Journalled, Fsynced e Replica Acknowledged. Ogni tag è associato a una determinata invocazione del costruttore sopra.
Modalità MongoDB non riconosciuta
Questa è la modalità "spara e dimentica". Il driver MongoDB non tenta di confermare la ricezione delle operazioni di scrittura. Ad esempio, se il tuo servizio MongoDB è inattivo e stai utilizzando questa modalità, tutti gli errori vengono ignorati silenziosamente e i tuoi dati vengono persi. Ovviamente, dovresti usare questa modalità solo per dati di basso valore in cui il throughput di scrittura è più importante della perdita di una certa quantità di dati. Questa modalità può essere specificata come segue:
new WriteConcern(0) / WriteConcern.UNACKNOWLEDGED
Modalità MongoDB riconosciuta
Questa è la modalità di scrittura predefinita per MongoDB. In questa modalità, il driver MongoDB tenta di confermare la ricezione delle operazioni di scrittura sul server, consentendo al driver di rilevare eventuali errori di rete, errori di chiavi duplicate, ecc. Tuttavia, ciò non garantisce che i dati vengano salvati sul disco. Se il server MongoDB si arresta in modo anomalo dopo aver riconosciuto la scrittura, ma prima di eseguirne il commit su disco, i dati vengono persi. Questa modalità può essere specificata come segue:
new WriteConcern(1) / WriteConcern.ACKNOWLEDGED
Modalità MongoDB con journaling
In questa modalità, il server MongoDB riconosce la scrittura solo dopo aver eseguito il commit dei dati nel journal. Quando si utilizza questa modalità, anche se il server si arresta in modo anomalo al riavvio, i dati vengono riapplicati dal journal. Ovviamente, il journaling deve essere abilitato affinché funzioni. Tutti i sistemi di produzione dovrebbero avere il journaling abilitato e puoi saperne di più nel nostro post.Devi abilitare il journaling MongoDB?
In uno scenario di set di repliche, i problemi di scrittura nel journal si applicano solo al primario. Per impostazione predefinita, il journal viene salvato su disco ogni 100 ms. Quando si specifica una scrittura con l'opzione journaled, il journal viene salvato su disco in 30 ms. Quindi, se specifichi j:true per ogni scrittura, il tuo throughput sarà un massimo di 1000/30 =33,3 scritture/sec. Se desideri un throughput migliore, dovrai eseguire il batch degli aggiornamenti e impostare j:true per l'ultimo aggiornamento del batch. Questa modalità può essere specificata come segue:
WriteConcern( 1, 0, false, true ) / WriteConcern.JOURNALLED
Modalità MongoDB sincronizzata
In questa modalità, il server MongoDB riconosce la scrittura solo dopo che la scrittura è stata scritta sul disco. Questa modalità può essere specificata come segue:
new WriteConcern(true) / WriteConcern.FSYNCED
Replica modalità MongoDB riconosciuta
Le precedenti modalità di sicurezza in scrittura si applicano solo a un singolo server. Quando esegui i set di repliche, hai la possibilità di controllare quante repliche devono essere scritte la tua scrittura prima che sia considerata riuscita. Ad esempio, con un problema di scrittura di “w:2″, la scrittura deve essere scritta su un primario e almeno su un secondario prima di essere considerata riuscita. Ciò riduce la produttività ma offre una maggiore sicurezza. Se non sei a conoscenza del numero di repliche in anticipo, puoi utilizzare il tag WriteConcern.MAJORITY per assicurarti che i dati vengano salvati nella maggior parte delle repliche. Questa è l'opzione più sicura in MongoDB. Se intendi utilizzare questa opzione, assicurati anche di impostare il valore "wtimeout" per indicare quanto tempo deve attendere il comando prima di restituire un errore:
new WriteConcern(2)/ REPLICA_ACKNOWLEDGED new Majority()/ WriteConcern.MAJORITY
I seguenti tag sono stati deprecati (o prevedono di esserlo):ERRORS_IGNORED, NORMAL, SAFE, FSYNC_SAFE, JOURNAL_SAFE, REPLICAS_SAFE. Si prega di utilizzare le opzioni più recenti invece di queste opzioni. Come sempre, se hai commenti o domande, contattaci all'indirizzo [email protected].
