क्या सीओएचडीबी में एकाधिक टैग खोज लागू करने का कोई तरीका है? मेरे पास एकाधिक टैग वाले दस्तावेज़ (पोस्ट) हैं। मुझे उन पदों को ढूंढने की ज़रूरत है जिन्हें टैग के मनमानी सेट के साथ टैग किया गया है। मैं यह कैसे करुं? मैं निश्चित रूप से एक दृश्य में कई कॉल के साथ ऐसा कर सकता हूं जो मुझे टैग के लिए दस्तावेज देता है और फिर इसे मेरे ऐप में सॉर्ट करता है लेकिन मैं जानना चाहता था कि सोफेडीबी व्यू भूमि में इसे प्राप्त करने का कोई तरीका था या नहीं।कॉच डीबी एकाधिक टैग
कॉच डीबी के हाल के संस्करणों में, आप keys नामक एक JSON दस्तावेज़ के साथ एक दृश्य में पोस्ट कर सकते हैं, जो बहु-कुंजी लुकअप की अनुमति देता है। संरचना कुछ इस तरह दिखेगा:
{"keys": ["first_tag", "second_tag", "third_tag"]}
यह आप हैं, वे अपने संबंधित चाबी के लिए कि उत्सर्जित करती है टैग के लिए एक दृश्य के लिए पोस्ट किया जा सकता है।
यह और अन्य पूछताछ विकल्प here दस्तावेज किए गए हैं।
रायन डफिल्ड द्वारा उपरोक्त समझाया गया एक तरीका है। हालांकि यह कुछ प्रश्न हल करता है लेकिन यह समय की अवधि में अप्रबंधनीय हो जाएगा। अन्यथा पूर्ण पाठ खोज का उपयोग करना है जो वर्तमान में कॉच डीबी द्वारा समर्थित नहीं है लेकिन लुसीन का उपयोग कर बाहरी प्लगइन है। http://wiki.apache.org/couchdb/Full_text_search पर और अधिक।
वास्तव में टैगिंग एक बहुत ही रिश्तेदार समस्या प्रतीत होती है और यह कॉच डीबी के डिजाइन के साथ अच्छी तरह से खेल नहीं पाती है। तो मैंने MySQL पर टैग के लिए एक छोटा डेटाबेस रखने का निर्णय लिया है और CouchDB में संग्रहीत वास्तविक दस्तावेज़ हैं। यह मुझे दोनों दुनिया के सर्वश्रेष्ठ प्राप्त करने देता है। यद्यपि इस तकनीक में सिंक्रनाइज़ेशन से संबंधित समस्याएं हैं, टैग पर खोज एसक्यूएल पर एक कुशल संचालन है और सामग्री प्रतिकृति या शेरिंग के बारे में चिंता करने के लिए बहुत अधिक नहीं है। आपके सभी उत्तरों के लिए धन्यवाद।
मैं इस दावे से असहमत हूं; CouchDB में सही ढंग से किए जाने पर टैग काफी अच्छी तरह से काम करते हैं। मैं प्रेरणा के लिए सोफा जैसे कुछ को देखने की सिफारिश करता हूं: http://github.com/jchris/sofa –
मुझे यकीन नहीं है कि यह क्यों कम हो गया है। ईआर और संबंधित प्रश्नों को एक रिलेशनल डेटाबेस में सबसे अच्छा हल किया जाता है। – Till
तो, जहां तक मुझे जवाब समझा गया, नहीं है। कॉच डीबी कई टैग्स की उपस्थिति वाले दस्तावेज़ों के लिए क्वेरी नहीं कर सकता है (ल्यूसीन या माइस्क्ल के साथ कामकाज की गणना नहीं होती है, इस तरह हमने सोफेडबी की कुछ विशेषताओं को खो दिया है)। दुःखद समाचार :(
। (एकाधिक टैग की उपस्थिति होने - दोनों ए और बी के होने, एक नहीं या बी)
युपीडी यह संभव है, लेकिन केवल 2-3 टैग करने के लिए सीमाओं के साथ
!।http://wiki.apache.org/couchdb/EntityRelationship
एकाधिक कुंजियों
कुछ अनुप्रयोग ओ चौराहे देखने की जरूरत से क्वैरी एफ इकाइयां जिनमें एकाधिक कुंजी हैं। उपर्युक्त उदाहरण में, यह उन संपर्कों के लिए एक प्रश्न होगा जो "मित्र" और "सहयोगी" समूहों दोनों में हैं। इस स्थिति को संभालने का सबसे सीधा-आगे तरीका कुंजी में से किसी एक के लिए पूछना है, और उसके बाद क्लाइंट-साइड पर शेष कुंजी द्वारा फ़िल्टर करना है। यदि कुंजी आवृत्तियों में काफी भिन्नता है, तो निम्नतम आवृत्ति के साथ कुंजी निर्धारित करने के लिए प्रारंभिक कॉल करना और डेटाबेस से प्रारंभिक दस्तावेज़ सूची लाने के लिए इसका उपयोग करना भी उपयोगी हो सकता है।
यदि यह एक अच्छा विकल्प नहीं है, तो कुंजी के संयोजनों को अनुक्रमणित करना संभव है, हालांकि किसी दिए गए दस्तावेज़ के लिए सूचकांक की वृद्धि इसकी कुंजी की संख्या के साथ घातीय हो जाएगी। फिर भी, छोटे-आइश कुंजी सेट के लिए, यह एक विकल्प है, क्योंकि चाबियों का आदेश दिया जा सकता है, और कुंजी जो कि एक बड़ी कुंजी के उपसर्ग हैं, छोड़े जा सकते हैं।उदाहरण के लिए, कुंजी सेट [1 2 3] के लिए संभावित कुंजी संयोजन [1] [2] [3] [1 2] [1 3] [2 3] [1 2 3] हालांकि, सूचकांक में केवल आवश्यकता होती है कुंजी [3] [1 3] [2 3] [1 2 3] चूंकि (उदाहरण के लिए) चाबियाँ मिलान करने वाले दस्तावेज़ [1 2] स्टार्टकी = [1,2, नल] और एंडकी के लिए एक क्वेरी के साथ प्राप्त किए जा सकते हैं = [1,2, {}] इंडेक्स प्रविष्टियों की संख्या 2^(एन -1) कुंजी की संख्या होगी।
एक अंतिम विकल्प ऐसे प्रश्नों के साथ मदद करने के लिए एक अलग इंडेक्स, जैसे कि कॉचडब-लुसीन का उपयोग करना है।
मुझे लगता है कि आपको थोड़ा जटिल लेकिन ठोस एल्गोरिदम देना चाहिए - यानी यह पहले परिणाम तेजी से पाता है, भले ही आपके पास बहुत सारे दस्तावेज़ हों। यह शायद अच्छी तरह से अभ्यास :(
सूचकांक में दस्तावेजों प्रत्येक एकल टैग द्वारा और प्रदर्शन नहीं करेगा वहाँ दस्तावेज़ आईडी:
[<some tag>, <document id>]
जैसे दस्तावेज़ों के लिए दस्तावेज़
साथ docid2
['blue', 'docid1'] ['blue', 'docid2'] ['green', 'docid1'] ['red', 'docid1'] ['yellow', 'docid2']
अब प्रत्येक टैग के लिए आप खोजना चाहते हैं, [टैग, ...] से शुरू होने वाली समांतर खोज खोलें।
प्रत्येक टैग के लिए आप वर्तमान खोज स्थिति बनाए रखते हैं। यदि आपकी सभी खोजों पर डॉकिड मेल खाते हैं, तो आपको एक मैच मिला। यदि वे मेल नहीं खाते हैं, तो कम से कम उच्चतम दस्तावेज़ आईडी को एक श्रेणी खोज के माध्यम से छोड़ने का प्रयास करें। दोहराएँ।
[यह मूल रूप से एक में शामिल होने की है।]
लंघन सैद्धांतिक रूप से तेजी से होता है: हम इन दस्तावेजों को खोजने के लिए एक सूचकांक है। व्यावहारिक रूप से, यह सर्वर के सभी दौर यात्राओं की वजह से शायद धीमा है। सर्वर पर निष्पादित फ़ंक्शन में उस एल्गोरिदम को ऑफ़लोड करने में सक्षम होना अच्छा होगा। क्या यह संभव है?
मैंने इस समस्या को एक पुनरावर्ती कार्य के साथ एक दृश्य बनाने का हल किया है। यहां गिस्ट https://gist.github.com/820412
मुझे यकीन नहीं है कि यह सबसे अच्छा तरीका होगा या नहीं। मान लीजिए कि मेरे पास 15 अलग-अलग टैग की एक सूची है जिसे किसी भी अलग संयोजन और क्रम में लागू किया जा सकता है, तो मेरे पास 15^14 कुंजी संयोजन होंगे। इन सभी प्रश्नों को उत्पन्न करना और अनुक्रमण करना स्वयं ही एक कठिन काम होगा। पीएस। गणित मेरा सबसे मजबूत क्षेत्र नहीं है। अगर मैं ग़लत हूं तो मेरी गलती सुझाएं। –
बेशक उन्हें सॉर्ट किया जा सकता है और आपके पास कई संयोजन नहीं हैं। – Luman75
यह उन सभी दस्तावेज़ों को पुनर्प्राप्त करने के लिए काम करता है जिनमें कुंजी सूची में से कम से कम टैग में से एक है। लेकिन क्या होगा यदि आप सभी दस्तावेजों को ढूंढना चाहते हैं जिनमें सभी टैग हैं? –