ग्राफ़ डेटा (जावा)

Question

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

मैं इस डेटा को बहुत अधिक अतिरिक्त काम के बिना जारी रखना चाहता हूं। मैंने इस समस्या को हल करने के लिए कुछ विकल्प चुने हैं, लेकिन मेरी ज़रूरतों के लिए बिल्कुल ठीक कुछ भी नहीं मिला। संभावित विकल्प: क्रमबद्धता, ओआरएम (हाइबरनेट?) के साथ डेटाबेस, जेसीआर (जैकबब्बीट?), और कुछ?

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

क्या किसी के पास इस तरह के डेटा को संग्रहीत करने के बारे में अनुभव या विचार हैं?

Answer 1

अपने डेटा एक ग्राफ डेटा संरचना का उपयोग करता है के रूप में (नोड्स और किनारों/रिश्तों मूल रूप से) है एक बहुत अच्छा मैच। कुछ लिंक के लिए The Next-gen Databases पर मेरा उत्तर देखें। मैं Neo4j ओपन सोर्स ग्राफ डेटाबेस प्रोजेक्ट का हिस्सा हूं, इसके बारे में कुछ चर्चा के लिए this thread देखें। आपके जैसे मामले में नियो 4j का उपयोग करने का एक बड़ा फायदा यह है कि वस्तुओं/सक्रियण गहराई को सक्रिय/सक्रिय करने का ट्रैक रखने में कोई परेशानी नहीं है। आपको शायद अपने आवेदन में डेटा संरचनाओं को बदलने की आवश्यकता नहीं होगी, लेकिन निश्चित रूप से कुछ अतिरिक्त कोड की आवश्यकता होगी। Design guide एक उदाहरण देता है कि आपका कोड डेटाबेस के साथ कैसे सहभागिता कर सकता है।

Answer 2

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

अन्य विकल्प जिसका आप उल्लेख करते हैं, ओआरएम, शायद यहां आपका सबसे अच्छा विकल्प है। जेपीए (जावा पर्सिस्टेंस एपीआई) जावा में ओआरएम करने के लिए बहुत अच्छा है। आप जेपीए स्पेक को लिख सकते हैं और हाइबरनेट, एक्लीपसेलिंक या महीने प्रदाता के किसी भी अन्य स्वाद का उपयोग कर सकते हैं। वे जो भी डेटाबेस चाहते हैं उसके साथ काम करेंगे। http://java.sun.com/javaee/5/docs/api/index.html?javax/persistence/package-summary.html

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

Answer 3

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

जावा में सीरियलाइजेशन काफी धीमा हो जाता है और डेटा का भार उत्पन्न करता है। जब आप अपने ऐप में कक्षा बदलते हैं तो सीरियलाइजेशन भी बहुत भंगुर होता है और यदि आपको वृक्ष परिवर्तनों को सिंक्रनाइज़ करने की आवश्यकता होती है तो पूरी तरह से बेकार है।

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

यदि समय चिंता नहीं है तो एक सक्षम डीबीए को शामिल करने और एक इष्टतम डाटामॉडल डिजाइन करने और तदनुसार पेड़ को दोबारा करने का सबसे अच्छा तरीका हमेशा होता है।

Answer 4

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

क्या आपके डेटा पर कुछ प्री-प्रोसेसिंग करना संभव है? यदि समस्या समान है तो डेटा को एक मध्यवर्ती रूप में बदलने की कोशिश करने में बहुत अधिक मूल्य है जो मूल डोमेन की तुलना में आपके दृश्य के करीब है और इसे डीबी में भी स्टोर करता है। आप हमेशा आलसी fetch प्रकार का उपयोग कर मूल स्रोत से लिंक कर सकते हैं।

असल में हम एक 4-स्तरीय प्रणाली का इस्तेमाल किया: डोमेन डीबी, ViewModel-डीबी संकर (पूर्व संसाधित परत), ViewModel, देखें

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

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

मैं वहाँ आशा है कि कुछ तो आप इस घुमावदार जवाब से बाहर खींच सकते हैं, और अच्छी किस्मत :)

Answer 5

एक डेटाबेस में अपने नोड्स संग्रहीत करने पर विचार, एक उपयुक्त स्कीमा हो सकता है:

t1(node_id,child_id) 
t2(node_id,data1,data2,..,datan) 

तो/उपयोग करने के लिए JDBC का उपयोग डेटा को संशोधित। यदि आप उचित इंडेक्स का उपयोग करते हैं, तो यह लगभग 100 मिलियन रिकॉर्ड स्केल करने के लिए बेहतर प्रदर्शन करेगा। मेरा आंत महसूस जेनेरिक ऑब्जेक्ट सीरियलाइजेशन से बचने के लिए है यदि प्रदर्शन वास्तव में महत्वपूर्ण है क्योंकि आप उन समाधानों के साथ कोड की प्रदर्शन विशेषताओं पर कुछ नियंत्रण खो देते हैं।

यदि आपको बेहतर प्रदर्शन की आवश्यकता है, तो आप memcached परत का उपयोग कर सकते हैं।

Answer 6

मुझे विश्वास है कि आपकी समस्या का समाधान Terracotta का उपयोग अपने सतत स्टोरेज तंत्र के रूप में करना है। मैं आपको ऐसा करने के बारे में this excellent article पढ़ने के लिए प्रोत्साहित करता हूं।

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

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

पेशेवरों की एक और पूरी समीक्षा के लिए & विपक्ष के लिए, this StackOverflow post पढ़ना सुनिश्चित करें जो पसंद करने में अधिक minutiae को शामिल करता है।