ग्राफ-आधारित डेटाबेस (http://neo4j.org/) के उपयोग के मामले क्या हैं?

Question

मैंने रिलेशनल डीबी का बहुत उपयोग किया है और उपलब्ध अन्य प्रकारों पर उद्यम करने का फैसला किया है।

इस विशेष उत्पाद अच्छा और होनहार लग रहा है: http://neo4j.org/

है किसी को भी इस्तेमाल किया ग्राफ आधारित डेटाबेस? उपयोगिता परिप्रेक्ष्य से पेशेवरों और विपक्ष क्या हैं?

क्या आपने इन्हें उत्पादन वातावरण में उपयोग किया है? आवश्यकता क्या थी जिसने आपको उनका उपयोग करने के लिए प्रेरित किया?

Answer 1

मैंने पिछले नौकरी में एक ग्राफ डेटाबेस का उपयोग किया था। हम neo4j का उपयोग नहीं कर रहे थे, यह बर्कले डीबी के शीर्ष पर निर्मित एक घर की चीज थी, लेकिन यह समान था। यह उत्पादन में इस्तेमाल किया गया था (यह अभी भी है)।

हम एक ग्राफ डेटाबेस का उपयोग करने का कारण यह था कि सिस्टम द्वारा संग्रहीत डेटा और डेटा के साथ सिस्टम जो संचालन कर रहा था वह रिलेशनल डेटाबेस की बिल्कुल कमजोर जगह थी और वास्तव में ग्राफ डेटाबेस का मजबूत स्थान था। सिस्टम को उन वस्तुओं के संग्रह को संग्रहीत करने की आवश्यकता होती है जिनमें एक निश्चित स्कीमा की कमी होती है और संबंधों से एक साथ जुड़े होते हैं। डेटा के बारे में तर्क देने के लिए, सिस्टम को बहुत सारे ऑपरेशन करने की आवश्यकता होती है जो ग्राफ डेटाबेस में कुछ ट्रैवर्सल होंगे, लेकिन यह SQL में काफी जटिल प्रश्न होंगे।

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

होने एक अजीब डेटाबेस हमें हमारे अन्य अजीब प्रौद्योगिकियों का एक बहुत का निर्माण करते हैं, हमारे प्रतियोगियों के उन लोगों से अपने उत्पाद को अलग करने के लिए हमें गुप्त-चटनी के बहुत सारे दे रही है।

मुख्य नुकसान है कि हम मानक संबंधपरक डेटाबेस प्रौद्योगिकी है, जो एक समस्या हो सकती है जब आपके ग्राहकों enterprisey हैं का उपयोग नहीं कर रहे थे। हमारे ग्राहक पूछेंगे कि क्यों हम अपने विशाल ओरेकल समूहों पर हमारे डेटा को होस्ट नहीं कर पाएंगे (हमारे ग्राहकों के पास आमतौर पर बड़े डेटासेंटर थे)। टीम में से एक वास्तव में ओरेकल (या PostgreSQL, या MySQL) का उपयोग करने के लिए डेटाबेस परत को फिर से लिखता है, लेकिन यह मूल से थोड़ा धीमा था। कम से कम एक बड़े उद्यम में ओरेकल-केवल नीति भी थी, लेकिन सौभाग्य से ओरेकल ने बर्कले डीबी खरीदी। हमें भी बहुत सारे टूल्स लिखना पड़ा - उदाहरण के लिए हम क्रिस्टल रिपोर्ट्स का उपयोग नहीं कर सके।

हमारे ग्राफ डेटाबेस के अन्य नुकसान यह है कि हम इसे अपने आप का निर्माण किया, जिसका मतलब था जब हम (आमतौर पर scalability के साथ) हम इसे अपने आप को हल करने के लिए किया था एक समस्या पर सफल रही। अगर हम एक रिलेशनल डेटाबेस का इस्तेमाल करेंगे, तो विक्रेता दस साल पहले ही समस्या हल कर लेगा।

आप enterprisey ग्राहकों के लिए एक उत्पाद का निर्माण कर रहे हैं और अपने डेटा संबंधपरक मॉडल में फिट बैठता है, तो अगर आप कर सकते हैं एक संबंधपरक डेटाबेस का उपयोग करें। यदि आपका एप्लिकेशन रिलेशनल मॉडल में फिट नहीं है लेकिन यह ग्राफ मॉडल फिट करता है, तो ग्राफ़ डेटाबेस का उपयोग करें। अगर यह केवल कुछ और फिट बैठता है, तो इसका इस्तेमाल करें।

यदि आपके एप्लिकेशन को वर्तमान ब्लब आर्किटेक्चर में फिट करने की आवश्यकता नहीं है, तो ग्राफ़ डेटाबेस, या कॉच डीबी, या बिगटेबल का उपयोग करें, या जो भी आपके ऐप फिट बैठता है और आपको लगता है कि यह अच्छा है। यह आपको एक नया फायदा उठाने का लाभ, और इसका मजा दे सकता है।

जो कुछ भी आपने चुना है, डेटाबेस डेटाबेस बनाने का प्रयास न करें जबतक कि आप वास्तव में डेटाबेस इंजन बनाना पसंद न करें।

Answer 2

मैं इंजीनियरिंग डेटा का प्रबंधन करने के लिए वर्षों से MySQL का उपयोग कर रहा हूं, और यह अच्छी तरह से काम करता है, लेकिन हमारी समस्याओं में से एक (लेकिन हमें नहीं पता था) था कि हमें हमेशा स्कीमा अप-फ्रंट की योजना बनाना पड़ा । एक और समस्या जिसे हम जानते थे, हम डेटा ऑब्जेक्ट्स और बैक तक डेटा मैप कर रहे थे।

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

और चूंकि कोड में ऑब्जेक्ट मॉडल आम तौर पर ग्राफ़ स्ट्रक्चर होता है, इसलिए डाटाबेस से मैपिंग भी सरल होता है, कम कोड और इसके परिणामस्वरूप कम बग।

और अतिरिक्त बोनस के रूप में, हमारे डेटा को neo4j में लोड करने के लिए हमारे प्रारंभिक प्रोटोटाइप कोड वास्तव में पिछले MySQL संस्करण की तुलना में तेज़ प्रदर्शन कर रहा है। मेरे पास इस पर अभी तक कोई ठोस संख्या नहीं है, लेकिन यह एक अच्छी अतिरिक्त सुविधा थी।

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

Answer 3

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

यदि आप पहले से ही जावा में काम कर रहे हैं, तो मुझे लगता है कि नियो 4j का उपयोग करके मॉडलिंग बहुत सीधी आगे है और हमारे द्वारा किए गए किसी भी अन्य समाधान के आर/डब्ल्यू के लिए इसका सबसे तेज़/तेज़ प्रदर्शन है।

ईमानदारी से कहूं तो मैं एक कठिन समय नहीं एक ग्राफ़/नेटवर्क के मामले में सोच क्योंकि यह इतना जटिल तालिका संरचनाओं डिजाइनिंग वस्तु गुण और रिश्तों धारण करने के लिए और भी आसान है है।

कहा जा रहा है कि, हम कुछ जानकारी केवल MySQL में संग्रहीत करते हैं क्योंकि व्यापार पक्ष के लिए त्वरित SQL क्वेरी चलाने के लिए यह आसान है। नियो के साथ समान कार्य करने के लिए हमें कोड लिखना होगा कि हमारे पास अभी बैंडविड्थ नहीं है। जैसे ही हम करते हैं, मैं उस डेटा को नियो में ले जा रहा हूं!

शुभकामनाएं।

Answer 4

दो अंक:

पहले, डेटा मैं एसक्यूएल सर्वर में पिछले 5 वर्षों के साथ काम कर रहा हूँ, मैं हाल ही में scalability दीवार एसक्यूएल के साथ प्रश्नों हम चलाने की आवश्यकता के प्रकार के लिए पहुंच जाते हैं (नेस्टेड relationhsips ... आप जानते हैं ... ग्राफ)। मैं neo4j के साथ खेल रहा हूं, और जब मुझे इस तरह की लुकअप की आवश्यकता होती है तो मेरे लुकअप टाइम्स तीव्रता के कई ऑर्डर तेज होते हैं।

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

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

वाक्यांश को सिक्का देने के लिए, कोई रजत बुलेट नहीं है। यह कहना बहुत छोटा है कि ग्राफ डेटाबेस मॉडल पुराने हैं और एक का उपयोग करने के लिए 40 साल की प्रगति होती है। ऐसा लगता है कि सी का उपयोग करके सभी तकनीकी प्रगतियां छोड़ रही हैं जिन्हें हमने जावा और सी # जैसी चीजों को प्राप्त करने के लिए किया है। हालांकि यह सच नहीं है। सी एक उपकरण है जो कुछ कार्यों के लिए आवश्यक है। और जावा अन्य कार्यों के लिए एक उपकरण है।

Answer 5

यहाँ एक अच्छा लेख है कि जरूरतों के बारे में बात करती है है कि गैर रिलेशनल डेटाबेस को भरने: http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php

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

Answer 6

थोड़ा देर हो सकता है, लेकिन नियो 4j का उपयोग करके परियोजनाओं की बढ़ती संख्या है, Neo4j पर सूचीबद्ध बेहतर ज्ञात। इसके अलावा NeoTechnology, Neo4j के पीछे कंपनी, पर their customers page

_{नोट कुछ संदर्भों है: मैं Neo4j टीम}

Answer 7

मैं अपनी कंपनी में एक इंट्रानेट का निर्माण कर रहा हूँ का हिस्सा हूँ।

मुझे समझने में दिलचस्पी है कि टेबल (ओरेकल, माईएसक्यूएल, एसक्यूएल सर्वर, एक्सेल, एक्सेस, विभिन्न यादृच्छिक सूचियों) में संग्रहीत डेटा को लोड करने और इसे नियो 4 जे, या कुछ अन्य ग्राफ डेटाबेस में लोड करने के तरीके को समझने में दिलचस्पी है। विशेष रूप से, क्या होता है जब सामान्य डेटा सिस्टम में पहले से मौजूद मौजूदा डेटा को ओवरलैप करता है।

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

उदाहरण के लिए, मैं एक विनिर्माण वातावरण में काम करता हूं। एक प्रमुख परियोजना है जिस पर हम काम कर रहे हैं और जटिलता के कारण, प्रत्येक विभाग ने एक अलग एक्सेल स्प्रेडशीट बनाई है जिसमें बाईं ओर एक कॉलम में BOM (Bill Of Materials) पदानुक्रम है और फिर इन चादरों वाले व्यक्तियों द्वारा किए गए नोट्स और चेक के कई कॉलम हैं।

तो समस्याओं में से एक समस्या इन सभी नोटों को एक साथ "दृश्य" में विलय कर रही है ताकि कोई भी उन सभी मुद्दों को देख सके जिन्हें किसी भी विशेष भाग में संबोधित करने की आवश्यकता है।

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

कंपनी इंट्रानेट के लिए, मैं आसानी से कुछ भी खोजना चाहता हूं। जैसे कि भाग संख्या से संबंधित डेटा, एक बीओएम संरचना, एक फोन नंबर, एक ईमेल पता, एक कंपनी नीति, या प्रक्रिया। मैं इसे कंप्यूटर हार्डवेयर संपत्तियों और स्थापित सॉफ़्टवेयर को प्रबंधित करने के लिए भी विस्तारित करना चाहता हूं।

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

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