हम संग्रह का अनुसरण करते हैं। तंग करने वाले शाप

यदि आप युवा और ऊर्जावान हैं , जो मोंगडॉब में रुचि रखते हैं, तो रूसी में अनुपलब्ध अनुवाद के विषय पर बहस करना चाहते हैं, और आप रुचि रखते हैं कि पिक्रेल कहाँ से आता है - बिल्ली का स्वागत।



कुछ समय पहले, एक छोटी परियोजना के लिए व्यवस्थापक पैनल बनाते हुए, मैंने सोचा कि इसमें कुछ महत्वपूर्ण घटनाओं का लॉग प्रदर्शित करना अच्छा होगा। स्मृति ने मदद से मुझे मोंगडब की उन विशेषताओं में से एक की याद दिला दी, जिनके बारे में मैंने सुना था, लेकिन कभी भी व्यवहार में नहीं लाया था - जमानतदार।

किस तरह का जानवर?

डिफ़ॉल्ट रूप से, ग्राहक द्वारा कर्सर को उपलब्ध सभी डेटा प्राप्त करने के बाद मोंगो अपने आप कनेक्शन बंद कर देता है। सीमित (छाया हुआ) संग्रह के लिए, अतिरिक्त व्यवहार संभव है, तथाकथित पूंछ कर्सर।

टेल कर्सर खुले रहते हैं और नए डेटा प्राप्त करना जारी रखते हैं जो खोज मानदंडों को पूरा करते हैं। उनकी कार्रवाई परिचित पूंछ की याद ताजा करती है। Mongo उत्पीड़न को ट्रैक करने के लिए टेल कर्सर का उपयोग करता है।

आपको क्या चाहिए, मैंने सोचा

new Thread(new Runnable() { @Override public void run() { DBCollection collection=MongoConnector.getInstance().getCollection("events"); //  addOption DBCursor cur= collection.find().addOption(Bytes.QUERYOPTION_TAILABLE).addOption(Bytes.QUERYOPTION_AWAITDATA); while (cur.hasNext()) { //   ,    ,     JS wsConnection.broadcast((String) cur.next().get("message")); } } }).start(); 

वैसे, जैसा कि अभ्यास से पता चला है, एक नया दस्तावेज़ डालने और टेल कर्सर के साथ क्लाइंट द्वारा इसे प्राप्त करने में देरी इतनी तुच्छ है कि इसे सिद्धांत रूप में अनदेखा किया जा सकता है।

मरहम में उड़ना

आधिकारिक प्रलेखन से पता चलता है कि बहुत सारे लेखन कार्यों के साथ संग्रह पर पूंछ के कर्सर का उपयोग करना बहुत महंगा हो सकता है। यदि एक क्वेरी उन फ़ील्ड पर बनाई गई है जिसके लिए एक इंडेक्स है, तो बड़ी संख्या में रिकॉर्ड के मामले में, नियमित कर्सर का उपयोग करना बेहतर होता है, समय-समय पर नए दस्तावेज़ों का अनुरोध करना

यह कैसे काम करता है?

ऊपर याद रखें, मैंने लिखा था पूंछ का काम कर्सर पूंछ -f के काम जैसा दिखता है? वास्तव में, पहली नज़र में लगता है कि तुलना में और भी समानताएँ हैं।
जब आप टेल कर्सर सेट करते हैं और इससे डेटा पढ़ते हैं, तो अंतिम दस्तावेज़ तक पहुंचते हुए, मोंगो उस पर कर्सर छोड़ देता है और संग्रह विवरणक को देखता है, अगर कोई नया तत्व प्रकट होता है जो अनुरोध को संतुष्ट करता है, तो कर्सर उसके पास चला जाता है।
साधारण (असीमित) संग्रहों के लिए, यह व्यवहार असंभव है, क्योंकि जिस क्रम में दस्तावेजों को डिस्क में संग्रहीत किया जाता है, वह हमेशा डेटा प्रविष्टि के क्रम के अनुरूप नहीं होता है।

दुनिया को झकझोर देने वाले टेल अभिशापों के बारे में 4 तथ्य

1) टेल कर्सर इंडेक्स और रिटर्न दस्तावेजों का उपयोग उस क्रम में नहीं करते हैं जिसमें वे डिस्क पर संग्रहीत होते हैं। सीमित संग्रहों के लिए, प्लेसमेंट ऑर्डर हमेशा दस्तावेजों के सम्मिलन क्रम से मेल खाता है।

2) चूंकि इंडेक्स का उपयोग नहीं किया जाता है, क्वेरी की शुरुआत में आपको संग्रह में सभी रिकॉर्ड पढ़ना होगा - जो, बड़ी मात्रा में डेटा के साथ, काफी महंगा हो सकता है। हम पहले से ही उपलब्ध डेटा प्राप्त करने के बाद, नए जोड़े गए दस्तावेजों की स्क्रीनिंग करते हैं जो अनुरोध को संतुष्ट नहीं करते हैं, लाभहीन नहीं है।

3) टेल कर्सर अमान्य हो सकता है (यदि संग्रह की कोई ट्रैकिंग नहीं होगी) यदि
प्रारंभिक खोज क्वेरी में कोई दस्तावेज़ नहीं मिले।
अंतिम दस्तावेज़ उस क्षण को हटा दिया गया था जिस दिन कर्सर उस ओर इशारा कर रहा था।

4) मृत कर्सर की आईडी 0 है