Jedna věc, která mě napadá, je, že možná nebudete muset dělat všechnu práci, kterou si myslíte, že potřebujete, a váš problém lze pravděpodobně vyřešit s malou pomocí od Indexy TTL a případně omezené sbírky . Zvažte následující položky:
{ "_id" : ObjectId("531cf5f3ba53b9dd07756bb7"), "user" : "A", "units" : 50 }
{ "_id" : ObjectId("531cf622ba53b9dd07756bb9"), "user" : "B", "units" : 62 }
Takže tam jsou dva záznamy a máte to _id hodnotu zpět, když jste vložili. Na začátku tedy „A“ nemělo proti komu hrát, ale položka „B“ bude hrát proti tomu před ním.
ObejctId jsou monotónní , což znamená, že „další“ je vždy větší hodnotu než minule. Takže s vloženými daty udělejte toto:
db.moves.find({
_id: {$lt: ObjectId("531cf622ba53b9dd07756bb9") },
user: { $ne: "B" }
}).limit(1)
To dává předchozí vložený "tah" aktuálnímu pohybu, který byl právě proveden, a dělá to proto, že cokoli který byl dříve vložen, bude mít _id s nižší hodnotou než aktuální položka. Ujistíte se také, že „nehrajete“ proti vlastnímu tahu uživatele, a samozřejmě omezíte výsledek pouze na jeden dokument.
Takže „tahy“ se budou navždy posouvat vpřed. Když další vložení provede uživatel „C“, dostanou „pohyb“ od uživatele „B“ a poté uživatel „A“ dostane „pohyb“ od uživatele „C “ a tak dále.
Vše, co se zde „může“ stát, je, že „B“ udělá další "přesunout" v pořadí a vyzvedli byste stejný dokument jako v poslední žádosti. Ale to je bod pro vaše "session" design, uložit poslední "výsledek" a ujistit se, že jste nedostali to samé zpět, a jako takový s tím naložte jakkoli jak chcete ve svém návrhu.
To by na "hraní" mělo stačit. Ale pojďme k vašemu „smazání " část.
Přirozeně si „myslíte“, že chcete věci smazat, ale zpět k mým počátečním „pomocníkům“ by to nemělo být nutné. Shora se mazání stává pouze faktorem „úklidu“, takže vaše sbírka nenarůstá do masivních rozměrů.
Pokud jste použili index TTL, v podstatě stejným způsobem jako tento výukový program vysvětluje, že vaše položky sbírky budou vyčištěny a po určité době odstraněny.
Také co se dá dělat, a hlavně s ohledem na to, že používáme zvyšování povaha _id klíč a že se jedná víceméně o „frontu“, můžete to případně použít jako omezená kolekce
. Můžete tedy nastavit maximální velikost, kolik "tahů" zachováte kdykoli.
Spojením těchto dvou dohromady získáte něco, co „doroste“ pouze do určité velikosti a pokud by se aktivita trochu zpomalila, automaticky se vyčistí za vás. A díky tomu budou všechny operace rychlé .
Sečteno a podtrženo, že souběžnost „deletes ", kterého jste se obávali, bylo odstraněno tím, že bylo skutečně "odstraněno" potřeba odstranit dokumenty, které byly právě přehrávány. Dotaz je jednoduchý a TTL index a omezená kolekce se o správu dat starají za vás.
Takže tady máte můj názor na velmi souběžnou hru "Blind War".