Concurrency Behavior: MongoDB vs. Couchbase

Pruebas multiusuario

David Glasser de Meteoro escribió un blog sobre una consulta en MongoDB en la que faltan documentos coincidentes con el que se encontró. Es sencillo reproducir el problema tanto en MongoDB MMAPv1 como en el motor MongoDB WiredTiger. Estas son las conclusiones de su artículo (el énfasis es mío)

Resumiendo...

Este problema no afecta a las consultas que no utilizan un índice, como las consultas que sólo buscan un documento por ID.
No afecta a las consultas que realizan explícitamente una coincidencia de igualdad de valor único en todos los campos utilizados en la clave del índice.
No afecta a las consultas que utilizan índices cuyos campos nunca se modifican tras la inserción original del documento.
Pero cualquier otro tipo de consulta a MongoDB puede no incluir todos los documentos coincidentes.

He aquí otra forma de verlo. En MongoDB, si la consulta puede recuperar dos documentos usando un índice secundario (índice sobre algo distinto de _id) cuando se están realizando operaciones concurrentes, los resultados podrían ser erróneos. Este es un escenario común en muchas aplicaciones de bases de datos.

Aquí está la prueba:

Crear un contenedor: Cubo, tabla o colección.
Cargue los datos con un pequeño conjunto de datos, digamos 300K documentos.
Cree un índice sobre el campo que desea filtrar (predicados).
En una sesión, actualiza el campo indexado en una sesión y consulta en la otra.

Pruebas de MongoDB

Pasos para reproducir el problema en MongoDB:

Instale MongoDB 3.2.
Sube a mongod con MMAPv1 o WiredTiger.
Cargar datos con tpcc.py
python tpcc.py -almacenes 1 -no-ejecutar mongodb
Obtener el recuento

> use tpcc

> db.ORDER_LINE.find().count();

299890

db.ORDER_LINE.ensureIndex({state:1});

Experimento 1 de MongoDB: Actualización a un valor superior

Configure el campo de estado con el valor aaaaaa y, a continuación, actualice simultáneamente este valor a zzzzzz y consulte el número total de documentos con los dos valores ['aaaaaa','zzzzzz'] que coinciden con el campo. Cuando el valor del campo indexado pasa del valor más bajo (aaaaaa) al más alto (zzzzzz), estas entradas se mueven de un lado al otro del árbol B. Ahora, estamos tratando de ver si el escaneo devuelve un valor duplicado, traducido a un valor mayor de count().

> db.ORDER_LINE.update({OL_DIST_INFO:{$gt:""}}, {$set: {state: "aaaaaa"}}, {multi:true});

WriteResult({"nMatched" : 299890, "nUpserted" : 0, "nModified" : 299890 })

> db.ORDER_LINE.find({state:{$in:['aaaaaa','zzzzzz']}}).count();

299890

> db.ORDER_LINE.find({state:{$in:['aaaaaa','zzzzzz']}}).explain();

{

"queryPlanner" : {

"plannerVersion" : 1,

"namespace" : "tpcc.ORDER_LINE",

"indexFilterSet" : falso,

"parsedQuery" : {

"state" : {

"$in" : [

"aaaaaa",

"zzzzzz"

]

}

"winningPlan" : {

"stage" : "FETCH",

"inputStage" : {

"etapa" : "IXSCAN",

"keyPattern" : {

"estado" : 1

"indexName" : "state_1",

"isMultiKey" : falso,

"direction" : "forward",

"indexBounds" : {

"estado" : [

"["aaaaaa"", "aaaaaa"]",

"["zzzzzz", "zzzzzz"]"

]

}

"rejectedPlans" : [ ]

"serverInfo" : {

"host" : "Keshavs-MacBook-Pro.local",

"puerto" : 27017,

"version" : "3.0.2",

"gitVersion" : "6201872043ecbbc0a4cc169b5482dcf385fc464f"

"ok" : 1

}

Declaración de actualización 1: Actualizar todos los documentos para establecer state = "zzzzzz"

db.ORDER_LINE.update({OL_DIST_INFO:{$gt:""}},

{$set: {estado: "zzzzzz"}}, {multi:true});

Declaración de actualización 2: Actualizar todos los documentos para establecer state = "aaaaaa"

db.ORDER_LINE.update({OL_DIST_INFO:{$gt:""}},

{$set: {estado: "aaaaaa"}}, {multi:true});

3. Declaración de recuento: Contar documentos:(estado en ["aaaaaa", "zzzzzz"])

db.ORDER_LINE.find({state:{$in:['aaaaaa','zzzzzz']}}).count();

Tiempo	Sesión 1: Declaración de actualización de temas1 (actualizar estado = "zzzzzz")	Sesión 2: Emisión continua de la declaración de recuento.
T0	Comienza la declaración de actualización	Recuento = 299890
T1	Continúa la declaración de actualización	Recuento = 312736
T2	Continúa la declaración de actualización	Recuento = 312730
T3	Continúa la declaración de actualización	Recuento = 312778
T4	Continúa la declaración de actualización	Recuento = 312656
T4	Continúa la declaración de actualización	Recuento = 313514
T4	Continúa la declaración de actualización	Recuento = 303116
T4	Declaración de actualización Realizada	Recuento = 299890

Resultado: En este escenario, el índice hace doble recuento de muchos documentos e informa de más de los que realmente tiene.

Causa: Los datos en el nivel de hoja del B-Tree están ordenados. Cuando el B-Tree se actualiza de aaaaaa a zzzzzz, las claves del extremo inferior se mueven al extremo superior. Los escaneos concurrentes no son conscientes de este movimiento. MongoDB no implementa un escaneo estable y cuenta las entradas según van llegando. Así, en un sistema de producción con muchas actualizaciones, podría contar el mismo documento dos veces, tres veces o más. Sólo depende de las operaciones concurrentes.

Experimento 2 de MongoDB: Actualización a un valor inferior

Hagamos la operación inversa para actualizar los datos de 'zzzzzz' a 'aaaaaa'. En este caso, las entradas del índice pasan de un valor más alto a un valor más bajo, lo que hace que el escaneo pase por alto algunos de los documentos calificados, mostrando un recuento insuficiente.

Tiempo	Sesión 1: Declaración de actualización2 (actualizar estado = "aaaaaa")	Sesión 2: Emisión continua de la declaración de recuento.
T0	Comienza la declaración de actualización	Recuento = 299890
T1	Continúa la declaración de actualización	Recuento = 299728
T2	Continúa la declaración de actualización	Recuento = 299750
T3	Continúa la declaración de actualización	Recuento = 299780
T4	Continúa la declaración de actualización	Recuento = 299761
T4	Continúa la declaración de actualización	Recuento = 299777
T4	Continúa la declaración de actualización	Recuento = 299815
T4	Declaración de actualización Realizada	Recuento = 299890

Resultado: En este escenario, el índice pasa por alto muchos documentos e informa de menos documentos de los que realmente tiene.

Causa: Esto expone el efecto contrario. Cuando las claves con valores zzzzzz se modifican a aaaaaa, los elementos pasan del extremo superior al inferior del B-Tree. De nuevo, como no hay estabilidad en los escaneos, se perderían las claves que se movieran del extremo superior al inferior.

Experimento 3 de MongoDB: ACTUALIZACIONES concurrentes

Dos sesiones actualizan el campo indexado de forma simultánea y continua. En este caso, basándonos en las observaciones anteriores, cada una de las sesiones se encuentra con un problema tanto de sobreconteo como de infraconteo. El resultado nModified varía porque MongoDB sólo informa de las actualizaciones que han cambiado el valor.

Pero el número total de documentos modificados nunca es superior a 299980. Por lo tanto, MongoDB evita actualizar el mismo documento dos veces, manejando así la clásico problema de halloween. Como no tienen un escaneo estable, supongo que manejan esto manteniendo listas de objectIDs actualizados durante esta declaración de actualización múltiple y evitando la actualización si el mismo objeto aparece como un documento calificado.

SESIÓN 1

> db.ORDER_LINE.update({state:{$gt:""}}, {$set: {state: "aaaaaa"}}, {multi:true});

WriteResult({"nMatched" : 299890, "nUpserted" : 0, "nModified" : 299890 })