ग्राफ डेटाबेस: Difference between revisions

From Vigyanwiki
No edit summary
No edit summary
Line 1: Line 1:
{{Short description|Database that uses mathematical graphs to store and search data}}एक ग्राफ़ [[डेटाबेस]] (जीडीबी) एक डेटाबेस है जो नोड (ग्राफ़ सिद्धांत), एज (ग्राफ़ सिद्धांत), और डेटा को प्रदर्शित करने और संग्रहीत करने के लिए गुणों के साथ [[सिमेंटिक क्वेरी]] के लिए ग्राफ़ (डेटा संरचना) का उपयोग करता है।<ref>{{cite book|first=Nikolaos G.|last=Bourbakis|url=https://books.google.com/books?id=mV3wxKLHlnwC&q=%22gdb%22+%22graph+database%22&pg=PA381|title=आर्टिफिशियल इंटेलिजेंस और ऑटोमेशन|publisher=World Scientific|year=1998|isbn=9789810226374|page=381|access-date=2018-04-20}}</ref> सिस्टम की एक प्रमुख अवधारणा ग्राफ़ (असतत गणित) (या किनारा या संबंध) है। ग्राफ स्टोर में डेटा आइटम को नोड्स और किनारों के संग्रह से संबंधित करता है, किनारों को नोड्स के बीच संबंधों का प्रतिनिधित्व करता है। रिश्ते स्टोर में डेटा को सीधे एक साथ जोड़ने की अनुमति देते हैं और कई मामलों में, एक ऑपरेशन के साथ पुनर्प्राप्त किए जाते हैं। ग्राफ़ डेटाबेस डेटा के बीच संबंधों को प्राथमिकता के रूप में रखते हैं। संबंधों को क्वेरी करना तेज़ है क्योंकि वे डेटाबेस में स्थायी रूप से संग्रहीत होते हैं। ग्राफ़ डेटाबेस का उपयोग करके संबंधों को सहज रूप से देखा जा सकता है, जिससे वे अत्यधिक परस्पर जुड़े डेटा के लिए उपयोगी हो जाते हैं।<ref name=":0">{{cite journal|last1=Yoon|first1=Byoung-Ha|last2=Kim|first2=Seon-Kyu|last3=Kim|first3=Seon-Young|date=March 2017|title=विषम जैविक डेटा के एकीकरण के लिए ग्राफ डेटाबेस का उपयोग|journal=Genomics & Informatics|volume=15|issue=1|pages=19–27|doi=10.5808/GI.2017.15.1.19|issn=1598-866X|pmc=5389944|pmid=28416946}}</ref>
{{Short description|Database that uses mathematical graphs to store and search data}}ग्राफ़ [[डेटाबेस]] (जीडीबी) एक डेटाबेस है जो नोड (ग्राफ़ सिद्धांत), एज (ग्राफ़ सिद्धांत), और डेटा को प्रदर्शित करने और संग्रहीत करने के लिए गुणों के साथ [[सिमेंटिक क्वेरी]] के लिए ग्राफ़ (डेटा संरचना) का उपयोग करता है।<ref>{{cite book|first=Nikolaos G.|last=Bourbakis|url=https://books.google.com/books?id=mV3wxKLHlnwC&q=%22gdb%22+%22graph+database%22&pg=PA381|title=आर्टिफिशियल इंटेलिजेंस और ऑटोमेशन|publisher=World Scientific|year=1998|isbn=9789810226374|page=381|access-date=2018-04-20}}</ref> सिस्टम की प्रमुख अवधारणा ग्राफ़ (असतत गणित) (या किनारा या संबंध) है। ग्राफ स्टोर में डेटा आइटम को नोड्स और किनारों के संग्रह से संबंधित करता है, किनारों को नोड्स के बीच संबंधों का प्रतिनिधित्व करता है। रिश्ते स्टोर में डेटा को सीधे एक साथ जोड़ने की अनुमति देते हैं और कई मामलों में, ऑपरेशन के साथ पुनर्प्राप्त किए जाते हैं। ग्राफ़ डेटाबेस डेटा के बीच संबंधों को प्राथमिकता के रूप में रखते हैं। संबंधों को क्वेरी करना तेज़ है क्योंकि वे डेटाबेस में स्थायी रूप से संग्रहीत होते हैं। ग्राफ़ डेटाबेस का उपयोग करके संबंधों को सहज रूप से देखा जा सकता है, जिससे वे अत्यधिक परस्पर जुड़े डेटा के लिए उपयोगी हो जाते हैं।<ref name=":0">{{cite journal|last1=Yoon|first1=Byoung-Ha|last2=Kim|first2=Seon-Kyu|last3=Kim|first3=Seon-Young|date=March 2017|title=विषम जैविक डेटा के एकीकरण के लिए ग्राफ डेटाबेस का उपयोग|journal=Genomics & Informatics|volume=15|issue=1|pages=19–27|doi=10.5808/GI.2017.15.1.19|issn=1598-866X|pmc=5389944|pmid=28416946}}</ref>
ग्राफ़ डेटाबेस को आमतौर पर [[NoSQL]] कहा जाता है। ग्राफ़ डेटाबेस 1970 के दशक के [[नेटवर्क मॉडल]] डेटाबेस के समान हैं, जिसमें दोनों सामान्य ग्राफ़ का प्रतिनिधित्व करते हैं, लेकिन नेटवर्क-मॉडल डेटाबेस अमूर्तता (कंप्यूटर विज्ञान) के निचले स्तर पर काम करते हैं।<ref name="Gutierrez2">{{cite journal|last1=Angles|first1=Renzo|last2=Gutierrez|first2=Claudio|date=1 Feb 2008|title=ग्राफ डेटाबेस मॉडल का सर्वेक्षण|url=http://www.cse.iitk.ac.in/users/smitr/PhD%20Resources/Survey%20of%20Graph%20Databases%20Models.pdf|url-status=dead|journal=ACM Computing Surveys|volume=40|issue=1|pages=1–39|citeseerx=10.1.1.110.1072|doi=10.1145/1322432.1322433|archive-url=https://web.archive.org/web/20170815064527/https://www.cse.iitk.ac.in/users/smitr/PhD%20Resources/Survey%20of%20Graph%20Databases%20Models.pdf|archive-date=15 August 2017|access-date=28 May 2016|quote=network models [...] lack a good abstraction level: it is difficult to separate the db-model from the actual implementation|s2cid=207166126}}</ref> और किनारों की एक श्रृंखला पर आसान [[ग्राफ ट्रैवर्सल]] की कमी है।<ref>{{cite book|last=Silberschatz|first=Avi|url=http://codex.cs.yale.edu/avi/db-book/db6/appendices-dir/d.pdf|title=डेटाबेस सिस्टम कॉन्सेप्ट्स, छठा संस्करण|date=28 January 2010|publisher=McGraw-Hill|isbn=978-0-07-352332-3|page=D-29}}</ref>
ग्राफ़ डेटाबेस को आमतौर पर [[NoSQL]] कहा जाता है। ग्राफ़ डेटाबेस 1970 के दशक के [[नेटवर्क मॉडल]] डेटाबेस के समान हैं, जिसमें दोनों सामान्य ग्राफ़ का प्रतिनिधित्व करते हैं, लेकिन नेटवर्क-मॉडल डेटाबेस अमूर्तता (कंप्यूटर विज्ञान) के निचले स्तर पर काम करते हैं।<ref name="Gutierrez2">{{cite journal|last1=Angles|first1=Renzo|last2=Gutierrez|first2=Claudio|date=1 Feb 2008|title=ग्राफ डेटाबेस मॉडल का सर्वेक्षण|url=http://www.cse.iitk.ac.in/users/smitr/PhD%20Resources/Survey%20of%20Graph%20Databases%20Models.pdf|url-status=dead|journal=ACM Computing Surveys|volume=40|issue=1|pages=1–39|citeseerx=10.1.1.110.1072|doi=10.1145/1322432.1322433|archive-url=https://web.archive.org/web/20170815064527/https://www.cse.iitk.ac.in/users/smitr/PhD%20Resources/Survey%20of%20Graph%20Databases%20Models.pdf|archive-date=15 August 2017|access-date=28 May 2016|quote=network models [...] lack a good abstraction level: it is difficult to separate the db-model from the actual implementation|s2cid=207166126}}</ref> और किनारों की श्रृंखला पर आसान [[ग्राफ ट्रैवर्सल]] की कमी है।<ref>{{cite book|last=Silberschatz|first=Avi|url=http://codex.cs.yale.edu/avi/db-book/db6/appendices-dir/d.pdf|title=डेटाबेस सिस्टम कॉन्सेप्ट्स, छठा संस्करण|date=28 January 2010|publisher=McGraw-Hill|isbn=978-0-07-352332-3|page=D-29}}</ref>
ग्राफ़ डेटाबेस का अंतर्निहित संग्रहण तंत्र भिन्न हो सकता है। रिश्ते एक ग्राफ़ डेटाबेस में प्रथम श्रेणी के नागरिक हैं और इन्हें लेबल, निर्देशित और गुण दिए जा सकते हैं। कुछ एक संबंधपरक इंजन पर निर्भर करते हैं और [[तालिका (डेटाबेस)]] में ग्राफ़ डेटा संग्रहीत करते हैं (हालांकि तालिका एक तार्किक तत्व है, इसलिए यह दृष्टिकोण ग्राफ़ डेटाबेस, ग्राफ़ डेटाबेस प्रबंधन प्रणाली और भौतिक उपकरणों के बीच अमूर्तता का एक और स्तर लागू करता है जहां डेटा वास्तव में संग्रहीत है)। अन्य भंडारण के लिए एट्रिब्यूट-वैल्यू पेयर | की-वैल्यू स्टोर या [[दस्तावेज़-उन्मुख डेटाबेस]] का उपयोग करते हैं, जिससे वे स्वाभाविक रूप से NoSQL संरचनाएँ बन जाते हैं।
ग्राफ़ डेटाबेस का अंतर्निहित संग्रहण तंत्र भिन्न हो सकता है। रिश्ते ग्राफ़ डेटाबेस में प्रथम श्रेणी के नागरिक हैं और इन्हें लेबल, निर्देशित और गुण दिए जा सकते हैं। कुछ संबंधपरक इंजन पर निर्भर करते हैं और [[तालिका (डेटाबेस)]] में ग्राफ़ डेटा संग्रहीत करते हैं (हालांकि तालिका तार्किक तत्व है, इसलिए यह दृष्टिकोण ग्राफ़ डेटाबेस, ग्राफ़ डेटाबेस प्रबंधन प्रणाली और भौतिक उपकरणों के बीच अमूर्तता का एक और स्तर लागू करता है जहां डेटा वास्तव में संग्रहीत है)। अन्य भंडारण के लिए एट्रिब्यूट-वैल्यू पेयर | की-वैल्यू स्टोर या [[दस्तावेज़-उन्मुख डेटाबेस]] का उपयोग करते हैं, जिससे वे स्वाभाविक रूप से NoSQL संरचनाएँ बन जाते हैं।


{{As of|2021}}, किसी भी सार्वभौमिक ग्राफ़ क्वेरी भाषा को उसी तरह से नहीं अपनाया गया है जैसे SQL रिलेशनल डेटाबेस के लिए था, और कई प्रकार की प्रणालियाँ हैं, जो अक्सर एक उत्पाद से कसकर बंधी होती हैं। कुछ शुरुआती मानकीकरण प्रयासों से [[ ग्रेमलिन (प्रोग्रामिंग भाषा) ]], [[SPARQL]] और [[ग्राफ क्वेरी भाषा]] जैसी मल्टी-वेंडर क्वेरी लैंग्वेज बनती हैं। सितंबर 2019 में एक नई मानक ग्राफ़ क्वेरी भाषा (ISO/IEC 39075 सूचना प्रौद्योगिकी — डेटाबेस भाषाएँ — GQL) बनाने के लिए एक परियोजना के प्रस्ताव को ISO/IEC संयुक्त तकनीकी समिति 1 (ISO/IEC JTC 1) के सदस्यों द्वारा अनुमोदित किया गया था। ग्राफ़ क्वेरी भाषा का उद्देश्य SQL की तरह एक घोषणात्मक डेटाबेस क्वेरी भाषा होना है। क्वेरी लैंग्वेज इंटरफेस होने के अलावा, कुछ ग्राफ डेटाबेस को [[अप्लिकेशन प्रोग्रामिंग अंतरफलक]] (एपीआई) के माध्यम से एक्सेस किया जाता है।
{{As of|2021}}, किसी भी सार्वभौमिक ग्राफ़ क्वेरी भाषा को उसी तरह से नहीं अपनाया गया है जैसे SQL रिलेशनल डेटाबेस के लिए था, और कई प्रकार की प्रणालियाँ हैं, जो अक्सर उत्पाद से कसकर बंधी होती हैं। कुछ शुरुआती मानकीकरण प्रयासों से [[ ग्रेमलिन (प्रोग्रामिंग भाषा) ]], [[SPARQL]] और [[ग्राफ क्वेरी भाषा]] जैसी मल्टी-वेंडर क्वेरी लैंग्वेज बनती हैं। सितंबर 2019 में नई मानक ग्राफ़ क्वेरी भाषा (ISO/IEC 39075 सूचना प्रौद्योगिकी — डेटाबेस भाषाएँ — GQL) बनाने के लिए परियोजना के प्रस्ताव को ISO/IEC संयुक्त तकनीकी समिति 1 (ISO/IEC JTC 1) के सदस्यों द्वारा अनुमोदित किया गया था। ग्राफ़ क्वेरी भाषा का उद्देश्य SQL की तरह घोषणात्मक डेटाबेस क्वेरी भाषा होना है। क्वेरी लैंग्वेज इंटरफेस होने के अलावा, कुछ ग्राफ डेटाबेस को [[अप्लिकेशन प्रोग्रामिंग अंतरफलक]] (एपीआई) के माध्यम से एक्सेस किया जाता है।


ग्राफ़ डेटाबेस ग्राफ़ कंप्यूट इंजन से भिन्न होते हैं। ग्राफ़ डेटाबेस ऐसी तकनीकें हैं जो रिलेशनल [[ ऑनलाइन लेनदेन प्रसंस्करण ]] (OLTP) डेटाबेस के अनुवाद हैं। दूसरी ओर, थोक विश्लेषण के लिए ऑनलाइन विश्लेषणात्मक प्रसंस्करण (OLAP) में ग्राफ कंप्यूट इंजन का उपयोग किया जाता है।<ref>{{cite book |last=Robinson |first=Ian |date=2015-06-10 |title=Graph Databases: New Opportunities for Connected Data |url=https://books.google.com/books?id=RTvcCQAAQBAJ&pg=PA4 |publisher=O'Reilly Media, Inc. |page=4 |isbn=9781491930861}}</ref> मालिकाना ग्राफ डेटाबेस का उपयोग करने में प्रमुख प्रौद्योगिकी निगमों की सफलताओं के कारण, 2000 के दशक में ग्राफ डेटाबेस ने काफी ध्यान आकर्षित किया,<ref>{{cite web|title=ग्राफ़ डेटाबेस मुख्यधारा में फट गया|url=https://www.kdnuggets.com/2018/02/graph-databases-burst-into-the-mainstream.html|access-date=2018-10-23|website=www.kdnuggets.com}}</ref> [[ खुला स्रोत सॉफ्टवेयर ]] की शुरुआत के साथ | ओपन-सोर्स ग्राफ डेटाबेस।
ग्राफ़ डेटाबेस ग्राफ़ कंप्यूट इंजन से भिन्न होते हैं। ग्राफ़ डेटाबेस ऐसी तकनीकें हैं जो रिलेशनल [[ ऑनलाइन लेनदेन प्रसंस्करण ]] (OLTP) डेटाबेस के अनुवाद हैं। दूसरी ओर, थोक विश्लेषण के लिए ऑनलाइन विश्लेषणात्मक प्रसंस्करण (OLAP) में ग्राफ कंप्यूट इंजन का उपयोग किया जाता है।<ref>{{cite book |last=Robinson |first=Ian |date=2015-06-10 |title=Graph Databases: New Opportunities for Connected Data |url=https://books.google.com/books?id=RTvcCQAAQBAJ&pg=PA4 |publisher=O'Reilly Media, Inc. |page=4 |isbn=9781491930861}}</ref> मालिकाना ग्राफ डेटाबेस का उपयोग करने में प्रमुख प्रौद्योगिकी निगमों की सफलताओं के कारण, 2000 के दशक में ग्राफ डेटाबेस ने काफी ध्यान आकर्षित किया,<ref>{{cite web|title=ग्राफ़ डेटाबेस मुख्यधारा में फट गया|url=https://www.kdnuggets.com/2018/02/graph-databases-burst-into-the-mainstream.html|access-date=2018-10-23|website=www.kdnuggets.com}}</ref> [[ खुला स्रोत सॉफ्टवेयर ]] की शुरुआत के साथ | ओपन-सोर्स ग्राफ डेटाबेस।


एक अध्ययन ने निष्कर्ष निकाला कि एक RDBMS ग्राफ़ प्रश्नों को निष्पादित करने पर मौजूदा ग्राफ़ विश्लेषण इंजनों के प्रदर्शन के बराबर था।<ref>{{cite conference|last1=Fan|first1=Jing|last2=Gerald|first2=Adalbert|date=2014-12-25|title=विशेष ग्राफ एनालिटिक्स इंजन के खिलाफ मामला|url=http://cidrdb.org/cidr2015/Papers/CIDR15_Paper20.pdf|conference=Conference on Innovative Data Systems Research (CIDR)}}</ref>
अध्ययन ने निष्कर्ष निकाला कि RDBMS ग्राफ़ प्रश्नों को निष्पादित करने पर मौजूदा ग्राफ़ विश्लेषण इंजनों के प्रदर्शन के बराबर था।<ref>{{cite conference|last1=Fan|first1=Jing|last2=Gerald|first2=Adalbert|date=2014-12-25|title=विशेष ग्राफ एनालिटिक्स इंजन के खिलाफ मामला|url=http://cidrdb.org/cidr2015/Papers/CIDR15_Paper20.pdf|conference=Conference on Innovative Data Systems Research (CIDR)}}</ref>


'''[[ग्राफ लेबलिंग]] को 1980 के दशक के मध्य से ग्राफ़ डेटाबेस में प्रदर्शित किया जा सकता है, जैसे लॉजिकल डेटा मॉडल।<ref name="Gutierrez" /><ref name=":1" />
'''[[ग्राफ लेबलिंग]] को 1980 के दशक के मध्य से ग्राफ़ डेटाबेस में प्रदर्शित किया जा सकता है, जैसे लॉजिकल डेटा मॉडल।<ref name="Gutierrez" /><ref name=":1" />
1990 के दशक की शुरुआत में वाणिज्यिक [[वस्तु डेटाबेस]] (ODBMS) का उदय हुआ। 2000 में, [[वस्तु डेटा प्रबंधन समूह]] ने अपने ODMG'93 प्रकाशन में ऑब्जेक्ट और रिलेशनशिप (ग्राफ़) संरचनाओं को परिभाषित करने के लिए एक मानक भाषा प्रकाशित की।<br />'''
1990 के दशक की शुरुआत में वाणिज्यिक [[वस्तु डेटाबेस]] (ODBMS) का उदय हुआ। 2000 में, [[वस्तु डेटा प्रबंधन समूह]] ने
== इतिहास ==
== इतिहास ==
1960 के दशक के मध्य में, [[आईबीएम]] के [[आईबीएम सूचना प्रबंधन प्रणाली]] जैसे [[नेविगेशनल डेटाबेस]] ने अपने [[पदानुक्रमित डेटाबेस मॉडल]] में ट्री (डेटा संरचना) जैसी संरचनाओं का समर्थन किया, लेकिन सख्त ट्री संरचना को वर्चुअल रिकॉर्ड से दरकिनार किया जा सकता था।<ref>{{cite book |last=Silberschatz |first=Avi |date=28 January 2010 |title=डेटाबेस सिस्टम कॉन्सेप्ट्स, छठा संस्करण|url=http://codex.cs.yale.edu/avi/db-book/db6/appendices-dir/e.pdf |publisher=McGraw-Hill |page=E-20 |isbn=978-0-07-352332-3}}</ref><ref>{{cite web |url=http://www.people.vcu.edu/~lparker/IMS.html |title=आईएमएस नोट्स|last1=Parker |first1=Lorraine |website=vcu.edu |access-date=31 May 2016}}</ref>
1960 के दशक के मध्य में, [[आईबीएम]] के [[आईबीएम सूचना प्रबंधन प्रणाली]] जैसे [[नेविगेशनल डेटाबेस]] ने अपने [[पदानुक्रमित डेटाबेस मॉडल]] में ट्री (डेटा संरचना) जैसी संरचनाओं का समर्थन किया, लेकिन सख्त ट्री संरचना को वर्चुअल रिकॉर्ड से दरकिनार किया जा सकता था।<ref>{{cite book |last=Silberschatz |first=Avi |date=28 January 2010 |title=डेटाबेस सिस्टम कॉन्सेप्ट्स, छठा संस्करण|url=http://codex.cs.yale.edu/avi/db-book/db6/appendices-dir/e.pdf |publisher=McGraw-Hill |page=E-20 |isbn=978-0-07-352332-3}}</ref><ref>{{cite web |url=http://www.people.vcu.edu/~lparker/IMS.html |title=आईएमएस नोट्स|last1=Parker |first1=Lorraine |website=vcu.edu |access-date=31 May 2016}}</ref>
Line 16: Line 16:


[[ग्राफ लेबलिंग]] को 1980 के दशक के मध्य से ग्राफ़ डेटाबेस में प्रदर्शित किया जा सकता है, जैसे लॉजिकल डेटा मॉडल।<ref name="Gutierrez">{{cite journal|last1=Angles|first1=Renzo|last2=Gutierrez|first2=Claudio|date=1 Feb 2008|title=ग्राफ डेटाबेस मॉडल का सर्वेक्षण|url=http://www.cse.iitk.ac.in/users/smitr/PhD%20Resources/Survey%20of%20Graph%20Databases%20Models.pdf|url-status=dead|journal=ACM Computing Surveys|volume=40|issue=1|pages=1–39|citeseerx=10.1.1.110.1072|doi=10.1145/1322432.1322433|archive-url=https://web.archive.org/web/20170815064527/https://www.cse.iitk.ac.in/users/smitr/PhD%20Resources/Survey%20of%20Graph%20Databases%20Models.pdf|archive-date=15 August 2017|access-date=28 May 2016|quote=network models [...] lack a good abstraction level: it is difficult to separate the db-model from the actual implementation|s2cid=207166126}}</ref><ref name=":1">{{cite thesis |last=Kuper |first=Gabriel M. |date=1985 |title=The Logical Data Model: A New Approach to Database Logic |type=Ph.D. |docket=STAN-CS-85-1069 |url=http://apps.dtic.mil/dtic/tr/fulltext/u2/a323935.pdf |archive-url=https://web.archive.org/web/20160630154240/http://www.dtic.mil/dtic/tr/fulltext/u2/a323935.pdf |url-status=live |archive-date=June 30, 2016 |access-date=31 May 2016}}</ref>
[[ग्राफ लेबलिंग]] को 1980 के दशक के मध्य से ग्राफ़ डेटाबेस में प्रदर्शित किया जा सकता है, जैसे लॉजिकल डेटा मॉडल।<ref name="Gutierrez">{{cite journal|last1=Angles|first1=Renzo|last2=Gutierrez|first2=Claudio|date=1 Feb 2008|title=ग्राफ डेटाबेस मॉडल का सर्वेक्षण|url=http://www.cse.iitk.ac.in/users/smitr/PhD%20Resources/Survey%20of%20Graph%20Databases%20Models.pdf|url-status=dead|journal=ACM Computing Surveys|volume=40|issue=1|pages=1–39|citeseerx=10.1.1.110.1072|doi=10.1145/1322432.1322433|archive-url=https://web.archive.org/web/20170815064527/https://www.cse.iitk.ac.in/users/smitr/PhD%20Resources/Survey%20of%20Graph%20Databases%20Models.pdf|archive-date=15 August 2017|access-date=28 May 2016|quote=network models [...] lack a good abstraction level: it is difficult to separate the db-model from the actual implementation|s2cid=207166126}}</ref><ref name=":1">{{cite thesis |last=Kuper |first=Gabriel M. |date=1985 |title=The Logical Data Model: A New Approach to Database Logic |type=Ph.D. |docket=STAN-CS-85-1069 |url=http://apps.dtic.mil/dtic/tr/fulltext/u2/a323935.pdf |archive-url=https://web.archive.org/web/20160630154240/http://www.dtic.mil/dtic/tr/fulltext/u2/a323935.pdf |url-status=live |archive-date=June 30, 2016 |access-date=31 May 2016}}</ref>
1990 के दशक की शुरुआत में वाणिज्यिक [[वस्तु डेटाबेस]] (ODBMS) का उदय हुआ। 2000 में, [[वस्तु डेटा प्रबंधन समूह]] ने अपने ODMG'93 प्रकाशन में ऑब्जेक्ट और रिलेशनशिप (ग्राफ़) संरचनाओं को परिभाषित करने के लिए एक मानक भाषा प्रकाशित की।
1990 के दशक की शुरुआत में वाणिज्यिक [[वस्तु डेटाबेस]] (ODBMS) का उदय हुआ। 2000 में, [[वस्तु डेटा प्रबंधन समूह]] ने अपने ODMG'93 प्रकाशन में ऑब्जेक्ट और रिलेशनशिप (ग्राफ़) संरचनाओं को परिभाषित करने के लिए मानक भाषा प्रकाशित की।


1990 के दशक की शुरुआत में ग्राफ डेटाबेस में कई सुधार दिखाई दिए, 1990 के दशक के अंत में वेब पेजों को अनुक्रमित करने के प्रयासों में तेजी आई।
1990 के दशक की शुरुआत में ग्राफ डेटाबेस में कई सुधार दिखाई दिए, 1990 के दशक के अंत में वेब पेजों को अनुक्रमित करने के प्रयासों में तेजी आई।
Line 27: Line 27:
[[File:GraphDatabase PropertyGraph.png|right|thumb|308px|ग्राफ़ डेटाबेस नोड्स, गुण और किनारों को नियोजित करते हैं]]ग्राफ़ डेटाबेस डेटा को चित्रित करते हैं क्योंकि इसे अवधारणात्मक रूप से देखा जाता है। यह डेटा को नोड्स और उसके संबंधों को किनारों में स्थानांतरित करके पूरा किया जाता है।
[[File:GraphDatabase PropertyGraph.png|right|thumb|308px|ग्राफ़ डेटाबेस नोड्स, गुण और किनारों को नियोजित करते हैं]]ग्राफ़ डेटाबेस डेटा को चित्रित करते हैं क्योंकि इसे अवधारणात्मक रूप से देखा जाता है। यह डेटा को नोड्स और उसके संबंधों को किनारों में स्थानांतरित करके पूरा किया जाता है।


एक ग्राफ़ डेटाबेस एक डेटाबेस है जो ग्राफ़ सिद्धांत पर आधारित है। इसमें ऑब्जेक्ट्स का एक सेट होता है, जो नोड या एज हो सकता है।
ग्राफ़ डेटाबेस एक डेटाबेस है जो ग्राफ़ सिद्धांत पर आधारित है। इसमें ऑब्जेक्ट्स का सेट होता है, जो नोड या एज हो सकता है।


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


Line 36: Line 36:


=== लेबल-संपत्ति ग्राफ ===
=== लेबल-संपत्ति ग्राफ ===
एक लेबल-प्रॉपर्टी ग्राफ़ मॉडल को नोड्स, रिलेशनशिप, प्रॉपर्टी और लेबल के सेट द्वारा दर्शाया जाता है। डेटा और उनके रिश्तों के दोनों नोड्स का नाम दिया गया है और एट्रिब्यूट-वैल्यू पेयर | की-वैल्यू पेयर द्वारा दर्शाए गए गुणों को स्टोर कर सकते हैं। नोड्स को समूहीकृत करने के लिए लेबल किया जा सकता है। संबंधों का प्रतिनिधित्व करने वाले किनारों में दो गुण होते हैं: उनके पास हमेशा एक प्रारंभ नोड और एक अंत नोड होता है, और निर्देशित होता है;<ref>{{cite web|url=http://www.dataversity.net/property-graphs-swiss-army-knife-data-modeling/|title=संपत्ति रेखांकन|last=Frisendal|first=Thomas|date=2017-09-22|website=graphdatamodeling.com|access-date=2018-10-23}}</ref> ग्राफ़ को एक [[निर्देशित ग्राफ]]़ बनाना। रिश्तों में गुण भी हो सकते हैं। यह नोड्स के संबंधों को अतिरिक्त मेटाडेटा और शब्दार्थ प्रदान करने में उपयोगी है।<ref>{{cite journal|last1=Das|first1=S|last2=Srinivasan|first2=J|last3=Perry|first3=Matthew|last4=Chong|first4=Eugene|last5=Banerjee|first5=Jay|date=2014-03-24|title=A Tale of Two Graphs: Property Graphs as RDF in Oracle|url=https://www.researchgate.net/publication/264702160}}</ref> संबंधों का प्रत्यक्ष भंडारण एक समय जटिलता#लगातार समय|निरंतर-समय ग्राफ़ ट्रैवर्सल की अनुमति देता है।<ref name=":32">{{cite journal|last1=Have|first1=Christian Theil|last2=Jensen|first2=Lars Juhl|date=2013-10-17|title=Are graph databases ready for bioinformatics?|journal=Bioinformatics|volume=29|issue=24|pages=3107–3108|doi=10.1093/bioinformatics/btt549|issn=1460-2059|pmc=3842757|pmid=24135261}}</ref>
लेबल-प्रॉपर्टी ग्राफ़ मॉडल को नोड्स, रिलेशनशिप, प्रॉपर्टी और लेबल के सेट द्वारा दर्शाया जाता है। डेटा और उनके रिश्तों के दोनों नोड्स का नाम दिया गया है और एट्रिब्यूट-वैल्यू पेयर | की-वैल्यू पेयर द्वारा दर्शाए गए गुणों को स्टोर कर सकते हैं। नोड्स को समूहीकृत करने के लिए लेबल किया जा सकता है। संबंधों का प्रतिनिधित्व करने वाले किनारों में दो गुण होते हैं: उनके पास हमेशा प्रारंभ नोड और अंत नोड होता है, और निर्देशित होता है;<ref>{{cite web|url=http://www.dataversity.net/property-graphs-swiss-army-knife-data-modeling/|title=संपत्ति रेखांकन|last=Frisendal|first=Thomas|date=2017-09-22|website=graphdatamodeling.com|access-date=2018-10-23}}</ref> ग्राफ़ को [[निर्देशित ग्राफ]]़ बनाना। रिश्तों में गुण भी हो सकते हैं। यह नोड्स के संबंधों को अतिरिक्त मेटाडेटा और शब्दार्थ प्रदान करने में उपयोगी है।<ref>{{cite journal|last1=Das|first1=S|last2=Srinivasan|first2=J|last3=Perry|first3=Matthew|last4=Chong|first4=Eugene|last5=Banerjee|first5=Jay|date=2014-03-24|title=A Tale of Two Graphs: Property Graphs as RDF in Oracle|url=https://www.researchgate.net/publication/264702160}}</ref> संबंधों का प्रत्यक्ष भंडारण समय जटिलता#लगातार समय|निरंतर-समय ग्राफ़ ट्रैवर्सल की अनुमति देता है।<ref name=":32">{{cite journal|last1=Have|first1=Christian Theil|last2=Jensen|first2=Lars Juhl|date=2013-10-17|title=Are graph databases ready for bioinformatics?|journal=Bioinformatics|volume=29|issue=24|pages=3107–3108|doi=10.1093/bioinformatics/btt549|issn=1460-2059|pmc=3842757|pmid=24135261}}</ref>




=== संसाधन विवरण फ्रेमवर्क (आरडीएफ) ===
=== संसाधन विवरण फ्रेमवर्क (आरडीएफ) ===
{{main|RDF (computer science)}}
{{main|RDF (computer science)}}
[[File:Rdf-graph3.png|thumb|493x493px|एक उदाहरण RDF ग्राफ़]]एक RDF (कंप्यूटर साइंस) ग्राफ मॉडल में, सूचना का जोड़ प्रत्येक को एक अलग नोड के साथ दर्शाया जाता है। उदाहरण के लिए, एक ऐसे परिदृश्य की कल्पना करें जहां एक उपयोगकर्ता को ग्राफ़ में एक विशिष्ट नोड के रूप में दर्शाए गए व्यक्ति के लिए एक नाम गुण जोड़ना है। एक लेबल-प्रॉपर्टी ग्राफ़ मॉडल में, यह व्यक्ति के नोड में एक नाम संपत्ति के अतिरिक्त के साथ किया जाएगा। हालाँकि, RDF में, उपयोगकर्ता को एक अलग नोड जोड़ना पड़ता है जिसे कहा जाता है <code>hasName</code> इसे मूल व्यक्ति नोड से जोड़ना। विशेष रूप से, एक RDF ग्राफ़ मॉडल नोड्स और आर्क्स से बना होता है। एक आरडीएफ ग्राफ संकेतन या एक बयान द्वारा दर्शाया गया है: विषय के लिए एक नोड, वस्तु के लिए एक नोड, और विधेय के लिए एक चाप। एक नोड खाली छोड़ा जा सकता है, एक [[ शाब्दिक (कंप्यूटर प्रोग्रामिंग) ]] और/या [[यूनिफॉर्म रिसोर्स पहचानकर्ता]] द्वारा पहचाना जा सकता है। यूआरआई द्वारा चाप की पहचान भी की जा सकती है। एक नोड के लिए एक शाब्दिक दो प्रकार का हो सकता है: सादा (अनटाइप्ड) और टाइप किया हुआ। एक सादे शाब्दिक का एक शाब्दिक रूप और वैकल्पिक रूप से एक भाषा टैग होता है। एक टाइप किया हुआ शाब्दिक एक URI के साथ एक स्ट्रिंग से बना होता है जो एक विशेष डेटाटाइप की पहचान करता है। डेटा में यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर नहीं होने पर डेटा की स्थिति को सटीक रूप से दर्शाने के लिए एक खाली नोड का उपयोग किया जा सकता है।<ref>{{cite web|url=https://www.w3.org/TR/rdf-concepts/#section-Overview|title=Resource Description Framework (RDF): Concepts and Abstract Syntax|website=www.w3.org|access-date=2018-10-24}}</ref>
[[File:Rdf-graph3.png|thumb|493x493px|उदाहरण RDF ग्राफ़]]RDF (कंप्यूटर साइंस) ग्राफ मॉडल में, सूचना का जोड़ प्रत्येक को अलग नोड के साथ दर्शाया जाता है। उदाहरण के लिए, ऐसे परिदृश्य की कल्पना करें जहां उपयोगकर्ता को ग्राफ़ में विशिष्ट नोड के रूप में दर्शाए गए व्यक्ति के लिए नाम गुण जोड़ना है। लेबल-प्रॉपर्टी ग्राफ़ मॉडल में, यह व्यक्ति के नोड में नाम संपत्ति के अतिरिक्त के साथ किया जाएगा। हालाँकि, RDF में, उपयोगकर्ता को अलग नोड जोड़ना पड़ता है जिसे कहा जाता है <code>hasName</code> इसे मूल व्यक्ति नोड से जोड़ना। विशेष रूप से, RDF ग्राफ़ मॉडल नोड्स और आर्क्स से बना होता है। आरडीएफ ग्राफ संकेतन या बयान द्वारा दर्शाया गया है: विषय के लिए नोड, वस्तु के लिए नोड, और विधेय के लिए चाप। नोड खाली छोड़ा जा सकता है, [[ शाब्दिक (कंप्यूटर प्रोग्रामिंग) ]] और/या [[यूनिफॉर्म रिसोर्स पहचानकर्ता]] द्वारा पहचाना जा सकता है। यूआरआई द्वारा चाप की पहचान भी की जा सकती है। नोड के लिए शाब्दिक दो प्रकार का हो सकता है: सादा (अनटाइप्ड) और टाइप किया हुआ। सादे शाब्दिक का शाब्दिक रूप और वैकल्पिक रूप से भाषा टैग होता है। एक टाइप किया हुआ शाब्दिक URI के साथ स्ट्रिंग से बना होता है जो विशेष डेटाटाइप की पहचान करता है। डेटा में यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर नहीं होने पर डेटा की स्थिति को सटीक रूप से दर्शाने के लिए खाली नोड का उपयोग किया जा सकता है।<ref>{{cite web|url=https://www.w3.org/TR/rdf-concepts/#section-Overview|title=Resource Description Framework (RDF): Concepts and Abstract Syntax|website=www.w3.org|access-date=2018-10-24}}</ref>




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


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


=== भंडारण ===
=== भंडारण ===
ग्राफ़ डेटाबेस का अंतर्निहित संग्रहण तंत्र भिन्न हो सकता है। कुछ एक संबंधपरक इंजन पर निर्भर करते हैं और तालिका (डेटाबेस) में ग्राफ़ डेटा संग्रहीत करते हैं (हालांकि तालिका एक तार्किक तत्व है, इसलिए यह दृष्टिकोण ग्राफ़ डेटाबेस, ग्राफ़ डेटाबेस प्रबंधन प्रणाली और भौतिक उपकरणों के बीच अमूर्तता का एक और स्तर लागू करता है जहां डेटा वास्तव में संग्रहीत है)। अन्य भंडारण के लिए एट्रिब्यूट-वैल्यू पेयर | की-वैल्यू स्टोर या दस्तावेज़-उन्मुख डेटाबेस का उपयोग करते हैं, जिससे वे स्वाभाविक रूप से NoSQL संरचनाएँ बन जाते हैं। एक नोड को किसी भी अन्य दस्तावेज़ स्टोर के रूप में दर्शाया जाएगा, लेकिन दो अलग-अलग नोड्स को जोड़ने वाले किनारे इसके दस्तावेज़ के अंदर विशेष गुण रखते हैं; a _from और _to विशेषताएँ।
ग्राफ़ डेटाबेस का अंतर्निहित संग्रहण तंत्र भिन्न हो सकता है। कुछ संबंधपरक इंजन पर निर्भर करते हैं और तालिका (डेटाबेस) में ग्राफ़ डेटा संग्रहीत करते हैं (हालांकि तालिका तार्किक तत्व है, इसलिए यह दृष्टिकोण ग्राफ़ डेटाबेस, ग्राफ़ डेटाबेस प्रबंधन प्रणाली और भौतिक उपकरणों के बीच अमूर्तता का एक और स्तर लागू करता है जहां डेटा वास्तव में संग्रहीत है)। अन्य भंडारण के लिए एट्रिब्यूट-वैल्यू पेयर | की-वैल्यू स्टोर या दस्तावेज़-उन्मुख डेटाबेस का उपयोग करते हैं, जिससे वे स्वाभाविक रूप से NoSQL संरचनाएँ बन जाते हैं। नोड को किसी भी अन्य दस्तावेज़ स्टोर के रूप में दर्शाया जाएगा, लेकिन दो अलग-अलग नोड्स को जोड़ने वाले किनारे इसके दस्तावेज़ के अंदर विशेष गुण रखते हैं; a _from और _to विशेषताएँ।


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


== अनुप्रयोग ==
== अनुप्रयोग ==
Line 60: Line 60:
* आशय ग्राफ: यह तर्क और प्रेरणा से संबंधित है।
* आशय ग्राफ: यह तर्क और प्रेरणा से संबंधित है।
* खपत ग्राफ: भुगतान ग्राफ के रूप में भी जाना जाता है, खुदरा उद्योग में खपत ग्राफ का अत्यधिक उपयोग किया जाता है। अमेज़ॅन, ईबे और वॉलमार्ट जैसी ई-कॉमर्स कंपनियां व्यक्तिगत ग्राहकों की खपत को ट्रैक करने के लिए खपत के ग्राफ का उपयोग करती हैं।
* खपत ग्राफ: भुगतान ग्राफ के रूप में भी जाना जाता है, खुदरा उद्योग में खपत ग्राफ का अत्यधिक उपयोग किया जाता है। अमेज़ॅन, ईबे और वॉलमार्ट जैसी ई-कॉमर्स कंपनियां व्यक्तिगत ग्राहकों की खपत को ट्रैक करने के लिए खपत के ग्राफ का उपयोग करती हैं।
* रुचि ग्राफ: यह किसी व्यक्ति के हितों को दर्शाता है और अक्सर एक सामाजिक ग्राफ द्वारा पूरक होता है। इसमें वेबपृष्ठों को अनुक्रमित करने के बजाय रुचि के आधार पर वेब मैपिंग द्वारा वेब संगठन की पिछली क्रांति का अनुसरण करने की क्षमता है।
* रुचि ग्राफ: यह किसी व्यक्ति के हितों को दर्शाता है और अक्सर सामाजिक ग्राफ द्वारा पूरक होता है। इसमें वेबपृष्ठों को अनुक्रमित करने के बजाय रुचि के आधार पर वेब मैपिंग द्वारा वेब संगठन की पिछली क्रांति का अनुसरण करने की क्षमता है।
* मोबाइल ग्राफ: यह मोबाइल डेटा से बनाया गया है। भविष्य में मोबाइल डेटा में वेब, एप्लिकेशन, डिजिटल वॉलेट, GPS और [[चीजों की इंटरनेट]] (IoT) उपकरणों का डेटा शामिल हो सकता है।
* मोबाइल ग्राफ: यह मोबाइल डेटा से बनाया गया है। भविष्य में मोबाइल डेटा में वेब, एप्लिकेशन, डिजिटल वॉलेट, GPS और [[चीजों की इंटरनेट]] (IoT) उपकरणों का डेटा शामिल हो सकता है।


== रिलेशनल डेटाबेस के साथ तुलना ==
== रिलेशनल डेटाबेस के साथ तुलना ==
संबंधपरक मॉडल पर एडगर एफ. कॉड के 1970 के पेपर के बाद से,<ref name=":2">{{cite journal|last=Codd|first=E. F.|date=1970-06-01|title=बड़े साझा डेटा बैंकों के लिए डेटा का एक रिलेशनल मॉडल|journal=Communications of the ACM|volume=13|issue=6|pages=377–387|doi=10.1145/362384.362685|s2cid=207549016|issn=0001-0782|doi-access=free}}</ref> [[ संबंधपरक डेटाबेस ]] बड़े पैमाने पर डेटा स्टोरेज सिस्टम के लिए वास्तविक उद्योग मानक रहे हैं। संबंधपरक मॉडल को एक सख्त स्कीमा और [[डेटा सामान्यीकरण]] की आवश्यकता होती है जो डेटा को कई तालिकाओं में अलग करता है और डेटाबेस के भीतर किसी भी डुप्लिकेट डेटा को हटा देता है। डेटा स्थिरता को बनाए रखने और एसीआईडी ​​​​(कंप्यूटर साइंस) का समर्थन करने के लिए डेटा को सामान्यीकृत किया जाता है। हालाँकि यह इस बात पर सीमाएँ लगाता है कि रिश्तों को कैसे समझा जा सकता है।
संबंधपरक मॉडल पर एडगर एफ. कॉड के 1970 के पेपर के बाद से,<ref name=":2">{{cite journal|last=Codd|first=E. F.|date=1970-06-01|title=बड़े साझा डेटा बैंकों के लिए डेटा का एक रिलेशनल मॉडल|journal=Communications of the ACM|volume=13|issue=6|pages=377–387|doi=10.1145/362384.362685|s2cid=207549016|issn=0001-0782|doi-access=free}}</ref> [[ संबंधपरक डेटाबेस ]] बड़े पैमाने पर डेटा स्टोरेज सिस्टम के लिए वास्तविक उद्योग मानक रहे हैं। संबंधपरक मॉडल को सख्त स्कीमा और [[डेटा सामान्यीकरण]] की आवश्यकता होती है जो डेटा को कई तालिकाओं में अलग करता है और डेटाबेस के भीतर किसी भी डुप्लिकेट डेटा को हटा देता है। डेटा स्थिरता को बनाए रखने और एसीआईडी ​​​​(कंप्यूटर साइंस) का समर्थन करने के लिए डेटा को सामान्यीकृत किया जाता है। हालाँकि यह इस बात पर सीमाएँ लगाता है कि रिश्तों को कैसे समझा जा सकता है।


रिलेशनल मॉडल की डिज़ाइन प्रेरणाओं में से एक तेज़ पंक्ति-दर-पंक्ति पहुँच प्राप्त करना था।<ref name=":2" />समस्याएँ तब उत्पन्न होती हैं जब संग्रहीत डेटा के बीच जटिल संबंध बनाने की आवश्यकता होती है। हालांकि संबंधपरक मॉडल के साथ संबंधों का विश्लेषण किया जा सकता है, कई तालिकाओं पर कई अलग-अलग विशेषताओं पर कई सम्मिलित संचालन करने वाले जटिल प्रश्नों की आवश्यकता होती है। रिलेशनल मॉडल के साथ काम करने में, [[विदेशी कुंजी]] बाधाओं पर भी विचार किया जाना चाहिए, जब रिश्तों को पुनः प्राप्त करना, अतिरिक्त ओवरहेड का कारण बनता है।
रिलेशनल मॉडल की डिज़ाइन प्रेरणाओं में से तेज़ पंक्ति-दर-पंक्ति पहुँच प्राप्त करना था।<ref name=":2" />समस्याएँ तब उत्पन्न होती हैं जब संग्रहीत डेटा के बीच जटिल संबंध बनाने की आवश्यकता होती है। हालांकि संबंधपरक मॉडल के साथ संबंधों का विश्लेषण किया जा सकता है, कई तालिकाओं पर कई अलग-अलग विशेषताओं पर कई सम्मिलित संचालन करने वाले जटिल प्रश्नों की आवश्यकता होती है। रिलेशनल मॉडल के साथ काम करने में, [[विदेशी कुंजी]] बाधाओं पर भी विचार किया जाना चाहिए, जब रिश्तों को पुनः प्राप्त करना, अतिरिक्त ओवरहेड का कारण बनता है।


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


इसके विपरीत, संबंधपरक डेटाबेस प्रबंधन प्रणालियां आम तौर पर बड़ी संख्या में डेटा तत्वों पर एक ही ऑपरेशन करने में तेज होती हैं, जिससे डेटा की प्राकृतिक संरचना में हेरफेर की अनुमति मिलती है। ग्राफ डेटाबेस के फायदे और हाल की लोकप्रियता के बावजूद  रिलेशनल डेटाबेस, यह अनुशंसा की जाती है कि ग्राफ़ मॉडल ही मौजूदा रिलेशनल डेटाबेस को बदलने का एकमात्र कारण नहीं होना चाहिए। एक ग्राफ़ डेटाबेस प्रासंगिक हो सकता है अगर परिमाण और कम विलंबता के क्रम में प्रदर्शन में सुधार के लिए कोई सबूत हो।<ref name=":12">{{cite news|url=https://www.safaribooksonline.com/library/view/graph-databases-2nd/9781491930885/|title=Graph Databases, 2nd Edition|work=O’Reilly {{!}} Safari|access-date=2018-10-23}}</ref>
इसके विपरीत, संबंधपरक डेटाबेस प्रबंधन प्रणालियां आम तौर पर बड़ी संख्या में डेटा तत्वों पर एक ही ऑपरेशन करने में तेज होती हैं, जिससे डेटा की प्राकृतिक संरचना में हेरफेर की अनुमति मिलती है। ग्राफ डेटाबेस के फायदे और हाल की लोकप्रियता के बावजूद  रिलेशनल डेटाबेस, यह अनुशंसा की जाती है कि ग्राफ़ मॉडल ही मौजूदा रिलेशनल डेटाबेस को बदलने का एकमात्र कारण नहीं होना चाहिए। ग्राफ़ डेटाबेस प्रासंगिक हो सकता है अगर परिमाण और कम विलंबता के क्रम में प्रदर्शन में सुधार के लिए कोई सबूत हो।<ref name=":12">{{cite news|url=https://www.safaribooksonline.com/library/view/graph-databases-2nd/9781491930885/|title=Graph Databases, 2nd Edition|work=O’Reilly {{!}} Safari|access-date=2018-10-23}}</ref>




=== उदाहरण ===
=== उदाहरण ===
रिलेशनल मॉडल डेटा में जानकारी का उपयोग करके डेटा को एक साथ इकट्ठा करता है। उदाहरण के लिए, कोई उन सभी उपयोगकर्ताओं को खोज सकता है जिनके फ़ोन नंबर में क्षेत्र कोड 311 है। यह स्ट्रिंग 311 के लिए चयनित फोन नंबर फ़ील्ड में देखकर चयनित डेटास्टोर्स, या टेबल (डेटाबेस) को खोजकर किया जाएगा। यह बड़ी तालिकाओं में समय लेने वाली प्रक्रिया हो सकती है, इसलिए रिलेशनल डेटाबेस डेटाबेस इंडेक्स प्रदान करते हैं, जो डेटा को एक छोटी उप-तालिका में संग्रहीत करने की अनुमति देते हैं, जिसमें केवल चयनित डेटा और रिकॉर्ड की एक अनूठी कुंजी (या प्राथमिक कुंजी) होती है। यदि फ़ोन नंबरों को अनुक्रमित किया जाता है, तो समान खोज छोटी अनुक्रमणिका तालिका में होगी, मेल खाने वाले रिकॉर्ड की कुंजियों को एकत्रित करना, और फिर उन कुंजियों वाले रिकॉर्ड के लिए मुख्य डेटा तालिका में देखना। आम तौर पर, एक टेबल को इस तरह से स्टोर किया जाता है जिससे कुंजी के माध्यम से लुकअप बहुत तेज हो जाता है।<ref name="from">{{cite web|url=http://neo4j.com/developer/graph-db-vs-rdbms/#_from_relational_to_graph_databases|title=रिलेशनल से ग्राफ डेटाबेस तक|website=Neo4j}}</ref>
रिलेशनल मॉडल डेटा में जानकारी का उपयोग करके डेटा को एक साथ इकट्ठा करता है। उदाहरण के लिए, कोई उन सभी उपयोगकर्ताओं को खोज सकता है जिनके फ़ोन नंबर में क्षेत्र कोड 311 है। यह स्ट्रिंग 311 के लिए चयनित फोन नंबर फ़ील्ड में देखकर चयनित डेटास्टोर्स, या टेबल (डेटाबेस) को खोजकर किया जाएगा। यह बड़ी तालिकाओं में समय लेने वाली प्रक्रिया हो सकती है, इसलिए रिलेशनल डेटाबेस डेटाबेस इंडेक्स प्रदान करते हैं, जो डेटा को एक छोटी उप-तालिका में संग्रहीत करने की अनुमति देते हैं, जिसमें केवल चयनित डेटा और रिकॉर्ड की अनूठी कुंजी (या प्राथमिक कुंजी) होती है। यदि फ़ोन नंबरों को अनुक्रमित किया जाता है, तो समान खोज छोटी अनुक्रमणिका तालिका में होगी, मेल खाने वाले रिकॉर्ड की कुंजियों को एकत्रित करना, और फिर उन कुंजियों वाले रिकॉर्ड के लिए मुख्य डेटा तालिका में देखना। आम तौर पर, टेबल को इस तरह से स्टोर किया जाता है जिससे कुंजी के माध्यम से लुकअप बहुत तेज हो जाता है।<ref name="from">{{cite web|url=http://neo4j.com/developer/graph-db-vs-rdbms/#_from_relational_to_graph_databases|title=रिलेशनल से ग्राफ डेटाबेस तक|website=Neo4j}}</ref>
संबंधपरक डेटाबेस में स्वाभाविक रूप से रिकॉर्ड के बीच निश्चित संबंधों का विचार नहीं होता है। इसके बजाय, संबंधित डेटा को एक रिकॉर्ड की अद्वितीय कुंजी को दूसरे रिकॉर्ड के डेटा में संग्रहीत करके एक दूसरे से जोड़ा जाता है। उदाहरण के लिए, उपयोगकर्ताओं के लिए ईमेल पते वाली एक तालिका में एक डेटा आइटम हो सकता है जिसे कहा जाता है <code>userpk</code>, जिसमें उस उपयोगकर्ता रिकॉर्ड की [[प्राथमिक कुंजी]] होती है जिससे वह संबद्ध है। उपयोगकर्ताओं और उनके ईमेल पतों को लिंक करने के लिए, सिस्टम पहले चयनित उपयोगकर्ता रिकॉर्ड प्राथमिक कुंजियों को देखता है, उन कुंजियों को खोजता है <code>userpk</code> ईमेल तालिका में कॉलम (या, अधिक संभावना है, उनमें से एक अनुक्रमणिका), ईमेल डेटा को निकालता है, और फिर सभी चयनित डेटा वाले समग्र रिकॉर्ड बनाने के लिए उपयोगकर्ता और ईमेल रिकॉर्ड को लिंक करता है। ज्वाइन (एसक्यूएल) नामक इस ऑपरेशन को कम्प्यूटेशनल रूप से महंगा हो सकता है। क्वेरी की जटिलता, जुड़ने की संख्या और विभिन्न चाबियों को अनुक्रमणित करने के आधार पर, सिस्टम को कई तालिकाओं और अनुक्रमितों के माध्यम से खोजना पड़ सकता है और फिर इसे एक साथ मिलान करने के लिए क्रमबद्ध करना पड़ सकता है।<ref name="from" />
संबंधपरक डेटाबेस में स्वाभाविक रूप से रिकॉर्ड के बीच निश्चित संबंधों का विचार नहीं होता है। इसके बजाय, संबंधित डेटा को रिकॉर्ड की अद्वितीय कुंजी को दूसरे रिकॉर्ड के डेटा में संग्रहीत करके एक दूसरे से जोड़ा जाता है। उदाहरण के लिए, उपयोगकर्ताओं के लिए ईमेल पते वाली तालिका में डेटा आइटम हो सकता है जिसे कहा जाता है <code>userpk</code>, जिसमें उस उपयोगकर्ता रिकॉर्ड की [[प्राथमिक कुंजी]] होती है जिससे वह संबद्ध है। उपयोगकर्ताओं और उनके ईमेल पतों को लिंक करने के लिए, सिस्टम पहले चयनित उपयोगकर्ता रिकॉर्ड प्राथमिक कुंजियों को देखता है, उन कुंजियों को खोजता है <code>userpk</code> ईमेल तालिका में कॉलम (या, अधिक संभावना है, उनमें से अनुक्रमणिका), ईमेल डेटा को निकालता है, और फिर सभी चयनित डेटा वाले समग्र रिकॉर्ड बनाने के लिए उपयोगकर्ता और ईमेल रिकॉर्ड को लिंक करता है। ज्वाइन (एसक्यूएल) नामक इस ऑपरेशन को कम्प्यूटेशनल रूप से महंगा हो सकता है। क्वेरी की जटिलता, जुड़ने की संख्या और विभिन्न चाबियों को अनुक्रमणित करने के आधार पर, सिस्टम को कई तालिकाओं और अनुक्रमितों के माध्यम से खोजना पड़ सकता है और फिर इसे एक साथ मिलान करने के लिए क्रमबद्ध करना पड़ सकता है।<ref name="from" />


इसके विपरीत, ग्राफ़ डेटाबेस सीधे रिकॉर्ड के बीच संबंधों को संग्रहीत करते हैं। में अपने उपयोगकर्ता की कुंजी को देखकर एक ईमेल पता खोजने के बजाय <code>userpk</code> स्तंभ, उपयोगकर्ता रिकॉर्ड में एक सूचक होता है जो सीधे ईमेल पता रिकॉर्ड को संदर्भित करता है। अर्थात्, एक उपयोगकर्ता का चयन करने के बाद, पॉइंटर को सीधे ईमेल रिकॉर्ड तक पहुँचाया जा सकता है, मेल खाने वाले रिकॉर्ड को खोजने के लिए ईमेल तालिका को खोजने की कोई आवश्यकता नहीं है। यह महंगे ज्वाइन ऑपरेशंस को खत्म कर सकता है। उदाहरण के लिए, यदि कोई क्षेत्र कोड 311 में उपयोगकर्ताओं के लिए सभी ईमेल पतों की खोज करता है, तो इंजन पहले 311 में उपयोगकर्ताओं को खोजने के लिए एक पारंपरिक खोज करेगा, लेकिन फिर उन रिकॉर्ड में पाए गए लिंक का अनुसरण करके ईमेल पते को पुनः प्राप्त करेगा। एक रिलेशनल डेटाबेस पहले 311 में सभी उपयोगकर्ताओं को खोजेगा, प्राथमिक कुंजियों की एक सूची निकालेगा, उन प्राथमिक कुंजियों के साथ ईमेल तालिका में किसी भी रिकॉर्ड के लिए दूसरी खोज करेगा, और मेल खाने वाले रिकॉर्ड को एक साथ लिंक करेगा। इस प्रकार के सामान्य कार्यों के लिए, ग्राफ़ डेटाबेस सैद्धांतिक रूप से तेज़ होंगे।<ref name="from" />
इसके विपरीत, ग्राफ़ डेटाबेस सीधे रिकॉर्ड के बीच संबंधों को संग्रहीत करते हैं। में अपने उपयोगकर्ता की कुंजी को देखकर ईमेल पता खोजने के बजाय <code>userpk</code> स्तंभ, उपयोगकर्ता रिकॉर्ड में सूचक होता है जो सीधे ईमेल पता रिकॉर्ड को संदर्भित करता है। अर्थात्, उपयोगकर्ता का चयन करने के बाद, पॉइंटर को सीधे ईमेल रिकॉर्ड तक पहुँचाया जा सकता है, मेल खाने वाले रिकॉर्ड को खोजने के लिए ईमेल तालिका को खोजने की कोई आवश्यकता नहीं है। यह महंगे ज्वाइन ऑपरेशंस को खत्म कर सकता है। उदाहरण के लिए, यदि कोई क्षेत्र कोड 311 में उपयोगकर्ताओं के लिए सभी ईमेल पतों की खोज करता है, तो इंजन पहले 311 में उपयोगकर्ताओं को खोजने के लिए पारंपरिक खोज करेगा, लेकिन फिर उन रिकॉर्ड में पाए गए लिंक का अनुसरण करके ईमेल पते को पुनः प्राप्त करेगा। रिलेशनल डेटाबेस पहले 311 में सभी उपयोगकर्ताओं को खोजेगा, प्राथमिक कुंजियों की सूची निकालेगा, उन प्राथमिक कुंजियों के साथ ईमेल तालिका में किसी भी रिकॉर्ड के लिए दूसरी खोज करेगा, और मेल खाने वाले रिकॉर्ड को एक साथ लिंक करेगा। इस प्रकार के सामान्य कार्यों के लिए, ग्राफ़ डेटाबेस सैद्धांतिक रूप से तेज़ होंगे।<ref name="from" />


ग्राफ़ दृष्टिकोण का सही मूल्य तब स्पष्ट हो जाता है जब कोई ऐसी खोज करता है जो एक स्तर से अधिक गहरी होती है। उदाहरण के लिए, 311 क्षेत्र कोड में उन उपयोगकर्ताओं की खोज पर विचार करें जिनके ग्राहक हैं (उपयोगकर्ताओं को अन्य उपयोगकर्ताओं से जोड़ने वाली तालिका)। इस मामले में एक संबंधपरक डेटाबेस को पहले 311 में एक क्षेत्र कोड वाले सभी उपयोगकर्ताओं को खोजना होता है, फिर उन उपयोगकर्ताओं में से किसी के लिए सब्सक्राइबर तालिका की खोज करनी होती है, और फिर अंत में मिलान करने वाले उपयोगकर्ताओं को पुनः प्राप्त करने के लिए उपयोगकर्ता तालिका को खोजना होता है। इसके विपरीत, एक ग्राफ डेटाबेस 311 में सभी उपयोगकर्ताओं के लिए खोज करेगा, फिर ग्राहक संबंध के माध्यम से ग्राहक उपयोगकर्ताओं को खोजने के लिए [[बैकलिंक]]्स का पालन करेगा। यह कई खोजों, लुक-अप और आउटपुट के निर्माण के लिए आवश्यक कई रिकॉर्ड से सभी अस्थायी डेटा को होल्ड करने में शामिल मेमोरी उपयोग से बचा जाता है। [[बिग ओ नोटेशन]] के संदर्भ में, यह प्रश्न होगा <math>O(\log n) + O(1)</math> समय - अर्थात, डेटा के आकार के लघुगणक के समानुपाती। इसके विपरीत, संबंधपरक संस्करण एकाधिक होगा <math>O(\log n)</math> लुकअप, साथ ही सभी डेटा रिकॉर्ड में शामिल होने के लिए आवश्यक समय।<ref name="from" />
ग्राफ़ दृष्टिकोण का सही मूल्य तब स्पष्ट हो जाता है जब कोई ऐसी खोज करता है जो स्तर से अधिक गहरी होती है। उदाहरण के लिए, 311 क्षेत्र कोड में उन उपयोगकर्ताओं की खोज पर विचार करें जिनके ग्राहक हैं (उपयोगकर्ताओं को अन्य उपयोगकर्ताओं से जोड़ने वाली तालिका)। इस मामले में संबंधपरक डेटाबेस को पहले 311 में क्षेत्र कोड वाले सभी उपयोगकर्ताओं को खोजना होता है, फिर उन उपयोगकर्ताओं में से किसी के लिए सब्सक्राइबर तालिका की खोज करनी होती है, और फिर अंत में मिलान करने वाले उपयोगकर्ताओं को पुनः प्राप्त करने के लिए उपयोगकर्ता तालिका को खोजना होता है। इसके विपरीत, ग्राफ डेटाबेस 311 में सभी उपयोगकर्ताओं के लिए खोज करेगा, फिर ग्राहक संबंध के माध्यम से ग्राहक उपयोगकर्ताओं को खोजने के लिए [[बैकलिंक]]्स का पालन करेगा। यह कई खोजों, लुक-अप और आउटपुट के निर्माण के लिए आवश्यक कई रिकॉर्ड से सभी अस्थायी डेटा को होल्ड करने में शामिल मेमोरी उपयोग से बचा जाता है। [[बिग ओ नोटेशन]] के संदर्भ में, यह प्रश्न होगा <math>O(\log n) + O(1)</math> समय - अर्थात, डेटा के आकार के लघुगणक के समानुपाती। इसके विपरीत, संबंधपरक संस्करण एकाधिक होगा <math>O(\log n)</math> लुकअप, साथ ही सभी डेटा रिकॉर्ड में शामिल होने के लिए आवश्यक समय।<ref name="from" />


ग्राफ़ पुनर्प्राप्ति का सापेक्ष लाभ क्वेरी की जटिलता के साथ बढ़ता है। उदाहरण के लिए, कोई उस अभिनेता के साथ पनडुब्बियों के बारे में उस फिल्म को जानना चाह सकता है जो उस फिल्म में उस अन्य अभिनेता के साथ थी जिसने गॉन विद द विंड (फिल्म) में मुख्य भूमिका निभाई थी। इसके लिए पहले सिस्टम को गॉन विद द विंड में अभिनेताओं को खोजने की आवश्यकता होती है, उन सभी फिल्मों को ढूंढें जिनमें वे थे, उन सभी फिल्मों में सभी अभिनेताओं को खोजें जो गॉन विद द विंड में प्रमुख नहीं थे, और फिर सभी फिल्मों को खोजें वे अंत में उस सूची को उन लोगों के लिए फ़िल्टर कर रहे थे जिनमें पनडुब्बी वाले विवरण थे। एक संबंधपरक डेटाबेस में, इसके लिए फिल्मों और अभिनेताओं की तालिकाओं के माध्यम से कई अलग-अलग खोजों की आवश्यकता होगी, पनडुब्बी फिल्मों पर एक और खोज करना, उन फिल्मों में सभी अभिनेताओं को ढूंढना और फिर (बड़े) एकत्रित परिणामों की तुलना करना। इसके विपरीत, ग्राफ डेटाबेस गॉन विद द विंड से [[क्लार्क गेबल]] तक चलेगा, उन फिल्मों के लिंक इकट्ठा करेगा जिनमें वह रहा है, उन फिल्मों के लिंक को अन्य अभिनेताओं के लिए इकट्ठा करेगा, और फिर उन अभिनेताओं के लिंक का अनुसरण करेगा फिल्मों की सूची। फिल्मों की परिणामी सूची को पनडुब्बी के लिए खोजा जा सकता है। यह सब एक खोज के माध्यम से किया जा सकता है।<ref name="examples">{{citation|title=Examples where Graph databases shine: Neo4j edition|url=https://zeroturnaround.com/rebellabs/examples-where-graph-databases-shine-neo4j-edition/2/|website=ZeroTurnaround}}</ref>
ग्राफ़ पुनर्प्राप्ति का सापेक्ष लाभ क्वेरी की जटिलता के साथ बढ़ता है। उदाहरण के लिए, कोई उस अभिनेता के साथ पनडुब्बियों के बारे में उस फिल्म को जानना चाह सकता है जो उस फिल्म में उस अन्य अभिनेता के साथ थी जिसने गॉन विद द विंड (फिल्म) में मुख्य भूमिका निभाई थी। इसके लिए पहले सिस्टम को गॉन विद द विंड में अभिनेताओं को खोजने की आवश्यकता होती है, उन सभी फिल्मों को ढूंढें जिनमें वे थे, उन सभी फिल्मों में सभी अभिनेताओं को खोजें जो गॉन विद द विंड में प्रमुख नहीं थे, और फिर सभी फिल्मों को खोजें वे अंत में उस सूची को उन लोगों के लिए फ़िल्टर कर रहे थे जिनमें पनडुब्बी वाले विवरण थे। संबंधपरक डेटाबेस में, इसके लिए फिल्मों और अभिनेताओं की तालिकाओं के माध्यम से कई अलग-अलग खोजों की आवश्यकता होगी, पनडुब्बी फिल्मों पर एक और खोज करना, उन फिल्मों में सभी अभिनेताओं को ढूंढना और फिर (बड़े) एकत्रित परिणामों की तुलना करना। इसके विपरीत, ग्राफ डेटाबेस गॉन विद द विंड से [[क्लार्क गेबल]] तक चलेगा, उन फिल्मों के लिंक इकट्ठा करेगा जिनमें वह रहा है, उन फिल्मों के लिंक को अन्य अभिनेताओं के लिए इकट्ठा करेगा, और फिर उन अभिनेताओं के लिंक का अनुसरण करेगा फिल्मों की सूची। फिल्मों की परिणामी सूची को पनडुब्बी के लिए खोजा जा सकता है। यह सब खोज के माध्यम से किया जा सकता है।<ref name="examples">{{citation|title=Examples where Graph databases shine: Neo4j edition|url=https://zeroturnaround.com/rebellabs/examples-where-graph-databases-shine-neo4j-edition/2/|website=ZeroTurnaround}}</ref>
गुण इस संरचना में अमूर्तता (कंप्यूटर विज्ञान) की एक और परत जोड़ते हैं जो कई सामान्य प्रश्नों को भी सुधारता है। गुण अनिवार्य रूप से लेबल होते हैं जिन्हें किसी भी रिकॉर्ड पर या कुछ मामलों में किनारों पर भी लागू किया जा सकता है। उदाहरण के लिए, कोई क्लार्क गेबल को अभिनेता के रूप में लेबल कर सकता है, जो तब निर्देशक या कैमरा ऑपरेटर के विपरीत, सिस्टम को अभिनेताओं के सभी रिकॉर्ड को जल्दी से खोजने की अनुमति देगा। यदि किनारों पर लेबल की अनुमति है, तो गॉन विद द विंड और क्लार्क गेबल के बीच संबंधों को लीड के रूप में भी लेबल किया जा सकता है, और गॉन विद द विंड मूवी में मुख्य अभिनेता लोगों पर एक खोज करके, डेटाबेस [[विवियन लेह]] का उत्पादन करेगा, [[ओलिविया देहविलैंड]] और क्लार्क गेबल। समतुल्य SQL क्वेरी को लोगों और फिल्मों को जोड़ने वाली तालिका में जोड़े गए डेटा पर निर्भर रहना होगा, जिससे क्वेरी सिंटैक्स में और जटिलता आ जाएगी। इस प्रकार के लेबल कुछ परिस्थितियों में खोज प्रदर्शन में सुधार कर सकते हैं, लेकिन अंतिम उपयोगकर्ताओं के लिए अतिरिक्त सिमेंटिक डेटा प्रदान करने में आम तौर पर अधिक उपयोगी होते हैं।<ref name="examples" />
गुण इस संरचना में अमूर्तता (कंप्यूटर विज्ञान) की एक और परत जोड़ते हैं जो कई सामान्य प्रश्नों को भी सुधारता है। गुण अनिवार्य रूप से लेबल होते हैं जिन्हें किसी भी रिकॉर्ड पर या कुछ मामलों में किनारों पर भी लागू किया जा सकता है। उदाहरण के लिए, कोई क्लार्क गेबल को अभिनेता के रूप में लेबल कर सकता है, जो तब निर्देशक या कैमरा ऑपरेटर के विपरीत, सिस्टम को अभिनेताओं के सभी रिकॉर्ड को जल्दी से खोजने की अनुमति देगा। यदि किनारों पर लेबल की अनुमति है, तो गॉन विद द विंड और क्लार्क गेबल के बीच संबंधों को लीड के रूप में भी लेबल किया जा सकता है, और गॉन विद द विंड मूवी में मुख्य अभिनेता लोगों पर खोज करके, डेटाबेस [[विवियन लेह]] का उत्पादन करेगा, [[ओलिविया देहविलैंड]] और क्लार्क गेबल। समतुल्य SQL क्वेरी को लोगों और फिल्मों को जोड़ने वाली तालिका में जोड़े गए डेटा पर निर्भर रहना होगा, जिससे क्वेरी सिंटैक्स में और जटिलता आ जाएगी। इस प्रकार के लेबल कुछ परिस्थितियों में खोज प्रदर्शन में सुधार कर सकते हैं, लेकिन अंतिम उपयोगकर्ताओं के लिए अतिरिक्त सिमेंटिक डेटा प्रदान करने में आम तौर पर अधिक उपयोगी होते हैं।<ref name="examples" />


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


आगे वर्णन करने के लिए, दो तालिकाओं के साथ एक संबंधपरक मॉडल की कल्पना करें: a <code>people</code> टेबल (जिसमें ए <code>person_id</code> और <code>person_name</code> कॉलम) और ए <code>friend</code> तालिका (साथ <code>friend_id</code> और <code>person_id</code>, जो की एक विदेशी कुंजी है <code>people</code> मेज)। इस मामले में, जैक के सभी दोस्तों को खोजने से निम्नलिखित SQL क्वेरी प्राप्त होगी।
आगे वर्णन करने के लिए, दो तालिकाओं के साथ संबंधपरक मॉडल की कल्पना करें: a <code>people</code> टेबल (जिसमें ए <code>person_id</code> और <code>person_name</code> कॉलम) और ए <code>friend</code> तालिका (साथ <code>friend_id</code> और <code>person_id</code>, जो की विदेशी कुंजी है <code>people</code> मेज)। इस मामले में, जैक के सभी दोस्तों को खोजने से निम्नलिखित SQL क्वेरी प्राप्त होगी।


<syntaxhighlight lang="sql">
<syntaxhighlight lang="sql">
Line 97: Line 97:
एक ही प्रश्न का अनुवाद किया जा सकता है -
एक ही प्रश्न का अनुवाद किया जा सकता है -


* साइफर [[ पूछताछ भाषा ]], एक ग्राफ डेटाबेस क्वेरी लैंग्वेज<syntaxhighlight lang="cypher">
* साइफर [[ पूछताछ भाषा ]], ग्राफ डेटाबेस क्वेरी लैंग्वेज<syntaxhighlight lang="cypher">
MATCH (p1:person {name: 'Jack'})-[:FRIEND_WITH]-(p2:person)
MATCH (p1:person {name: 'Jack'})-[:FRIEND_WITH]-(p2:person)
RETURN p2.name
RETURN p2.name
</syntaxhighlight>
</syntaxhighlight>
* SPARQL, [[W3C]] द्वारा मानकीकृत एक RDF ग्राफ़ डेटाबेस क्वेरी भाषा और कई RDF [[ट्रिपलस्टोर]] और नामांकित ग्राफ़ स्टोर में उपयोग की जाती है
* SPARQL, [[W3C]] द्वारा मानकीकृत RDF ग्राफ़ डेटाबेस क्वेरी भाषा और कई RDF [[ट्रिपलस्टोर]] और नामांकित ग्राफ़ स्टोर में उपयोग की जाती है
** लंबा प्रपत्र <syntaxhighlight lang="sparql">
** लंबा प्रपत्र <syntaxhighlight lang="sparql">
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
Line 122: Line 122:


</syntaxhighlight>
</syntaxhighlight>
* SPA[[SQL]], एक हाइब्रिड डेटाबेस क्वेरी भाषा, जो SQL को SPARQL के साथ विस्तारित करती है<syntaxhighlight lang="sparql">
* SPA[[SQL]], हाइब्रिड डेटाबेस क्वेरी भाषा, जो SQL को SPARQL के साथ विस्तारित करती है<syntaxhighlight lang="sparql">
SELECT people.name
SELECT people.name
FROM (
FROM (
Line 133: Line 133:
     ) AS people ;
     ) AS people ;
</syntaxhighlight>
</syntaxhighlight>
उपरोक्त उदाहरण एक बुनियादी संबंध क्वेरी का एक सरल उदाहरण हैं। वे संबंधपरक मॉडल की क्वेरी जटिलता के विचार को संघनित करते हैं जो डेटा की कुल मात्रा के साथ बढ़ता है। इसकी तुलना में, एक ग्राफ़ डेटाबेस क्वेरी परिणाम प्रस्तुत करने के लिए संबंध ग्राफ़ के माध्यम से सॉर्ट करने में आसानी से सक्षम है।
उपरोक्त उदाहरण बुनियादी संबंध क्वेरी का एक सरल उदाहरण हैं। वे संबंधपरक मॉडल की क्वेरी जटिलता के विचार को संघनित करते हैं जो डेटा की कुल मात्रा के साथ बढ़ता है। इसकी तुलना में, ग्राफ़ डेटाबेस क्वेरी परिणाम प्रस्तुत करने के लिए संबंध ग्राफ़ के माध्यम से सॉर्ट करने में आसानी से सक्षम है।


ऐसे परिणाम भी हैं जो इंगित करते हैं कि ग्राफ़ डेटाबेस के सरल, संघनित और घोषणात्मक प्रश्न आवश्यक रूप से संबंधपरक डेटाबेस की तुलना में अच्छा प्रदर्शन प्रदान नहीं करते हैं। जबकि ग्राफ़ डेटाबेस डेटा का सहज प्रतिनिधित्व प्रदान करते हैं, रिलेशनल डेटाबेस बेहतर परिणाम प्रदान करते हैं जब सेट ऑपरेशंस की आवश्यकता होती है।<ref name=":32"/>
ऐसे परिणाम भी हैं जो इंगित करते हैं कि ग्राफ़ डेटाबेस के सरल, संघनित और घोषणात्मक प्रश्न आवश्यक रूप से संबंधपरक डेटाबेस की तुलना में अच्छा प्रदर्शन प्रदान नहीं करते हैं। जबकि ग्राफ़ डेटाबेस डेटा का सहज प्रतिनिधित्व प्रदान करते हैं, रिलेशनल डेटाबेस बेहतर परिणाम प्रदान करते हैं जब सेट ऑपरेशंस की आवश्यकता होती है।<ref name=":32"/>
Line 204: Line 204:


* [[AQL (ArangoDB क्वेरी लैंग्वेज)]]: दस्तावेज़ और ग्राफ़ दोनों के लिए ArangoDB में उपयोग की जाने वाली SQL जैसी क्वेरी भाषा
* [[AQL (ArangoDB क्वेरी लैंग्वेज)]]: दस्तावेज़ और ग्राफ़ दोनों के लिए ArangoDB में उपयोग की जाने वाली SQL जैसी क्वेरी भाषा
* साइफर क्वेरी लैंग्वेज (साइफर): Neo4j के लिए एक ग्राफ क्वेरी [[घोषणात्मक भाषा]] जो ग्राफ के लिए एड हॉक और प्रोग्रामेटिक (एसक्यूएल-लाइक) एक्सेस को सक्षम बनाती है।<ref>{{cite web |url=http://sdtimes.com/guest-view-relational-vs-graph-databases-use/ |title=Guest View: Relational vs. graph databases: Which to use and when? |last1=Svensson |first1=Johan |date=5 July 2016 |website=San Diego Times |publisher=BZ Media |access-date=30 August 2016}}</ref>
* साइफर क्वेरी लैंग्वेज (साइफर): Neo4j के लिए ग्राफ क्वेरी [[घोषणात्मक भाषा]] जो ग्राफ के लिए एड हॉक और प्रोग्रामेटिक (एसक्यूएल-लाइक) एक्सेस को सक्षम बनाती है।<ref>{{cite web |url=http://sdtimes.com/guest-view-relational-vs-graph-databases-use/ |title=Guest View: Relational vs. graph databases: Which to use and when? |last1=Svensson |first1=Johan |date=5 July 2016 |website=San Diego Times |publisher=BZ Media |access-date=30 August 2016}}</ref>
* [[GQL ग्राफ़ क्वेरी भाषा]]: प्रस्तावित ISO मानक ग्राफ़ क्वेरी भाषा
* [[GQL ग्राफ़ क्वेरी भाषा]]: प्रस्तावित ISO मानक ग्राफ़ क्वेरी भाषा
* [[ग्राफक्यूएल]]: एपीआई के लिए एक ओपन-सोर्स डेटा क्वेरी और हेरफेर भाषा। [[ डगराफ ]] डीक्यूएल नामक संशोधित ग्राफक्यूएल भाषा को लागू करता है (पूर्व में ग्राफक्यूएल+-)
* [[ग्राफक्यूएल]]: एपीआई के लिए ओपन-सोर्स डेटा क्वेरी और हेरफेर भाषा। [[ डगराफ ]] डीक्यूएल नामक संशोधित ग्राफक्यूएल भाषा को लागू करता है (पूर्व में ग्राफक्यूएल+-)
* ग्रेमलिन (प्रोग्रामिंग लैंग्वेज): एक ग्राफ प्रोग्रामिंग लैंग्वेज जो अपाचे टिंकरपॉप ओपन-सोर्स प्रोजेक्ट का एक हिस्सा है<ref>{{cite web|url=https://tinkerpop.apache.org/gremlin.html|title=अपाचे टिंकरपॉप|last=TinkerPop|first=Apache|website=अपाचे टिंकरपॉप|access-date=2016-11-02}}</ref>
* ग्रेमलिन (प्रोग्रामिंग लैंग्वेज): ग्राफ प्रोग्रामिंग लैंग्वेज जो अपाचे टिंकरपॉप ओपन-सोर्स प्रोजेक्ट का एक हिस्सा है<ref>{{cite web|url=https://tinkerpop.apache.org/gremlin.html|title=अपाचे टिंकरपॉप|last=TinkerPop|first=Apache|website=अपाचे टिंकरपॉप|access-date=2016-11-02}}</ref>
* SPARQL: RDF डेटाबेस के लिए एक क्वेरी भाषा जो RDF प्रारूप में संग्रहीत डेटा को पुनः प्राप्त और हेरफेर कर सकती है
* SPARQL: RDF डेटाबेस के लिए क्वेरी भाषा जो RDF प्रारूप में संग्रहीत डेटा को पुनः प्राप्त और हेरफेर कर सकती है


== यह भी देखें ==
== यह भी देखें ==
Line 219: Line 219:
* [[संरचित भंडारण]]
* [[संरचित भंडारण]]
* [[टेक्स्ट ग्राफ]]
* [[टेक्स्ट ग्राफ]]
* विकिडेटा एक विकिपीडिया सहयोगी परियोजना है जो डेटा को एक ग्राफ डेटाबेस में संग्रहीत करती है। साधारण वेब ब्राउजिंग नोड्स को देखने, किनारों का अनुसरण करने और SPARQL प्रश्नों को चलाने की अनुमति देता है।
* विकिडेटा विकिपीडिया सहयोगी परियोजना है जो डेटा को ग्राफ डेटाबेस में संग्रहीत करती है। साधारण वेब ब्राउजिंग नोड्स को देखने, किनारों का अनुसरण करने और SPARQL प्रश्नों को चलाने की अनुमति देता है।


== संदर्भ ==
== संदर्भ ==

Revision as of 14:08, 16 May 2023

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

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

As of 2021, किसी भी सार्वभौमिक ग्राफ़ क्वेरी भाषा को उसी तरह से नहीं अपनाया गया है जैसे SQL रिलेशनल डेटाबेस के लिए था, और कई प्रकार की प्रणालियाँ हैं, जो अक्सर उत्पाद से कसकर बंधी होती हैं। कुछ शुरुआती मानकीकरण प्रयासों से ग्रेमलिन (प्रोग्रामिंग भाषा) , SPARQL और ग्राफ क्वेरी भाषा जैसी मल्टी-वेंडर क्वेरी लैंग्वेज बनती हैं। सितंबर 2019 में नई मानक ग्राफ़ क्वेरी भाषा (ISO/IEC 39075 सूचना प्रौद्योगिकी — डेटाबेस भाषाएँ — GQL) बनाने के लिए परियोजना के प्रस्ताव को ISO/IEC संयुक्त तकनीकी समिति 1 (ISO/IEC JTC 1) के सदस्यों द्वारा अनुमोदित किया गया था। ग्राफ़ क्वेरी भाषा का उद्देश्य SQL की तरह घोषणात्मक डेटाबेस क्वेरी भाषा होना है। क्वेरी लैंग्वेज इंटरफेस होने के अलावा, कुछ ग्राफ डेटाबेस को अप्लिकेशन प्रोग्रामिंग अंतरफलक (एपीआई) के माध्यम से एक्सेस किया जाता है।

ग्राफ़ डेटाबेस ग्राफ़ कंप्यूट इंजन से भिन्न होते हैं। ग्राफ़ डेटाबेस ऐसी तकनीकें हैं जो रिलेशनल ऑनलाइन लेनदेन प्रसंस्करण (OLTP) डेटाबेस के अनुवाद हैं। दूसरी ओर, थोक विश्लेषण के लिए ऑनलाइन विश्लेषणात्मक प्रसंस्करण (OLAP) में ग्राफ कंप्यूट इंजन का उपयोग किया जाता है।[5] मालिकाना ग्राफ डेटाबेस का उपयोग करने में प्रमुख प्रौद्योगिकी निगमों की सफलताओं के कारण, 2000 के दशक में ग्राफ डेटाबेस ने काफी ध्यान आकर्षित किया,[6] खुला स्रोत सॉफ्टवेयर की शुरुआत के साथ | ओपन-सोर्स ग्राफ डेटाबेस।

अध्ययन ने निष्कर्ष निकाला कि RDBMS ग्राफ़ प्रश्नों को निष्पादित करने पर मौजूदा ग्राफ़ विश्लेषण इंजनों के प्रदर्शन के बराबर था।[7]

ग्राफ लेबलिंग को 1980 के दशक के मध्य से ग्राफ़ डेटाबेस में प्रदर्शित किया जा सकता है, जैसे लॉजिकल डेटा मॉडल।[8][9] 1990 के दशक की शुरुआत में वाणिज्यिक वस्तु डेटाबेस (ODBMS) का उदय हुआ। 2000 में, वस्तु डेटा प्रबंधन समूह ने अ

इतिहास

1960 के दशक के मध्य में, आईबीएम के आईबीएम सूचना प्रबंधन प्रणाली जैसे नेविगेशनल डेटाबेस ने अपने पदानुक्रमित डेटाबेस मॉडल में ट्री (डेटा संरचना) जैसी संरचनाओं का समर्थन किया, लेकिन सख्त ट्री संरचना को वर्चुअल रिकॉर्ड से दरकिनार किया जा सकता था।[10][11] 1960 के दशक के अंत से नेटवर्क मॉडल डेटाबेस में ग्राफ संरचनाओं का प्रतिनिधित्व किया जा सकता है। CODASYL, जिसने 1959 में COBOL को परिभाषित किया था, ने 1969 में नेटवर्क डेटाबेस लैंग्वेज को परिभाषित किया।

ग्राफ लेबलिंग को 1980 के दशक के मध्य से ग्राफ़ डेटाबेस में प्रदर्शित किया जा सकता है, जैसे लॉजिकल डेटा मॉडल।[8][9] 1990 के दशक की शुरुआत में वाणिज्यिक वस्तु डेटाबेस (ODBMS) का उदय हुआ। 2000 में, वस्तु डेटा प्रबंधन समूह ने अपने ODMG'93 प्रकाशन में ऑब्जेक्ट और रिलेशनशिप (ग्राफ़) संरचनाओं को परिभाषित करने के लिए मानक भाषा प्रकाशित की।

1990 के दशक की शुरुआत में ग्राफ डेटाबेस में कई सुधार दिखाई दिए, 1990 के दशक के अंत में वेब पेजों को अनुक्रमित करने के प्रयासों में तेजी आई।

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

2010 के दशक में, वाणिज्यिक एसीआईडी ​​​​ग्राफ़ डेटाबेस जो स्केलेबिलिटी # क्षैतिज और लंबवत स्केलिंग हो सकते थे, उपलब्ध हो गए। इसके अलावा, SAP HANA ने इन-मेमोरी डेटाबेस | इन-मेमोरी और कॉलम-ओरिएंटेड DBMS तकनीकों को ग्राफ डेटाबेस में लाया।[12] इसके अलावा 2010 के दशक में, बहु-मॉडल डेटाबेस जो ग्राफ़ मॉडल (और अन्य मॉडल जैसे रिलेशनल डेटाबेस या दस्तावेज़-उन्मुख डेटाबेस) का समर्थन करते थे, जैसे कि OrientDB, ArangoDB, और MarkLogic (इसके 7.0 संस्करण से शुरू) उपलब्ध हो गए। इस समय के दौरान, सोशल मीडिया कंपनियों के आगमन के साथ विभिन्न प्रकार के ग्राफ डेटाबेस सामाजिक नेटवर्क विश्लेषण के साथ विशेष रूप से लोकप्रिय हो गए हैं। साथ ही दशक के दौरान, क्लाउड कम्प्यूटिंग -आधारित ग्राफ़ डेटाबेस जैसे Amazon Neptune और Neo4j#Licensing और संस्करण उपलब्ध हो गए।

पृष्ठभूमि

ग्राफ़ डेटाबेस नोड्स, गुण और किनारों को नियोजित करते हैं

ग्राफ़ डेटाबेस डेटा को चित्रित करते हैं क्योंकि इसे अवधारणात्मक रूप से देखा जाता है। यह डेटा को नोड्स और उसके संबंधों को किनारों में स्थानांतरित करके पूरा किया जाता है।

ग्राफ़ डेटाबेस एक डेटाबेस है जो ग्राफ़ सिद्धांत पर आधारित है। इसमें ऑब्जेक्ट्स का सेट होता है, जो नोड या एज हो सकता है।

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

ग्राफ मॉडल

लेबल-संपत्ति ग्राफ

लेबल-प्रॉपर्टी ग्राफ़ मॉडल को नोड्स, रिलेशनशिप, प्रॉपर्टी और लेबल के सेट द्वारा दर्शाया जाता है। डेटा और उनके रिश्तों के दोनों नोड्स का नाम दिया गया है और एट्रिब्यूट-वैल्यू पेयर | की-वैल्यू पेयर द्वारा दर्शाए गए गुणों को स्टोर कर सकते हैं। नोड्स को समूहीकृत करने के लिए लेबल किया जा सकता है। संबंधों का प्रतिनिधित्व करने वाले किनारों में दो गुण होते हैं: उनके पास हमेशा प्रारंभ नोड और अंत नोड होता है, और निर्देशित होता है;[13] ग्राफ़ को निर्देशित ग्राफ़ बनाना। रिश्तों में गुण भी हो सकते हैं। यह नोड्स के संबंधों को अतिरिक्त मेटाडेटा और शब्दार्थ प्रदान करने में उपयोगी है।[14] संबंधों का प्रत्यक्ष भंडारण समय जटिलता#लगातार समय|निरंतर-समय ग्राफ़ ट्रैवर्सल की अनुमति देता है।[15]


संसाधन विवरण फ्रेमवर्क (आरडीएफ)

उदाहरण RDF ग्राफ़

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


गुण

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

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

भंडारण

ग्राफ़ डेटाबेस का अंतर्निहित संग्रहण तंत्र भिन्न हो सकता है। कुछ संबंधपरक इंजन पर निर्भर करते हैं और तालिका (डेटाबेस) में ग्राफ़ डेटा संग्रहीत करते हैं (हालांकि तालिका तार्किक तत्व है, इसलिए यह दृष्टिकोण ग्राफ़ डेटाबेस, ग्राफ़ डेटाबेस प्रबंधन प्रणाली और भौतिक उपकरणों के बीच अमूर्तता का एक और स्तर लागू करता है जहां डेटा वास्तव में संग्रहीत है)। अन्य भंडारण के लिए एट्रिब्यूट-वैल्यू पेयर | की-वैल्यू स्टोर या दस्तावेज़-उन्मुख डेटाबेस का उपयोग करते हैं, जिससे वे स्वाभाविक रूप से NoSQL संरचनाएँ बन जाते हैं। नोड को किसी भी अन्य दस्तावेज़ स्टोर के रूप में दर्शाया जाएगा, लेकिन दो अलग-अलग नोड्स को जोड़ने वाले किनारे इसके दस्तावेज़ के अंदर विशेष गुण रखते हैं; a _from और _to विशेषताएँ।

अनुक्रमणिका-मुक्त निकटता

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

अनुप्रयोग

डेटा के प्रकार के अनुसार ग्राफ़ की कई श्रेणियां पहचानी गई हैं। गार्टनर ग्राफ़ की पाँच व्यापक श्रेणियों का सुझाव देता है:[17]

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

रिलेशनल डेटाबेस के साथ तुलना

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

रिलेशनल मॉडल की डिज़ाइन प्रेरणाओं में से तेज़ पंक्ति-दर-पंक्ति पहुँच प्राप्त करना था।[18]समस्याएँ तब उत्पन्न होती हैं जब संग्रहीत डेटा के बीच जटिल संबंध बनाने की आवश्यकता होती है। हालांकि संबंधपरक मॉडल के साथ संबंधों का विश्लेषण किया जा सकता है, कई तालिकाओं पर कई अलग-अलग विशेषताओं पर कई सम्मिलित संचालन करने वाले जटिल प्रश्नों की आवश्यकता होती है। रिलेशनल मॉडल के साथ काम करने में, विदेशी कुंजी बाधाओं पर भी विचार किया जाना चाहिए, जब रिश्तों को पुनः प्राप्त करना, अतिरिक्त ओवरहेड का कारण बनता है।

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

इसके विपरीत, संबंधपरक डेटाबेस प्रबंधन प्रणालियां आम तौर पर बड़ी संख्या में डेटा तत्वों पर एक ही ऑपरेशन करने में तेज होती हैं, जिससे डेटा की प्राकृतिक संरचना में हेरफेर की अनुमति मिलती है। ग्राफ डेटाबेस के फायदे और हाल की लोकप्रियता के बावजूद रिलेशनल डेटाबेस, यह अनुशंसा की जाती है कि ग्राफ़ मॉडल ही मौजूदा रिलेशनल डेटाबेस को बदलने का एकमात्र कारण नहीं होना चाहिए। ग्राफ़ डेटाबेस प्रासंगिक हो सकता है अगर परिमाण और कम विलंबता के क्रम में प्रदर्शन में सुधार के लिए कोई सबूत हो।[19]


उदाहरण

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

इसके विपरीत, ग्राफ़ डेटाबेस सीधे रिकॉर्ड के बीच संबंधों को संग्रहीत करते हैं। में अपने उपयोगकर्ता की कुंजी को देखकर ईमेल पता खोजने के बजाय userpk स्तंभ, उपयोगकर्ता रिकॉर्ड में सूचक होता है जो सीधे ईमेल पता रिकॉर्ड को संदर्भित करता है। अर्थात्, उपयोगकर्ता का चयन करने के बाद, पॉइंटर को सीधे ईमेल रिकॉर्ड तक पहुँचाया जा सकता है, मेल खाने वाले रिकॉर्ड को खोजने के लिए ईमेल तालिका को खोजने की कोई आवश्यकता नहीं है। यह महंगे ज्वाइन ऑपरेशंस को खत्म कर सकता है। उदाहरण के लिए, यदि कोई क्षेत्र कोड 311 में उपयोगकर्ताओं के लिए सभी ईमेल पतों की खोज करता है, तो इंजन पहले 311 में उपयोगकर्ताओं को खोजने के लिए पारंपरिक खोज करेगा, लेकिन फिर उन रिकॉर्ड में पाए गए लिंक का अनुसरण करके ईमेल पते को पुनः प्राप्त करेगा। रिलेशनल डेटाबेस पहले 311 में सभी उपयोगकर्ताओं को खोजेगा, प्राथमिक कुंजियों की सूची निकालेगा, उन प्राथमिक कुंजियों के साथ ईमेल तालिका में किसी भी रिकॉर्ड के लिए दूसरी खोज करेगा, और मेल खाने वाले रिकॉर्ड को एक साथ लिंक करेगा। इस प्रकार के सामान्य कार्यों के लिए, ग्राफ़ डेटाबेस सैद्धांतिक रूप से तेज़ होंगे।[20]

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

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

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

आगे वर्णन करने के लिए, दो तालिकाओं के साथ संबंधपरक मॉडल की कल्पना करें: a people टेबल (जिसमें ए person_id और person_name कॉलम) और ए friend तालिका (साथ friend_id और person_id, जो की विदेशी कुंजी है people मेज)। इस मामले में, जैक के सभी दोस्तों को खोजने से निम्नलिखित SQL क्वेरी प्राप्त होगी।

SELECT p2.person_name 
FROM people p1 
JOIN friend ON (p1.person_id = friend.person_id)
JOIN people p2 ON (p2.person_id = friend.friend_id)
WHERE p1.person_name = 'Jack';

एक ही प्रश्न का अनुवाद किया जा सकता है -

  • साइफर पूछताछ भाषा , ग्राफ डेटाबेस क्वेरी लैंग्वेज
    MATCH (p1:person {name: 'Jack'})-[:FRIEND_WITH]-(p2:person)
    RETURN p2.name
    
  • SPARQL, W3C द्वारा मानकीकृत RDF ग्राफ़ डेटाबेस क्वेरी भाषा और कई RDF ट्रिपलस्टोर और नामांकित ग्राफ़ स्टोर में उपयोग की जाती है
    • लंबा प्रपत्र
      PREFIX foaf: <http://xmlns.com/foaf/0.1/>
      
      SELECT ?name
      WHERE { ?s a          foaf:Person . 
              ?s foaf:name  "Jack" . 
              ?s foaf:knows ?o . 
              ?o foaf:name  ?name . 
            }
      
    • संक्षिप्त रूप
      PREFIX foaf: <http://xmlns.com/foaf/0.1/>
      
      SELECT ?name
      WHERE { ?s foaf:name     "Jack" ;
                 foaf:knows    ?o .
                 ?o foaf:name  ?name .
            }
      
  • SPASQL, हाइब्रिड डेटाबेस क्वेरी भाषा, जो SQL को SPARQL के साथ विस्तारित करती है
    SELECT people.name
    FROM (
           SPARQL PREFIX foaf: <http://xmlns.com/foaf/0.1/>
                  SELECT ?name
                  WHERE { ?s foaf:name  "Jack" ; 
                             foaf:knows ?o .
                          ?o foaf:name  ?name .
                        }
        ) AS people ;
    

उपरोक्त उदाहरण बुनियादी संबंध क्वेरी का एक सरल उदाहरण हैं। वे संबंधपरक मॉडल की क्वेरी जटिलता के विचार को संघनित करते हैं जो डेटा की कुल मात्रा के साथ बढ़ता है। इसकी तुलना में, ग्राफ़ डेटाबेस क्वेरी परिणाम प्रस्तुत करने के लिए संबंध ग्राफ़ के माध्यम से सॉर्ट करने में आसानी से सक्षम है।

ऐसे परिणाम भी हैं जो इंगित करते हैं कि ग्राफ़ डेटाबेस के सरल, संघनित और घोषणात्मक प्रश्न आवश्यक रूप से संबंधपरक डेटाबेस की तुलना में अच्छा प्रदर्शन प्रदान नहीं करते हैं। जबकि ग्राफ़ डेटाबेस डेटा का सहज प्रतिनिधित्व प्रदान करते हैं, रिलेशनल डेटाबेस बेहतर परिणाम प्रदान करते हैं जब सेट ऑपरेशंस की आवश्यकता होती है।[15]


ग्राफ डेटाबेस की सूची

निम्नलिखित WP की एक सूची है: GNG ग्राफ डेटाबेस:

name current
version
latest
release
date
(YYYY-MM-DD)
software
license
programming language description
AllegroGraph 7.0.0 2020-04 Proprietary, clients: Eclipse Public License v1 C#, C, Common Lisp, Java, Python Resource Description Framework (RDF) and graph database.
Amazon
Neptune
1.2.1.0 2023-03-08[22] Proprietary Not disclosed Amazon Neptune is a fully managed graph database by Amazon.com. It is used as a web service, and is part of Amazon Web Services. Supports popular graph models property graph and W3C's RDF, and their respective query languages Apache TinkerPop, Gremlin, SPARQL, and openCypher.
AnzoGraph DB 2.1 2020-02 Proprietary C, C++ AnzoGraph DB is a massively parallel native graph GOLAP (Graph Online Analytics Processing) style database built to support SPARQL and Cypher Query Language to analyze trillions of relationships. AnzoGraph DB is designed for interactive analysis of large sets of semantic triple data, but also supports labeled properties under proposed W3C standards.[23][24][25][26]
ArangoDB 3.9.1 2022-04 Free Apache 2, Proprietary C++, JavaScript, .NET, Java, Python, Node.js, PHP, Scala, Go, Ruby, Elixir NoSQL native graph database system developed by ArangoDB Inc, supporting three data models (key/value, documents, graphs), with one database core and a unified query language called AQL (ArangoDB Query Language). Provides scalability and high availability via datacenter-to-datacenter replication, auto-sharding, automatic failover, and other capabilities.
Azure Cosmos DB 2017 Proprietary Not disclosed Multi-modal database which supports graph concepts using the Apache Gremlin query language
DataStax
Enterprise
Graph
v6.0.1 2018-06 Proprietary Java Distributed, real-time, scalable database; supports Tinkerpop, and integrates with Cassandra[27]
InfiniteGraph 2021.2 2021-05 Proprietary, commercial, free 50GB version Java, C++, REST API, 'DO' query Language A distributed, cloud-enabled and massively scalable graph database for complex, real-time queries and operations. Its Vertex and Edge objects have unique 64-bit object identifiers that considerably speed up graph navigation and pathfinding operations. It supports batch or streaming updates to the graph alongside concurrent, parallel queries. InfiniteGraph's 'DO' query language enables both value based queries, as well as complex graph queries. InfiniteGraph is goes beyond graph databases to also support complex object queries.
JanusGraph 0.6.2 2022-05-31[28] Apache 2 Java Open source, scalable, distributed across a multi-machine cluster graph database under The Linux Foundation; supports various storage backends (Apache Cassandra, Apache HBase, Google Cloud Bigtable, Oracle BerkeleyDB);[29] supports global graph data analytics, reporting, and extract, transform, load (ETL) through integration with big data platforms (Apache Spark, Apache Giraph, Apache Hadoop); supports geo, numeric range, and full-text search via external index storages (Elasticsearch, Apache Solr, Apache Lucene).[30]
MarkLogic 8.0.4 2015 Proprietary, freeware developer version Java Multi-model NoSQL database that stores documents (JSON and XML) and semantic graph data (RDF triples); also has a built-in search engine.
Microsoft SQL Server 2017 RC1 Proprietary SQL/T-SQL, R, Python Offers graph database abilities to model many-to-many relationships. The graph relationships are integrated into Transact-SQL, and use SQL Server as the foundational database management system.[31]
NebulaGraph 3.0.2 2022-03 Apache 2.0, open source, Common Clause 1.0 C++, Go, Java, Python A scalable open-source distributed graph database for storing and handling billions of vertices and trillions of edges with milliseconds of latency. It is designed based on a shared-nothing distributed architecture for linear scalability.[32]
Neo4j 5.7 2023-04-20[33] GPLv3 Community Edition, commercial and AGPLv3 options for enterprise and advanced editions Java, .NET, JavaScript, Python, Go, Ruby, PHP, R, Erlang/Elixir, C/C++, Clojure, Perl, Haskell Open-source, supports ACID, has high-availability clustering for enterprise deployments, and comes with a web-based administration that includes full transaction support and visual node-link graph explorer; accessible from most programming languages using its built-in REST web API interface, and a proprietary Bolt protocol with official drivers.
Ontotext GraphDB 10.2.1 2023-04-25[34] Proprietary, Standard and Enterprise Editions are commercial, Free Edition is freeware Java Highly efficient and robust semantic graph database with RDF and SPARQL support, also available as a high-availability cluster. Integrates OpenRefine for ingestion and reconciliation of tabular data and ontop for Ontology-Based Data Access. Connects to Lucene, SOLR and Elasticsearch for Full text and Faceted search, and Kafka for event and stream processing. Supports OGC GeoSPARQL. Provides JDBC access to Knowledge Graphs.
OpenLink
Virtuoso
8.2 2018-10 Open Source Edition is GPLv2, Enterprise Edition is proprietary C, C++ Multi-model (Hybrid) relational database management system (RDBMS) that supports both SQL and SPARQL for declarative (Data Definition and Data Manipulation) operations on data modelled as SQL tables and/or RDF Graphs. Also supports indexing of RDF-Turtle, RDF-N-Triples, RDF-XML, JSON-LD, and mapping and generation of relations (SQL tables or RDF graphs) from numerous document types including CSV, XML, and JSON. May be deployed as a local or embedded instance (as used in the NEPOMUK Semantic Desktop), a one-instance network server, or a shared-nothing elastic-cluster multiple-instance networked server[35]
Oracle RDF Graph; part of Oracle Database 21c 2020 Proprietary SPARQL, SQL RDF Graph capabilities as features in multi-model Oracle Database: RDF Graph: comprehensive W3C RDF graph management in Oracle Database with native reasoning and triple-level label security. ACID, high-availability, enterprise scale. Includes visualization, RDF4J, and native end Sparql end point.
Oracle Property Graph; part of Oracle Database 21c 2020 Proprietary; Open Source language specification PGQL, Java, Python Property Graph; consisting of a set of objects or vertices, and a set of arrows or edges connecting the objects. Vertices and edges can have multiple properties, which are represented as key–value pairs. Includes PGQL, an SQL-like graph query language and an in-memory analytic engine (PGX) nearly 60 prebuilt parallel graph algorithms. Includes REST APIs and graph visualization.
OrientDB 3.0.28 2020-02 Community Edition is Apache 2, Enterprise Edition is commercial Java Second-generation[clarification needed] distributed graph database with the flexibility of documents in one product (i.e., it is both a graph database and a document NoSQL database); licensed under open-source Apache 2 license; and has full ACID support; it has a multi-master replication and sharding; supports schema-less, -full, and -mixed modes; has security profiling based on user and roles; supports a query language similar to SQL. It has HTTP REST and JSON API.
RedisGraph 2.0.20 2020-09 Redis Source Available License C In-memory, queryable Property Graph database which uses sparse matrices to represent the adjacency matrix in graphs and linear algebra to query the graph.[36]
SAP HANA 2.0 SPS 05 2020-06[37] Proprietary C, C++, Java, JavaScript and SQL-like language In-memory ACID transaction supported property graph[38]
Sparksee 5.2.0 2015 Proprietary, commercial, freeware for evaluation, research, development C++ High-performance scalable database management system from Sparsity Technologies; main trait is its query performance for retrieving and exploring large networks; has bindings for Java, C++, C#, Python, and Objective-C; version 5 is the first graph mobile database.
Sqrrl
Enterprise
2.0 2015-02 Proprietary Java Distributed, real-time graph database featuring cell-level security and mass-scalability[39]
Teradata
Aster
7 2016 Proprietary Java, SQL, Python, C++, R Massive parallel processing (MPP) database incorporating patented engines supporting native SQL, MapReduce, and graph data storage and manipulation; provides a set of analytic function libraries and data visualization[40]
TerminusDB 10.1.4 2022-08[41] Free Apache 2 Prolog, Rust, Python, JSON-LD Document-oriented knowledge graph; the power of an enterprise knowledge graph with the simplicity of documents.
TigerGraph 3.8.0 2022-11[42] Proprietary C++ Massive parallel processing (MPP) native graph database management system[43]
TypeDB 2.14.0 2022-11[44] Free, GNU AGPLv3 Java, Python, JavaScript TypeDB is a strongly-typed database with a rich and logical type system. TypeDB empowers you to tackle complex problems, and TypeQL is its query language. TypeDB allows you to model your domain based on logical and object-oriented principles. Composed of entity, relationship, and attribute types, as well as type hierarchies, roles, and rules, TypeDB allows you to think higher-level, as opposed to join-tables, columns, documents, vertices, edges, and properties.[promotion?]


ग्राफ़ क्वेरी-प्रोग्रामिंग भाषाएँ

  • AQL (ArangoDB क्वेरी लैंग्वेज): दस्तावेज़ और ग्राफ़ दोनों के लिए ArangoDB में उपयोग की जाने वाली SQL जैसी क्वेरी भाषा
  • साइफर क्वेरी लैंग्वेज (साइफर): Neo4j के लिए ग्राफ क्वेरी घोषणात्मक भाषा जो ग्राफ के लिए एड हॉक और प्रोग्रामेटिक (एसक्यूएल-लाइक) एक्सेस को सक्षम बनाती है।[45]
  • GQL ग्राफ़ क्वेरी भाषा: प्रस्तावित ISO मानक ग्राफ़ क्वेरी भाषा
  • ग्राफक्यूएल: एपीआई के लिए ओपन-सोर्स डेटा क्वेरी और हेरफेर भाषा। डगराफ डीक्यूएल नामक संशोधित ग्राफक्यूएल भाषा को लागू करता है (पूर्व में ग्राफक्यूएल+-)
  • ग्रेमलिन (प्रोग्रामिंग लैंग्वेज): ग्राफ प्रोग्रामिंग लैंग्वेज जो अपाचे टिंकरपॉप ओपन-सोर्स प्रोजेक्ट का एक हिस्सा है[46]
  • SPARQL: RDF डेटाबेस के लिए क्वेरी भाषा जो RDF प्रारूप में संग्रहीत डेटा को पुनः प्राप्त और हेरफेर कर सकती है

यह भी देखें

संदर्भ

  1. Bourbakis, Nikolaos G. (1998). आर्टिफिशियल इंटेलिजेंस और ऑटोमेशन. World Scientific. p. 381. ISBN 9789810226374. Retrieved 2018-04-20.
  2. Yoon, Byoung-Ha; Kim, Seon-Kyu; Kim, Seon-Young (March 2017). "विषम जैविक डेटा के एकीकरण के लिए ग्राफ डेटाबेस का उपयोग". Genomics & Informatics. 15 (1): 19–27. doi:10.5808/GI.2017.15.1.19. ISSN 1598-866X. PMC 5389944. PMID 28416946.
  3. Angles, Renzo; Gutierrez, Claudio (1 Feb 2008). "ग्राफ डेटाबेस मॉडल का सर्वेक्षण" (PDF). ACM Computing Surveys. 40 (1): 1–39. CiteSeerX 10.1.1.110.1072. doi:10.1145/1322432.1322433. S2CID 207166126. Archived from the original (PDF) on 15 August 2017. Retrieved 28 May 2016. network models [...] lack a good abstraction level: it is difficult to separate the db-model from the actual implementation
  4. Silberschatz, Avi (28 January 2010). डेटाबेस सिस्टम कॉन्सेप्ट्स, छठा संस्करण (PDF). McGraw-Hill. p. D-29. ISBN 978-0-07-352332-3.
  5. Robinson, Ian (2015-06-10). Graph Databases: New Opportunities for Connected Data. O'Reilly Media, Inc. p. 4. ISBN 9781491930861.
  6. "ग्राफ़ डेटाबेस मुख्यधारा में फट गया". www.kdnuggets.com. Retrieved 2018-10-23.
  7. Fan, Jing; Gerald, Adalbert (2014-12-25). विशेष ग्राफ एनालिटिक्स इंजन के खिलाफ मामला (PDF). Conference on Innovative Data Systems Research (CIDR).
  8. 8.0 8.1 Angles, Renzo; Gutierrez, Claudio (1 Feb 2008). "ग्राफ डेटाबेस मॉडल का सर्वेक्षण" (PDF). ACM Computing Surveys. 40 (1): 1–39. CiteSeerX 10.1.1.110.1072. doi:10.1145/1322432.1322433. S2CID 207166126. Archived from the original (PDF) on 15 August 2017. Retrieved 28 May 2016. network models [...] lack a good abstraction level: it is difficult to separate the db-model from the actual implementation
  9. 9.0 9.1 Kuper, Gabriel M. (1985). The Logical Data Model: A New Approach to Database Logic (PDF) (Ph.D.). Docket STAN-CS-85-1069. Archived (PDF) from the original on June 30, 2016. Retrieved 31 May 2016.
  10. Silberschatz, Avi (28 January 2010). डेटाबेस सिस्टम कॉन्सेप्ट्स, छठा संस्करण (PDF). McGraw-Hill. p. E-20. ISBN 978-0-07-352332-3.
  11. Parker, Lorraine. "आईएमएस नोट्स". vcu.edu. Retrieved 31 May 2016.
  12. "सैप ने हाना के साथ क्लाउड में नई क्षमताओं की घोषणा की". 2014-10-22. Retrieved 2016-07-07.
  13. Frisendal, Thomas (2017-09-22). "संपत्ति रेखांकन". graphdatamodeling.com. Retrieved 2018-10-23.
  14. Das, S; Srinivasan, J; Perry, Matthew; Chong, Eugene; Banerjee, Jay (2014-03-24). "A Tale of Two Graphs: Property Graphs as RDF in Oracle". {{cite journal}}: Cite journal requires |journal= (help)
  15. 15.0 15.1 Have, Christian Theil; Jensen, Lars Juhl (2013-10-17). "Are graph databases ready for bioinformatics?". Bioinformatics. 29 (24): 3107–3108. doi:10.1093/bioinformatics/btt549. ISSN 1460-2059. PMC 3842757. PMID 24135261.
  16. "Resource Description Framework (RDF): Concepts and Abstract Syntax". www.w3.org. Retrieved 2018-10-24.
  17. "The Competitive Dynamics of the Consumer Web: Five Graphs Deliver a Sustainable Advantage". www.gartner.com. Retrieved 2018-10-23.
  18. 18.0 18.1 Codd, E. F. (1970-06-01). "बड़े साझा डेटा बैंकों के लिए डेटा का एक रिलेशनल मॉडल". Communications of the ACM. 13 (6): 377–387. doi:10.1145/362384.362685. ISSN 0001-0782. S2CID 207549016.
  19. "Graph Databases, 2nd Edition". O’Reilly | Safari. Retrieved 2018-10-23.
  20. 20.0 20.1 20.2 20.3 "रिलेशनल से ग्राफ डेटाबेस तक". Neo4j.
  21. 21.0 21.1 "Examples where Graph databases shine: Neo4j edition", ZeroTurnaround
  22. "Amazon Neptune Engine Version 1.2.1.0 (2023-03-08)". Docs.AWS.Amazon.com. Amazon Web Services. Retrieved 20 April 2023.
  23. "In-memory massively parallel distributed graph database purpose-built for analytics". CambridgeSemantics.com. Retrieved 2018-02-20.
  24. Rueter, John (15 February 2018). "Cambridge Semantics announces AnzoGraph graph-based analytics support for Amazon Neptune and graph databases". BusinessWire.com. Retrieved 20 February 2018.
  25. Zane, Barry (2 November 2016). "Semantic graph databases: a worthy successor to relational databases". DBTA.com. Database Trends and Applications. Retrieved 20 February 2018.
  26. "Cambridge Semantics announces AnzoGraph support for Amazon Neptune and graph databases". DBTA.com. Database Trends and Applications. 2018-02-15. Retrieved 2018-03-08.
  27. Woodie, Alex (21 June 2016). "Beyond Titan: the evolution of DataStax's new graph database". Datanami.com. Retrieved 9 May 2017.
  28. "JanusGraph version 0.6.2". GitHub.com. 31 May 2022.
  29. "JanusGraph storage backends". docs.JanusGraph.org. Archived from the original on 2018-10-02. Retrieved 2018-10-01.
  30. "JanusGraph index storages". docs.JanusGraph.org. Archived from the original on 2018-10-02. Retrieved 2018-10-01.
  31. "What's new in SQL Server 2017". Docs.Microsoft.com. Microsoft Corp. 19 April 2017. Retrieved 9 May 2017.
  32. "Nebula Graph debuts for big data analytics discovery". Datanami.com. 29 June 2020. Retrieved 2 December 2020.
  33. "Release notes: Neo4j 5". Neo4j.com. Neo4j Graph Database Platform. Retrieved 2023-04-20.
  34. "Release Notes". Ontotext GraphDB. 25 April 2023. Retrieved 1 May 2023.
  35. "Clustering deployment architecture diagrams for Virtuoso". Virtuoso.OpenLinkSW.com. OpenLink Software. Retrieved 9 May 2017.
  36. Ewbank, Key. "RedisGraph reaches general availability". I-Programmer.info.
  37. "What's new in SAP HANA 2.0 SPS 05". blogs.SAP.com. 2020-06-26. Retrieved 2020-06-26.
  38. Rudolf, Michael; Paradies, Marcus; Bornhövd, Christof; Lehner, Wolfgang. The graph story of the SAP HANA database (PDF). Lecture Notes in Informatics.
  39. Vanian, Jonathan (18 February 2015). "NSA-linked Sqrrl eyes cyber security and lands $7M in funding". Gigaom.com. Gigaom. Archived from the original on 9 March 2019. Retrieved 9 May 2017.
  40. Woodie, Alex (23 October 2015). "The art of analytics, or what the green-haired people can teach us". Datanami.com. Retrieved 9 May 2017.
  41. "GitHub Releases". GitHub. Retrieved 9 Sep 2022.
  42. "Release notes : TigerGraph : Docs". Docs.TigerGraph.com. TigerGraph. Retrieved 17 June 2022.
  43. "The Forrester Wave™: graph data platforms, Q4 2020". AWS.Amazon.com. Amazon Web Services. 16 November 2020. Retrieved 16 November 2020.
  44. "Release TypeDB 2.14.0 · vaticle/typedb". GitHub (in English). Retrieved 2022-11-25.
  45. Svensson, Johan (5 July 2016). "Guest View: Relational vs. graph databases: Which to use and when?". San Diego Times. BZ Media. Retrieved 30 August 2016.
  46. TinkerPop, Apache. "अपाचे टिंकरपॉप". अपाचे टिंकरपॉप. Retrieved 2016-11-02.