क्या MySQL और Neo4j का एक साथ उपयोग करना अच्छा विचार है?

Question

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

लेकिन साथ ही, मैं सभी वस्तुओं के बीच संबंधों को संग्रहित करूंगा, जो कि कई जुड़े बाइनरी-पेड़ जैसी संरचनाओं (ट्रांजिटिव क्लोजर) से संबंधित हैं, और रिलेशन डेटाबेस इस तरह की संरचनाओं में अच्छे नहीं हैं, इसलिए मैं Neo4j में सभी संबंधों को स्टोर करना चाहते हैं जिनके पास इस तरह के डेटा के लिए अच्छा प्रदर्शन है।

मेरी योजना है MySQL डेटाबेस में संबंधों को छोड़कर सभी डेटा और item_id के साथ सभी संबंध Neo4j डेटाबेस में संग्रहीत हैं। पेड़ में है, तो मुझे लगता है कि कैसा दिखेगा एक प्रश्न में सभी निर्दिष्ट मदों के लिए MySQL-डेटाबेस को देखें:: जब मैं एक पेड़ देखने के लिए चाहते हैं, मैं पहली बार Neo4j के लिए सभी item_id खोज

SELECT * FROM items WHERE item_id = 45 OR item_id = 345435 OR item_id = 343 OR item_id = 78 OR item_id = 4522 OR item_id = 676 OR item_id = 443 OR item_id = 4255 OR item_id = 4345

क्या यह एक अच्छा विचार है, या क्या मैं बहुत गलत हूं? मैंने पहले ग्राफ-डेटाबेस का उपयोग नहीं किया है। क्या मेरी समस्या के लिए कोई बेहतर दृष्टिकोण है? MySQL- क्वेरी इस मामले में कैसे कार्य करेगी?

Answer 1

इस पर कुछ विचार:

मैं अपने Neo4j डोमेन मॉडल मॉडलिंग ग्राफ में प्रत्येक नोड के गुण शामिल करने के लिए कोशिश करेंगे। अपने डेटा को दो अलग-अलग डेटा स्टोर्स में विभाजित करके आप कुछ ऑपरेशन सीमित कर सकते हैं जिन्हें आप करना चाहते हैं।

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

अपने डेटा बदलेगा या यह स्थिर है? दो अलग-अलग डेटा स्टोर्स होने से यह मामलों को जटिल करेगा।

जबकि MySQL डेटाबेस का उपयोग कर आंकड़े उत्पन्न करना नियो 4j में सब कुछ करने से आसान हो सकता है, परिभाषित मानदंडों को पूरा करने वाले सभी नोड्स को खोजने के लिए ग्राफ़ को पार करने के लिए आवश्यक कोड अत्यधिक कठिन नहीं है। इन आंकड़ों को आपके समाधान को ड्राइव करना चाहिए।

मैं नोड आईडी का चयन करने के लिए MySQL क्वेरी के प्रदर्शन पर टिप्पणी नहीं कर सकता। मुझे लगता है कि यह चुनने के लिए कि आपको कितने नोड्स चुनने होंगे और आपकी अनुक्रमणिका रणनीति की आवश्यकता होगी। हालांकि ग्राफ के ट्रैवर्स की बात आने पर मैं चीजों के प्रदर्शन पक्ष के बारे में सहमत हूं। MySQL vs. Neo4j on a Large-Scale Graph Traversal और इस मामले में, जब वे बड़े कहते हैं कि, वे केवल एक लाख कोने/नोड्स और चार लाख किनारों मतलब है:

यह सिर्फ इस पर एक अच्छा लेख है। तो यह एक विशेष रूप से घना ग्राफ भी नहीं था।

Answer 2

आप में उपयोग करके क्वेरी में सुधार कर सकते हैं:

SELECT * 
FROM items 
WHERE item_id IN (45, 345435, 343, 78, 4522, 676, 443, 4255, 4345) 

यह भी पूरी तरह सच नहीं है कि रिलेशनल डेटाबेस वृक्ष संरचना भंडारण पर बुरा कर रहे हैं। निश्चित रूप से MySQL में कुछ कार्यक्षमता गुम है जो इसे आसान बनाती है, लेकिन अधिकांश अन्य डेटाबेस इसे अच्छी तरह से समर्थन देते हैं। ओरेकल में CONNECT BY है। अधिकांश मुख्यधारा के आरडीबीएमएस में रिकर्सिव प्रश्नों का कुछ रूप है - MySQL एक उल्लेखनीय अपवाद है। शायद आप PostgreSQL पर एक नज़र डाल सकते हैं और देख सकते हैं कि यह आपकी आवश्यकताओं को पूरा करता है या नहीं?

Answer 3

मैं अधिकतर इस पर बाइनरी नेर्ड के साथ हूं, लेकिन एक भिन्नता जोड़ना चाहता हूं। आप लाइव डेटा को Neo4j में संग्रहीत कर सकते हैं और फिर आंकड़ों/रिपोर्टिंग के लिए आवश्यक डेटा निकाल सकते हैं और MySQL में डाल सकते हैं। खोजों के लिए यदि 0 आपकी आवश्यकताओं के अनुरूप है तो मैं Neo4j-Lucene integration के साथ जाऊंगा।

Answer 4

रिलेशनल डेटाबेस ग्राफ संरचनाओं को संभाल सकते हैं। उनमें से कुछ उन्हें साधारण रूप से सुन्दर तरीके से भी संभाल सकते हैं (जैसा कि एक रिलेशनल डेटाबेस के रूप में सुंदरता के रूप में!)।

संबंधपरक डेटाबेस में सामान्य ग्राफ हैंडलिंग की कुंजी recursive common table expression (आरसीटीई) है, जो मूल रूप से आपको पंक्तियों के एक सेट पर एक प्रश्न का विस्तार करके, पंक्तियों के एक सेट पर एक प्रश्न का विस्तार करके, क्रमशः (दोबारा नहीं, नाम के बावजूद) की अनुमति देता है पंक्तियों और एक प्रश्न का सेट जो अब तक चुनी गई पंक्तियों के पड़ोसियों को परिभाषित करता है। वाक्यविन्यास थोड़ा गुंजाइश है, लेकिन यह सामान्य और शक्तिशाली है।

आरसीटीई पोस्टग्रेएसक्यूएल, फायरबर्ड, एसक्यूएल सर्वर, और स्पष्ट रूप से डीबी 2 में समर्थित हैं। ओरेकल के पास एक अलग लेकिन समकक्ष निर्माण है; मैंने पढ़ा है कि हाल के संस्करण उचित आरसीटीई का समर्थन करते हैं। MySQL आरसीटीई का समर्थन नहीं करता है। यदि आप MySQL से शादी नहीं कर रहे हैं, तो मैं आपको PostgreSQL का उपयोग करने पर विचार करने के लिए आग्रह करता हूं, जो मूल रूप से पूरे दौर में एक बेहतर डेटाबेस है।

हालांकि, ऐसा लगता है कि आपको सामान्य ग्राफ, केवल पेड़ का समर्थन करने की आवश्यकता नहीं है। उस स्थिति में, आपके लिए अधिक विशिष्ट विकल्प खुले हैं।

एक क्लासिक लेकिन मस्तिष्क nested sets है।

प्रत्येक पंक्ति के साथ पथ को स्टोर करना एक आसान है: यह एक स्ट्रिंग है जो पेड़ में पंक्ति की स्थिति का प्रतिनिधित्व करती है, और संपत्ति है कि नोड के लिए पथ किसी भी उपनोड के लिए पथ का उपसर्ग है, आपको पूर्वजों के बारे में विभिन्न प्रश्नों को बहुत कुशलतापूर्वक करने देता है ("नोड ए नोड बी का बच्चा है?", "नोड ए और नोड बी का सबसे कम आम पूर्वज क्या है?", आदि)। उदाहरण के लिए, आप रूट से पेड़ को चलाकर और पंक्तियों के आईडी में शामिल होने से पंक्ति के लिए पथ बना सकते हैं। यह निर्माण करना आसान है, लेकिन अगर आप पेड़ को पुनर्व्यवस्थित करते हैं तो इसे बनाए रखने के लिए सावधानी बरतती है। पथ कॉलम के साथ, आप and path like '23/%' जोड़कर किसी दिए गए पेड़ पर एक क्वेरी को प्रतिबंधित कर सकते हैं, जहां 23 रूट की आईडी है।

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