O bloqueio do MongoDB é diferente
Bloquear no MongoDB não funciona como bloquear em um RDBMS, então um pouco de explicação está em ordem. Nas versões anteriores do MongoDB, havia uma única trava global de leitor/gravador. A partir do MongoDB 2.2, há uma trava de leitor/gravador para cada banco de dados.
A trava do leitor-escritor
A trava é de vários leitores, de um único escritor e é ávida por escritor. Isso significa que:
- Pode haver um número ilimitado de leitores simultâneos em um banco de dados
- Só pode haver um escritor por vez em qualquer coleção em qualquer banco de dados (mais sobre isso daqui a pouco)
- Os escritores bloqueiam os leitores
- Por "escritor-ganancioso", quero dizer que, quando uma solicitação de gravação chega, todos os leitores são bloqueados até que a gravação seja concluída (mais sobre isso posteriormente)
Observe que eu chamo isso de "trava" em vez de "trava". Isso ocorre porque é leve e, em um esquema projetado adequadamente, o bloqueio de gravação é mantido na ordem de uma dúzia de microssegundos. Veja aqui para saber mais sobre o bloqueio de leitores-escritor.
No MongoDB, você pode executar quantas consultas simultâneas desejar:desde que os dados relevantes estejam na RAM, todos serão atendidos sem conflitos de bloqueio.
Atualizações de documentos atômicos
Lembre-se de que no MongoDB o nível de transação é um único documento. Todas as atualizações de um único documento são Atômicas. O MongoDB consegue isso mantendo a trava de gravação apenas pelo tempo necessário para atualizar um único documento na RAM. Se houver alguma operação de execução lenta (em particular, se um documento ou uma entrada de índice precisar ser paginada do disco), essa operação renderá a trava de escrita. Quando a operação produz a trava, a próxima operação na fila pode prosseguir.
Isso significa que as gravações em todos os documentos em um único banco de dados são serializadas. Isso pode ser um problema se você tiver um design de esquema ruim e suas gravações demorarem muito, mas em um esquema projetado adequadamente, o bloqueio não é um problema.
Escritor-ganancioso
Mais algumas palavras sobre ser ganancioso por escritor:
Apenas um gravador pode segurar a trava de cada vez; vários leitores podem segurar a trava de cada vez. Em uma implementação ingênua, os escritores poderiam morrer de fome indefinidamente se houvesse um único leitor em operação. Para evitar isso, na implementação do MongoDB, uma vez que qualquer thread faz uma solicitação de gravação para uma trava específica
- Todos os leitores subsequentes que precisarem dessa trava serão bloqueados
- Esse escritor aguardará até que todos os leitores atuais terminem
- O escritor adquirirá a trava de gravação, fará seu trabalho e, em seguida, liberará a trava de gravação
- Todos os leitores na fila continuarão agora
O comportamento real é complexo, uma vez que esse comportamento ganancioso do escritor interage com a rendição de maneiras que podem não ser óbvias. Lembre-se de que, a partir da versão 2.2, há um separado latch para cada banco de dados, portanto, gravações em qualquer coleção no banco de dados 'A' adquirirão um latch separado do que grava em qualquer coleção no banco de dados 'B'.
Perguntas específicas
Sobre as perguntas específicas:
- Os bloqueios (na verdade, travas) são mantidos pelo kernel do MongoDB apenas pelo tempo necessário para atualizar um único documento
- Se você tiver várias conexões chegando ao MongoDB e cada uma delas estiver executando uma série de gravações, a trava será mantida por banco de dados apenas pelo tempo necessário para que a gravação seja concluída l>
- Várias conexões que chegam ao realizar gravações (atualizar/inserir/excluir) serão todas intercaladas
Embora isso pareça ser uma grande preocupação com o desempenho, na prática isso não desacelera as coisas. Com um esquema projetado adequadamente e uma carga de trabalho típica, o MongoDB saturará a capacidade de E/S do disco - mesmo para um SSD - antes que a porcentagem de bloqueio em qualquer banco de dados ultrapasse 50%.
O cluster MongoDB de maior capacidade que conheço está atualmente executando 2 milhões de gravações por segundo.
