लुसीन/सोलर/लोचदार खोज सूचकांक या नोएसक्यूएल डीबी में पेड़ डेटा कैसे स्टोर करें?

Question

दस्तावेजों के बजाय कहें मेरे पास छोटे पेड़ हैं जिन्हें मुझे लुसीन इंडेक्स में स्टोर करने की आवश्यकता है। मैं इसे कैसे करूं?

पेड़ में एक उदाहरण नोड:

class Node 
{ 
    String data; 
    String type; 
    List<Node> children; 
} 

ऊपर नोड में "डाटा" सदस्य चर शब्दों का एक अंतरिक्ष अलग स्ट्रिंग, ताकि संपूर्ण-पाठ खोज होने की जरूरत है है। "प्रकार" सदस्य चर केवल एक शब्द है।

खोज क्वेरी एक पेड़ ही होगी और दोनों डेटा खोजेगी और प्रत्येक नोड में टाइप करेगी और एक मैच के लिए पेड़ की संरचना भी होगी। एक बच्चे नोड के खिलाफ मिलान करने से पहले, क्वेरी पहले माता-पिता नोड डेटा से मेल खाना चाहिए और टाइप करें। डेटा मान पर लगभग मिलान स्वीकार्य है।

इस तरह के डेटा को इंडेक्स करने का सबसे अच्छा तरीका क्या है? यदि लुसीन सीधे इन आंकड़ों को अनुक्रमणित करने का समर्थन नहीं करता है तो क्या यह सोलर या लोचदार खोज द्वारा किया जा सकता है?

मैंने neo4j पर एक त्वरित नज़र डाली, लेकिन ऐसा लगता है कि यह एक बड़ा ग्राफ डीबी में स्टोर करता है, न कि बड़े पेड़ संरचनाओं के बड़े संग्रह (अरबों या ट्रिलियन कहें)। या मेरी समझ गलत थी?

इसके अलावा, गैर-लुसीन आधारित नोएसक्यूएल समाधान इस के लिए बेहतर है?

Answer 1

एक और दृष्टिकोण पेड़ में वर्तमान नोड के स्थान का प्रतिनिधित्व स्टोर करने के लिए है। उदाहरण के लिए, 14 वें पेड़ के पहले प्रथम स्तर के नोड के तीसरे द्वितीय स्तर के नोड के 17 वें पत्ते को 014.001.003.017 के रूप में दर्शाया जाएगा।

मानते हैं कि 'वृक्षपाथ' पेड़ के स्थान का क्षेत्र का नाम है, तो आप 14 वें पेड़ में सभी नोड्स और पत्तियों को खोजने के लिए 'वृक्षपाथ: 014 *' पर पूछेंगे। इसी तरह, 14 वें पेड़ के सभी बच्चों को खोजने के लिए आप 'वृक्षपाथ: 014. *' पर पूछेंगे।

इस दृष्टिकोण के साथ बड़ी समस्या यह है कि आसपास की शाखाओं को स्थानांतरित करने के बाद प्रत्येक शाखा को फिर से व्यवस्थित करने की आवश्यकता होती है। यदि आपके पेड़ अपेक्षाकृत स्थिर हैं, तो यह केवल अभ्यास में मामूली समस्या हो सकती है।

(मैं इस दृष्टिकोण या तो 'पथ गणन' या 'डेवी दशमलव' प्रतिनिधित्व बुलाया देखा है।)

Answer 2

मैं Neo4j का सुझाव देता हूं। पेड़, आखिरकार, एक विशेष, संयम ग्राफ है।

कि क्या आप Neo4j में एक पेड़ संग्रहीत करना चाहिए पर इस महान चर्चा को यहां देखें:

http://www.mail-archive.com/user@lists.neo4j.org/msg03256.html

Answer 3

इस आवश्यकता और यहाँ समाधान कब्जा कर लिया है: Proposal for nested docs

इस डिजाइन था बाद में कोर ल्यूसीन और लोचदार खोज दोनों द्वारा कार्यान्वित किया गया। Elastic search nested docs

Answer 4

एक परियोजना भोंपू http://rdelbru.github.io/SIREn जो 'में गहराई से' पेड़ के साथ सौदों, को संबोधित नहीं है: BlockJoinQuery के रूप में यहां उनका उल्लेख कोर Lucene कार्यान्वयन और लचीला खोजें नज़र एक कार्यान्वयन है। आंतरिक रूप से डेवी नंबरिंग का उपयोग करता है (http://www.ipl.org/div/farq/deweyFARQ.html) ....