neo4j - एक डेटाबेस डेटाबेस के साथ ग्राफ डेटाबेस?

Question

यह सर्वोत्तम अभ्यास पर एक प्रश्न है, मैं समझता हूं कि ऐसा करने के लिए कई अलग-अलग विकल्प हैं, लेकिन मैं आपकी राय चाहूंगा कि आप इस समस्या को हल करने के तरीके के बारे में क्या करेंगे। कृपया इसे लें क्योंकि इस प्रणाली में प्रदर्शन महत्वपूर्ण है, दूसरे शब्दों में स्केलेबल।

मुझे हाल ही में ग्राफ डेटाबेस के चमत्कार मिल गए हैं, इसलिए मैं एक सैद्धांतिक स्थिति के साथ आया जहां एक कंपनी अपने ग्राहकों के रिश्तों को प्रबंधित करना चाहता है, और ऐसा करने के लिए वे neo4j का उपयोग करने जा रहे हैं जो महान है, और अनुमति देता है ग्राहकों के वास्तव में महान प्रबंधन के लिए, विभिन्न कर्मचारियों के सदस्यों और उनके रिश्तों, जो कि सभी महान हैं, हालांकि कंपनी अब एक वेब आधारित इंटरफ़ेस बनाना चाहता है जिसे प्रमाणीकरण की आवश्यकता होगी, और neo4j डेटाबेस में से कोई भी सिस्टम में लॉगिन करने में सक्षम होना चाहिए यह देखने के लिए कि वे कंपनी के डेटाबेस में अन्य लोगों से कैसे संबंधित हैं, इसलिए प्रत्येक उपयोगकर्ता के पास उनके नाम से जुड़े पासवर्ड/ईमेल/आईडी होना चाहिए।

तो मेरा सवाल यह है कि, इस मामले में, mysql डेटाबेस में password_hash/password_salt/id/ईमेल को संग्रहीत करना सबसे अच्छा है और उसके बाद नोड पर आधारित MySQL डेटाबेस पर इसे देखें। या नोड्स के अंदर हैश टेबल में password_hash/password_salt/id/ईमेल को स्टोर करना बेहतर है।

इसके अलावा प्रत्येक दुकान के उत्पादों के 1000s है, और वे ग्राफ डाटाबेस में संग्रहित किया जा सकता है या मैं mysql डेटाबेस में उत्पादों स्टोर कर सकते हैं और फिर वहाँ उत्पाद को देखने, और वहां परिवर्तन करते हैं, क्योंकि उत्पाद नहीं हैं एक-दूसरे से संबंधित, इसलिए ग्राफ डेटाबेस में उन्हें संग्रहीत करने में कोई बात नहीं है, तो क्या उन्हें प्रदर्शन में सुधार के लिए वहां संग्रहित नहीं किया जाना चाहिए?

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

डेटाबेस शब्दावली के बारे में ज्ञान की कमी के लिए पहले से माफ़ी मांगना।

Answer 1

ग्राफ़ डीबी मुख्य रूप से संबंधों को बनाए रखने के लिए प्रयोग किया जाता है:

सुरक्षा के लिए विशिष्ट है, वहाँ कोई कारण नहीं क्यों Neo4j या किसी अन्य उचित NoSQL समाधान है कि नहीं कर सका है। यदि ऐप में ग्राफ डीबी है जिसका मतलब यह नहीं है कि ऐप को ग्राफ डीबी में सब कुछ स्टोर करने की आवश्यकता है।

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

उच्च स्तरीय संपत्ति (जो नोड को परिभाषित करने वाले संबंध और अन्य महत्वपूर्ण गुणों को परिभाषित करती है) ग्राफ में जाती है जबकि अतिरिक्त जानकारी आरडीएमएस में जाती है।

उदाहरण के लिए एफबी में एफबीआईडी ​​हो सकती है, नाम ग्राफ में जाता है क्योंकि यह एक नोड के रिश्ते को दूसरे के साथ परिभाषित करता है।लेकिन जब उपयोगकर्ता किसी फेसबुक आईडी पर क्लिक करता है, तो उसे अन्य उपयोगकर्ता डीओबी, एज, कॉलेज देखना पड़ता है। ये सभी आरडीबीएमएस में जा सकते हैं।

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

इस दृष्टिकोण के लिए नीचे की ओर है: आपको दो डीबीएस बनाए रखने की आवश्यकता है।

Answer 2

आप चाहिए का उपयोग दोनों मामले में डेटा जहां यह खास मतलब एक ग्राफ में संग्रहीत करना नहीं है है डीबी neo4j/orientDB (और कुछ डेटा एक ग्राफ डीबी के रूप में एक संबंधपरक DB के लिए विरोध में बंद बेहतर होगा जैसे)। एक मंच पर डेटा को मजबूर करने से लाइन के नीचे प्रदर्शन/स्केलेबिलिटी के साथ समस्या हो सकती है।

Answer 3

जब तक आपके पास दो-डीबी समाधान के लिए एक सिद्ध मामला नहीं है, तो मैं कहूंगा कि कम चलने वाले हिस्सों में आपको अधिक चुस्त रहना होगा, और चीजों को जल्दी से बदलने में सक्षम होगा। यदि बाद में आपको एक ऐसा केस मिलता है जो मुश्किल है, तो दूसरा स्टोरेज पेश करने की लागत/लाभ का वजन लें। एक दो-डीबी आर्किटेक्चर की अनदेखी नहीं है, लेकिन एक ओवरहेड के साथ आता है। http://spring.neo4j.org/docs#tutorial_security