جدید معلوماتی نظام کافی پیچیدہ ہیں۔ سب سے کم نہیں، ان کی پیچیدگی ان میں پروسیس شدہ ڈیٹا کی پیچیدگی کی وجہ سے ہے۔ ڈیٹا کی پیچیدگی اکثر استعمال ہونے والے ڈیٹا ماڈلز کی مختلف اقسام میں ہوتی ہے۔ لہذا، مثال کے طور پر، جب ڈیٹا "بڑا" ہو جاتا ہے، تو ایک پریشانی والی خصوصیت نہ صرف اس کا حجم ("حجم")، بلکہ اس کی مختلف قسم ("قسم") بھی ہے۔

اگر آپ کو ابھی تک استدلال میں کوئی خامی نظر نہیں آتی ہے تو پھر پڑھیں۔

مواد

پولی گلوٹ استقامت
ملٹی ماڈل
ملٹی ماڈل DBMS رشتہ دار ماڈل پر مبنی ہے۔
     MS SQL سرور میں دستاویز کا ماڈل
     MS SQL سرور میں گراف ماڈل
دستاویز کے ماڈل پر مبنی ملٹی ماڈل DBMS
     مارک لاجک میں رشتہ دار ماڈل
     MarkLogic میں گراف ماڈل
ملٹی ماڈل DBMS "بغیر مرکزی ماڈل کے"
     ارنگو ڈی بی۔
     اورینٹل ڈی بی
     Azure CosmosDB
گراف ماڈل پر مبنی ملٹی ماڈل DBMS؟
حاصل يہ ہوا
Опрос

پولی گلوٹ استقامت

مندرجہ بالا اس حقیقت کی طرف جاتا ہے کہ بعض اوقات ایک سسٹم کے فریم ورک کے اندر بھی ڈیٹا کو ذخیرہ کرنے اور ان پر کارروائی کے مختلف مسائل کو حل کرنے کے لیے کئی مختلف DBMSs کا استعمال کرنا ضروری ہوتا ہے، جن میں سے ہر ایک اپنے ڈیٹا ماڈل کی حمایت کرتا ہے۔ ایم فاؤلر کے ہلکے ہاتھ سے، مصنف کئی مشہور کتابیں اور ایک شریک مصنفین چست منشور، اس صورتحال کو کہتے ہیں۔ ملٹی ویرینٹ اسٹوریج ("پولی گلوٹ استقامت")۔

فولر کے پاس ای کامرس کے میدان میں مکمل خصوصیات والی اور زیادہ بوجھ والی ایپلی کیشن میں ڈیٹا اسٹوریج کو منظم کرنے کی مندرجہ ذیل مثال بھی ہے۔

یہ مثال، بلاشبہ، کسی حد تک مبالغہ آمیز ہے، لیکن متعلقہ مقصد کے لیے ایک یا دوسرے DBMS کو منتخب کرنے کے حق میں کچھ تحفظات مل سکتے ہیں، مثال کے طور پر، یہاں.

یہ واضح ہے کہ ایسے چڑیا گھر میں خادم بننا آسان نہیں ہے۔

کوڈ کی مقدار جو ڈیٹا اسٹوریج کو انجام دیتی ہے استعمال شدہ DBMSs کی تعداد کے تناسب سے بڑھتی ہے۔ کوڈ سنکرونائزنگ ڈیٹا کی مقدار اچھی ہے اگر اس نمبر کے مربع کے متناسب نہ ہو۔
استعمال شدہ DBMSs کی تعداد کے کثیر کے طور پر، استعمال شدہ DBMSs میں سے ہر ایک کی انٹرپرائز خصوصیات (اسکیل ایبلٹی، فالٹ ٹولرنس، زیادہ دستیابی) فراہم کرنے کے اخراجات بڑھ جاتے ہیں۔
مجموعی طور پر اسٹوریج سب سسٹم کی انٹرپرائز خصوصیات کو یقینی بنانا ناممکن ہے - خاص طور پر لین دین۔

چڑیا گھر کے ڈائریکٹر کے نقطہ نظر سے، سب کچھ اس طرح لگتا ہے:

DBMS مینوفیکچرر کی طرف سے لائسنس اور تکنیکی مدد کی لاگت میں متعدد اضافہ۔
ضرورت سے زیادہ ملازمین اور ڈیڈ لائن میں اضافہ۔
اعداد و شمار کی عدم مطابقت کی وجہ سے براہ راست مالی نقصان یا جرمانے۔

نظام کی ملکیت کی کل لاگت (TCO) میں نمایاں اضافہ ہوا ہے۔ کیا "متعدد اسٹوریج کے اختیارات" کی صورتحال سے نکلنے کا کوئی راستہ ہے؟

ملٹی ماڈل

"ملٹی ویریٹیٹ اسٹوریج" کی اصطلاح 2011 میں استعمال ہوئی۔ نقطہ نظر کے مسائل سے آگاہی اور حل کی تلاش میں کئی سال لگے، اور 2015 تک، گارٹنر تجزیہ کاروں کے منہ سے، جواب تیار کیا گیا:

سے "NoSQL DBMSs کے لیے مارکیٹ گائیڈ - 2015"

DBMSs کا مستقبل، ان کے فن تعمیر اور ان کے استعمال کے طریقے ملٹی ماڈل ہیں۔
سے "جادوئی کواڈرینٹ برائے ODBMS - 2016"

سرکردہ آپریشنل DBMSs ایک ہی پلیٹ فارم کے حصے کے طور پر متعدد ماڈلز — رشتہ دار اور غیر متعلقہ — پیش کریں گے۔

ایسا لگتا ہے کہ اس بار گارٹنر کے تجزیہ کار اپنی پیشن گوئی کے ساتھ درست تھے۔ اگر آپ کے ساتھ صفحہ پر جائیں اہم درجہ بندی DB-Engines پر DBMS، آپ اسے دیکھ سکتے ہیں۔оاس کے زیادہ تر رہنما خود کو خاص طور پر ملٹی ماڈل DBMSs کے طور پر رکھتے ہیں۔ کسی بھی نجی درجہ بندی کے ساتھ صفحہ پر اسی کو دیکھا جا سکتا ہے۔

نیچے دی گئی جدول DBMS کو دکھاتی ہے - ہر ایک نجی درجہ بندی میں رہنما، جو کثیر ماڈل ہونے کا دعویٰ کرتے ہیں۔ ہر DBMS کے لیے، اصل سپورٹ شدہ ماڈل (جو کبھی صرف ایک تھا) اور اس کے ساتھ فی الحال سپورٹ کردہ ماڈلز کی نشاندہی کی گئی ہے۔ DBMSs بھی درج ہیں جو خود کو "اصلی طور پر ملٹی ماڈل" کے طور پر پوزیشن دیتے ہیں اور تخلیق کاروں کے مطابق، ان کے پاس کوئی ابتدائی وراثتی ماڈل نہیں ہے۔

ڈی بی ایم ایس	ابتدائی ماڈل	اضافی ماڈلز
اوریکل	رشتہ دار	گراف، دستاویز
ایم ایس ایس کیو ایل۔	رشتہ دار	گراف، دستاویز
PostgreSQL کی	رشتہ دار	گراف*، دستاویز
مارک لاجک	دستاویزی فلم	گراف، رشتہ دار
منگو ڈی بی	دستاویزی فلم	کلیدی قدر، گراف*
ڈیٹا اسٹیکس	چوڑا کالم	دستاویزی فلم، گراف
ریڈس	کلیدی قدر	دستاویزی فلم، گراف*
ارنگو ڈی بی۔	-	گراف، دستاویز
اورینٹل ڈی بی	-	گراف، دستاویز، رشتہ دار
Azure CosmosDB	-	گراف، دستاویز، رشتہ دار

میز پر نوٹ

ٹیبل میں ستارے ایسے بیانات کو نشان زد کرتے ہیں جن کے لیے تحفظات کی ضرورت ہوتی ہے:

PostgreSQL DBMS گراف ڈیٹا ماڈل کی حمایت نہیں کرتا، لیکن یہ پروڈکٹ اس کی حمایت کرتا ہے۔ اس کی بنیاد پرجیسے AgensGraph۔
MongoDB کے سلسلے میں، استفسار کی زبان میں گراف آپریٹرز کی موجودگی کے بارے میں بات کرنا زیادہ درست ہے ($lookup, $graphLookup) گراف ماڈل کو سپورٹ کرنے کے بجائے، اگرچہ، یقیناً، ان کے تعارف کے لیے گراف ماڈل کو سپورٹ کرنے کی سمت میں فزیکل اسٹوریج کی سطح پر کچھ اصلاح کی ضرورت تھی۔
Redis کے سلسلے میں، ہمارا مطلب ہے توسیع ریڈس گراف.

اگلا، ہر ایک کلاس کے لیے، ہم دکھائیں گے کہ کس طرح اس کلاس سے DBMS میں متعدد ماڈلز کے لیے سپورٹ کو لاگو کیا جاتا ہے۔ ہم رشتہ دار، دستاویز اور گراف ماڈلز کو سب سے اہم سمجھیں گے اور مخصوص DBMSs کی مثالیں استعمال کریں گے تاکہ یہ ظاہر کیا جا سکے کہ "لاپتہ افراد" کو کیسے نافذ کیا جاتا ہے۔

ملٹی ماڈل DBMS رشتہ دار ماڈل پر مبنی ہے۔

سرکردہ DBMSs فی الحال رشتہ دار ہیں؛ اگر RDBMSs ملٹی ماڈلنگ کی سمت میں حرکت نہیں دکھاتے ہیں تو گارٹنر کی پیشن گوئی کو درست نہیں سمجھا جا سکتا۔ اور وہ مظاہرہ کرتے ہیں۔ اب یہ خیال کہ ایک ملٹی ماڈل ڈی بی ایم ایس سوئس چاقو کی طرح ہے، جو کچھ بھی اچھی طرح سے نہیں کر سکتا، براہ راست لیری ایلیسن تک پہنچایا جا سکتا ہے۔

مصنف، تاہم، مائیکروسافٹ ایس کیو ایل سرور میں ملٹی ماڈلنگ کے نفاذ کو ترجیح دیتا ہے، جس کی مثال کے طور پر دستاویز اور گراف ماڈلز کے لیے RDBMS سپورٹ کو بیان کیا جائے گا۔

MS SQL سرور میں دستاویز کا ماڈل

Habré پر پہلے ہی دو بہترین مضامین آ چکے ہیں کہ کس طرح MS SQL Server دستاویز کے ماڈل کے لیے سپورٹ کو لاگو کرتا ہے؛ میں اپنے آپ کو ایک مختصر بیان اور تبصرے تک محدود رکھوں گا:

MS SQL سرور میں دستاویز کے ماڈل کو سپورٹ کرنے کا طریقہ متعلقہ DBMSs کے لیے کافی عام ہے: JSON دستاویزات کو عام ٹیکسٹ فیلڈز میں اسٹور کرنے کی تجویز ہے۔ دستاویز ماڈل کے لیے سپورٹ اس JSON کو پارس کرنے کے لیے خصوصی آپریٹرز فراہم کرنا ہے:

JSON_VALUE اسکیلر انتساب اقدار کو نکالنے کے لیے،
JSON_QUERY ذیلی دستاویزات نکالنے کے لیے۔

دونوں آپریٹرز کی دوسری دلیل JSONPath نما نحو میں ایک اظہار ہے۔

خلاصہ طور پر، ہم یہ کہہ سکتے ہیں کہ اس طرح سے ذخیرہ شدہ دستاویزات ایک رشتہ دار DBMS میں ٹیپلز کے برعکس "فرسٹ کلاس ہستی" نہیں ہیں۔ خاص طور پر، ایم ایس ایس کیو ایل سرور میں فی الحال JSON دستاویزات کی فیلڈز پر کوئی انڈیکس نہیں ہے، جس کی وجہ سے ان فیلڈز کی قدروں کو استعمال کرتے ہوئے ٹیبلز میں شامل ہونا اور یہاں تک کہ ان اقدار کو استعمال کرتے ہوئے دستاویزات کا انتخاب کرنا مشکل ہو جاتا ہے۔ تاہم، ایسے فیلڈ کے لیے حسابی کالم اور اس پر انڈیکس بنانا ممکن ہے۔

مزید برآں، MS SQL سرور آپریٹر کا استعمال کرتے ہوئے میزوں کے مواد سے آسانی سے JSON دستاویز بنانے کی صلاحیت فراہم کرتا ہے۔ FOR JSON PATH - ایک امکان، ایک خاص معنوں میں، پچھلے ایک کے برعکس، روایتی ذخیرہ۔ یہ واضح ہے کہ RDBMS کتنی ہی تیز کیوں نہ ہو، یہ نقطہ نظر دستاویز DBMSs کے نظریے سے متصادم ہے، جو بنیادی طور پر مقبول سوالات کے تیار جوابات کو ذخیرہ کرتا ہے، اور صرف ترقی کی آسانی کے مسائل کو حل کر سکتا ہے، لیکن رفتار نہیں۔

آخر میں، ایم ایس ایس کیو ایل سرور آپ کو دستاویز کی تعمیر کے مخالف مسئلے کو حل کرنے کی اجازت دیتا ہے: آپ JSON کو ٹیبلز میں تحلیل کر سکتے ہیں۔ OPENJSON. اگر دستاویز مکمل طور پر فلیٹ نہیں ہے، تو آپ کو استعمال کرنے کی ضرورت ہوگی۔ CROSS APPLY.

MS SQL سرور میں گراف ماڈل

مائیکروسافٹ ایس کیو ایل سرور میں گراف (LPG) ماڈل کے لیے سپورٹ بھی مکمل طور پر نافذ ہے۔ پیشین گوئی: نوڈس کو ذخیرہ کرنے اور گراف کے کناروں کو ذخیرہ کرنے کے لیے خصوصی میزیں استعمال کرنے کی تجویز ہے۔ اس طرح کی میزیں تاثرات کا استعمال کرتے ہوئے بنائی جاتی ہیں۔ 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

اس سیکشن میں، میں دستاویز DBMSs میں ملٹی ماڈل کے نفاذ کی مثال دینا چاہوں گا جس میں ان میں سے سب سے زیادہ مقبول نہیں، MongoDB (جیسا کہ کہا گیا ہے، اس میں صرف مشروط گراف آپریٹرز ہوتے ہیں۔ $lookup и $graphLookup، شارڈڈ کلیکشنز پر کام نہیں کر رہا ہے) لیکن ایک زیادہ پختہ اور "انٹرپرائز" DBMS کی مثال استعمال کرتے ہوئے مارک لاجک.

لہذا، مجموعہ میں درج ذیل قسم کے 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>

آپ ایس کیو ایل استفسار (مثال کے طور پر، بذریعہ 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>

آپ SPARQL استفسار کے ساتھ نتیجے میں RDF گراف کو ایڈریس کر سکتے ہیں:

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

رشتہ دار کے برعکس، MarkLogic گراف ماڈل کو دو دیگر طریقوں سے سپورٹ کرتا ہے:

ڈی بی ایم ایس آر ڈی ایف ڈیٹا کا ایک مکمل علیحدہ ذخیرہ ہوسکتا ہے (اس میں ٹرپلٹس کہا جائے گا میں کامیاب اوپر بیان کردہ ان کے برعکس نکالا).
خصوصی سیریلائزیشن میں RDF آسانی سے XML یا JSON دستاویزات میں داخل کیا جا سکتا ہے (اور پھر تینوں کو کہا جائے گا غیر منظم)۔ یہ شاید میکانزم کا متبادل ہے۔ idref وغیرہ

MarkLogic میں چیزیں "واقعی" کیسے کام کرتی ہیں اس کا ایک اچھا خیال ہے۔ آپٹیکل API, اس لحاظ سے، یہ نچلی سطح کا ہے، حالانکہ اس کا مقصد اس کے برعکس ہے - استعمال کیے گئے ڈیٹا ماڈل سے خلاصہ کرنے کی کوشش کرنا، مختلف ماڈلز میں ڈیٹا کے ساتھ مسلسل کام کو یقینی بنانا، لین دین وغیرہ۔

ملٹی ماڈل DBMS "بغیر مرکزی ماڈل کے"

مارکیٹ میں ایسے DBMSs بھی ہیں جو اپنے آپ کو ابتدائی طور پر ملٹی ماڈل کے طور پر پوزیشن دیتے ہیں، بغیر کسی وراثت میں ملے مرکزی ماڈل کے۔ یہ شامل ہیں ارنگو ڈی بی۔, اورینٹل ڈی بی (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"
    }
  ]

جیسا کہ ہم دیکھ سکتے ہیں، vertices آنے والے اور جانے والے کناروں کے بارے میں بھی معلومات محفوظ کرتے ہیں۔ پر استعمال کرتے ہوئے دستاویز 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 درج ذیل ڈیٹا تک رسائی APIs فراہم کرتا ہے: SQL، MongoDB، Gremlin اور Cassandra۔

SQL API اور MongoDB API کو دستاویز کے ماڈل میں ڈیٹا تک رسائی کے لیے استعمال کیا جاتا ہے۔ Gremlin API اور Cassandra API - بالترتیب گراف اور کالم فارمیٹس میں ڈیٹا تک رسائی کے لیے۔ تمام ماڈلز کا ڈیٹا CosmosDB اندرونی ماڈل فارمیٹ میں محفوظ کیا جاتا ہے: ARS ("ایٹم-ریکارڈ-سیکونس")، جو دستاویز کے ایک کے قریب بھی ہے۔

لیکن صارف کے ذریعہ منتخب کردہ ڈیٹا ماڈل اور استعمال شدہ API سروس میں اکاؤنٹ بنانے کے وقت طے ہوتے ہیں۔ ایک ماڈل میں لوڈ کردہ ڈیٹا تک دوسرے ماڈل کی شکل میں رسائی ممکن نہیں ہے، جیسا کہ کچھ اس طرح سے واضح کیا گیا ہے:

اس طرح، Azure CosmosDB میں ملٹی ماڈل آج صرف ایک مینوفیکچرر کے مختلف ماڈلز کو سپورٹ کرنے والے متعدد ڈیٹا بیس استعمال کرنے کی صلاحیت ہے، جو ملٹی ویرینٹ اسٹوریج کے تمام مسائل کو حل نہیں کرتا ہے۔

گراف ماڈل پر مبنی ملٹی ماڈل DBMS؟

قابل ذکر حقیقت یہ ہے کہ مارکیٹ میں ابھی تک کوئی ملٹی ماڈل DBMSs موجود نہیں ہیں جو گراف ماڈل پر مبنی ہوں (سوائے ایک ساتھ دو گراف ماڈلز کے لیے ملٹی ماڈل سپورٹ کے: RDF اور LPG؛ اسے دیکھیں پچھلی اشاعت)۔ سب سے بڑی مشکلات گراف ماڈل کے اوپری حصے پر ایک دستاویزی ماڈل کے نفاذ کی وجہ سے ہوتی ہیں، بجائے اس کے کہ ایک رشتہ دار ہو۔

گراف ماڈل کے اوپری حصے پر رشتہ دار ماڈل کو کیسے نافذ کیا جائے اس سوال پر مؤخر الذکر کی تشکیل کے دوران بھی غور کیا گیا تھا۔ کیسے بات کیمثال کے طور پر ڈیوڈ میک گورن:

گراف کے نقطہ نظر میں ایسی کوئی چیز موجود نہیں ہے جو گراف ڈیٹا بیس پر ایک پرت (مثلاً مناسب اشاریہ سازی کے ذریعے) بنانے سے روکتی ہے جو (1) معمول کے کلیدی قدر کے جوڑوں سے ٹیپلز کی بازیافت اور (2) کی گروپ بندی کے ساتھ ایک رشتہ دار نظریہ کو قابل بناتا ہے۔ رشتہ کی قسم کے لحاظ سے tuples

گراف ماڈل کے اوپر دستاویزی ماڈل کو لاگو کرتے وقت، آپ کو ذہن میں رکھنے کی ضرورت ہے، مثال کے طور پر، درج ذیل:

JSON سرنی کے عناصر کو ترتیب دیا گیا سمجھا جاتا ہے، لیکن گراف کے ایک کنارے کے عمودی حصے سے نکلنے والے عناصر نہیں ہیں؛
دستاویز کے ماڈل میں ڈیٹا کو عام طور پر غیر معمولی کیا جاتا ہے؛ آپ اب بھی ایک ہی ایمبیڈڈ دستاویز کی کئی کاپیاں ذخیرہ نہیں کرنا چاہتے ہیں، اور ذیلی دستاویزات میں عام طور پر شناخت کنندہ نہیں ہوتا ہے۔
دوسری طرف، دستاویز DBMSs کا نظریہ یہ ہے کہ دستاویزات تیار شدہ "مجموعی" ہیں جنہیں ہر بار نئے سرے سے تعمیر کرنے کی ضرورت نہیں ہے۔ تیار شدہ دستاویز کے مطابق ایک ذیلی گراف کو تیزی سے حاصل کرنے کی صلاحیت کے ساتھ گراف ماڈل فراہم کرنے کی ضرورت ہے۔

تھوڑا سا اشتہار

مضمون کا مصنف NitrosBase DBMS کی ترقی سے متعلق ہے، جس کا اندرونی ماڈل گراف ہے، اور بیرونی ماڈلز - رشتہ دار اور دستاویز - اس کی نمائندگی ہیں۔ تمام ماڈلز برابر ہیں: تقریباً کوئی بھی ڈیٹا ان میں سے کسی میں بھی استفسار کی زبان کا استعمال کرتے ہوئے دستیاب ہے جو اس کے لیے فطری ہے۔ اس کے علاوہ، کسی بھی نقطہ نظر میں، ڈیٹا کو تبدیل کیا جا سکتا ہے. تبدیلیاں اندرونی ماڈل میں اور اس کے مطابق، دوسرے خیالات میں ظاہر ہوں گی۔

میں امید کے ساتھ مندرجہ ذیل مضامین میں سے کسی ایک میں بیان کروں گا کہ نائٹروس بیس میں ماڈل کی مماثلت کیسی نظر آتی ہے۔

حاصل يہ ہوا

مجھے امید ہے کہ جس چیز کو ملٹی ماڈلنگ کہا جاتا ہے اس کا عمومی خاکہ قارئین پر کم و بیش واضح ہو گیا ہے۔ ملٹی ماڈل ڈی بی ایم ایس بالکل مختلف ہیں، اور "ملٹی ماڈل سپورٹ" مختلف نظر آ سکتی ہے۔ یہ سمجھنے کے لیے کہ ہر مخصوص معاملے میں "ملٹی ماڈل" کیا کہا جاتا ہے، درج ذیل سوالات کا جواب دینا مفید ہے۔

کیا ہم روایتی ماڈلز یا کسی قسم کے "ہائبرڈ" ماڈل کو سپورٹ کرنے کی بات کر رہے ہیں؟
کیا ماڈل "برابر" ہیں، یا ان میں سے ایک دوسرے کا موضوع ہے؟
کیا ماڈل ایک دوسرے سے "لاتعلق" ہیں؟ کیا ایک ماڈل میں لکھا گیا ڈیٹا دوسرے میں پڑھا جا سکتا ہے یا پھر اوور رائٹ بھی کیا جا سکتا ہے؟

مجھے لگتا ہے کہ ملٹی ماڈل ڈی بی ایم ایس کی مطابقت کے بارے میں سوال کا پہلے ہی مثبت جواب دیا جا سکتا ہے، لیکن دلچسپ سوال یہ ہے کہ مستقبل قریب میں ان میں سے کن اقسام کی زیادہ مانگ ہوگی۔ ایسا لگتا ہے کہ ملٹی ماڈل DBMSs جو روایتی ماڈلز کی حمایت کرتے ہیں، بنیادی طور پر رشتہ دار، زیادہ مانگ میں ہوں گے۔ ملٹی ماڈل DBMSs کی مقبولیت، نئے ماڈلز پیش کرتے ہیں جو مختلف روایتی کے فوائد کو یکجا کرتے ہیں، مستقبل قریب کی بات ہے۔

سروے میں صرف رجسٹرڈ صارفین ہی حصہ لے سکتے ہیں۔ سائن ان، برائے مہربانی.

کیا آپ ملٹی ماڈل DBMS استعمال کرتے ہیں؟

ہم اسے استعمال نہیں کرتے، ہم ہر چیز کو ایک DBMS اور ایک ماڈل میں اسٹور کرتے ہیں۔
ہم روایتی DBMSs کی ملٹی ماڈل صلاحیتوں کا استعمال کرتے ہیں۔
ہم پولی گلوٹ استقامت کی مشق کرتے ہیں۔
ہم نئے ملٹی ماڈل DBMS (Arango، Orient، CosmosDB) استعمال کرتے ہیں۔

19 صارفین نے ووٹ دیا۔ 4 صارفین غیر حاضر رہے۔

ماخذ: www.habr.com

کیا ملٹی ماڈل DBMSs جدید معلوماتی نظام کی بنیاد ہیں؟