Motori di archiviazione MongoDB MMAPv1 e WiredTiger

Question

In mongoDB3 è apparso un nuovo motore di archiviazione: WiredTiger. Ancora, MMAPv1 è ancora la scelta predefinita in Mongo.

Uno potrebbe non essere migliore dell'altro, spesso è una questione di caso d'uso e di scelta dello strumento giusto per il lavoro.Ma quale motore è adatto per quale lavoro?

Infatti, mentre MMAPv1 è il motore predefinito, WiredTiger sembra migliore in quasi tutti i campi.Ha le stesse caratteristiche di MMAPv1 più:

• migliori prestazioni di scrittura,
• concorrenza a livello di documento,
• compressione,
• sistema di istantanee e checkpoint.

Ho trovato una tabella comparativa su Il blog di MongoDB:

Quindi, a meno che tu non utilizzi Solaris, c'è un motivo per non scegliere WiredTiger?

---

MODIFICARE

Ecco due video che spiegano nel dettaglio l'interno diWiredTiger E MMAPv1.

Answer 1

Personalmente, al momento preferisco il motore di archiviazione mmapv1 per tre motivi.

Motivo 1:Scadenza

Non è che WiredTiger sia immaturo.Ma mmapv1 è ben compreso e testato in battaglia su e giù, avanti e indietro e sopra e oltre.WiredTiger ha avuto alcuni problemi seri (vedi http://jira.mongodb.com per i dettagli) abbastanza recentemente, e non sono disposto a lasciare che i miei clienti trovino il prossimo nel modo più duro.

Motivo 2:Caratteristiche

Detto questo, WT ha alcune f...caratteristiche assolutamente fantastiche.La cosa è:Non ho visto nessuno trarne beneficio.Compressione?In ogni caso, si sacrifica piuttosto duramente per ottenere prestazioni per uno spazio su disco piuttosto economico.Mancanza del problema della migrazione dei documenti per l'espansione dei documenti?Bene, abbiamo ancora il limite di dimensione di 16 MB e una maggiore complessità per i documenti incorporati, soprattutto quando l'incorporamento è eccessivo.

Ci sono altre funzionalità, ma in generale:Non vedo molti benefici da loro al momento.

Motivo 3:Costo totale della proprietà

Per i nuovi progetti, WT potrebbe andare bene, soprattutto a partire dalla 3.2, poiché quanto segue non si applica.

Fare migrazioni di dati lo è costoso.È necessario pianificarlo, il piano deve essere concordato da tutte le parti interessate, i piani di emergenza devono essere creati e concordati, la migrazione deve essere preparata, eseguita e rivista.Ora moltiplica il tempo necessario con le parti interessate che fanno parte di questo processo e i costi per la migrazione dei dati saliranno alle stelle.Il ritorno sull’investimento, d’altro canto, sembra piuttosto ridotto.Puoi ridimensionare parecchio invece di eseguire una migrazione se prendi in considerazione questi fattori.Per darti un'impressione:Stimerei circa una "settimana-uomo" per stakeholder se una migrazione viene pianificata, eseguita e rivista correttamente.Con costi di $ 100 l'ora per persona e solo tre persone coinvolte (manager, DBA e sviluppatore), il totale ammonta a $ 12.000.Tieni presente che questa è una stima conservativa.

Conclusione

Tutti questi fattori sopra mi hanno portato alla conclusione di non usare assolutamente il WT. Al momento.

---

Aggiornamento

Questo post è vecchio ormai di qualche mese, quindi merita un aggiornamento

Alla scadenza

I miei commenti originali sulla maturità sono in un certo senso obsoleti.WiredTiger non ha avuto grossi problemi ormai da un po' ed è diventato il motore di storage predefinito a partire da MongoDB 3.2

Sulle funzionalità

I miei commenti originali hanno ancora una certa validità, imho.

Compressione

Tuttavia, quando il budget è limitato o, più in generale, le prestazioni non sono la preoccupazione principale, il compromesso in termini di prestazioni è piuttosto piccolo e fondamentalmente si scambiano lievi impatti sulle prestazioni (rispetto al WT non compresso) con spazio su disco, utilizzando ciò che altrimenti sarebbe inattivo in giro:la CPU.

Crittografia

MongoDB 3.2 Enterprise ha introdotto la possibilità di crittografare gli archivi WiredTiger.Per i dati con esigenze di sicurezza avanzate, questa è una funzionalità killer e rende WT l'unico motore di archiviazione preferito, sia tecnicamente (MMAPv1 non supporta la crittografia) che concettualmente.Tralasciando ovviamente la possibilità di partizioni del disco crittografate, anche se in alcuni ambienti potresti non avere questa opzione.

Blocco a livello di documento

Devo ammettere che sostanzialmente ho omesso questa caratteristica del WT nella mia analisi di cui sopra, principalmente perché non si applicava a me o ai miei clienti quando ho scritto la risposta originale.

A seconda della configurazione, soprattutto quando si hanno molti client di scrittura simultanei, questa funzionalità può fornire un notevole incremento delle prestazioni.

Sul costo totale di proprietà

Effettuare migrazioni è ancora costoso.Tuttavia, tenendo conto dei cambiamenti nella maturità e della nuova visione delle funzionalità, una migrazione potrebbe valere l'investimento se:

• È necessaria la crittografia (solo Enterprise Edition!)
• Le prestazioni non sono la tua preoccupazione principale in assoluto e puoi risparmiare denaro a lungo termine (calcola in modo conservativo) utilizzando la compressione
• Hai molti processi che scrivono contemporaneamente, poiché l'aumento delle prestazioni potrebbe farti risparmiare il ridimensionamento verticale o orizzontale.

Conclusione aggiornata

Per i nuovi progetti, ora utilizzo WiredTiger.Poiché la migrazione da uno storage WiredTiger compresso a uno non compresso è piuttosto semplice, tendo a iniziare con la compressione per migliorare l'utilizzo della CPU ("ottieni di più con il denaro").Se la compressione dovesse avere un impatto notevole sulle prestazioni o sulla UX, migrerò a WiredTiger non compresso.

Per i progetti con molti autori simultanei, anche la risposta alla domanda se migrare o meno è quasi sempre "Sì", a meno che il budget del progetto non vieti l'investimento.A lungo termine, l’aumento delle prestazioni dovrebbe ripagarsi da solo, se l’implementazione fosse stata pianificata in modo ragionevole in altro modo.Tuttavia, è necessario aggiungere al calcolo del tempo di sviluppo, poiché in alcuni casi è necessario aggiornare il driver e potrebbero esserci problemi da risolvere.

Per i progetti che hanno un budget limitato e non possono permettersi più spazio su disco per il momento, la migrazione a un WiredTiger compresso può essere un'opzione, ma la compressione carica un po' la CPU, cosa inaudita con MMAPv1.Inoltre, i costi di migrazione potrebbero essere proibitivi per un progetto del genere.

Answer 2

I miei due centesimi:

Journaling in Wiredtiger può perdere aggiornamenti in arresti rigidi perché utilizza il buffering in memoria per la memorizzazione dei record del giornale.

.

tra le operazioni di scrittura, mentre i record del diario rimangono nel Buffer wiredtiger, gli aggiornamenti possono essere persi a seguito di un arresto duro di Mongod.

Journaling in mmapv1 scrive modifiche ai file del diario on-disk.

.

Se l'istanza mongolod dovesse schiantarsi senza aver applicato le scritture Ai file di dati, il diario potrebbe riprodurre le scritture alla condivisione Visualizza per eventuale scrittura ai file di dati.

Answer 3

Siamo spostati su Wiredtiger da mmapv1 sull'apparecchio di 7x a 10x guadagno delle prestazioni.Abbiamo dovuto tornare a Mmapv1 poiché MongoDB si blocca quando la cache del Wiredtiger avrebbe colpito il 100%.Abbiamo documentato la nostra esperienza qui - https://blog.clevertAp.com/sleepless-nthss-with-mongodb-wiredtiger-and-our-return-to-mmapv1/