आधुनिक माहिती प्रणाली खूप जटिल आहेत. सर्वात कमी नाही, त्यांची जटिलता त्यांच्यामध्ये प्रक्रिया केलेल्या डेटाच्या जटिलतेमुळे आहे. डेटाची जटिलता अनेकदा वापरलेल्या डेटा मॉडेलच्या विविधतेमध्ये असते. म्हणून, उदाहरणार्थ, जेव्हा डेटा "मोठा" होतो, तेव्हा समस्याप्रधान वैशिष्ट्यांपैकी एक म्हणजे केवळ त्याची मात्रा ("व्हॉल्यूम") नाही तर त्याची विविधता ("विविधता") देखील असते.

तुम्हाला अद्याप तर्कामध्ये त्रुटी आढळली नसल्यास, वाचा.

सामग्री

पॉलीग्लॉट चिकाटी
मल्टी मॉडेल
रिलेशनल मॉडेलवर आधारित मल्टी-मॉडेल DBMS
     एमएस एसक्यूएल सर्व्हरमधील दस्तऐवज मॉडेल
     MS SQL सर्व्हरमधील आलेख मॉडेल
दस्तऐवज मॉडेलवर आधारित मल्टी-मॉडेल DBMS
     MarkLogic मध्ये रिलेशनल मॉडेल
     MarkLogic मध्ये आलेख मॉडेल
मल्टी-मॉडेल डीबीएमएस "मुख्य मॉडेलशिवाय"
     अरंगोडीबी
     ओरिएंटडीबी
     अझर कॉसमॉसडीबी
आलेख मॉडेलवर आधारित मल्टी-मॉडेल डीबीएमएस?
निष्कर्ष
सर्वेक्षण

पॉलीग्लॉट चिकाटी

उपरोक्त वस्तुस्थितीकडे नेत आहे की कधीकधी एका सिस्टमच्या चौकटीत डेटा संग्रहित करण्यासाठी आणि त्यावर प्रक्रिया करण्याच्या विविध समस्यांचे निराकरण करण्यासाठी अनेक भिन्न डीबीएमएस वापरणे आवश्यक असते, ज्यापैकी प्रत्येक स्वतःच्या डेटा मॉडेलला समर्थन देतो. एम. फॉलरच्या हलक्या हाताने, लेखक अनेक प्रसिद्ध पुस्तके आणि एक सह-लेखक चपळ जाहीरनामा, या स्थितीला म्हणतात मल्टी-व्हेरियंट स्टोरेज ("पॉलीग्लॉट पर्सिस्टन्स").

ई-कॉमर्स क्षेत्रात पूर्ण-वैशिष्ट्यीकृत आणि उच्च-लोड ऍप्लिकेशनमध्ये डेटा स्टोरेज आयोजित करण्याचे खालील उदाहरण फॉलरकडे आहे.

हे उदाहरण, अर्थातच, काहीसे अतिशयोक्तीपूर्ण आहे, परंतु संबंधित हेतूसाठी एक किंवा दुसरा DBMS निवडण्याच्या बाजूने काही विचार आढळू शकतात, उदाहरणार्थ, येथे.

हे स्पष्ट आहे की अशा प्राणीसंग्रहालयात सेवक असणे सोपे नाही.

डेटा स्टोरेज करत असलेल्या कोडचे प्रमाण वापरलेल्या DBMS च्या संख्येच्या प्रमाणात वाढते; कोड सिंक्रोनाइझिंग डेटाचे प्रमाण या संख्येच्या वर्गाच्या प्रमाणात नसल्यास चांगले आहे.
वापरल्या जाणार्‍या DBMS च्या संख्येच्या गुणाकार म्हणून, वापरलेल्या प्रत्येक DBMS ची एंटरप्राइझ वैशिष्ट्ये (स्केलेबिलिटी, फॉल्ट टॉलरन्स, उच्च उपलब्धता) प्रदान करण्याचा खर्च वाढतो.
संपूर्णपणे स्टोरेज उपप्रणालीची एंटरप्राइझ वैशिष्ट्ये सुनिश्चित करणे अशक्य आहे - विशेषत: व्यवहार.

प्राणीसंग्रहालय संचालकाच्या दृष्टिकोनातून, सर्वकाही असे दिसते:

DBMS निर्मात्याकडून परवाने आणि तांत्रिक समर्थनाच्या किंमतीमध्ये एकापेक्षा जास्त वाढ.
ओव्हरस्टाफ आणि वाढलेली मुदत.
डेटाच्या विसंगतीमुळे थेट आर्थिक नुकसान किंवा दंड.

सिस्टमच्या एकूण मालकी खर्चामध्ये (TCO) लक्षणीय वाढ झाली आहे. "मल्टिपल स्टोरेज पर्याय" च्या परिस्थितीतून बाहेर पडण्याचा काही मार्ग आहे का?

मल्टी मॉडेल

"मल्टीव्हेरिएट स्टोरेज" हा शब्द 2011 मध्ये वापरात आला. दृष्टिकोनाच्या समस्यांबद्दल जागरूकता आणि उपाय शोधण्यासाठी अनेक वर्षे लागली आणि 2015 पर्यंत, गार्टनर विश्लेषकांच्या तोंडून, उत्तर तयार केले गेले:

पासून "NoSQL DBMSs साठी बाजार मार्गदर्शक - 2015"

DBMS चे भविष्य, त्यांची वास्तुकला आणि त्यांचा वापर करण्याचे मार्ग बहु-मॉडेल आहेत.
पासून "ODBMS साठी मॅजिक क्वाड्रंट - 2016"

अग्रगण्य ऑपरेशनल DBMSs एकाच प्लॅटफॉर्मचा भाग म्हणून अनेक मॉडेल ऑफर करतील—रिलेशनल आणि नॉन-रिलेशनल—.

असे दिसते की यावेळी गार्टनर विश्लेषकांचा अंदाज बरोबर होता. सह पृष्ठावर गेलात तर मुख्य रेटिंग डीबी-इंजिनवर डीबीएमएस, तुम्ही ते पाहू शकताоत्याचे बहुतेक नेते स्वतःला विशेषतः मल्टी-मॉडेल डीबीएमएस म्हणून स्थान देतात. कोणत्याही खाजगी रेटिंगसह पृष्ठावर तेच पाहिले जाऊ शकते.

खालील सारणी DBMS दर्शविते - प्रत्येक खाजगी रेटिंगमधील नेते, जे बहु-मॉडेल असल्याचा दावा करतात. प्रत्येक DBMS साठी, मूळ समर्थित मॉडेल (जे एकेकाळी एकमेव होते) आणि त्यासोबत सध्या समर्थित मॉडेल्स सूचित केले आहेत. डीबीएमएस देखील सूचीबद्ध आहेत जे स्वतःला "मूळत: मल्टी-मॉडेल" म्हणून स्थान देतात आणि निर्मात्यांनुसार, कोणतेही प्रारंभिक वारसा मिळालेले मॉडेल नाहीत.

DBMS	प्रारंभिक मॉडेल	अतिरिक्त मॉडेल
ओरॅकल	संबंधीत	आलेख, दस्तऐवज
एमएस एसक्यूएल	संबंधीत	आलेख, दस्तऐवज
पोस्टग्रे एसक्यूएल	संबंधीत	आलेख*, दस्तऐवज
मार्कलॉजिक	माहितीपट	आलेख, संबंधात्मक
MongoDB	माहितीपट	मुख्य मूल्य, आलेख*
डेटास्टॅक्स	रुंद-स्तंभ	माहितीपट, आलेख
Redis	की-मूल्य	माहितीपट, आलेख*
अरंगोडीबी	-	आलेख, दस्तऐवज
ओरिएंटडीबी	-	आलेख, दस्तऐवज, संबंधात्मक
अझर कॉसमॉसडीबी	-	आलेख, दस्तऐवज, संबंधात्मक

टेबलावर नोट्स

टेबलमधील तारका चिन्हांकित विधाने ज्यांना आरक्षण आवश्यक आहे:

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

पुढे, प्रत्येक वर्गासाठी, या वर्गातून DBMS मध्ये अनेक मॉडेल्ससाठी समर्थन कसे लागू केले जाते ते आम्ही दाखवू. आम्ही रिलेशनल, डॉक्युमेंट आणि आलेख मॉडेल्सना सर्वात महत्वाचे मानू आणि विशिष्ट DBMS ची उदाहरणे वापरून "गहाळ असलेले" कसे अंमलात आणले जातात हे दाखवू.

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

आघाडीचे DBMS सध्या रिलेशनल आहेत; जर RDBMS ने मल्टी-मॉडेलिंगच्या दिशेने हालचाल दाखवली नाही तर गार्टनरचा अंदाज खरा मानता येणार नाही. आणि ते दाखवून देतात. आता बहु-मॉडेल डीबीएमएस हे स्विस चाकूसारखे आहे, जे काही चांगले करू शकत नाही, थेट लॅरी एलिसनकडे निर्देशित केले जाऊ शकते.

लेखक, तथापि, Microsoft SQL सर्व्हरमध्ये मल्टी-मॉडेलिंगच्या अंमलबजावणीला प्राधान्य देतात, ज्याच्या उदाहरणावर दस्तऐवज आणि आलेख मॉडेलसाठी RDBMS समर्थन वर्णन केले जाईल.

एमएस एसक्यूएल सर्व्हरमधील दस्तऐवज मॉडेल

एमएस एसक्यूएल सर्व्हर दस्तऐवज मॉडेलसाठी समर्थन कसे लागू करते याबद्दल हॅब्रेवर दोन उत्कृष्ट लेख आधीच आले आहेत; मी स्वत: ला थोडक्यात रीटेलिंग आणि समालोचनापर्यंत मर्यादित ठेवतो:

MS SQL सर्व्हरमधील दस्तऐवज मॉडेलला समर्थन देण्याचा मार्ग रिलेशनल DBMS साठी अगदी वैशिष्ट्यपूर्ण आहे: JSON दस्तऐवज सामान्य मजकूर फील्डमध्ये संग्रहित करण्याचा प्रस्ताव आहे. दस्तऐवज मॉडेलसाठी समर्थन हे JSON पार्स करण्यासाठी विशेष ऑपरेटर प्रदान करणे आहे:

JSON_VALUE स्केलर विशेषता मूल्ये काढण्यासाठी,
JSON_QUERY उप-दस्तऐवज काढण्यासाठी.

दोन्ही ऑपरेटर्सचा दुसरा युक्तिवाद JSONPath सारखी वाक्यरचना मध्ये एक अभिव्यक्ती आहे.

अमूर्तपणे, आम्ही असे म्हणू शकतो की अशा प्रकारे संग्रहित केलेले दस्तऐवज टपल्सच्या विपरीत, रिलेशनल डीबीएमएसमध्ये "प्रथम-श्रेणी संस्था" नाहीत. विशेषतः, MS SQL सर्व्हरमध्ये सध्या JSON दस्तऐवजांच्या फील्डवर कोणतेही अनुक्रमणिका नाहीत, ज्यामुळे या फील्डची मूल्ये वापरून सारण्यांमध्ये सामील होणे कठीण होते आणि या मूल्यांचा वापर करून दस्तऐवज देखील निवडणे कठीण होते. तथापि, अशा फील्डसाठी गणना केलेला स्तंभ आणि त्यावर निर्देशांक तयार करणे शक्य आहे.

याव्यतिरिक्त, एमएस एसक्यूएल सर्व्हर ऑपरेटर वापरून टेबलच्या सामग्रीमधून JSON दस्तऐवज सोयीस्करपणे तयार करण्याची क्षमता प्रदान करतो FOR JSON PATH - एक शक्यता, एका विशिष्ट अर्थाने, मागील एकाच्या विरुद्ध, पारंपारिक स्टोरेज. हे स्पष्ट आहे की RDBMS कितीही वेगवान असला तरीही, हा दृष्टीकोन दस्तऐवज DBMSs च्या विचारसरणीच्या विरोधाभास आहे, जे मूलत: लोकप्रिय प्रश्नांची तयार उत्तरे संग्रहित करते आणि केवळ विकासाच्या सुलभतेच्या समस्या सोडवू शकते, परंतु गती नाही.

शेवटी, एमएस एसक्यूएल सर्व्हर तुम्हाला दस्तऐवज बांधकामाच्या विरुद्ध समस्या सोडवण्याची परवानगी देतो: तुम्ही जेएसओएनला टेबलमध्ये विघटित करू शकता OPENJSON. दस्तऐवज पूर्णपणे सपाट नसल्यास, आपल्याला वापरण्याची आवश्यकता असेल CROSS APPLY.

MS SQL सर्व्हरमधील आलेख मॉडेल

ग्राफ (LPG) मॉडेलसाठी समर्थन देखील 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';

शिवाय, अशा सारण्यांसह काम करताना हे आलेख नमुने न वापरणे खूप कठीण आहे, कारण समान समस्यांचे निराकरण करण्यासाठी सामान्य एसक्यूएल क्वेरींमध्ये सिस्टम "ग्राफ" नोड अभिज्ञापक मिळविण्यासाठी अतिरिक्त प्रयत्न करणे आवश्यक आहे ($node_id, $from_id, $to_id; त्याच कारणास्तव, डेटा घालण्यासाठीच्या क्वेरी येथे दाखवल्या जात नाहीत कारण त्या अनावश्यकपणे अवजड आहेत).

एमएस एसक्यूएल सर्व्हरमधील दस्तऐवज आणि आलेख मॉडेल्सच्या अंमलबजावणीच्या वर्णनाचा सारांश देण्यासाठी, मी लक्षात घेतो की एका मॉडेलच्या दुसर्‍या मॉडेलची अशी अंमलबजावणी प्रामुख्याने भाषा डिझाइनच्या दृष्टिकोनातून यशस्वी वाटत नाही. एका भाषेचा दुसर्‍या भाषेसह विस्तार करणे आवश्यक आहे, भाषा पूर्णपणे "ऑर्थोगोनल" नसतात, सुसंगतता नियम बरेच विचित्र असू शकतात.

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

या विभागात, मी सर्वात लोकप्रिय नसलेल्या मोंगोडीबीचे उदाहरण वापरून दस्तऐवज डीबीएमएसमध्ये मल्टी-मॉडेलची अंमलबजावणी स्पष्ट करू इच्छितो (म्हटल्याप्रमाणे, त्यात फक्त सशर्त आलेख ऑपरेटर आहेत $lookup и $graphLookup. मार्कलॉजिक.

म्हणून, संग्रहामध्ये खालील प्रकारच्या XML दस्तऐवजांचा संच असू द्या (मार्कलॉजिक तुम्हाला 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 मध्ये आलेख मॉडेल

ग्राफ (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>

तुम्ही परिणामी RDF आलेखाला SPARQL क्वेरीसह संबोधित करू शकता:

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

रिलेशनलच्या विपरीत, मार्कलॉजिक ग्राफ मॉडेलला इतर दोन प्रकारे समर्थन देते:

डीबीएमएस हा आरडीएफ डेटाचा पूर्ण वाढ झालेला स्वतंत्र स्टोरेज असू शकतो (त्यातील तिप्पट म्हणतात. व्यवस्थापित वर वर्णन केलेल्या विरूद्ध काढला).
विशेष क्रमवारीत RDF फक्त XML किंवा JSON दस्तऐवजांमध्ये घातला जाऊ शकतो (आणि नंतर तिप्पट म्हटले जाईल अव्यवस्थापित). हे बहुधा यंत्रणांना पर्याय आहे idref आणि इतर.

मार्कलॉजिकमध्ये "खरोखर" गोष्टी कशा कार्य करतात याची चांगली कल्पना दिली आहे ऑप्टिकल API, या अर्थाने, ते निम्न-स्तरीय आहे, जरी त्याचा उद्देश उलट आहे - वापरलेल्या डेटा मॉडेलमधून अमूर्त करण्याचा प्रयत्न करणे, भिन्न मॉडेलमधील डेटासह सुसंगत कार्य सुनिश्चित करणे, व्यवहार इ.

मल्टी-मॉडेल डीबीएमएस "मुख्य मॉडेलशिवाय"

बाजारात असे डीबीएमएस देखील आहेत जे स्वतःला सुरवातीला मल्टी-मॉडेल म्हणून ठेवतात, कोणत्याही वारशाने मिळालेल्या मुख्य मॉडेलशिवाय. यात समाविष्ट अरंगोडीबी, ओरिएंटडीबी (2018 पासून विकास कंपनी SAP च्या मालकीची आहे) आणि कॉसमॉसडीबी (Microsoft Azure क्लाउड प्लॅटफॉर्मचा भाग म्हणून सेवा).

खरं तर, ArangoDB आणि OrientDB मध्ये "कोर" मॉडेल्स आहेत. दोन्ही प्रकरणांमध्ये, हे त्यांचे स्वतःचे डेटा मॉडेल आहेत, जे एक दस्तऐवजाचे सामान्यीकरण आहेत. सामान्यीकरण हे प्रामुख्याने आलेख आणि रिलेशनल निसर्गाच्या प्रश्नांची क्षमता सुलभ करण्यासाठी आहेत.

ही मॉडेल्स निर्दिष्ट DBMS मध्ये वापरण्यासाठी उपलब्ध आहेत; त्यांच्या स्वतःच्या क्वेरी भाषा त्यांच्यासह कार्य करण्यासाठी डिझाइन केल्या आहेत. अर्थात, अशी मॉडेल्स आणि डीबीएमएस आशादायक आहेत, परंतु मानक मॉडेल्स आणि भाषांशी सुसंगततेच्या अभावामुळे या डीबीएमएसचा वापर लेगेसी सिस्टीममध्ये करणे अशक्य होते-आधीपासून वापरलेल्या डीबीएमएस पुनर्स्थित करण्यासाठी.

Habré वर ArangoDB आणि OrientDB बद्दल आधीच एक अद्भुत लेख होता: NoSQL डेटाबेसमध्ये सामील व्हा.

अरंगोडीबी

ArangoDB ग्राफ डेटा मॉडेलसाठी समर्थनाचा दावा करते.

ArangoDB मधील आलेखाचे नोड्स हे सामान्य दस्तऐवज आहेत आणि कडा हे विशिष्ट प्रकारचे दस्तऐवज आहेत ज्यात नियमित सिस्टम फील्डसह (_key, _id, _rev) सिस्टम फील्ड _from и _to. दस्तऐवज डीबीएमएसमधील दस्तऐवज पारंपारिकपणे संग्रहांमध्ये एकत्रित केले जातात. एजन्सचे प्रतिनिधित्व करणाऱ्या दस्तऐवजांच्या संग्रहांना अरांगोडीबीमध्ये एज कलेक्शन म्हणतात. तसे, एज कलेक्शन दस्तऐवज देखील दस्तऐवज आहेत, म्हणून 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

निकालाचे स्वरूप मागील विनंतीप्रमाणेच असेल. पहिल्या प्रश्नाप्रमाणे ते अधिक "संबंधित" बनवण्यासाठी काय काढले जाणे आवश्यक आहे याचा विचार करा.

अझर कॉसमॉसडीबी

थोड्या प्रमाणात, वर ArangoDB आणि OrientDB बद्दल जे सांगितले गेले होते ते Azure CosmosDB ला लागू होते. CosmosDB खालील डेटा ऍक्सेस API प्रदान करते: SQL, MongoDB, Gremlin आणि Cassandra.

SQL API आणि MongoDB API दस्तऐवज मॉडेलमधील डेटा ऍक्सेस करण्यासाठी वापरले जातात. Gremlin API आणि Cassandra API - अनुक्रमे ग्राफ आणि कॉलम फॉरमॅटमध्ये डेटा ऍक्सेस करण्यासाठी. सर्व मॉडेलमधील डेटा CosmosDB अंतर्गत मॉडेल फॉरमॅटमध्ये सेव्ह केला जातो: एआरएस (“एटम-रेकॉर्ड-सिक्वेंस”), जे दस्तऐवजाच्या अगदी जवळ आहे.

परंतु सेवेमध्ये खाते तयार करताना वापरकर्त्याने निवडलेले डेटा मॉडेल आणि वापरलेले API निश्चित केले जातात. एका मॉडेलमध्ये लोड केलेला डेटा दुसर्‍या मॉडेलच्या फॉरमॅटमध्ये ऍक्सेस करणे शक्य नाही, जसे की असे काहीतरी स्पष्ट केले आहे:

अशाप्रकारे, Azure CosmosDB मधील मल्टी-मॉडेल आज एका निर्मात्याकडून वेगवेगळ्या मॉडेल्सना समर्थन देणारे अनेक डेटाबेस वापरण्याची क्षमता आहे, जे मल्टी-व्हेरियंट स्टोरेजच्या सर्व समस्या सोडवत नाही.

आलेख मॉडेलवर आधारित मल्टी-मॉडेल डीबीएमएस?

लक्षणीय वस्तुस्थिती अशी आहे की बाजारात अद्याप कोणतेही मल्टी-मॉडेल डीबीएमएस नाहीत जे आलेख मॉडेलवर आधारित आहेत (एकाच वेळी दोन आलेख मॉडेलसाठी मल्टी-मॉडेल समर्थन वगळता: RDF आणि LPG; हे पहा मागील प्रकाशन). सर्वात मोठी अडचण संबंधित मॉडेलच्या ऐवजी ग्राफ मॉडेलच्या शीर्षस्थानी दस्तऐवज मॉडेलच्या अंमलबजावणीमुळे उद्भवते.

आलेख मॉडेलच्या शीर्षस्थानी रिलेशनल मॉडेल कसे अंमलात आणायचे हा प्रश्न नंतरच्या निर्मिती दरम्यान देखील विचारात घेतला गेला. कसे बोललेउदाहरणार्थ डेव्हिड मॅकगव्हर्न:

आलेखाच्या दृष्टिकोनामध्ये अंतर्भूत असे काहीही नाही जे आलेख डेटाबेसवर एक स्तर (उदा. योग्य अनुक्रमणिकेद्वारे) तयार करण्यास प्रतिबंधित करते जे (1) नेहमीच्या की व्हॅल्यू जोड्यांमधून ट्युपल्सची पुनर्प्राप्ती आणि (2) गटबद्धतेसह एक संबंधात्मक दृश्य सक्षम करते. संबंध प्रकारानुसार tuples.

आलेख मॉडेलच्या शीर्षस्थानी दस्तऐवज मॉडेल लागू करताना, आपण लक्षात ठेवणे आवश्यक आहे, उदाहरणार्थ, खालील:

JSON अॅरेचे घटक क्रमबद्ध मानले जातात, परंतु आलेखाच्या काठाच्या शिरोबिंदूपासून निघणारे घटक नाहीत;
दस्तऐवज मॉडेलमधील डेटा सामान्यतः विकृत केला जातो; आपण अद्याप समान एम्बेड केलेल्या दस्तऐवजाच्या अनेक प्रती संग्रहित करू इच्छित नाही आणि उपदस्तऐवजांना सहसा अभिज्ञापक नसतात;
दुसरीकडे, दस्तऐवज DBMSs ची विचारधारा अशी आहे की दस्तऐवज तयार केलेले "एकत्रित" असतात ज्यांना प्रत्येक वेळी नवीन तयार करण्याची आवश्यकता नसते. तयार दस्तऐवजाशी संबंधित सबग्राफ द्रुतपणे प्राप्त करण्याच्या क्षमतेसह आलेख मॉडेल प्रदान करणे आवश्यक आहे.

थोडी जाहिरात

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

खालीलपैकी एका लेखात मी NitrosBase मध्ये मॉडेल जुळणारे कसे दिसते याचे आशेने वर्णन करेन.

निष्कर्ष

मला आशा आहे की ज्याला मल्टी-मॉडेलिंग म्हणतात त्याची सामान्य रूपरेषा वाचकांसाठी कमी-अधिक प्रमाणात स्पष्ट झाली आहे. मल्टी-मॉडेल DBMS खूप भिन्न आहेत आणि “मल्टी-मॉडेल सपोर्ट” भिन्न दिसू शकतात. प्रत्येक विशिष्ट प्रकरणात "मल्टी-मॉडेल" काय म्हणतात हे समजून घेण्यासाठी, खालील प्रश्नांची उत्तरे देणे उपयुक्त आहे:

आम्ही पारंपारिक मॉडेल किंवा "हायब्रिड" मॉडेलचे समर्थन करण्याबद्दल बोलत आहोत?
मॉडेल "समान" आहेत किंवा त्यापैकी एक इतरांचा विषय आहे?
मॉडेल एकमेकांबद्दल "उदासीन" आहेत का? एका मॉडेलमध्ये लिहिलेला डेटा दुसर्‍या मॉडेलमध्ये वाचला जाऊ शकतो किंवा अगदी ओव्हरराईट केला जाऊ शकतो?

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

केवळ नोंदणीकृत वापरकर्तेच सर्वेक्षणात भाग घेऊ शकतात. साइन इन करा, आपले स्वागत आहे.

तुम्ही मल्टी-मॉडेल DBMS वापरता का?

आम्ही ते वापरत नाही, आम्ही सर्व काही एका DBMS आणि एका मॉडेलमध्ये संग्रहित करतो
आम्ही पारंपारिक DBMS च्या मल्टी-मॉडेल क्षमता वापरतो
आम्ही पॉलीग्लॉट चिकाटीचा सराव करतो
आम्ही नवीन मल्टी-मॉडेल DBMS (Arango, Orient, CosmosDB) वापरतो

19 वापरकर्त्यांनी मतदान केले. 4 वापरकर्ते दूर राहिले.

स्त्रोत: www.habr.com

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