यहां एक बात जो दिमाग में आती है वह यह है कि आपको वह सभी काम करने की आवश्यकता नहीं हो सकती है जो आपको लगता है कि आपको करने की आवश्यकता है, और आपकी समस्या को शायद थोड़ी सी मदद से हल किया जा सकता है TTL अनुक्रमणिका और संभवतः कैप्ड संग्रह . निम्नलिखित प्रविष्टियों पर विचार करें:
{ "_id" : ObjectId("531cf5f3ba53b9dd07756bb7"), "user" : "A", "units" : 50 }
{ "_id" : ObjectId("531cf622ba53b9dd07756bb9"), "user" : "B", "units" : 62 }
तो दो प्रविष्टियाँ हैं और आपको वह _id मिल गया है मूल्य वापस जब आप डाला। तो शुरुआत में, "ए" के खिलाफ खेलने के लिए कोई नहीं था, लेकिन "बी" के लिए प्रविष्टि इससे पहले के खिलाफ खेली जाएगी।
ObejctId's हैं मोनोटोनिक , जिसका अर्थ है कि साथ में "अगला" हमेशा . है पिछले से मूल्य में अधिक। तो डाले गए डेटा के साथ, बस यह करें:
db.moves.find({
_id: {$lt: ObjectId("531cf622ba53b9dd07756bb9") },
user: { $ne: "B" }
}).limit(1)
यह पिछले सम्मिलित "चाल" को वर्तमान चाल में देता है जो अभी बनाया गया था, और ऐसा इसलिए करता है क्योंकि कुछ भी जो पहले डाला गया था उसमें एक _id होगा कम मूल्य . के साथ वर्तमान वस्तु की तुलना में। आप यह भी सुनिश्चित करते हैं कि आप उपयोगकर्ता के अपने कदम के खिलाफ "खेल" नहीं रहे हैं, और निश्चित रूप से आप परिणाम को केवल एक दस्तावेज़ तक सीमित कर देते हैं।
तो "चाल" हमेशा आगे बढ़ते रहेंगे, जब उपयोगकर्ता "सी" द्वारा अगला सम्मिलन किया जाता है तो उन्हें उपयोगकर्ता "बी" से "चाल" मिलता है, और फिर उपयोगकर्ता "ए" को उपयोगकर्ता "सी" से "चाल" मिल जाएगा ", और इसी तरह।
यहाँ केवल "हो सकता है" यह है कि "B" अगला . बनाता है क्रम में "स्थानांतरित करें", और आप पिछले अनुरोध के समान दस्तावेज़ उठाएंगे। लेकिन यह आपके . के लिए एक बिंदु है "सत्र" डिज़ाइन, पिछले "परिणाम" को संग्रहीत करने के लिए और यह सुनिश्चित करने के लिए कि आपको वही चीज़ वापस नहीं मिली है, और इस तरह, उससे निपटें हालांकि आप अपने डिजाइन में चाहते हैं।
यह "खेलने" के लिए पर्याप्त होना चाहिए। लेकिन चलिए आपके "हटाने . पर चलते हैं "भाग।
स्वाभाविक रूप से आप "सोचते हैं" आप चीजों को हटाना चाहते हैं, लेकिन मेरे शुरुआती "सहायकों" पर वापस यह आवश्यक नहीं होना चाहिए। ऊपर से, हटाना केवल "सफाई-अप" का एक कारक बन जाता है, इसलिए आपका संग्रह बड़े अनुपात में नहीं बढ़ता है।
अगर आपने टीटीएल इंडेक्स लागू किया है, तो ठीक उसी तरह जैसे इस ट्यूटोरियल बताते हैं, आपकी संग्रह प्रविष्टियां आपके लिए साफ़ कर दी जाएंगी, और एक निश्चित अवधि के बाद हटा दी जाएंगी।
इसके अलावा क्या किया जा सकता है, और विशेष रूप से यह देखते हुए कि हम बढ़ते . का उपयोग कर रहे हैं _id . की प्रकृति कुंजी और यह कि यह कमोबेश एक "कतार" प्रकृति की है, आप संभवतः इसे कैप्ड संग्रह
. तो आप अधिकतम आकार सेट कर सकते हैं कि आप कितने "चाल" रखेंगे किसी भी समय।
दोनों को एक साथ मिलाकर, आपको कुछ ऐसा मिलता है जो केवल एक निश्चित आकार में "बढ़ता" है, और आपके लिए स्वचालित रूप से साफ हो जाएगा, गतिविधि थोड़ी धीमी होनी चाहिए। और यह सभी कार्यों को तेज़ रखने वाला है ।
लब्बोलुआब यह है कि "हटाए गए . की संगामिति " जिसके बारे में आप चिंतित थे, उसे वास्तव में अभी-अभी चलाए गए दस्तावेज़ों को हटाने की आवश्यकता को "हटाकर" हटा दिया गया है। क्वेरी इसे सरल रखती है, और TTL अनुक्रमणिका और कैप्ड संग्रह आपके लिए डेटा प्रबंधन की देखभाल करते हैं।
तो वहाँ आपके पास "ब्लाइंड वॉर" के एक बहुत ही समवर्ती खेल पर मेरा क्या विचार है।
