جديد معلوماتي نظام ڪافي پيچيده آهن. گهٽ ۾ گهٽ نه، انهن جي پيچيدگي انهن ۾ پروسيس ٿيل ڊيٽا جي پيچيدگي جي سبب آهي. ڊيٽا جي پيچيدگي اڪثر استعمال ٿيل ڊيٽا ماڊل جي مختلف قسمن ۾ آهي. تنهن ڪري، مثال طور، جڏهن ڊيٽا "وڏي" ٿي ويندي آهي، هڪ مشڪلاتي خاصيتن مان هڪ آهي نه رڳو ان جي مقدار ("حجم")، پر ان جي مختلف قسم ("مختلف").

جيڪڏهن توهان اڃا تائين دليل ۾ ڪو نقص نه ڳوليندا آهيو، پوء پڙهو.

Contents

Polyglot تسلسل
ملٽي ماڊل
ملٽي ماڊل ڊي بي ايم ايس لاڳاپي ماڊل جي بنياد تي
     MS SQL سرور ۾ دستاويز ماڊل
     MS SQL سرور ۾ گراف ماڊل
ملٽي ماڊل ڊي بي ايم ايس دستاويز جي ماڊل جي بنياد تي
     MarkLogic ۾ تعلقي ماڊل
     MarkLogic ۾ گراف ماڊل
ملٽي ماڊل DBMS "بغير مکيه ماڊل"
     آرانگو ڊي بي
     آرڊيڊي ڊي بي
     آورور ڪسموس ڊي بي
ملٽي ماڊل ڊي بي ايم ايس هڪ گراف ماڊل جي بنياد تي؟
ٿڪل
راء

Polyglot تسلسل

مٿي ڄاڻايل حقيقت ڏانهن وڌي ٿو ته ڪڏهن ڪڏهن هڪ سسٽم جي فريم ورڪ ۾ پڻ ڊيٽا کي ذخيرو ڪرڻ ۽ انهن جي پروسيسنگ جي مختلف مسئلن کي حل ڪرڻ لاء ڪيترن ئي مختلف ڊي بي ايم ايس استعمال ڪرڻ ضروري آهي، جن مان هر هڪ پنهنجي پنهنجي ڊيٽا ماڊل کي سپورٽ ڪري ٿو. ايم فولر جي هلڪي هٿ سان، ليکڪ ڪيترائي مشهور ڪتاب ۽ هڪ ساٿي ليکڪ Agile Manifesto، هن صورتحال کي سڏيو ويندو آهي گھڻن قسمن جي اسٽوريج ("polyglot تسلسل").

فولر پڻ اي ڪامرس جي فيلڊ ۾ مڪمل خصوصيت ۽ اعلي لوڊ ايپليڪيشن ۾ ڊيٽا اسٽوريج کي منظم ڪرڻ جو هيٺيان مثال آهي.

اهو مثال، يقينا، ڪجهه حد تائين مبالغو آهي، پر ساڳئي مقصد لاء هڪ يا ٻئي DBMS چونڊڻ جي حق ۾ ڪجهه غور ڳولي سگهجن ٿا، مثال طور، هتي.

اهو واضح آهي ته اهڙي زو ۾ نوڪر هجڻ آسان ناهي.

ڪوڊ جو مقدار جيڪو ڊيٽا اسٽوريج کي انجام ڏئي ٿو استعمال ٿيل DBMSs جي تعداد جي تناسب ۾ وڌي ٿو؛ ڪوڊ جي هم وقت سازي واري ڊيٽا جو مقدار سٺو آهي جيڪڏهن هن نمبر جي چورس جي متناسب نه هجي.
استعمال ٿيل DBMSs جي تعداد جي گھڻائي جي طور تي، استعمال ٿيل DBMSs مان ھر ھڪ جي انٽرنيشنل خاصيتن (اسڪيليبلٽي، غلطي رواداري، اعلي دستيابي) مهيا ڪرڻ جي قيمت وڌائي ٿي.
اهو ناممڪن آهي ته مجموعي طور تي اسٽوريج سب سسٽم جي انٽرنيشنل خاصيتن کي يقيني بڻائڻ - خاص طور تي ٽرانزيڪشن.

زو ڊائريڪٽر جي نقطي نظر کان، هر شيء هن وانگر ڏسڻ ۾ اچي ٿو:

ڊي بي ايم ايس ٺاهيندڙ کان لائسنس ۽ ٽيڪنيڪل سپورٽ جي قيمت ۾ هڪ کان وڌيڪ اضافو.
اوور اسٽافنگ ۽ وڌايل ڊيڊ لائنون.
ڊيٽا جي عدم مطابقت جي ڪري سڌو مالي نقصان يا ڏنڊ.

سسٽم جي ملڪيت جي مجموعي قيمت (TCO) ۾ هڪ اهم اضافو آهي. ڇا "گهڻن اسٽوريج جا اختيار" جي صورتحال مان نڪرڻ جو ڪو طريقو آهي؟

ملٽي ماڊل

اصطلاح "ملٽي ويريٽ اسٽوريج" 2011 ۾ استعمال ۾ آيو. طريقه ڪار جي مسئلن جي آگاهي ۽ حل جي ڳولا ۾ ڪيترائي سال لڳا، ۽ 2015 ۾، گارٽنر تجزيه نگارن جي وات ذريعي، جواب تيار ڪيو ويو:

کان "NoSQL DBMSs لاءِ مارڪيٽ گائيڊ - 2015»:
DBMSs جو مستقبل، انهن جي فن تعمير ۽ انهن کي استعمال ڪرڻ جا طريقا ملٽي ماڊل آهن.
کان "ODBMS - 2016 لاءِ جادوئي ڪواڊرنٽ»:
معروف آپريشنل DBMSs هڪ پليٽ فارم جي حصي طور ڪيترن ئي ماڊل- لاڳاپو ۽ غير لاڳاپو پيش ڪندا.

اهو لڳي ٿو ته هن ڀيري گارٽنر تجزيه نگار انهن جي اڳڪٿي سان صحيح هئا. جيڪڏھن توھان صفحي ڏانھن وڃو بنيادي درجه بندي DBMS تي DB-انجن، توهان ڏسي سگهو ٿا تهоان جا اڪثر اڳواڻ پاڻ کي خاص طور تي ملٽي ماڊل ڊي بي ايم ايس جي حيثيت رکن ٿا. ساڳئي صفحي تي ڪنهن به خانگي درجه بندي سان ڏسي سگھجي ٿو.

هيٺ ڏنل جدول ڏيکاري ٿو DBMS - اڳواڻن مان هر هڪ نجي درجه بندي ۾، جيڪي دعوي ڪن ٿا ته ملٽي ماڊل. هر DBMS لاءِ، اصل سپورٽ ٿيل ماڊل (جيڪو هڪ دفعو صرف هڪ هوندو هو) ۽ ان سان گڏ هن وقت سپورٽ ڪيل ماڊل ظاهر ڪيا ويا آهن. پڻ درج ٿيل آهن DBMSs جيڪي پاڻ کي "اصل ۾ ملٽي ماڊل" جي حيثيت سان پوزيشن ڪن ٿا ۽، تخليق ڪندڙن جي مطابق، ڪو به ابتدائي وارث ماڊل نه آهي.

ڊي بي ايم ايس	شروعاتي ماڊل	اضافي ماڊلز
Oracle	تعلقي	گراف ، سند
MS SQL	تعلقي	گراف ، سند
PostgreSQL	تعلقي	گراف*، سند
مارڪ لاجڪ	دستاويزي	گراف ، لاڳاپو
منڊو ڊي	دستاويزي	اھم قدر، گراف*
ڊيٽا اسٽيٽ	وسيع ڪالمن	دستاويزي، گراف
Redis	اھم قدر	دستاويزي، گراف*
آرانگو ڊي بي	-	گراف ، سند
آرڊيڊي ڊي بي	-	گراف ، سند ، لاڳاپو
آورور ڪسموس ڊي بي	-	گراف ، سند ، لاڳاپو

ٽيبل تي نوٽس

جدول ۾ ستارن جا نشان بيان ڪيل بيان جيڪي تحفظات جي ضرورت هونديون آهن:

PostgreSQL DBMS گراف ڊيٽا ماڊل کي سپورٽ نٿو ڪري، پر هي پراڊڪٽ ان کي سپورٽ ڪري ٿو ان جي بنياد تي، جهڙوڪ AgensGraph.
مونگو ڊي بي جي سلسلي ۾، سوال جي ٻولي ۾ گراف آپريٽرز جي موجودگي بابت ڳالهائڻ وڌيڪ صحيح آهي ($lookup, $graphLookup) گراف ماڊل جي حمايت ڪرڻ جي ڀيٽ ۾، جيتوڻيڪ، يقينا، انهن جي تعارف جي ضرورت آهي ڪجهه اصلاحن جي فزيڪل اسٽوريج سطح تي گراف ماڊل کي سپورٽ ڪرڻ جي هدايت ۾.
ريڊس جي حوالي سان، اسان جو مطلب آهي واڌارو ريڊيس گراف.

اڳيون، هر هڪ ڪلاس لاءِ، اسين ڏيکارينداسين ته ڪيئن ڪيترن ئي ماڊلز لاءِ سپورٽ هن ڪلاس مان DBMS ۾ لاڳو ٿئي ٿي. اسان لاڳاپن، دستاويزن ۽ گراف ماڊلز کي سڀ کان اهم سمجھنداسين ۽ مخصوص DBMSs جا مثال استعمال ڪنداسين ته ڪيئن "غائب ٿيل" تي عمل ڪيو وڃي.

ملٽي ماڊل ڊي بي ايم ايس لاڳاپي ماڊل جي بنياد تي

معروف DBMSs في الحال لاڳاپا آهن؛ گارٽنر جي اڳڪٿي کي درست نه ٿو سمجهي سگهجي جيڪڏهن RDBMSs ملٽي ماڊلنگ جي هدايت ۾ حرڪت نه ڏيکاري. ۽ اهي ظاهر ڪن ٿا. هاڻي اهو خيال آهي ته هڪ ملٽي ماڊل ڊي بي ايم ايس هڪ سوئس چاقو وانگر آهي، جيڪو ڪجهه به سٺو نٿو ڪري سگهي، سڌو ليري ايلسن ڏانهن هدايت ڪري سگهجي ٿو.

ليکڪ، بهرحال، Microsoft SQL سرور ۾ ملٽي ماڊلنگ جي عمل کي ترجيح ڏئي ٿو، جنهن جي مثال تي دستاويز ۽ گراف ماڊلز لاءِ RDBMS سپورٽ بيان ڪئي ويندي.

MS SQL سرور ۾ دستاويز ماڊل

Habré تي اڳ ۾ ئي ٻه شاندار مضمون آيا آهن ته ڪيئن MS SQL سرور دستاويز جي ماڊل لاءِ سپورٽ لاڳو ڪري ٿو؛ مان پاڻ کي مختصر بيان ۽ تبصري تائين محدود ڪندس:

MS SQL سرور ۾ دستاويز جي ماڊل کي سپورٽ ڪرڻ جو طريقو خاص طور تي تعلق رکندڙ DBMSs لاءِ عام آهي: JSON دستاويزن کي عام ٽيڪسٽ فيلڊز ۾ ذخيرو ڪرڻ جي تجويز ڏني وئي آهي. دستاويز جي ماڊل لاءِ سپورٽ خاص آپريٽرز مهيا ڪرڻ آهي هن JSON کي پارس ڪرڻ لاءِ:

JSON_VALUE اسڪيلر خاصيت جي قيمتن کي ڪڍڻ لاء،
JSON_QUERY ذيلي دستاويز ڪڍڻ لاء.

ٻئي آپريٽرز جو ٻيو دليل JSONPath-جهڙو نحو ۾ هڪ اظهار آهي.

خلاصي طور تي، اسان اهو چئي سگهون ٿا ته هن طريقي سان ذخيرو ٿيل دستاويز "فرسٽ ڪلاس ادارو" نه آهن هڪ تعلقي DBMS ۾، tuples جي برعڪس. خاص طور تي، MS SQL Server ۾ في الحال JSON دستاويزن جي شعبن تي ڪا به انڊيڪس نه آهي، جنهن ڪري انهن شعبن جي قدرن کي استعمال ڪندي جدولن ۾ شامل ٿيڻ ۽ انهن قدرن کي استعمال ڪندي دستاويزن کي به چونڊڻ ڏکيو ٿي پوي ٿو. بهرحال، اهو ممڪن آهي ته اهڙي فيلڊ لاء هڪ حسابي ڪالمن ۽ ان تي هڪ انڊيڪس ٺاهي.

اضافي طور تي، MS SQL سرور مهيا ڪري ٿو آساني سان هڪ JSON دستاويز ٺاهڻ جي جدولن جي مواد مان آپريٽر استعمال ڪندي FOR JSON PATH - هڪ امڪان، هڪ خاص معنى ۾، اڳئين هڪ جي سامهون، روايتي اسٽوريج. اهو واضح آهي ته RDBMS ڪيترو به تيز هجي، اهو طريقو دستاويز DBMSs جي نظريي سان تضاد رکي ٿو، جيڪو بنيادي طور تي مشهور سوالن جا تيار ڪيل جوابن کي محفوظ ڪري ٿو، ۽ صرف ترقي جي آسانيء جي مسئلن کي حل ڪري سگهي ٿو، پر رفتار نه.

آخرڪار، MS SQL سرور توهان کي دستاويز جي تعمير جي سامهون واري مسئلي کي حل ڪرڻ جي اجازت ڏئي ٿو: توهان JSON کي استعمال ڪندي جدولن ۾ ختم ڪري سگهو ٿا 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';

ان کان علاوه، اهڙي جدولن سان ڪم ڪرڻ وقت انهن گراف جي نمونن کي استعمال نه ڪرڻ تمام ڏکيو آهي، ڇاڪاڻ ته عام SQL سوالن ۾ ساڳئي مسئلن کي حل ڪرڻ لاء، سسٽم حاصل ڪرڻ لاء اضافي ڪوششون ڪرڻ جي ضرورت پوندي "گراف" نوڊ سڃاڻپ ڪندڙ ($node_id, $from_id, $to_id؛ ساڳئي سبب، ڊيٽا داخل ڪرڻ جا سوال هتي نه ڏيکاريا ويا آهن جيئن اهي غير ضروري طور تي منجهيل آهن).

MS SQL سرور ۾ دستاويزن ۽ گراف ماڊلز جي عملن جي وضاحت کي اختصار ڪرڻ لاءِ، مان ياد ڏيان ٿو ته هڪ ماڊل جي ٻئي جي مٿان اهڙيون عملدرآمدون ڪامياب نه ٿيون لڳيون، بنيادي طور تي ٻوليءَ جي ڊيزائن جي نقطي نظر کان. اهو ضروري آهي ته هڪ ٻولي کي ٻي سان وڌايو وڃي، ٻوليون مڪمل طور تي "orthogonal" نه آهن، مطابقت جا ضابطا ڪافي عجيب ٿي سگهن ٿا.

ملٽي ماڊل ڊي بي ايم ايس دستاويز جي ماڊل جي بنياد تي

ھن حصي ۾، مان توھان کي بيان ڪرڻ چاھيان ٿو ملٽي ماڊل جي عمل کي ڊاڪيومينٽ ڊي بي ايم ايس ۾ استعمال ڪندي مثال طور انھن مان سڀ کان وڌيڪ مقبول نه، مونگو ڊي بي (جيئن چيو ويو آھي، ان ۾ صرف مشروط گراف آپريٽر آھن. $lookup и $graphLookup، شارڊ ٿيل مجموعن تي ڪم نه ڪندي) پر وڌيڪ بالغ ۽ ”انٽرپرائز“ ڊي بي ايم ايس جو مثال استعمال ڪندي مارڪ لاجڪ.

تنهن ڪري، جمع ڪرڻ ڏيو هيٺ ڏنل قسم جي 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 ۾ گراف ماڊل

گراف (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 .
}

لاڳاپي جي برعڪس، مارڪ لاجڪ گراف ماڊل کي ٻن ٻين طريقن سان سپورٽ ڪري ٿو:

هڪ ڊي بي ايم ايس آر ڊي ايف ڊيٽا جي مڪمل طور تي الڳ اسٽوريج ٿي سگهي ٿو (ان ۾ ٽنهي کي سڏيو ويندو. منظم مٿي بيان ڪيل انهن جي ابتڙ ڪڍيون ويون).
خاص سيريلائيزيشن ۾ آر ڊي ايف کي صرف XML يا JSON دستاويزن ۾ داخل ڪري سگھجي ٿو (۽ ٽرپلٽس وري سڏيو ويندو غير منظم). اهو شايد ميڪانيزم جو هڪ متبادل آهي idref ۽ ٻيا.

هڪ سٺو خيال آهي ته ڪيئن شيون "واقعي" ڪم ۾ MarkLogic پاران ڏنل آهي آپٽيڪل API، هن لحاظ کان، اهو گهٽ-سطح آهي، جيتوڻيڪ ان جو مقصد ان جي ابتڙ آهي - استعمال ٿيل ڊيٽا ماڊل مان خلاصو ڪرڻ جي ڪوشش ڪرڻ، مختلف ماڊلز ۾ ڊيٽا سان مسلسل ڪم کي يقيني بڻائڻ، ٽرانزيڪشن وغيره.

ملٽي ماڊل DBMS "بغير مکيه ماڊل"

مارڪيٽ تي ڊي بي ايم ايس پڻ آهن جيڪي پاڻ کي شروعاتي طور تي ملٽي ماڊل طور پوزيشن ڪن ٿا، بغير ڪنهن وراثت واري مکيه ماڊل جي. انهن ۾ شامل آهن آرانگو ڊي بي, آرڊيڊي ڊي بي (2018 کان وٺي ترقياتي ڪمپني SAP سان تعلق رکي ٿو) ۽ CosmosDB (Microsoft Azure ڪلائوڊ پليٽ فارم جي حصي طور خدمت).

حقيقت ۾، اتي آهن "بنيادي" ماڊل ArangoDB ۽ OrientDB ۾. ٻنهي صورتن ۾، اهي انهن جا پنهنجا ڊيٽا ماڊل آهن، جيڪي هڪ دستاويز جي جنرلائيزيشن آهن. عام ترتيبون خاص طور تي گراف ۽ لاڳاپي واري نوعيت جي سوالن کي انجام ڏيڻ جي صلاحيت کي آسان ڪرڻ لاء آهن.

اهي ماڊل صرف مخصوص ڊي بي ايم ايس ۾ استعمال لاءِ موجود آهن؛ انهن جون پنهنجون سواليون ٻوليون انهن سان ڪم ڪرڻ لاءِ ٺهيل آهن. يقينن، اهڙا ماڊل ۽ ڊي بي ايم ايسز واعدو ڪندڙ آهن، پر معياري ماڊل ۽ ٻولين سان مطابقت جي کوٽ ان ڊي بي ايم ايس کي وراثت واري نظام ۾ استعمال ڪرڻ ناممڪن بڻائي ٿي - اڳ ۾ ئي استعمال ٿيل ڊي بي ايم ايس کي تبديل ڪرڻ لاء.

Habré تي ArangoDB ۽ OrientDB بابت اڳ ۾ ئي ھڪڙو شاندار مضمون ھو. NoSQL ڊيٽابيس ۾ شامل ٿيو.

آرانگو ڊي بي

ArangoDB دعويٰ ڪري ٿو سپورٽ گراف ڊيٽا ماڊل لاءِ.

ArangoDB ۾ گراف جا نوڊس عام دستاويز آهن، ۽ ڪنڊا هڪ خاص قسم جا دستاويز آهن، جيڪي باقاعده سسٽم فيلڊ سان گڏ، (_key, _id, _rev) سسٽم جا شعبا _from и _to. دستاويزن ۾ دستاويز DBMSs روايتي طور تي مجموعن ۾ گڏيل آهن. ڪنارن جي نمائندگي ڪندڙ دستاويزن جي مجموعن کي 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 
  }
]

سوال ۽ نتيجا

AQL ٻولي ۾ گراف طرز جو سوال ArangoDB ۾ استعمال ڪيو ويو، انسان جي پڙهڻ جي قابل فارم ۾ واپسي جي معلومات بابت ڪير پسند ڪندو آهي ڪيفي، هن طرح نظر اچي ٿو:

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 سان Gremlin-like inserts. نسخو 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 ھيٺ ڏنل ڊيٽا رسائي APIs مهيا ڪري ٿو: SQL، MongoDB، Gremlin ۽ Cassandra.

SQL API ۽ MongoDB API دستاويز ماڊل ۾ ڊيٽا تائين رسائي حاصل ڪرڻ لاء استعمال ڪيا ويا آهن. Gremlin API ۽ Cassandra API - ترتيب سان گراف ۽ ڪالمن فارميٽ ۾ ڊيٽا تائين رسائي لاءِ. سڀني ماڊل ۾ ڊيٽا محفوظ ڪئي وئي آهي CosmosDB اندروني ماڊل فارميٽ ۾: آر ايس ("ايٽم-ريڪارڊ-سڪيننس")، جيڪو پڻ هڪ دستاويز جي ويجهو آهي.

پر صارف پاران چونڊيل ڊيٽا ماڊل ۽ استعمال ٿيل API سروس ۾ اڪائونٽ ٺاهڻ وقت مقرر ٿيل آهن. اهو ممڪن ناهي ته هڪ ماڊل ۾ لوڊ ٿيل ڊيٽا کي ٻئي ماڊل جي فارميٽ ۾، جيئن ڪجهه هن طرح بيان ڪيو ويو آهي:

اهڙيء طرح، Azure CosmosDB ۾ ملٽي ماڊل اڄ صرف ڪيترن ئي ڊيٽابيس کي استعمال ڪرڻ جي صلاحيت آهي مختلف ماڊل کي سپورٽ ڪندڙ هڪ ٺاهيندڙ کان، جيڪو حل نه ڪندو آهي ملائي ويئر اسٽوريج جي سڀني مسئلن کي.

ملٽي ماڊل ڊي بي ايم ايس هڪ گراف ماڊل جي بنياد تي؟

قابل ذڪر حقيقت اها آهي ته مارڪيٽ تي اڃا تائين ڪي به ملٽي ماڊل ڊي بي ايم ايس نه آهن جيڪي گراف ماڊل تي ٻڌل آهن (سواءِ ملٽي ماڊل سپورٽ لاءِ هڪ ئي وقت ۾ ٻه گراف ماڊل: آر ڊي ايف ۽ ايل پي جي؛ ڏسو هن ۾ اڳوڻي اشاعت). سڀ کان وڏيون مشڪلاتون گراف ماڊل جي مٿان هڪ دستاويزي ماڊل کي لاڳو ڪرڻ جي ڪري آهن، بلڪه هڪ تعلقي جي ڀيٽ ۾.

گراف ماڊل جي چوٽي تي هڪ تعلقي نموني کي ڪيئن لاڳو ڪرڻ جو سوال به بعد ۾ ٺهڻ دوران سمجهيو ويو. ڪيئن ڳالهايومثال طور David McGovern:

گراف جي نقطه نظر ۾ اهڙي ڪا به شيءِ موجود ناهي جيڪا گراف ڊيٽابيس تي هڪ پرت ٺاهڻ کان روڪي ٿي (مثال طور، مناسب انڊيڪسنگ جي ذريعي) جيڪا هڪ لاڳاپي واري ڏيک کي فعال ڪري ٿي (1) عام اهم قدر جي جوڙي مان ٽوپلز جي بحالي ۽ (2) گروپن جي تعلق جي قسم جي لحاظ کان tuples.

جڏهن گراف ماڊل جي چوٽي تي هڪ دستاويز جي ماڊل کي لاڳو ڪرڻ، توهان کي ذهن ۾ رکڻ جي ضرورت آهي، مثال طور، هيٺيان:

هڪ JSON صف جا عنصر ترتيب ڏنل سمجهيا وڃن ٿا، پر اهي نه آهن جيڪي گراف جي ڪنڊ جي چوٽي مان نڪرندا آهن؛
دستاويزن جي ماڊل ۾ ڊيٽا عام طور تي غير معمولي ڪئي وئي آهي؛ توهان اڃا تائين ساڳئي ايمبيڊڊ دستاويزن جون ڪيتريون ئي ڪاپيون ذخيرو ڪرڻ نٿا چاهيو، ۽ ذيلي دستاويزن کي عام طور تي سڃاڻپ ڪندڙ نه آهن؛
ٻئي طرف، دستاويز DBMSs جو نظريو اهو آهي ته دستاويز تيار ڪيل "مجموعي" آهن جيڪي هر وقت نئين سر تعمير ڪرڻ جي ضرورت ناهي. اهو ضروري آهي ته گراف ماڊل مهيا ڪرڻ جي صلاحيت سان جلدي حاصل ڪرڻ جي صلاحيت سان گڏ هڪ ذيلي گراف مڪمل ٿيل دستاويز سان.

ٿورڙو اشتهار

مضمون جو مصنف نيٽروس بيس ڊي بي ايم ايس جي ترقي سان لاڳاپيل آهي، جنهن جو اندروني ماڊل گراف آهي، ۽ بيروني ماڊل - لاڳاپو ۽ دستاويز - ان جي نمائندگي آهن. سڀئي ماڊل برابر آهن: تقريبن ڪنهن به ڊيٽا موجود آهي انهن مان ڪنهن به سوال جي ٻولي استعمال ڪندي جيڪا قدرتي آهي. ان کان سواء، ڪنهن به نظر ۾، ڊيٽا کي تبديل ڪري سگهجي ٿو. تبديليون اندروني نموني ۾ ظاهر ٿينديون ۽، مطابق، ٻين نظرين ۾.

مان اميد سان بيان ڪندس ته هيٺ ڏنل مضمونن مان هڪ ۾ NitrosBase ۾ ڪهڙي نموني جو ميلاپ نظر اچي ٿو.

ٿڪل

مون کي اميد آهي ته عام خاڪا جنهن کي ملٽي ماڊلنگ چئجي ٿو پڙهندڙن لاءِ گهٽ يا گهٽ واضح ٿي چڪا آهن. ملٽي ماڊل ڊي بي ايم ايس بلڪل مختلف آهن، ۽ "ملٽي ماڊل سپورٽ" مختلف نظر اچن ٿا. اهو سمجهڻ لاءِ ته هر مخصوص صورت ۾ ”ملٽي ماڊل“ کي ڇا چئبو آهي، هيٺ ڏنل سوالن جا جواب ڏيڻ مفيد آهي:

ڇا اسان روايتي ماڊل يا ڪنهن قسم جي "هائبرڊ" ماڊل جي حمايت بابت ڳالهائي رهيا آهيون؟
ڇا ماڊل "برابر" آهن، يا انهن مان هڪ آهي ٻين جو موضوع؟
ڇا ماڊل هڪ ٻئي ڏانهن "لاتعلق" آهن؟ ڇا ھڪڙي نموني ۾ لکيل ڊيٽا ٻئي ۾ پڙھي سگھجي ٿو يا اڃا به اوور رائٽ ٿي سگھي ٿو؟

مان سمجهان ٿو ته ملٽي ماڊل ڊي بي ايم ايس جي لاڳاپي بابت سوال اڳ ۾ ئي مثبت جواب ڏئي سگهجي ٿو، پر دلچسپ سوال اهو آهي ته انهن مان ڪهڙي قسم جي ويجهي مستقبل ۾ وڌيڪ گهربل هوندي. اهو لڳي ٿو ته ملٽي ماڊل ڊي بي ايم ايس جيڪي روايتي ماڊل جي حمايت ڪن ٿا، بنيادي طور تي لاڳاپو، وڌيڪ طلب ۾ هوندا؛ ملٽي ماڊل ڊي بي ايم ايس جي مقبوليت، نوان ماڊل پيش ڪن ٿيون جيڪي مختلف روايتي طريقن جي فائدن کي گڏ ڪن ٿيون، هڪ وڌيڪ مستقبل جو معاملو آهي.

صرف رجسٽرڊ استعمال ڪندڙ سروي ۾ حصو وٺي سگهن ٿا. سائن ان ڪريو، توهان جي مهرباني.

ڇا توهان ملٽي ماڊل ڊي بي ايم ايس استعمال ڪندا آهيو؟

اسان ان کي استعمال نٿا ڪريون، اسان هر شيء کي هڪ ڊي بي ايم ايس ۽ هڪ ماڊل ۾ ذخيرو ڪندا آهيون
اسان روايتي DBMSs جي ملٽي ماڊل صلاحيتون استعمال ڪندا آهيون
اسان پوليو گلوٽ مسلسل مشق ڪندا آهيون
اسان نئين ملٽي ماڊل ڊي بي ايم ايس استعمال ڪندا آهيون (آرانگو، اورينٽ، CosmosDB)

19 صارفين ووٽ ڪيو. 4 استعمال ڪندڙن کي روڪيو ويو.

جو ذريعو: www.habr.com