Een ding dat hierbij in je opkomt, is dat je misschien niet al het werk hoeft te doen dat je denkt nodig te hebben, en je probleem kan waarschijnlijk worden opgelost met een beetje hulp van TTL-indexen en mogelijk afgetopte collecties . Overweeg de volgende vermeldingen:
{ "_id" : ObjectId("531cf5f3ba53b9dd07756bb7"), "user" : "A", "units" : 50 }
{ "_id" : ObjectId("531cf622ba53b9dd07756bb9"), "user" : "B", "units" : 62 }
Er zijn dus twee items en je hebt die _id waarde terug wanneer u invoegde. Dus in het begin had "A" niemand om tegen te spelen, maar de inzending voor "B" speelt tegen degene ervoor.
ObejctId's zijn monotoon , wat betekent dat de "volgende" is altijd groter in waarde dan de vorige. Dus met de ingevoegde gegevens, doe dit gewoon:
db.moves.find({
_id: {$lt: ObjectId("531cf622ba53b9dd07756bb9") },
user: { $ne: "B" }
}).limit(1)
Dat geeft de vorige ingevoegde "zet" naar de huidige zet die zojuist is gemaakt, en doet dit omdat alles die eerder was ingevoegd, heeft een _id met minder waarde dan het huidige item. Je zorgt er ook voor dat je niet "speelt" tegen de eigen zet van de gebruiker, en natuurlijk beperk je het resultaat tot slechts één document.
Dus de "bewegingen" zullen voor altijd vooruit gaan. Wanneer de volgende invoeging wordt gemaakt door gebruiker "C", krijgen ze de "zet" van gebruiker "B", en dan krijgt gebruiker "A" de "zet" van gebruiker "C ", enzovoort.
Het enige dat hier "zou" kan gebeuren, is dat "B" de volgende . maakt achtereenvolgens "verplaatsen", en u zou hetzelfde document ophalen als in het laatste verzoek. Maar dat is een punt voor uw "sessie"-ontwerp, om het laatste "resultaat" op te slaan en ervoor te zorgen dat u niet hetzelfde terugkrijgt, en als zodanig hiermee omgaat, hoe u wilt in uw ontwerp.
Dat zou genoeg moeten zijn om mee te "spelen". Maar laten we naar uw "verwijdering . gaan " deel.
Natuurlijk "denk" je dat je dingen wilt verwijderen, maar terug naar mijn oorspronkelijke "helpers" zou dit niet nodig moeten zijn. Van bovenaf wordt verwijdering slechts een factor van "opschonen", dus uw verzameling groeit niet tot enorme proporties.
Als je een TTL-index hebt toegepast, op ongeveer dezelfde manier als deze tutorial legt uit dat uw collectievermeldingen voor u worden opgeschoond en na een bepaalde tijd worden verwijderd.
Ook wat er kan worden gedaan, en vooral gezien het feit dat we de toenemende . gebruiken aard van de _id sleutel en dat dit min of meer een "wachtrij" van aard is, zou je dit mogelijk kunnen toepassen als een afgetopte collectie
. U kunt dus een maximale grootte instellen voor het aantal "zetten" dat u houdt op elk moment.
Als je de twee combineert, krijg je iets dat alleen "groeit" tot een bepaalde grootte en dat automatisch voor je wordt schoongemaakt, mocht de activiteit een beetje vertragen. En dat houdt alle bewerkingen snel .
Waar het op neerkomt is dat de gelijktijdigheid van "verwijdert " waar u zich zorgen over maakte, is verwijderd door de noodzaak om de zojuist afgespeelde documenten te verwijderen "verwijderd". De zoekopdracht houdt het eenvoudig en de TTL-index en de gecapte verzameling zorgen voor uw gegevensbeheer.
Dus daar heb je wat mijn mening is over een zeer gelijktijdig spel van "Blind War".