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

यदि आपको अभी भी तर्क में कोई दोष नहीं मिला है, तो आगे पढ़ें।

बहुवचन दृढ़ता

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

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

यह उदाहरण, ज़ाहिर है, कुछ हद तक अतिरंजित है, लेकिन इसी उद्देश्य के लिए एक या दूसरे DBMS चुनने के पक्ष में कुछ विचार पाए जा सकते हैं, उदाहरण के लिए, यहाँ ।

यह स्पष्ट है कि इस तरह के चिड़ियाघर में मंत्री बनना आसान नहीं है।

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

चिड़ियाघर के निदेशक के दृष्टिकोण से, सब कुछ इस तरह दिखता है:

• DBMS निर्माता से लाइसेंस और तकनीकी सहायता की लागत में कई वृद्धि।
• कर्मचारी फूले और लंबे समय तक नेतृत्व करते हैं।
• असंगत डेटा के कारण प्रत्यक्ष वित्तीय नुकसान या दंड।

प्रणाली के स्वामित्व की कुल लागत (TCO) में उल्लेखनीय वृद्धि हुई है। क्या "मल्टीवेरेट स्टोरेज" स्थिति से बाहर निकलने का कोई रास्ता है?

बहु मॉडल

"मल्टीवेरिएट स्टोरेज" शब्द 2011 में उपयोग में आया। दृष्टिकोण की समस्याओं के बारे में जागरूकता और एक समाधान की खोज में कई साल लग गए, और 2015 तक जवाब गार्टनर विश्लेषकों के मुंह से तैयार किया गया था:

• " मार्केट गाइड फॉर नोएसक्यूएल डीबीएमएस - 2015 " से:
  

  DBMS का भविष्य, उनके आर्किटेक्चर और उपयोग के तरीके मल्टीमॉडल हैं।
  

• ODBMS 2016 के लिए मैजिक क्वाड्रंट से:
  

  एक ही प्लेटफॉर्म के हिस्से के रूप में परिचालन डीबीएमएस कई मॉडल - रिलेशनल और नॉन-रिलेशनल - की पेशकश करेगा।
  

ऐसा लगता है कि इस बार गार्टनर विश्लेषकों का पूर्वानुमान के साथ गलत नहीं था। यदि आप DB-Engines पर मुख्य DBMS रेटिंग वाले पेज पर जाते हैं, तो आप देख सकते हैं कि इसके अधिकांश नेता खुद को मल्टीमॉडल DBMS के रूप में ठीक-ठीक बताते हैं। वही पृष्ठ पर किसी भी निजी रेटिंग के साथ देखा जा सकता है।

नीचे दी गई तालिका में डीबीएमएस को दिखाया गया है - प्रत्येक निजी रेटिंग में नेता अपने बहु-मॉडल की घोषणा करते हैं। प्रत्येक DBMS के लिए, प्रारंभिक समर्थित मॉडल (केवल एक बार) संकेत दिया गया है और इसके साथ ही, अब समर्थित मॉडल। रचनाकारों के अनुसार DBMS को उस स्थिति में भी प्रस्तुत किया जाता है जो स्वयं "आरंभ में मल्टीमॉडल" के रूप में है और कोई भी मूल विरासत वाला मॉडल नहीं है।

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

मल्टीमॉडल डीबीएमएस एक रिलेशनल मॉडल पर आधारित है

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

लेखक, हालांकि, Microsoft SQL सर्वर में मल्टीमॉडलिंग के कार्यान्वयन को पसंद करता है, जिसके उदाहरण पर दस्तावेज़ और ग्राफ़ मॉडल के लिए RDBMS समर्थन का वर्णन किया जाएगा।

MS SQL सर्वर में दस्तावेज़ मॉडल

MS SQL सर्वर दस्तावेज़ मॉडल का समर्थन कैसे करता है, इसके बारे में Habré पर पहले से ही दो उत्कृष्ट लेख थे, मैं खुद को एक संक्षिप्त रीटेलिंग और टिप्पणी के लिए सीमित करूंगा:

• SQL सर्वर 2016 में JSON के साथ कार्य करना
• SQL सर्वर 2017 JSON

MS SQL सर्वर में दस्तावेज़ मॉडल का समर्थन करने का तरीका संबंधपरक DBMS के लिए काफी विशिष्ट है: JSON दस्तावेजों को सादे क्षेत्र के क्षेत्रों में संग्रहीत किया जाना प्रस्तावित है। दस्तावेज़ मॉडल का समर्थन इस JSON को पार्स करने के लिए विशेष ऑपरेटर प्रदान करना है:

• स्केलर विशेषता मान प्राप्त करने के लिए JSON_VALUE ,
• JSON_QUERY को पुनः प्राप्त करने के लिए।

दोनों ऑपरेटरों के लिए दूसरा तर्क JSONPath- जैसे सिंटैक्स में एक अभिव्यक्ति है।

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

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

अंत में, MS SQL सर्वर आपको समस्या को हल करने की अनुमति देता है, दस्तावेज़ के डिजाइन का उलटा: आप OPENJSON का उपयोग करके JSON को तालिकाओं में विघटित कर सकते हैं। यदि दस्तावेज़ पूरी तरह से सपाट नहीं है, तो आपको CROSS APPLY का उपयोग करना होगा।

MS SQL सर्वर में ग्राफ मॉडल

Microsoft SQL सर्वर में कार्यान्वित ग्राफ ( LPG ) मॉडल के लिए समर्थन भी काफी अनुमानित है : यह नोड्स के भंडारण के लिए और ग्राफ़ किनारों के भंडारण के लिए विशेष तालिकाओं का उपयोग करने का प्रस्ताव है। इस तरह की तालिकाओं को क्रमशः CREATE TABLE AS NODE और CREATE TABLE AS EDGE जाता है।

पहले प्रकार के टेबल केवल बाहरी अंतर के साथ रिकॉर्ड को संग्रहीत करने के लिए साधारण तालिकाओं के समान हैं जो तालिका में सिस्टम फ़ील्ड $node_id - डेटाबेस के भीतर एक ग्राफ नोड पहचानकर्ता अद्वितीय।

इसी प्रकार, दूसरे प्रकार की तालिकाओं में सिस्टम फ़ील्ड $from_id और $to_id , ऐसी तालिकाओं में रिकॉर्ड स्पष्ट रूप से नोड्स के बीच संबंधों को परिभाषित करते हैं। प्रत्येक प्रकार के संबंधों को संग्रहीत करने के लिए एक अलग तालिका का उपयोग किया जाता है।

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

 CREATE TABLE Person ( ID INTEGER NOT NULL, name VARCHAR(100) ) AS NODE; CREATE TABLE Cafe ( ID INTEGER NOT NULL, name VARCHAR(100), ) AS NODE; CREATE TABLE likes ( rating INTEGER ) AS EDGE; CREATE TABLE friendOf AS EDGE; /*   SQL Server 2019: ALTER TABLE likes ADD CONSTRAINT EC_LIKES CONNECTION (Person TO Cafe); */ 

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

 SELECT Cafe.name FROM Person, likes, Cafe WHERE MATCH (Person-(friendOf)-(likes)->Cafe) AND Person.name = 'John'; 

इसके अलावा, इस तरह के तालिकाओं के साथ काम करते समय इन ग्राफ पैटर्न का उपयोग करना मुश्किल नहीं है, क्योंकि समान समस्याओं को हल करने के लिए साधारण एसक्यूएल प्रश्नों में, सिस्टम "ग्राफ" नोड पहचानकर्ताओं ( $node_id , $from_id , $to_id ; को प्राप्त करने के लिए अतिरिक्त प्रयासों की आवश्यकता होगी; उसी कारण से, डेटा प्रविष्टि अनुरोध यहाँ भी बोझिल नहीं दिए गए हैं)।

MS SQL सर्वर में दस्तावेज़ और ग्राफ़ मॉडल के कार्यान्वयन के विवरण को सारांशित करते हुए, मैं ध्यान दूंगा कि एक मॉडल के दूसरे के ऊपर इस तरह के कार्यान्वयन मुख्य रूप से भाषा डिजाइन के संदर्भ में सफल नहीं लगते हैं। एक भाषा का दूसरे के साथ विस्तार करना आवश्यक है, भाषाएं पूरी तरह से "ऑर्थोगोनल" नहीं हैं, संगतता के नियम काफी विचित्र हो सकते हैं।

मल्टीमॉडल DBMS एक डॉक्यूमेंट मॉडल पर आधारित है

इस खंड में, मैं दस्तावेज़ DBMSs में मल्टीमॉडल के कार्यान्वयन का उदाहरण देना चाहूंगा, न कि उनमें से सबसे लोकप्रिय MongoDB के उदाहरण का उपयोग करते हुए (जैसा कि कहा गया था, इसमें केवल सशर्त रूप से ग्राफ़ ऑपरेटर $lookup और $graphLookup जो $graphLookup संग्रह पर काम नहीं करते हैं), लेकिन उदाहरण पर यह अधिक परिपक्व है और " एंटरप्राइज »DBMS मार्कलोगिक ।

तो, संग्रह में निम्न फॉर्म के XML दस्तावेजों का एक सेट है (MarkLogic भी JSON दस्तावेज़ों को संग्रहीत करने की अनुमति देता है):

 <Person INN="631803299804"> <name>John</name> <surname>Smith</surname> </Person> 

MarkLogic पर संबंधपरक मॉडल

दस्तावेजों के संग्रह का एक संबंधपरक प्रतिनिधित्व एक प्रदर्शन टेम्पलेट का उपयोग करके बनाया जा सकता है (नीचे दिए गए उदाहरण में value तत्वों की सामग्री मनमाना XPath हो सकती है):

 <template xmlns="http://marklogic.com/xdmp/tde"> <context>/Person</context> <rows> <row> <view-name>Person</view-name> <columns> <column> <name>SSN</name> <value>@SSN</value> <type>string</type> </column> <column> <name>name</name> <value>name</value> </column> <column> <name>surname</name> <value>surname</value> </column> </columns> </row> <rows> </template> 

SQL क्वेरी बनाई गई दृश्य (उदाहरण के लिए ODBC के माध्यम से) को संबोधित की जा सकती है:

 SELECT name, surname FROM Person WHERE name="John" 

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

MarkLogic में ग्राफ मॉडल

ग्राफ ( RDF ) मॉडल समर्थन के साथ, चीजें बहुत अधिक समान हैं। फिर, प्रदर्शन टेम्पलेट का उपयोग करके , आप उपरोक्त उदाहरण से दस्तावेज़ संग्रह का RDF प्रतिनिधित्व बना सकते हैं:

 <template xmlns="http://marklogic.com/xdmp/tde"> <context>/Person</context> <vars> <var> <name>PREFIX</name> <val>"http://example.org/example#"</val> </var> </vars> <triples> <triple> <subject><value>sem:iri( $PREFIX || @SSN )</value></subject> <predicate><value>sem:iri( $PREFIX || surname )</value></predicate> <object><value>xs:string( surname )</value></object> </triple> <triple> <subject><value>sem:iri( $PREFIX || @SSN )</value></subject> <predicate><value>sem:iri( $PREFIX || name )</value></predicate> <object><value>xs:string( name )</value></object> </triple> </triples> </template> 

परिणामस्वरूप RDF ग्राफ़ को SPARQL क्वेरी के साथ संबोधित किया जा सकता है:

 PREFIX : <http://example.org/example#> SELECT ?name ?surname { :631803299804 :name ?name ; :surname ?surname . } 

रिलेशनल के विपरीत, MarkLogic ग्राफ मॉडल दो अन्य तरीकों से समर्थन करता है:

1. DBMS RDF डेटा का एक पूर्ण-पृथक रिपॉजिटरी हो सकता है (इसमें ट्रिपल को प्रबंधित किया जाएगा , जैसा कि ऊपर निकाले गए अर्क के विपरीत है)।
2. विशेष क्रमांकन में RDF को केवल XML या JSON डॉक्यूमेंट्स में डाला जा सकता है (और फिर ट्रिपल को अनवांटेड कहा जाएगा)। यह शायद idref तंत्र इत्यादि का ऐसा विकल्प है।

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

मल्टीमॉडल DBMS "मुख्य मॉडल के बिना"

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

वास्तव में, ArangoDB और OrientDB में "बुनियादी" मॉडल हैं। दोनों ही मामलों में, ये मालिकाना डेटा मॉडल हैं, जो दस्तावेज़ सामान्यीकरण हैं। सामान्यीकरण मुख्य रूप से ग्राफ और संबंधपरक प्रश्नों के उत्पादन की क्षमता को सुविधाजनक बनाने के लिए हैं।

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

Hrané पर ArangoDB और OrientDB के बारे में पहले से ही एक अद्भुत लेख था: NoSQL डेटाबेस में शामिल हों ।

ArangoDB

ArangoDB एक ग्राफ डेटा मॉडल के लिए समर्थन का दावा करता है।

ArangoDB में ग्राफ़ नोड्स साधारण दस्तावेज़ हैं, और किनारों पर एक विशेष प्रकार के दस्तावेज़ होते हैं, जो सामान्य सिस्टम फ़ील्ड्स ( _key , _rev , _rev ), सिस्टम फ़ील्ड _from और _to । दस्तावेज़ में दस्तावेज़ DBMS को पारंपरिक रूप से संग्रह में जोड़ा जाता है। किनारों का प्रतिनिधित्व करने वाले दस्तावेजों के संग्रह को अरेंजबीडीबी में किनारे संग्रह कहा जाता है। वैसे, एज कलेक्शन के डॉक्यूमेंट भी डॉक्यूमेंट्स होते हैं, इसलिए अरंगबोब में किनारे भी नोड्स की तरह काम कर सकते हैं।

 [ { "_id" : "people/alice" , "_key" : "alice" , "name" : "" }, { "_id" : "people/bob" , "_key" : "bob" , "name" : "" } ] 

 [ { "_id" : "cafes/jd" , "_key" : "jd" , "name" : " " }, { "_id" : "cafes/jj" , "_key" : "jj" , "name" : "-" } ] 

 [ { "_id" : "likes/1" , "_key" : "1" , "_from" : "persons/alice" , "_to" : "cafes/jd", "since" : 2010 }, { "_id" : "likes/2" , "_key" : "2" , "_from" : "persons/alice" , "_to" : "cafes/jj", "since" : 2011 } , { "_id" : "likes/3" , "_key" : "3" , "_from" : "persons/bob" , "_to" : "cafes/jd", "since" : 2012 } ] 

 FOR p IN persons FOR c IN OUTBOUND p likes RETURN { person : p.name , likes : c.name } 

 FOR p IN persons FOR l IN likes FILTER p._key == l._from FOR c IN cafes FILTER l._to == c._key RETURN { person : p.name , likes : c.name } 

 [ { "person" : "" , likes : "-" } , { "person" : "" , likes : " " } , { "person" : "" , likes : " " } ] 

 FOR p IN persons RETURN { person : p.name, likes : ( FOR c IN OUTBOUND p likes RETURN c.name ) } 

 [ { "person" : "" , likes : ["-" , " "] } , { "person" : "" , likes : [" "] } ] 

OrientDB

ओरिएंटडीबी में दस्तावेज़ मॉडल के शीर्ष पर ग्राफ मॉडल का कार्यान्वयन, अधिक या कम मानक स्केलर मानों के अतिरिक्त दस्तावेज़ फ़ील्ड की क्षमता पर आधारित है, जैसे कि LINK , LINKLIST , LINKSET , LINKMAP और LINKBAG जैसे प्रकारों के मान। इन प्रकारों के मूल्य सिस्टम दस्तावेज़ पहचानकर्ताओं के लिंक या संग्रह हैं।

सिस्टम द्वारा असाइन किए गए दस्तावेज़ पहचानकर्ता का एक "भौतिक अर्थ" है, जो डेटाबेस में रिकॉर्ड की स्थिति को दर्शाता है, और कुछ इस तरह दिखता है: @rid : #3:16 । इस प्रकार, संदर्भ गुणों के मान वास्तव में अधिक संभावना सूचक होते हैं (जैसा कि एक ग्राफ मॉडल में), चयन स्थितियों के बजाय (रिलेशनल मॉडल के रूप में)।

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

 [ { "@type": "document", "@rid": "#11:0", "@class": "Person", "name": "", "out_likes": [ "#30:1", "#30:2" ], "@fieldTypes": "out_likes=LINKBAG" }, { "@type": "document", "@rid": "#12:0", "@class": "Person", "name": "", "out_likes": [ "#30:3" ], "@fieldTypes": "out_likes=LINKBAG" }, { "@type": "document", "@rid": "#21:0", "@class": "Cafe", "name": "-", "in_likes": [ "#30:2", "#30:3" ], "@fieldTypes": "in_likes=LINKBAG" }, { "@type": "document", "@rid": "#22:0", "@class": "Cafe", "name": " ", "in_likes": [ "#30:1" ], "@fieldTypes": "in_likes=LINKBAG" }, { "@type": "document", "@rid": "#30:1", "@class": "likes", "in": "#22:0", "out": "#11:0", "since": 1262286000000, "@fieldTypes": "in=LINK,out=LINK,since=date" }, { "@type": "document", "@rid": "#30:2", "@class": "likes", "in": "#21:0", "out": "#11:0", "since": 1293822000000, "@fieldTypes": "in=LINK,out=LINK,since=date" }, { "@type": "document", "@rid": "#30:3", "@class": "likes", "in": "#21:0", "out": "#12:0", "since": 1325354400000, "@fieldTypes": "in=LINK,out=LINK,since=date" } ] 

 SELECT name AS person_name, OUT('likes').name AS cafe_name FROM Person UNWIND cafe_name 

 [ { "person_name": "", "cafe_name": " " }, { "person_name": "", "cafe_name": "-" }, { "person_name": "", "cafe_name": "-" } ] 

 [ { "person_name": "", "cafe_name": [ " ", "-" ] }, { "person_name": "", "cafe_name": [ "-" ' } ] 

 MATCH {CLASS: Person, AS: person}-likes->{CLASS: Cafe, AS: cafe} RETURN person.name AS person_name, LIST(cafe.name) AS cafe_name GROUP BY person_name 

एज़्योर कोस्मोसबडी

कुछ हद तक, अरंग्गबीडी और ओरिएंटडीबी के बारे में ऊपर जो कहा गया था वह अज़ूर कोस्मोसबडी को संदर्भित करता है। CosmosDB निम्नलिखित डेटा एक्सेस APIs प्रदान करता है: SQL, MongoDB, Gremlin, और Cassandra।

SQL API और MongoDB API का उपयोग दस्तावेज़ मॉडल में डेटा तक पहुंचने के लिए किया जाता है। ग्रेमलिन एपीआई और कैसंड्रा एपीआई - क्रमशः ग्राफ और कॉलम में डेटा तक पहुंचने के लिए। सभी मॉडलों में डेटा कोस्मोसबीडी आंतरिक मॉडल के प्रारूप में सहेजा गया है: एआरएस ("परमाणु-रिकॉर्ड-अनुक्रम"), जो दस्तावेज़ एक के भी करीब है।

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

इस प्रकार, Azure CosmosDB में मल्टीमॉडल आज केवल एक ही निर्माता से विभिन्न मॉडलों का समर्थन करने वाले कई डेटाबेस का उपयोग करने का अवसर है, जो मल्टीवेरेट स्टोरेज की सभी समस्याओं का समाधान नहीं करता है।

मल्टीमॉडल DBMS एक ग्राफ मॉडल पर आधारित है?

यह उल्लेखनीय है कि बाजार पर एक ग्राफ मॉडल (एक साथ दो ग्राफ मॉडल के लिए मल्टीमॉडल समर्थन को छोड़कर: आरडीएफ और एलपीजी के अलावा कोई मल्टीमॉडल डीबीएमएस नहीं हैं); इसे पिछले प्रकाशन में देखें )। संबंध के बजाय दस्तावेज़ के ग्राफ़ मॉडल के शीर्ष पर कार्यान्वयन सबसे बड़ी कठिनाइयाँ हैं।

एक ग्राफ मॉडल पर एक संबंधपरक मॉडल को कैसे लागू किया जाए, इस सवाल पर बाद के गठन के समय भी विचार किया गया था। उदाहरण के लिए डेविड मैकगवर्न ने कहा :

ग्राफ़ के दृष्टिकोण में कुछ भी अंतर्निहित नहीं है जो एक ग्राफ़ डेटाबेस पर एक परत (जैसे उपयुक्त अनुक्रमण द्वारा) बनाने से रोकता है जो सामान्य कुंजी मान जोड़े से टुपल्स की पुनर्प्राप्ति (1) के साथ संबंधपरक दृष्टिकोण को सक्षम करता है और (2) टुपल्स का समूहन। संबंध प्रकार।

ग्राफ़ के शीर्ष पर दस्तावेज़ मॉडल को लागू करते समय, आपको ध्यान में रखना होगा, उदाहरण के लिए, निम्नलिखित:

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

निष्कर्ष

मुझे उम्मीद है कि मल्टीमॉडलिंग को जो सामान्य रूप में कहा जाता है, वह पाठक के लिए कमोबेश स्पष्ट हो गया है। अलग-अलग DBMS को मल्टीमॉडल कहा जाता है, और "कई मॉडलों के लिए समर्थन" अलग दिख सकता है। यह समझने के लिए कि प्रत्येक मामले में "मल्टी-मॉडल" क्या है, निम्नलिखित प्रश्नों के उत्तर देना उपयोगी है:

1. क्या यह पारंपरिक मॉडल का समर्थन करने के बारे में है, या एकल हाइब्रिड मॉडल के बारे में है?
2. क्या मॉडल "बराबर" हैं या उनमें से एक दूसरों के अधीन है?
3. क्या मॉडल एक दूसरे के प्रति "उदासीन" हैं? क्या एक मॉडल में दर्ज किया गया डेटा दूसरे में पढ़ा जा सकता है या ओवरराइट भी किया जा सकता है?

मुझे लगता है कि मल्टीमॉडल डीबीएमएस की प्रासंगिकता के सवाल का सकारात्मक जवाब देना पहले से ही संभव है, लेकिन दिलचस्प सवाल यह है कि निकट भविष्य में उनकी कौन सी किस्में अधिक लोकप्रिय होंगी। ऐसा लगता है कि पारंपरिक मॉडल का समर्थन करने वाले मल्टीमॉडल डीबीएमएस, मुख्य रूप से रिलेशनल, मांग में अधिक होंगे; , , , — .