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

यदि तपाईंले तर्कमा कुनै त्रुटि फेला पार्नुभएन भने, त्यसपछि पढ्नुहोस्।

सामग्रीहरू

Polyglot दृढता
बहु-मोडेल
रिलेशनल मोडेलमा आधारित बहु-मोडेल DBMS
     MS SQL सर्भरमा कागजात मोडेल
     MS SQL सर्भरमा ग्राफ मोडेल
कागजात मोडेलमा आधारित बहु-मोडल DBMS
     MarkLogic मा रिलेशनल मोडेल
     MarkLogic मा ग्राफ मोडेल
बहु-मोडेल DBMS "मुख्य मोडेल बिना"
     ArangoDB
     ओरिएन्टडीबी
     Azure CosmosDB
ग्राफ मोडेलमा आधारित बहु-मोडेल DBMS?
निष्कर्षमा
पोल

Polyglot दृढता

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

फाउलरसँग ई-वाणिज्यको क्षेत्रमा पूर्ण-विशेष र उच्च-लोड अनुप्रयोगमा डेटा भण्डारण व्यवस्थित गर्ने निम्न उदाहरण पनि छ।

यो उदाहरण, निस्सन्देह, केही हदसम्म अतिरंजित छ, तर सम्बन्धित उद्देश्यका लागि एक वा अर्को DBMS छनौट गर्ने पक्षमा केही विचारहरू फेला पार्न सकिन्छ, उदाहरणका लागि, यहाँ.

यस्तो चिडियाखानामा सेवक हुन सजिलो छैन भन्ने स्पष्ट छ।

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

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

DBMS निर्माताबाट इजाजतपत्र र प्राविधिक सहयोगको लागतमा बहु वृद्धि।
ओभर स्टाफिङ र म्याद थपियो।
डेटा असंगतिको कारण प्रत्यक्ष वित्तीय घाटा वा दण्ड।

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

बहु-मोडेल

"बहुभिन्न भण्डारण" शब्द 2011 मा प्रयोगमा आयो। दृष्टिकोणको समस्याहरूको जागरूकता र समाधानको खोजीमा धेरै वर्ष लाग्यो, र 2015 सम्म, गार्टनर विश्लेषकहरूको मुखबाट, जवाफ तयार भयो:

बाट "NoSQL DBMSs को लागि बजार गाइड - 2015"
DBMSs को भविष्य, तिनीहरूको वास्तुकला र तिनीहरूलाई प्रयोग गर्ने तरिका बहु-मोडेल हो।
बाट "ODBMS - 2016 को लागि जादुई क्वाड्रन्ट"
अग्रणी परिचालन DBMSs ले एकल प्लेटफर्मको भागको रूपमा बहुविध मोडेलहरू - रिलेशनल र गैर-रिलेशनल - प्रस्ताव गर्दछ।

यस्तो देखिन्छ कि यस पटक गार्टनर विश्लेषकहरू तिनीहरूको भविष्यवाणीमा सही थिए। यदि तपाइँ पृष्ठमा जानुहुन्छ भने मुख्य मूल्याङ्कन DB-इन्जिनहरूमा DBMS, तपाईंले त्यो देख्न सक्नुहुन्छоयसका अधिकांश नेताहरूले आफूलाई विशेष गरी बहु-मोडेल DBMSs को रूपमा राख्छन्। उही कुनै पनि निजी मूल्याङ्कन पृष्ठमा देख्न सकिन्छ।

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

DBMS	प्रारम्भिक मोडेल	अतिरिक्त मोडेलहरू
बजेट	सम्बन्धगत	ग्राफ, कागजात
एमएस एसक्यूएल	सम्बन्धगत	ग्राफ, कागजात
PostgreSQL	सम्बन्धगत	ग्राफ*, कागजात
MarkLogic	वृत्तचित्र	ग्राफ, सापेक्ष
MongoDB	वृत्तचित्र	कुञ्जी-मान, ग्राफ*
डाटास्ट्याक्स	चौडा स्तम्भ	वृत्तचित्र, ग्राफ
Redis	कुञ्जी-मान	वृत्तचित्र, ग्राफ*
ArangoDB	-	ग्राफ, कागजात
ओरिएन्टडीबी	-	ग्राफ, कागजात, सापेक्ष
Azure CosmosDB	-	ग्राफ, कागजात, सापेक्ष

टेबुलमा नोटहरू

रिजर्भेसनहरू आवश्यक पर्ने तालिकामा तारा चिन्हहरू चिन्ह लगाउँछन्:

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

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

रिलेशनल मोडेलमा आधारित बहु-मोडेल DBMS

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

लेखक, तथापि, Microsoft SQL सर्भरमा बहु-मोडलिंगको कार्यान्वयनलाई प्राथमिकता दिन्छन्, जसको उदाहरणमा कागजात र ग्राफ मोडेलहरूको लागि RDBMS समर्थन वर्णन गरिनेछ।

MS SQL सर्भरमा कागजात मोडेल

MS SQL सर्भरले कागजात मोडेलको लागि समर्थन कसरी लागू गर्छ भन्ने बारे Habré मा दुईवटा उत्कृष्ट लेखहरू छन्; म आफैलाई संक्षिप्त रिटेलिङ र कमेन्टरीमा सीमित गर्नेछु:

MS SQL सर्भरमा कागजात मोडेललाई समर्थन गर्ने तरिका रिलेशनल DBMSs को लागि एकदम सामान्य छ: JSON कागजातहरू साधारण पाठ क्षेत्रहरूमा भण्डारण गर्न प्रस्ताव गरिएको छ। कागजात मोडेलको लागि समर्थन यो JSON पार्स गर्न विशेष अपरेटरहरू प्रदान गर्नु हो:

JSON_VALUE स्केलर विशेषता मानहरू निकाल्न,
JSON_QUERY उप-कागजातहरू निकाल्न।

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

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

थप रूपमा, MS SQL सर्भरले अपरेटर प्रयोग गरेर तालिकाहरूको सामग्रीबाट JSON कागजात सहज रूपमा निर्माण गर्ने क्षमता प्रदान गर्दछ। FOR JSON PATH - एक सम्भावना, एक निश्चित अर्थमा, अघिल्लोको विपरीत, परम्परागत भण्डारण। यो स्पष्ट छ कि RDBMS जतिसुकै छिटो होस्, यो दृष्टिकोण कागजात DBMSs को विचारधाराको विरोधाभासपूर्ण छ, जसले अनिवार्य रूपमा लोकप्रिय प्रश्नहरूको तयार जवाफहरू भण्डारण गर्दछ, र विकासको सहजताका समस्याहरू मात्र समाधान गर्न सक्छ, तर गति होइन।

अन्तमा, MS SQL सर्भरले तपाईंलाई कागजात निर्माणको विपरित समस्या समाधान गर्न अनुमति दिन्छ: तपाईंले JSON लाई तालिकाहरूमा विघटन गर्न सक्नुहुन्छ OPENJSON। यदि कागजात पूर्ण रूपमा समतल छैन भने, तपाईंले प्रयोग गर्न आवश्यक छ CROSS APPLY.

MS SQL सर्भरमा ग्राफ मोडेल

ग्राफ (LPG) मोडेलको लागि समर्थन पनि Microsoft SQL Server मा पूर्ण रूपमा लागू गरिएको छ अनुमान गर्न सकिने: यो नोडहरू भण्डारण गर्न र ग्राफ किनारहरू भण्डारण गर्न विशेष तालिकाहरू प्रयोग गर्न प्रस्ताव गरिएको छ। त्यस्ता तालिकाहरू अभिव्यक्ति प्रयोग गरेर सिर्जना गरिन्छ 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; एउटै कारणले, डेटा सम्मिलित गर्नका लागि प्रश्नहरू यहाँ देखाइएको छैन किनभने तिनीहरू अनावश्यक रूपमा बोझिल छन्)।

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

कागजात मोडेलमा आधारित बहु-मोडल DBMS

यस खण्डमा, म ती मध्ये सबैभन्दा लोकप्रिय नभएको, MongoDB (जस्तै भनिएको थियो, यसमा केवल सशर्त ग्राफ अपरेटरहरू छन्। $lookup и $graphLookup, शार्डेड सङ्कलनहरूमा काम गरिरहेको छैन), तर अझ परिपक्व र "उद्यम" DBMS को उदाहरण प्रयोग गर्दै MarkLogic.

त्यसोभए, संग्रहमा निम्न प्रकारका XML कागजातहरूको सेट समावेश गरौं (MarkLogic ले तपाईंलाई JSON कागजातहरू भण्डारण गर्न पनि अनुमति दिन्छ):

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

MarkLogic मा रिलेशनल मोडेल

कागजातहरूको सङ्कलनको सम्बन्धगत दृश्य प्रयोग गरेर सिर्जना गर्न सकिन्छ प्रदर्शन टेम्प्लेट (तत्वहरूको सामग्री 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"

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

MarkLogic मा ग्राफ मोडेल

ग्राफ (RDF) मोडेलको लागि समर्थनको साथ, सबै कुरा उस्तै छ। साथमा फेरि प्रदर्शन टेम्प्लेट तपाईंले माथिको उदाहरणबाट कागजातहरूको सङ्ग्रहको RDF प्रतिनिधित्व सिर्जना गर्न सक्नुहुन्छ:

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

तपाईंले SPARQL क्वेरीको साथ परिणामी RDF ग्राफलाई सम्बोधन गर्न सक्नुहुन्छ:

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

रिलेशनल एकको विपरीत, MarkLogic ले ग्राफ मोडेललाई दुई अन्य तरिकामा समर्थन गर्दछ:

एक DBMS RDF डाटाको पूर्ण-फुलिएको छुट्टै भण्डारण हुन सक्छ (यसमा ट्रिपलेटहरू भनिनेछ। व्यवस्थित माथि उल्लेखित को विपरीत झिकिएको).
विशेष क्रमबद्धतामा RDF लाई केवल XML वा JSON कागजातहरूमा सम्मिलित गर्न सकिन्छ (र त्यसपछि ट्रिपलेटहरू बोलाइनेछ। अप्रबन्धित)। यो सम्भवतः संयन्त्रको विकल्प हो idref र अन्य।

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

बहु-मोडेल DBMS "मुख्य मोडेल बिना"

त्यहाँ बजारमा DBMS हरू पनि छन् जसले आफूलाई प्रारम्भिक रूपमा बहु-मोडलको रूपमा राख्छन्, कुनै पनि वंशानुगत मुख्य मोडेल बिना। यी समावेश छन् ArangoDB, ओरिएन्टडीबी (२०१८ देखि विकास कम्पनी SAP को हो) र CosmosDB (Microsoft Azure क्लाउड प्लेटफर्मको भागको रूपमा सेवा)।

वास्तवमा, त्यहाँ ArangoDB र OrientDB मा "कोर" मोडेलहरू छन्। दुबै अवस्थामा, यी तिनीहरूको आफ्नै डेटा मोडेलहरू हुन्, जुन कागजातको सामान्यीकरणहरू हुन्। सामान्यीकरणहरू मुख्यतया ग्राफ र रिलेशनल प्रकृतिका प्रश्नहरू प्रदर्शन गर्ने क्षमतालाई सहज बनाउनका लागि हुन्।

यी मोडेलहरू निर्दिष्ट DBMS मा प्रयोगको लागि मात्र उपलब्ध छन्; तिनीहरूका आफ्नै क्वेरी भाषाहरू तिनीहरूसँग काम गर्न डिजाइन गरिएका छन्। निस्सन्देह, त्यस्ता मोडेलहरू र DBMS हरू आशाजनक छन्, तर मानक मोडेलहरू र भाषाहरूसँग अनुकूलताको अभावले यी DBMS हरू विरासत प्रणालीहरूमा प्रयोग गर्न असम्भव बनाउँदछ — त्यहाँ पहिले नै प्रयोग गरिएको DBMS हरू प्रतिस्थापन गर्न।

Habré मा ArangoDB र OrientDB को बारेमा पहिले नै एक अद्भुत लेख थियो: NoSQL डाटाबेसहरूमा सामेल हुनुहोस्.

ArangoDB

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 मा कागजात मोडेलको शीर्षमा ग्राफ मोडेल लागू गर्ने आधार हो मौका कागजात क्षेत्रहरू, अधिक वा कम मानक स्केलर मानहरूका अतिरिक्त, पनि मानहरू छन् जस्तै 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"
    }
  ]

हामी देख्न सक्छौं, ठाडोहरूले आगमन र बहिर्गमन किनारहरू बारे जानकारी पनि भण्डारण गर्दछ। मा प्रयोग गर्दै कागजात API ले सन्दर्भात्मक अखण्डता आफैंलाई निगरानी गर्नुपर्दछ, र ग्राफ API ले यो काम लिन्छ। तर हेरौं OrientDB को पहुँच "शुद्ध" क्वेरी भाषाहरूमा कस्तो देखिन्छ जुन प्रोग्रामिङ भाषाहरूमा एकीकृत छैन।

प्रश्न र परिणामहरू

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

नतिजाको ढाँचा अघिल्लो अनुरोधमा जस्तै हुनेछ। यसलाई थप "सम्बन्धित" बनाउनको लागि के हटाउन आवश्यक छ भन्ने बारे सोच्नुहोस्, जस्तै पहिलो प्रश्नमा।

Azure CosmosDB

थोरै हदसम्म, ArangoDB र OrientDB को बारेमा माथि भनिएको कुरा Azure CosmosDB मा लागू हुन्छ। CosmosDB ले निम्न डेटा पहुँच API हरू प्रदान गर्दछ: SQL, MongoDB, Gremlin र Cassandra।

SQL API र MongoDB API कागजात मोडेलमा डाटा पहुँच गर्न प्रयोग गरिन्छ। Gremlin API र Cassandra API - क्रमशः ग्राफ र स्तम्भ ढाँचाहरूमा डेटा पहुँच गर्नका लागि। सबै मोडेलहरूमा डाटा CosmosDB आन्तरिक मोडेल ढाँचामा बचत गरिएको छ: ARS ("एटम-रेकर्ड-अनुक्रम"), जुन कागजातको नजिक पनि छ।

तर प्रयोगकर्ताले रोजेको डाटा मोडेल र प्रयोग गरिएको एपीआई सेवामा खाता सिर्जना गर्दा निश्चित हुन्छ। एउटा मोडेलमा लोड गरिएको डाटालाई अर्को मोडेलको ढाँचामा पहुँच गर्न सम्भव छैन, जस्तो कि यो जस्तै केहि द्वारा चित्रण गरिएको छ:

यसैले, Azure CosmosDB मा बहु-मोडेल आज एक निर्माताबाट विभिन्न मोडेलहरूलाई समर्थन गर्ने धेरै डाटाबेसहरू प्रयोग गर्ने क्षमता मात्र हो, जसले बहु-भ्यारिएन्ट भण्डारणका सबै समस्याहरू समाधान गर्दैन।

ग्राफ मोडेलमा आधारित बहु-मोडेल DBMS?

उल्लेखनीय तथ्य यो हो कि बजारमा कुनै पनि बहु-मोडेल DBMS हरू छैनन् जुन ग्राफ मोडेलमा आधारित छन् (एकै साथ दुई ग्राफ मोडेलहरूको लागि बहु-मोडेल समर्थन बाहेक: RDF र LPG; यसलाई हेर्नुहोस्। अघिल्लो प्रकाशन)। सबैभन्दा ठूलो कठिनाइहरू ग्राफ मोडेलको शीर्षमा कागजात मोडेलको कार्यान्वयनको कारणले गर्दा, एक सापेक्षिक भन्दा।

ग्राफ मोडेलको शीर्षमा रिलेसनल मोडेल कसरी लागू गर्ने भन्ने प्रश्न पछिको गठनको समयमा पनि विचार गरिएको थियो। कसरी बोलेउदाहरणका लागि डेभिड McGovern:

ग्राफ दृष्टिकोणमा कुनै पनि अन्तर्निहित छैन जसले ग्राफ डाटाबेसमा तह (जस्तै, उपयुक्त अनुक्रमणिकाद्वारा) सिर्जना गर्नबाट रोक्छ जसले (१) सामान्य कुञ्जी मान जोडीहरूबाट ट्युपलहरूको पुन: प्राप्ति र (२) समूहीकरणको साथ एक सम्बन्धात्मक दृश्य सक्षम गर्दछ। सम्बन्ध प्रकार द्वारा tuples।

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

JSON एर्रेका तत्वहरूलाई क्रमबद्ध मानिन्छ, तर ग्राफको किनाराको शीर्षबाट निस्कनेहरू होइनन्;
कागजात मोडेलमा डाटा सामान्यतया असमानीकृत हुन्छ; तपाईं अझै पनि एउटै इम्बेडेड कागजातको धेरै प्रतिलिपिहरू भण्डारण गर्न चाहनुहुन्न, र उप-कागजातहरूमा सामान्यतया पहिचानकर्ताहरू हुँदैनन्;
अर्कोतर्फ, कागजात DBMSs को विचारधारा यो हो कि कागजातहरू तयार-बनाइएका "समग्र" हुन् जुन प्रत्येक पटक नयाँ निर्माण गर्न आवश्यक छैन। समाप्त कागजातसँग सम्बन्धित सबग्राफ द्रुत रूपमा प्राप्त गर्ने क्षमताको साथ ग्राफ मोडेल प्रदान गर्न आवश्यक छ।

एक सानो विज्ञापन

लेखको लेखक NitrosBase DBMS को विकाससँग सम्बन्धित छ, जसको आन्तरिक मोडेल ग्राफ हो, र बाह्य मोडेल - सम्बन्ध र कागजात - यसको प्रतिनिधित्व हो। सबै मोडेलहरू बराबर छन्: लगभग कुनै पनि डाटा तिनीहरूमध्ये कुनै पनि क्वेरी भाषा प्रयोग गरेर उपलब्ध छ जुन यो स्वाभाविक हो। यसबाहेक, कुनै पनि दृश्यमा, डाटा परिवर्तन गर्न सकिन्छ। परिवर्तनहरू आन्तरिक मोडेलमा प्रतिबिम्बित हुनेछन् र, तदनुसार, अन्य दृश्यहरूमा।

म आशा गर्दछु कि निम्न लेखहरू मध्ये एकमा NitrosBase मा कस्तो मोडेल मिल्दोजुल्दो देखिन्छ वर्णन गर्नेछु।

निष्कर्षमा

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

के हामी परम्परागत मोडेल वा कुनै प्रकारको "हाइब्रिड" मोडेललाई समर्थन गर्ने बारे कुरा गर्दैछौं?
के मोडेलहरू "समान" छन्, वा तिनीहरूमध्ये एउटा अरूको विषय हो?
के मोडेलहरू एकअर्काप्रति "उदासीन" छन्? के एक मोडेलमा लेखिएको डाटा अर्कोमा पढ्न सकिन्छ वा ओभरराइट गर्न सकिन्छ?

मलाई लाग्छ कि बहु-मोडेल DBMS को सान्दर्भिकता को बारे मा प्रश्न पहिले नै सकारात्मक जवाफ दिन सकिन्छ, तर चाखलाग्दो प्रश्न छ कि कुन प्रकार को निकट भविष्य मा मांग मा अधिक हुनेछ। यस्तो देखिन्छ कि बहु-मोडेल DBMSs जसले परम्परागत मोडेलहरूलाई समर्थन गर्दछ, मुख्य रूपमा सापेक्ष, बढी मागमा हुनेछ। बहु-मोडेल DBMSs को लोकप्रियता, नयाँ मोडेलहरू प्रदान गर्दै जुन विभिन्न परम्परागतका फाइदाहरू संयोजन गर्दछ, अझ टाढाको भविष्यको कुरा हो।

दर्ता भएका प्रयोगकर्ताहरूले मात्र सर्वेक्षणमा भाग लिन सक्छन्। साइन इन गर्नुहोस्कृपया