Concurrency Behavior: MongoDB vs. Couchbase

Testes com vários usuários

David Glasser de Meteoro escreveu um blog sobre um problema de consulta do MongoDB sem documentos correspondentes que ele encontrou. É fácil reproduzir o problema no mecanismo MongoDB MMAPv1 e MongoDB WiredTiger. Aqui estão as conclusões do artigo dele (a ênfase é minha)

Resumindo a história...

Esse problema não afeta as consultas que não usam um índice, como as consultas que apenas procuram um documento por ID.
Isso não afeta as consultas que fazem explicitamente uma correspondência de igualdade de valor único em todos os campos usados na chave do índice.
Isso não afeta as consultas que usam índices cujos campos nunca são modificados depois que o documento é inserido originalmente.
Mas qualquer outro tipo de consulta ao MongoDB pode não incluir todos os documentos correspondentes!

Aqui está outra maneira de ver isso. No MongoDB, se a consulta puder recuperar dois documentos usando um índice secundário (índice em algo diferente de _id) quando operações simultâneas estiverem em andamento, os resultados poderão estar errados. Esse é um cenário comum em muitos aplicativos de banco de dados.

Aqui está o teste:

Crie um contêiner: Bucket, tabela ou coleção.
Carregue os dados com um pequeno conjunto de dados, por exemplo, 300 mil documentos.
Crie um índice no campo que você deseja filtrar (predicados).
Em uma sessão, atualize o campo indexado em uma sessão e consulte na outra.

Teste do MongoDB

Etapas para reproduzir o problema no MongoDB:

Instale o MongoDB 3.2.
Crie o mongod com o MMAPv1 ou o WiredTiger.
Carregar dados usando tpcc.py
python tpcc.py -warehouses 1 -no-execute mongodb
Obter a contagem

> use tpcc

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

299890

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

Experiência 1 do MongoDB: atualizar para um valor mais alto

Configure o campo de estado com o valor aaaaaa e, em seguida, atualize simultaneamente esse valor para zzzzzz e consulte o número total de documentos com os dois valores ['aaaaaa','zzzzzz'] correspondentes ao campo. Quando o valor do campo indexado se move do valor mais baixo (aaaaaa) para o mais alto (zzzzzz), essas entradas estão se movendo de um lado para o outro da árvore B. Agora, estamos tentando ver se a varredura retorna um valor duplicado, traduzido em um valor count() mais alto.

> 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" : false,

"parsedQuery" : {

"state" : {

"$in" : [

"aaaaaa",

"zzzzzz"

]

}

"winningPlan" : {

"stage" : "FETCH",

"inputStage" : {

"estágio" : "IXSCAN",

"keyPattern" : {

"state" : 1

"indexName" : "state_1",

"isMultiKey" : false,

"direction" : "forward",

"indexBounds" : {

"state" : [

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

"["zzzzzz", "zzzzzz"]"

]

}

"rejectedPlans" : [ ]

"serverInfo" : {

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

"port" : 27017,

"versão" : "3.0.2",

"gitVersion" : "6201872043ecbbc0a4cc169b5482dcf385fc464f"

"ok" : 1

}

Declaração de atualização 1: Atualizar todos os documentos para definir state = "zzzzzz"

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

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

Declaração de atualização 2: Atualize todos os documentos para definir state = "aaaaaa"

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

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

3. Declaração de contagem: Count documents:(state in ["aaaaaa", "zzzzzz"])

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

Tempo	Sessão 1: Declaração de atualização de problemas1 (atualizar estado = "zzzzzz")	Sessão 2: Declaração de contagem de emissões continuamente.
T0	Início da declaração de atualização	Contagem = 299890
T1	Declaração de atualização continua	Contagem = 312736
T2	Declaração de atualização continua	Contagem = 312730
T3	Declaração de atualização continua	Contagem = 312778
T4	Declaração de atualização continua	Contagem = 312656
T4	Declaração de atualização continua	Contagem = 313514
T4	Declaração de atualização continua	Contagem = 303116
T4	Declaração de atualização concluída	Contagem = 299890

Resultado: Nesse cenário, o índice faz uma contagem dupla de muitos documentos e informa mais do que realmente tem.

Causa: Os dados no nível de folha da árvore B são classificados. À medida que a atualização da árvore B é atualizada de aaaaaa para zzzzzz, as chaves na extremidade inferior são movidas para a extremidade superior. As varreduras simultâneas não sabem dessa movimentação. O MongoDB não implementa uma varredura estável e conta as entradas à medida que elas chegam. Portanto, em um sistema de produção com muitas atualizações em andamento, ele pode contar o mesmo documento duas, três ou mais vezes. Isso depende apenas das operações simultâneas.

Experiência 2 do MongoDB: atualizar para um valor mais baixo

Vamos fazer a operação inversa para atualizar os dados de "zzzzzz" para "aaaaaa". Nesse caso, as entradas do índice estão se movendo de um valor mais alto para um valor mais baixo, fazendo com que a varredura não veja alguns dos documentos qualificados, o que mostra uma subcontagem.

Tempo	Sessão 1: Declaração de atualização de problemas2 (update state = "aaaaaa")	Sessão 2: Declaração de contagem de emissões continuamente.
T0	Início da declaração de atualização	Contagem = 299890
T1	Declaração de atualização continua	Contagem = 299728
T2	Declaração de atualização continua	Contagem = 299750
T3	Declaração de atualização continua	Contagem = 299780
T4	Declaração de atualização continua	Contagem = 299761
T4	Declaração de atualização continua	Contagem = 299777
T4	Declaração de atualização continua	Contagem = 299815
T4	Declaração de atualização concluída	Contagem = 299890

Resultado: Nesse cenário, o índice perde muitos documentos e informa menos documentos do que realmente tem.

Causa: Isso expõe o efeito inverso. Quando as chaves com valores zzzzzz são modificadas para aaaaaa, os itens vão da extremidade superior para a inferior da árvore B. Mais uma vez, como não há estabilidade nas varreduras, ele perderia as chaves que foram movidas da extremidade superior para a inferior.

Experiência 3 do MongoDB: UPDATES simultâneas

Duas sessões atualizam o campo indexado de forma simultânea e contínua. Nesse caso, com base nas observações anteriores, cada uma das sessões apresenta problemas de supercontagem e subcontagem. O resultado de nModified varia porque o MongoDB relata apenas as atualizações que alteraram o valor.

Mas o número total de documentos modificados nunca é maior que 299980. Portanto, o MongoDB evita atualizar o mesmo documento duas vezes, tratando assim o problema clássico de halloween. Como eles não têm uma varredura estável, presumo que lidam com isso mantendo listas de objectIDs atualizados durante essa declaração de várias atualizações e evitando a atualização se o mesmo objeto aparecer como um documento qualificado.

SESSÃO 1

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

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