El bloqueo de MongoDB es diferente
El bloqueo en MongoDB no funciona como el bloqueo en un RDBMS, por lo que se necesita una pequeña explicación. En versiones anteriores de MongoDB, había un único pestillo de lectura/escritura global. A partir de MongoDB 2.2, hay un pestillo de lector/escritor para cada base de datos.
El pestillo del lector-escritor
El pestillo es de lector múltiple, escritor único y ávido de escritor. Esto significa que:
- Puede haber un número ilimitado de lectores simultáneos en una base de datos
- Solo puede haber un escritor a la vez en cualquier colección en cualquier base de datos (más sobre esto en un momento)
- Los escritores bloquean a los lectores
- Por "escritor codicioso", me refiero a que una vez que llega una solicitud de escritura, todos los lectores se bloquean hasta que se completa la escritura (más sobre esto más adelante)
Tenga en cuenta que llamo a esto un "pestillo" en lugar de un "bloqueo". Esto se debe a que es liviano y, en un esquema diseñado correctamente, el bloqueo de escritura se mantiene en el orden de una docena de microsegundos. Consulte aquí para obtener más información sobre el bloqueo de lectores y escritores.
En MongoDB, puede ejecutar tantas consultas simultáneas como desee:siempre que los datos relevantes estén en la RAM, se satisfarán todos sin conflictos de bloqueo.
Actualizaciones de documentos atómicos
Recuerde que en MongoDB el nivel de transacción es un solo documento. Todas las actualizaciones de un solo documento son atómicas. MongoDB logra esto manteniendo el pestillo de escritura solo el tiempo necesario para actualizar un solo documento en la RAM. Si hay alguna operación de ejecución lenta (en particular, si es necesario paginar un documento o una entrada de índice desde el disco), entonces esa operación rendirá el pestillo de escritura. Cuando la operación produce el pestillo, la siguiente operación en cola puede continuar.
Esto significa que las escrituras en todos los documentos dentro de una sola base de datos se serializan. Esto puede ser un problema si tiene un diseño de esquema deficiente y sus escrituras toman mucho tiempo, pero en un esquema diseñado correctamente, el bloqueo no es un problema.
Escritor-Codicioso
Algunas palabras más sobre ser codicioso de escritores:
Solo un escritor puede sostener el pestillo a la vez; varios lectores pueden sostener el pestillo a la vez. En una implementación ingenua, los escritores podrían pasar hambre indefinidamente si hubiera un solo lector en funcionamiento. Para evitar esto, en la implementación de MongoDB, una vez que cualquier subproceso realiza una solicitud de escritura para un latch en particular
- Todos los lectores subsiguientes que necesiten ese pestillo se bloquearán
- Ese escritor esperará hasta que todos los lectores actuales hayan terminado
- El escritor adquirirá el pestillo de escritura, hará su trabajo y luego liberará el pestillo de escritura
- Todos los lectores en cola procederán ahora
El comportamiento real es complejo, ya que este comportamiento codicioso de escritor interactúa con el rendimiento de maneras que pueden no ser obvias. Recuerde que, a partir de la versión 2.2, hay un separado pestillo para cada base de datos, por lo que las escrituras en cualquier colección en la base de datos 'A' adquirirán un pestillo separado que las escrituras en cualquier colección en la base de datos 'B'.
Preguntas específicas
En cuanto a las preguntas específicas:
- El kernel de MongoDB retiene los bloqueos (en realidad, latches) solo durante el tiempo necesario para actualizar un único documento
- Si tiene varias conexiones entrando a MongoDB, y cada una de ellas está realizando una serie de escrituras, el pestillo se mantendrá por base de datos solo durante el tiempo que tarde en completarse esa escritura
- Se intercalarán varias conexiones que ingresen realizando escrituras (actualizar/insertar/eliminar)
Si bien esto parece que sería una gran preocupación para el rendimiento, en la práctica no ralentiza las cosas. Con un esquema diseñado correctamente y una carga de trabajo típica, MongoDB saturará la capacidad de E/S del disco, incluso para un SSD, antes de que el porcentaje de bloqueo en cualquier base de datos supere el 50 %.
El clúster MongoDB de mayor capacidad que conozco actualmente realiza 2 millones de escrituras por segundo.
