Едно нещо, което идва на ум тук е, че може да не е необходимо да вършите цялата работа, която смятате, че трябва, и проблемът ви вероятно може да бъде разрешен с малко помощ от TTL индекси и евентуално ограничени колекции . Разгледайте следните записи:
{ "_id" : ObjectId("531cf5f3ba53b9dd07756bb7"), "user" : "A", "units" : 50 }
{ "_id" : ObjectId("531cf622ba53b9dd07756bb9"), "user" : "B", "units" : 62 }
Така че има два записа и вие получавате този _id стойност обратно, когато поставите. Така че в началото "A" нямаше срещу кого да играе, но влизането за "B" ще играе срещу това преди него.
ObejctId са монотонни , което означава, че "следващият" е винаги по-голяма по стойност от последната. Така че с вмъкнатите данни просто направете следното:
db.moves.find({
_id: {$lt: ObjectId("531cf622ba53b9dd07756bb9") },
user: { $ne: "B" }
}).limit(1)
Това дава предишния вмъкнат „ход“ към текущия ход, който току-що беше направен, и прави това, защото всичко който е бил вмъкнат преди това, ще има _id с по-малка стойност отколкото текущия елемент. Също така се уверете, че не „играете“ срещу собствения ход на потребителя и, разбира се, ограничавате резултата само до един документ.
Така че "ходовете" ще се движат винаги напред, когато следващото вмъкване е направено от потребител "C", те получават "движението" от потребител "B", а след това потребител "A" ще получи "движението" от потребител "C" “ и т.н.
Всичко, което „може“ да се случи тук, е „Б“ да направиследващия „преместване“ последователно и ще вземете същия документ като при последната заявка. Но това е точка за вас дизайн на „сесия“, за да съхраните последния „резултат“ и да се уверите, че не сте получили същото нещо обратно, и като такъв, се справете с това, както и вие искате във вашия дизайн.
Това би трябвало да е достатъчно за „играене“. Но нека да стигнем до вашето „изтриване " част.
Естествено вие „мислите“, че искате да изтриете неща, но да се върнем към моите първоначални „помощници“, това не би трябвало да е необходимо. Отгоре изтриването става само фактор за „почистване“, така че вашата колекция да не нарасне до огромни размери.
Ако сте приложили TTL индекс, почти по същия начин като този урок обяснява, вашите записи в колекцията ще бъдат изчистени вместо вас и премахнати след определен период от време.
Също така какво може да се направи и особено като се има предвид, че използваме увеличаването характер на _id ключ и че това е повече или по-малко "опашка" по природа, бихте могли да приложите това като ограничена колекция
. Така че можете да зададете максимален размер за това колко "движения" ще запазите по всяко време.
Комбинирайки двете заедно, вие получавате нещо, което "расте" само до определен размер и ще бъде автоматично почистено за вас, ако активността се забави малко. И това ще поддържа всички операции бързи .
Заключението е, че едновременността на „изтрива ", за което се притеснявахте, е премахнато, като всъщност е "премахнато" необходимостта от изтриване на току-що възпроизведените документи. Заявката е проста, а TTL индексът и ограничената колекция се грижат за управлението на вашите данни вместо вас.
И така, ето какво е моето мнение за една много съпътстваща игра на "Blind War".
