MongoDB
 sql >> Base de Dados >  >> NoSQL >> MongoDB

MongoDB Melhor maneira de emparelhar e excluir entradas de banco de dados sequenciais


Uma coisa que vem à mente aqui é que você pode não precisar fazer todo o trabalho que acha necessário, e seu problema provavelmente pode ser resolvido com uma pequena ajuda de Índices TTL e possivelmente coleções limitadas . Considere as seguintes entradas:
{ "_id" : ObjectId("531cf5f3ba53b9dd07756bb7"), "user" : "A", "units" : 50 }
{ "_id" : ObjectId("531cf622ba53b9dd07756bb9"), "user" : "B", "units" : 62 }

Portanto, há duas entradas e você tem esse _id valor de volta quando você inseriu. Então, no início, "A" não tinha ninguém para jogar contra, mas a entrada para "B" jogará contra a anterior.

ObejctIds são monotônicos , o que significa que o "próximo" é sempre maior em valor do último. Então, com os dados inseridos, basta fazer isso:
db.moves.find({ 
    _id: {$lt: ObjectId("531cf622ba53b9dd07756bb9") }, 
    user: { $ne: "B" } 
}).limit(1)

Isso fornece o "movimento" inserido anteriormente para o movimento atual que acabou de ser feito e faz isso porque qualquer coisa que foi inserido anteriormente terá um _id com menor valor do que o item atual. Você também garante que não está "jogando" contra a jogada do próprio usuário e, claro, limita o resultado a apenas um documento.

Assim, os "movimentos" estarão sempre avançando, quando a próxima inserção for feita pelo usuário "C", eles receberão o "movimento" do usuário "B" e, em seguida, o usuário "A" obterá o "movimento" do usuário "C ", e assim por diante.

Tudo o que "poderia" acontecer aqui é que "B" faça o próximo "mover" em sequência, e você pegaria o mesmo documento da última solicitação. Mas esse é um ponto para seu design de "sessão", para armazenar o último "resultado" e garantir que você não tenha a mesma coisa de volta e, como tal, lide com isso da maneira que você deseja em seu projeto.

Isso deve ser o suficiente para "brincar". Mas vamos ao seu "exclusão " papel.

Naturalmente você "acha" que quer deletar coisas, mas voltando aos meus "ajudantes" iniciais, isso não deveria ser necessário. De cima, a exclusão torna-se apenas um fator de "limpeza", para que sua coleção não cresça em proporções massivas.

Se você aplicou um índice TTL, da mesma forma que este tutorial explica, suas entradas de coleção serão limpas para você e removidas após um determinado período de tempo.

Também o que pode ser feito, e especialmente considerando que estamos usando o aumento natureza do _id key e que isso é mais ou menos uma "fila" por natureza, você poderia aplicar isso como um coleção limitada . Assim, você pode definir um tamanho máximo para quantos "movimentos" você manterá a qualquer momento.

Combinando os dois, você obtém algo que apenas "cresce" até um determinado tamanho e será automaticamente limpo para você, caso a atividade diminua um pouco. E isso manterá todas as operações rápidas .

A conclusão é que a simultaneidade de "exclusões " com o qual você estava preocupado foi removido, na verdade, "removendo" a necessidade de excluir os documentos que acabaram de ser reproduzidos. A consulta mantém tudo simples, e o índice TTL e a coleção limitada cuidam do gerenciamento de dados para você.

Então aí está a minha opinião sobre um jogo muito simultâneo de "Blind War".