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

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

सामग्री

बहुभाषी दृढ़ता
बहु मॉडल
रिलेशनल मॉडल पर आधारित मल्टी-मॉडल DBMS
     MS SQL सर्वर में दस्तावेज़ मॉडल
     MS SQL सर्वर में ग्राफ़ मॉडल
दस्तावेज़ मॉडल पर आधारित मल्टी-मॉडल DBMS
     मार्कलॉजिक में रिलेशनल मॉडल
     मार्कलॉजिक में ग्राफ़ मॉडल
मल्टी-मॉडल DBMS "बिना मुख्य मॉडल के"
     अरंगोडीबी
     OrientDB
     एज़्योर कॉसमॉसडीबी
ग्राफ़ मॉडल पर आधारित मल्टी-मॉडल DBMS?
निष्कर्ष
Опрос

बहुभाषी दृढ़ता

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

फाउलर के पास ई-कॉमर्स के क्षेत्र में पूर्ण-विशेषताओं वाले और उच्च-लोड एप्लिकेशन में डेटा भंडारण को व्यवस्थित करने का निम्नलिखित उदाहरण भी है।

यह उदाहरण, निश्चित रूप से, कुछ हद तक अतिरंजित है, लेकिन संबंधित उद्देश्य के लिए एक या दूसरे डीबीएमएस को चुनने के पक्ष में कुछ विचार पाए जा सकते हैं, उदाहरण के लिए, यहां.

साफ़ है कि ऐसे चिड़ियाघर में नौकर बनना आसान नहीं है।

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

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

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

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

बहु मॉडल

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

से "NoSQL DBMSs के लिए मार्केट गाइड - 2015»:

डीबीएमएस का भविष्य, उनकी वास्तुकला और उनके उपयोग के तरीके मल्टी-मॉडल हैं।
से "ओडीबीएमएस के लिए मैजिक क्वाड्रेंट - 2016»:

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

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

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

डीबीएमएस	प्रारंभिक मॉडल	अतिरिक्त मॉडल
ओरेकल	रिलेशनल	ग्राफ़, दस्तावेज़
MS SQL	रिलेशनल	ग्राफ़, दस्तावेज़
पोस्टग्रेएसक्यूएल	रिलेशनल	ग्राफ*, दस्तावेज़
मार्कलॉजिक	दस्तावेज़ी	ग्राफ़, संबंधपरक
MongoDB	दस्तावेज़ी	कुंजी-मूल्य, ग्राफ*
DataStax	विस्तृत स्तम्भ	वृत्तचित्र, ग्राफ
Redis	मौलिक मूल्य	वृत्तचित्र, ग्राफ*
अरंगोडीबी	-	ग्राफ़, दस्तावेज़
OrientDB	-	ग्राफ़, दस्तावेज़, संबंधपरक
एज़्योर कॉसमॉसडीबी	-	ग्राफ़, दस्तावेज़, संबंधपरक

तालिका के लिए नोट

तालिका में तारांकन उन कथनों को चिह्नित करते हैं जिनके लिए आरक्षण की आवश्यकता होती है:

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

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

रिलेशनल मॉडल पर आधारित मल्टी-मॉडल DBMS

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

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

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

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

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

JSON_VALUE अदिश विशेषता मान निकालने के लिए,
JSON_QUERY उप-दस्तावेज़ निकालने के लिए.

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

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

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

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

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

ग्राफ़ (एलपीजी) मॉडल के लिए समर्थन भी Microsoft SQL सर्वर में पूरी तरह से लागू किया गया है उम्मीद के मुताबिक: नोड्स को स्टोर करने और ग्राफ किनारों को स्टोर करने के लिए विशेष तालिकाओं का उपयोग करने का प्रस्ताव है। ऐसी तालिकाएँ अभिव्यक्तियों का उपयोग करके बनाई जाती हैं CREATE TABLE AS NODE и CREATE TABLE AS EDGE क्रमशः.

पहले प्रकार की तालिकाएँ रिकॉर्ड संग्रहीत करने के लिए सामान्य तालिकाओं के समान होती हैं, केवल बाहरी अंतर यह होता है कि तालिका में एक सिस्टम फ़ील्ड होता है $node_id - डेटाबेस के भीतर ग्राफ़ नोड का विशिष्ट पहचानकर्ता।

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

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

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;

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';

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

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

दस्तावेज़ मॉडल पर आधारित मल्टी-मॉडल DBMS

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

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

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

मार्कलॉजिक में रिलेशनल मॉडल

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

<template >
  <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"

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

मार्कलॉजिक में ग्राफ़ मॉडल

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

<template >
  <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 .
}

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

एक डीबीएमएस आरडीएफ डेटा का एक पूर्ण रूप से अलग भंडारण हो सकता है (इसमें ट्रिपल कहा जाएगा कामयाब ऊपर वर्णित लोगों के विपरीत निकाले).
विशेष क्रमबद्धता में आरडीएफ को केवल XML या JSON दस्तावेज़ों में डाला जा सकता है (और फिर ट्रिपल को बुलाया जाएगा अप्रबंधित). यह संभवतः तंत्र का एक विकल्प है idref आदि

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

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

बाज़ार में ऐसे DBMS भी हैं जो बिना किसी विरासत वाले मुख्य मॉडल के, स्वयं को प्रारंभ में मल्टी-मॉडल के रूप में स्थापित करते हैं। इसमे शामिल है अरंगोडीबी, OrientDB (2018 से विकास कंपनी SAP की है) और कॉसमॉसडीबी (Microsoft Azure क्लाउड प्लेटफ़ॉर्म के भाग के रूप में सेवा)।

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

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

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

अरंगोडीबी

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

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

कच्चा डेटा

चलो एक संग्रह है persons, जिनके दस्तावेज़ इस तरह दिखते हैं:

[
  {
    "_id"  : "people/alice" ,
    "_key" : "alice" ,
    "name" : "Алиса"
  },
  {
    "_id"  : "people/bob" ,
    "_key" : "bob" ,
    "name" : "Боб"  
  }
]

एक संग्रह भी हो cafes:

[
  {
    "_id" : "cafes/jd" ,
    "_key" : "jd" ,
    "name" : "Джон Донн"  
  },
  {
    "_id" : "cafes/jj" ,
    "_key" : "jj" ,
    "name" : "Жан-Жак"
  }
]

फिर संग्रह likes इस तरह लग सकता है:

[
  {
    "_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 
  }
]

प्रश्न और परिणाम

ArangoDB में प्रयुक्त AQL भाषा में एक ग्राफ़-शैली क्वेरी, मानव-पठनीय रूप में यह जानकारी लौटाती है कि किसे कौन सा कैफे पसंद है, इस तरह दिखता है:

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

संबंधपरक शैली में, जहां हम रिश्तों को संग्रहीत करने के बजाय "कंप्यूटिंग" कर रहे हैं, इस क्वेरी को इस तरह फिर से लिखा जा सकता है (वैसे, संग्रह के बिना likes बिना कर सकते हैं):

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 : "Джон Донн" }
]

अधिक प्रश्न और परिणाम

यदि उपरोक्त परिणाम प्रारूप दस्तावेज़ DBMS की तुलना में रिलेशनल DBMS के लिए अधिक विशिष्ट लगता है, तो आप इस क्वेरी को आज़मा सकते हैं (या आप इसका उपयोग कर सकते हैं) COLLECT):

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

परिणाम इस तरह दिखेगा:

[
  { "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"]  } ,
  { "person" : "Боб" , likes : ["Джон Донн"] }
]

OrientDB

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

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

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

कच्चा डेटा

के करीब एक प्रारूप में डंप प्रारूप OrientDB डेटाबेस, ArangoDB के लिए पिछले उदाहरण का डेटा कुछ इस तरह दिखेगा:

[
     {
      "@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"
    }
  ]

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

प्रश्न और परिणाम

OrientDB में ArangoDB के उदाहरण की क्वेरी के उद्देश्य के समान एक क्वेरी इस तरह दिखती है:

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": "Жан-Жак" }
]

यदि परिणाम प्रारूप फिर से बहुत अधिक "संबंधपरक" लगता है, तो आपको पंक्ति को हटाने की आवश्यकता है UNWIND():

[
  { "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
  { "person_name": "Боб",  "cafe_name": [ "Жан-Жак" ' }
]

OrientDB की क्वेरी भाषा को ग्रेमलिन-जैसे आवेषण के साथ SQL के रूप में वर्णित किया जा सकता है। संस्करण 2.2 में, एक साइफ़र-जैसा अनुरोध फ़ॉर्म दिखाई दिया, MATCH :

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

परिणाम प्रारूप पिछले अनुरोध के समान ही होगा। इस बारे में सोचें कि इसे और अधिक "संबंधपरक" बनाने के लिए क्या हटाने की आवश्यकता है, जैसे कि पहली क्वेरी में।

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

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

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

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

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

ग्राफ़ मॉडल पर आधारित मल्टी-मॉडल DBMS?

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

ग्राफ़ मॉडल के शीर्ष पर एक रिलेशनल मॉडल को कैसे लागू किया जाए, इस सवाल पर बाद के गठन के दौरान भी विचार किया गया था। कैसे говорил, उदाहरण के लिए, डेविड मैकगवर्न:

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

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

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

थोड़ा विज्ञापन

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

आशा है कि मैं निम्नलिखित लेखों में से एक में वर्णन करूंगा कि नाइट्रोसबेस में मॉडल मिलान कैसा दिखता है।

निष्कर्ष

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

क्या हम पारंपरिक मॉडल या किसी प्रकार के "हाइब्रिड" मॉडल का समर्थन करने के बारे में बात कर रहे हैं?
क्या मॉडल "समान" हैं, या उनमें से एक दूसरे का विषय है?
क्या मॉडल एक-दूसरे के प्रति "उदासीन" हैं? क्या एक मॉडल में लिखा गया डेटा दूसरे में पढ़ा जा सकता है या ओवरराइट भी किया जा सकता है?

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

केवल पंजीकृत उपयोगकर्ता ही सर्वेक्षण में भाग ले सकते हैं। साइन इन करेंकृपया।

क्या आप मल्टी-मॉडल DBMS का उपयोग करते हैं?

हम इसका उपयोग नहीं करते हैं, हम सब कुछ एक DBMS और एक मॉडल में संग्रहीत करते हैं
हम पारंपरिक DBMS की मल्टी-मॉडल क्षमताओं का उपयोग करते हैं
हम बहुभाषी दृढ़ता का अभ्यास करते हैं
हम नए मल्टी-मॉडल DBMS (अरंगो, ओरिएंट, कॉसमॉसडीबी) का उपयोग करते हैं

19 उपयोगकर्ताओं ने मतदान किया। 4 उपयोगकर्ता अनुपस्थित रहे।

स्रोत: www.habr.com

क्या मल्टी-मॉडल डीबीएमएस आधुनिक सूचना प्रणाली का आधार हैं?