Cosa succede se ci sono troppi inserti in MongoDB? Come garantire che tutti i dati siano archiviati?

Uso MongoDB per memorizzare valori misurati periodicamente. Ogni ~ 100 ms viene inserito un gruppo di valori come documento. Funziona bene, ma sono preoccupato per i problemi di prestazioni. (Uso inserti sicuri, sembra che in PyMongo sia l'impostazione predefinita.)

Cosa succede se ci sono più inserti al secondo di quanti mongod sia in grado di salvare sul disco rigido? Ci sarà qualche avvertimento o semplicemente fallirà silenziosamente?

Esiste un metodo per monitorare il carico in scrittura? Ho trovato solo db.serverStatus().writeBacksQueuedche è sempre impostato su false quando lo chiamo. Come posso verificare quanti dati devo inserire per riempire la coda di scrittura?

mongostatmostra i blocchi. È qualcosa di cui dovrei preoccuparmi?

insert  query update delete getmore command flushes mapped  vsize    res faults  locked db idx miss %     qr|qw   ar|aw  netIn netOut  conn repl       time 
  *117     *0     *0     *0       0     2|0       0  17.4g  35.3g  3.76g      0     .:6.5%          0       0|0     0|0   124b     6k     2  SLV   09:58:10 
  *111     *0     *0     *0       0     2|0       0  17.4g  35.3g  3.76g      0     .:0.8%          0       0|0     0|0   124b     6k     2  SLV   09:58:11 
  *111     *0     *0     *0       0     2|0       0  17.4g  35.3g  3.76g      0     .:4.2%          0       0|0     0|0   124b     6k     2  SLV   09:58:1

Devo preoccuparmi dei blocchi di scrittura? Cosa succede a un inserto durante un periodo di tempo bloccato in scrittura? Viene messo in coda e archiviato in seguito?

Sto pensando a una semplice configurazione della replica usando un master e uno slave. La sincronizzazione iniziale o un processo di risincronizzazione bloccano i database?

(Sto usando la versione 2.4.3.)

Aggiornamento: penso di aver parzialmente risposto alla mia domanda. Sono riuscito a ottenere fino a 12.000 inserti al secondo usando un semplice ciclo while inserendo un piccolo documento di prova. Ma qr | qw mostra ancora che la coda di lettura e scrittura è ancora vuota:

insert  query update delete getmore command flushes mapped  vsize    res faults       locked db idx miss %     qr|qw   ar|aw  netIn netOut  conn repl       time 
 11234     *0      2     *0    1563     1|0       1  21.9g  44.3g  1.22g      0    testdb:58.9%          0       1|0     1|1   797k   980k     6  PRI   10:26:32 
 12768     *0      2     *0    1284     1|0       0  21.9g  44.3g  1.22g      0    testdb:58.0%          0       0|0     0|1   881k     1m     6  PRI   10:26:33 
 12839     *0      2     *0    1231     1|0       0  21.9g  44.3g  1.22g      0    testdb:60.3%          0       0|0     0|1   883k     1m     6  PRI   10:26:34 
 12701     *0      2     *0     910     1|0       0  21.9g  44.3g  1.22g      0    testdb:61.8%          0       0|0     0|1   858k     1m     6  PRI   10:26:35 
 12241     *0      2     *0    1206     1|0       0  21.9g  44.3g  1.22g      0    testdb:56.7%          0       0|0     0|0   843k     1m     6  PRI   10:26:36 
 11581     *0      2     *0    1406     1|0       0  21.9g  44.3g  1.22g      0    testdb:61.8%          0       0|0     0|1   811k     1m     6  PRI   10:26:37 
  8719     *0      2     *0    1210     1|0       0  21.9g  44.3g  1.22g      0    testdb:43.8%          0       0|0     0|1   618k   762k     6  PRI   10:26:38 
 11429     *0      2     *0    1469     1|0       0  21.9g  44.3g  1.22g      0    testdb:60.6%          0       0|0     0|1   804k   993k     6  PRI   10:26:39 
 12779     *0      2     *0    1092     1|0       0  21.9g  44.3g  1.22g      0    testdb:60.2%          0       1|0     0|1   872k     1m     6  PRI   10:26:40 
 12757     *0      2     *0     436     1|0       0  21.9g  44.3g  1.22g      0    testdb:59.7%          0       0|0     0|1   838k   432k     6  PRI   10:26:41 

Suppongo che ciò significhi che gli inserti da soli non causeranno molti problemi: "Le code tenderanno ad aumentare se si eseguono molte operazioni di scrittura insieme ad altre operazioni di scrittura pesanti, come le operazioni di rimozione a grande distanza". (trovato qui )

La mia domanda aperta: cosa succede ai miei dati se la coda di scrittura aumenta a lungo termine?

Hai risposto ad alcune delle tue domande qui, in particolare hai un'idea decente dell'aspetto del blocco di scrittura dell'equazione: 12.000 inserti / sec ti portano a circa il 60% del blocco di scrittura. Questo è un livello ragionevole per ottenere prestazioni costanti - otterrai qualche contesa e alcune operazioni saranno un po 'più lente, ma vuoi davvero iniziare a preoccuparti all'80% circa - come molte cose, quando inizi a superare l'80% disponibile capacità inizierai a colpire i problemi molto più spesso.

In termini di altri colli di bottiglia, e in particolare la velocità con cui è possibile scrivere su disco, ciò può causare problemi, ma per esaminare le statistiche pertinenti nel tempo, consiglierei di installare MMS con il plugin munin-node per fornire statistiche hardware e I / O in oltre alle statistiche MongoDB.

Quando lo hai, le metriche che vorresti tenere d'occhio sono:

• Il tempo di lavaggio medio (questo è il tempo impiegato dalla sincronizzazione periodica di MongoDB su disco)
• IOStats nella scheda hardware (IOWait in particolare)
• Errori di pagina (se il tuo disco è occupato con le scritture e devi leggere i dati, saranno in competizione per una risorsa scarsa)

Quindi è un po 'complicato, ma ecco un'idea di base:

• Quando il tempo di lavaggio medio inizia ad aumentare, preoccupati
• Se rientra nell'intervallo di più secondi, probabilmente sei al limite (anche se questo dipende dal volume di dati scritti e dalla velocità del disco)
• Se si avvicina a 60 secondi, le prestazioni peggioreranno notevolmente (il flush avviene ogni 60 secondi, quindi sostanzialmente si accoderebbero)
• L'alto IOWait ostacolerà anche le prestazioni, soprattutto se devi leggere dal disco in qualsiasi momento
• Quindi sarà importante anche esaminare i livelli di errore della pagina

L'altro pezzo di questo puzzle, che non abbiamo ancora menzionato, è il diario. Ciò consentirà anche di conservare i dati sul disco (per impostazione predefinita ogni 100 ms) e quindi si aggiungerà al carico del disco se si trova sullo stesso volume. Pertanto, se si riscontra un utilizzo elevato del disco, spostare il giornale su un altro disco sarebbe una buona idea.

Non ci sono veri e propri "numeri magici" a cui attenersi, nella maggior parte dei casi è tutto relativo, quindi ottieni una buona base per il tuo traffico normale, controlla se le cose vanno di moda e magari carica i test per vedere quali sono i tuoi limiti e quando le cose inizia a degradare e sarai in buona forma.

Dopo tutto ciò che precede, su alcune delle tue domande:

Cosa succede se ci sono più inserti al secondo di quelli che mongod è in grado di salvare sul disco rigido? Ci sarà qualche avvertimento o semplicemente fallirà silenziosamente?

Se inizi a stressare il disco ai livelli sopra descritti, alla fine tutto rallenterà e ad un certo punto (e questo dipenderà dai timeout, da quanto è robusto il tuo hardware, da come gestisci le eccezioni) le tue scritture falliranno - se stai usando una versione recente di pymongo quindi userai le scritture sicure di default e quelle falliranno. Se desideri essere un po 'più paranoico, di tanto in tanto puoi fare una preoccupazione di scrittura di j: true che attenderà di tornare OK fino a quando la scrittura non sarà arrivata sul journal (cioè sul disco). Questo, ovviamente, sarà più lento di una normale scrittura sicura, ma sarà un'indicazione immediata di problemi relativi alla capacità del disco e potresti usarlo per bloccare / mettere in coda altre operazioni e essenzialmente agire come un throttle per impedire al tuo database di essere sopraffatto.

Sto pensando a una semplice configurazione della replica usando un master e uno slave. La sincronizzazione iniziale o un processo di risincronizzazione bloccano i database?

Penso di aver coperto il blocco in generale all'inizio, ma per rispondere in modo specifico a questo pezzo: in primo luogo, assicurati di utilizzare un set di repliche , non master / slave. L'implementazione master / slave è obsoleta e non è consigliata per l'uso in generale. Per quanto riguarda la sincronizzazione iniziale aggiungerà un po 'di carico al primario in termini di letture, ma non in termini di scritture, quindi dovresti stare bene in termini di blocco.

Cosa succede ai miei dati se la coda di scrittura aumenta a lungo termine?

Come probabilmente puoi dire dalla spiegazione sopra, la risposta dipende molto da come scrivi la tua domanda, da come scegli di far riconoscere le tue scritture e da quanta capacità hai a disposizione. In sostanza, puoi essere sicuro quanto desideri quando si tratta di scrivere su disco su MongoDB, ma c'è un compromesso sulle prestazioni, come menzionato nella j:truediscussione sopra.

In generale, vuoi capire il tuo fattore limitante - che si tratti di blocco, velocità del disco ecc. E quindi tracciare i livelli nel tempo e ridimensionarli (sharding) o su (hardware migliore) prima di raggiungere un limite rigido e vedere problemi di prestazioni.

Un'ultima cosa, in db.serverStatus().writeBacksQueuedrealtà , è una metrica che sarà sempre diversa da zero in un ambiente frammentato, e ha a che fare con l'accertarsi che le scritture su un blocco durante una migrazione siano gestite in modo appropriato (gestite dall'ascoltatore di writeback ). Quindi è essenzialmente un'aringa rossa qui - niente a che fare con il volume di scrittura generale.