हमारे मास्टर डेटाबेस के रूप में मोंगोडीबी का उपयोग करके, क्या मुझे इकाइयों के बीच संबंधों को लागू करने के लिए एक अलग ग्राफ डेटाबेस का उपयोग करना चाहिए?

Question

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

इस सीआरएम समाधान के हिस्से के रूप में हम संस्थाओं के बीच संबंधों और संघों को संग्रहित करना चाहते हैं, उदाहरणों में ब्याज की जानकारी, शेयरधारकों, ट्रस्टी आदि के संघर्षों को संग्रहित करना शामिल है। इन सभी इकाइयों को एक साथ सबसे प्रभावी तरीके से जोड़कर हमने " रिश्ते "जरूरी था। सभी रिश्तों में उनके साथ जुड़ी इतिहास की जानकारी होनी चाहिए (प्रारंभ और समाप्ति तिथियां), साथ ही विभिन्न मेटा डेटा; उदाहरण के लिए एक शेयरधारक रिश्ते में आयोजित शेयरों की संख्या भी होगी।

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

रिश्ते की जानकारी पूरे सिस्टम में काफी भारी उपयोग की जा रही है। सूचना के प्रश्नों हम प्रदर्शन करना चाहते में से कुछ का एक उदाहरण हैं:

• कौन हैं कंपनियों के सभी 'कुंजी संपर्क' लोगों तक पहुंचाएं 'ग्राहकों' 'xyz सीमित' की
• अन्य सभी 'शेयरधारकों की कंपनियों में से प्राप्त करें जहां 'जॉन' एक शेयरधारक
• है जाओ संस्थाओं के सभी 'की कॉन्टॅक्ट' लोग हैं, जो कर रहे हैं 'ग्राहकों' 'एबीसी सीमित' की और के ग्राहकों रहे हैं

'हमें बैंक सीमित भरोसा' इस "पेड़" को देखते हुए रिश्तों की संरचना, ग्राफ डेटाबेस (जैसे Neo4j) का उपयोग कर अधिक उपयुक्त है?

Answer 1

माइक,

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

आपकी अन्य आवश्यकताएं क्या हैं (यानी डेटा सेट आकार, समवर्ती पहुंच आदि #, संबंध/ग्राफ जटिलता)।

आपके प्रश्न ग्राफ डेटाबेस के लिए वास्तव में एकदम सही फिट हैं और इसकी शर्तों में आसानी से अभिव्यक्त हैं।

मैं सुझाव दूंगा कि आप केवल neo4j जैसे ग्राफडी को पकड़ लें और सामान्य व्यवहार्यता को सत्यापित करने के लिए अपने डोमेन के साथ त्वरित स्पाइक करें और दूसरी तकनीक में निवेश करने से पहले अतिरिक्त प्रश्नों का भी उत्तर दें जिन्हें आप जवाब देना चाहते हैं।

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

Answer 2

mongodb के साथ रहें। दो कारण - 1. यदि आप जटिलता को कम करने के लिए एक ही डोमेन में रहना बेहतर है और 2. मोंगोडब पूछताछ के लिए उत्कृष्ट है और उदाहरण के लिए रेडिस की तुलना में कम काम की आवश्यकता है।

Answer 3

मोंगो डीबी में दस्तावेज नियो 4j में नोड्स जैसा दिखता है, रिश्तों को कम करता है। वे दोनों महत्वपूर्ण मूल्य गुण रखते हैं। यदि आप पहले से ही मोंगोडीबी के साथ जाने का विकल्प बना चुके हैं, तो आप रिश्तों को स्टोर करने के लिए नियो 4j का उपयोग कर सकते हैं और फिर अपने एप्लिकेशन में स्टोर को पुल कर सकते हैं। यदि आप नई तकनीक चुन रहे हैं, तो आप सब कुछ के लिए नियो 4j के साथ जा सकते हैं, क्योंकि नोड्स संपत्ति डेटा को साथ ही दस्तावेज कर सकते हैं।

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

ईमानदारी से, आपके लिए क्या काम करता है यह जानने का सबसे अच्छा तरीका है पीओसी - कम लागत, उच्च मूल्य।

अस्वीकरण: मैं नव प्रौद्योगिकी के लिए काम करते हैं।

Answer 4

हम का उपयोग कर दोनों, हम एक परिवहन नेटवर्क के लिए एक खोज इंजन को लागू कर रहे हैं समाप्त हो गया।

1 या 2 "लिंक" से आगे जाने के बाद मोंगो डीबी में संबंधों को लागू करने की कोशिश करना मुश्किल हो सकता है। अनिवार्य रूप से आप एक सरणी में ऑब्जेक्ट संग्रहित करेंगे और यदि आप द्वि-दिशात्मक संबंधों को लागू करना चाहते हैं, तो आपको दो अलग-अलग लिंक लागू करना होगा। मोंगो में, एक इकाई (या "लिंक") के लिए "सूचक" एक और पाठ संपत्ति है (जिसे अलग-अलग व्याख्या किया जा सकता है), यह नियो 4j में रिश्ते की तरह प्रथम श्रेणी की वस्तु नहीं है।

तो हमने रिश्तों को स्टोर करने के लिए नियो 4j का उपयोग करने का निर्णय लिया और मोंगो डीबी को बाकी सब कुछ स्टोर करने के लिए उपयोग किया। तब चुनौती दो स्टोर्स को सिंक में रख रही थी।

हम "मोंगोकनेक्टर" नामक 10gen प्रयोगशाला प्रोजेक्ट का उपयोग कर रहे हैं जो मोंगोडीबी को किसी अन्य स्टोर के साथ सिंक में रखने के लिए तंत्र है। परियोजना वर्तमान में असमर्थित है, लेकिन कोड उपलब्ध है:

http://blog.mongodb.org/post/29127828146/introducing-mongo-connector

MongoConnector सिंक्रनाइज़ लागू करने के लिए प्रतिकृति तंत्र का उपयोग करता है। अनिवार्य रूप से आप मोंगोडीबी ओप्पलॉग की निगरानी कर रहे हैं और आप किसी भी अपरिवर्तनीय (अपडेट या डालने) और हटाए जाने के लिए कॉलबैक लागू कर रहे हैं। इस कार्यान्वयन को मोंगोकनेक्टर बोलने में "दस्तावेज़ प्रबंधक" कहा जाता है। हमने Neo4jDocumentManager को कार्यान्वित करना समाप्त कर दिया।

क्वेरी पक्ष पर, हमने पाया कि नियो "दोस्त के मित्र" के लिए बेहतर अनुकूल है, जबकि मोंगोडीबी सामान्य प्रयोजन प्रश्नों के लिए बेहतर था, यानी। तारीखों से निपटने के लिए प्रति फ़ील्ड या रेंज प्रश्न।

मैं एक बात और एक ब्लॉग पोस्ट के लिए योजना बना रहा है, लेकिन मैं इसे करने के लिए अभी तक नहीं मिला है:

http://www.meetup.com/graphdb-boston/events/91703472/

, इस समाधान के लिए कमियां हैं बातों सिंक्रनाइज़ेशन से बाहर हो रही है की तरह अगर कोई प्रक्रिया धीमा हो या सिंक हो रही हो (रीयलटाइम में नहीं)।