¿Qué sucede si hay demasiados insertos en MongoDB? ¿Cómo asegurar que todos los datos estén almacenados?

Yo uso MongoDB para almacenar valores medidos periódicamente. Cada ~ 100 ms se inserta un conjunto de valores como documento. Funciona bien, pero me preocupan los problemas de rendimiento. (Uso insertos seguros, parece que en PyMongo este es el valor predeterminado).

¿Qué sucede si hay más inserciones por segundo de las que mongod puede guardar en el disco duro? ¿Habrá alguna advertencia o simplemente fallará en silencio?

¿Hay algún método para monitorear la carga de escritura? Solo he encontrado lo db.serverStatus().writeBacksQueuedque siempre se establece en falso cuando lo llamo. ¿Cómo podría probar cuántos datos tengo que insertar para completar la cola de escritura?

mongostatmuestra cerraduras. ¿Es algo por lo que debería preocuparme?

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

¿Tengo que preocuparme por los bloqueos de escritura? ¿Qué le sucede a una inserción durante un período de tiempo de escritura bloqueado? ¿Está en cola y almacenado más adelante?

Estoy pensando en una configuración de replicación simple usando un maestro y un esclavo. ¿La sincronización inicial o un proceso de resincronización bloquean las bases de datos?

(Estoy usando la versión 2.4.3.)

Actualización: creo que he respondido en parte a mi propia pregunta. Logré obtener hasta 12,000 inserciones por segundo usando un ciclo simple mientras insertaba un pequeño documento de prueba. Pero qr | qw todavía muestra que existen las colas de lectura y escritura que todavía están vacías:

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 

Supongo que esto significa que las inserciones por sí solas no causarán muchos problemas: "Las colas tenderán a aumentar si está realizando muchas operaciones de escritura junto con otras operaciones pesadas de escritura, como las eliminaciones de gran alcance". (encontrado aquí )

Mi pregunta abierta: ¿Qué sucede con mis datos si la cola de escritura aumenta a largo plazo?

Ha respondido algunas de sus propias preguntas aquí, específicamente tiene una idea decente sobre el aspecto de bloqueo de escritura de la ecuación: 12,000 inserciones / seg lo lleva a ~ 60% de bloqueo de escritura. Ese es un nivel razonable para obtener un rendimiento constante: obtendrá cierta contención y algunas operaciones serán un poco más lentas, pero realmente desea comenzar a preocuparse en aproximadamente el 80%, como muchas cosas, cuando comienza a exceder el 80% disponible capacidad comenzará a atacar problemas con mucha más frecuencia.

En términos de otros cuellos de botella, y específicamente qué tan rápido puede escribir en el disco, esto puede causar problemas, pero para ver las estadísticas relevantes a lo largo del tiempo, recomendaría instalar MMS con el complemento munin-node para darle estadísticas de hardware y E / S en Además de las estadísticas de MongoDB.

Cuando tenga eso, las métricas que querrá vigilar son:

• El tiempo promedio de descarga (es el tiempo que tarda la sincronización periódica de MongoDB en el disco)
• Los IOStats en la pestaña de hardware (IOWait en particular)
• Fallos de página (si su disco está ocupado con escrituras y necesita leer datos, estarán compitiendo por un recurso escaso)

Es un poco complicado entonces, pero aquí hay una idea básica:

• Cuando el tiempo promedio de descarga comienza a aumentar, preocúpese
• Si entra en el rango de segundos múltiples, probablemente esté en el límite (aunque esto depende del volumen de datos escritos y la velocidad del disco)
• Si se acerca a los 60 segundos, verá que el rendimiento se degrada severamente (el enjuague ocurre cada 60 segundos, por lo que esencialmente estarían haciendo cola)
• IOWait alto también obstaculizará el rendimiento, especialmente si tiene que leer desde el disco en cualquier momento
• Por lo tanto, mirar los niveles de falla de la página también será importante

La otra pieza de este rompecabezas, que aún no hemos mencionado, es el diario. También serán datos persistentes en el disco (de manera predeterminada cada 100 ms) y, por lo tanto, se agregarán a la carga del disco si está en el mismo volumen. Por lo tanto, si observa una alta utilización del disco, sería una buena idea mover el diario a otro disco.

No hay verdaderos "números mágicos" en los que quedarse, en la mayoría de los casos todo es relativo, así que obtenga una buena línea de base para su tráfico normal, verifique si las cosas están en tendencia y tal vez realice una prueba de carga para ver cuáles son sus límites y cuándo comenzará a degradarse y estará en buena forma.

Después de todo ese preámbulo, pase a algunas de sus preguntas:

¿Qué sucede si hay más inserciones por segundo de las que mongod puede guardar en el disco duro? ¿Habrá alguna advertencia o simplemente fallará en silencio?

Si comienza a estresar el disco a los niveles descritos anteriormente, eventualmente todo se ralentizará y en algún momento (y esto dependerá de los tiempos de espera, cuán robusto sea su hardware, cómo maneje las excepciones) sus escrituras fallarán, si está utilizando una versión reciente de pymongo, luego utilizará escrituras seguras de forma predeterminada y luego fallarán. Si desea ser un poco más paranoico, de vez en cuando puede hacer una preocupación de escritura de j: verdadero, que esperará para regresar OK hasta que la escritura haya llegado al diario (es decir, en el disco). Esto, por supuesto, será más lento que una escritura segura normal, pero será una indicación inmediata de problemas relacionados con la capacidad del disco, y podría usarlo para bloquear / poner en cola otras operaciones y esencialmente actuar como un acelerador para evitar que su base de datos sea abrumado.

Estoy pensando en una configuración de replicación simple usando un maestro y un esclavo. ¿La sincronización inicial o un proceso de resincronización bloquean las bases de datos?

Creo que cubrí el bloqueo en general al principio, pero para responder específicamente a esta pieza: Primero, asegúrese de estar utilizando un conjunto de réplica , no maestro / esclavo. La implementación maestro / esclavo está en desuso y no se recomienda su uso en general. En cuanto a la sincronización inicial, agregará algo de carga a la primaria en términos de lecturas, pero no en términos de escrituras, por lo que debería estar bien en términos de bloqueo.

¿Qué sucede con mis datos si la cola de escritura aumenta a largo plazo?

Como probablemente pueda deducir de la explicación anterior, la respuesta depende en gran medida de cómo escribe su solicitud, cómo elige que se reconozcan sus escritos y cuánta capacidad tiene disponible. Esencialmente, puede estar tan seguro como desee cuando se trata de escribir en el disco en MongoDB, pero hay una compensación de rendimiento, como se mencionó en la j:truediscusión anterior.

En general, desea averiguar su factor limitante, ya sea bloqueo, velocidad de disco, etc. y luego rastrear los niveles a lo largo del tiempo y escalar (fragmentación) o hacia arriba (mejor hardware) antes de alcanzar un límite duro y ver problemas de rendimiento.

Una última cosa, db.serverStatus().writeBacksQueuedes en realidad una métrica que solo será distinta de cero en un entorno fragmentado, y tiene que ver con asegurarse de que las escrituras en un fragmento durante una migración se traten de manera adecuada (manejado por el oyente de reescritura ). Por lo tanto, esencialmente es un arenque rojo aquí, nada que ver con el volumen de escritura general.