د معلوماتو عصري سیسټمونه خورا پیچلي دي. لږترلږه، د دوی پیچلتیا په دوی کې د پروسس شوي معلوماتو پیچلتیا له امله ده. د ډیټا پیچلتیا اکثرا د ډیټا ماډلونو مختلف ډولونو کې کارول کیږي. نو، د مثال په توګه، کله چې ډاټا "لوی" شي، یو له ستونزمن ځانګړتیاوو څخه نه یوازې د هغې حجم ("حجم")، بلکې د هغې ډول ("ډول") هم دی.
که تاسو لاهم په استدلال کې نیمګړتیا ونه مومئ ، نو بیا یې ولولئ.
منځپانګې
د پولیګلوټ دوام
پورتني حقیقت د دې لامل کیږي چې ځینې وختونه حتی د یو سیسټم په چوکاټ کې دا اړینه ده چې د ډیټا ذخیره کولو لپاره ډیری مختلف DBMSs وکاروئ او د پروسس کولو مختلف ستونزې حل کړئ ، چې هر یو یې د خپل ډیټا ماډل ملاتړ کوي. د M. Fowler په رڼا لاس سره، یو شمیر مشهور کتابونه او یو دا حالت د ځیرک منشور په نوم یادیږي څو ډوله ذخیره ("پولیګلوټ دوام").
فولر د ای کامرس په ساحه کې د بشپړ ب featuresو او لوړ بار غوښتنلیک کې د ډیټا ذخیره کولو تنظیم کولو لاندې مثال هم لري.
دا بیلګه، البته، یو څه مبالغه ده، مګر د ورته هدف لپاره د یو یا بل DBMS غوره کولو په برخه کې ځینې ملاحظات موندل کیدی شي، د بیلګې په توګه، .
دا څرګنده ده چې په داسې ژوبڼ کې د خدمتګار پاتې کیدل اسانه کار نه دی.
- د کوډ مقدار چې د ډیټا ذخیره کولو ترسره کوي د DBMSs کارول شوي شمیر په تناسب وده کوي؛ د کوډ همغږي کولو ډاټا اندازه ښه ده که چیرې د دې شمیرې مربع سره متناسب نه وي.
- د ډیری کارول شوي DBMSs شمیرې په توګه ، د هرې کارول شوي DBMSs د تصدۍ ځانګړتیاو چمتو کولو لګښتونه (توپیدل ، د غلطۍ زغم ، لوړ شتون) ډیریږي.
- دا ناشونې ده چې د ذخیره کولو فرعي سیسټم تصدۍ ځانګړتیاوې په ټولیزه توګه ډاډمن شي - په ځانګړې توګه د لیږد وړتیا.
د ژوبڼ د رییس له نظره، هر څه داسې ښکاري:
- د DBMS جوړونکي څخه د جوازونو او تخنیکي ملاتړ په لګښت کې ډیری زیاتوالی.
- د کارمندانو زیاتوالی او د وخت زیاتوالی.
- د معلوماتو د متناقض له امله مستقیم مالي زیانونه یا جریمې.
د سیسټم د ملکیت ټول لګښت (TCO) کې د پام وړ زیاتوالی شتون لري. ایا د "ډیری ذخیره کولو اختیارونو" وضعیت څخه کومه لاره شتون لري؟
څو ماډل
د "څو اړخیز ذخیره" اصطلاح په 2011 کې کارول شوې. د چلند د ستونزو په اړه پوهاوی او د حل لټون څو کاله وخت نیولی و، او په 2015 کې، د ګارټینر شنونکو د خولې له لارې، ځواب چمتو شوی و:
- له "»:
د DBMSs راتلونکی، د دوی جوړښت او د دوی کارولو طریقې څو ماډل دي.
- له "»:
مخکښ عملیاتي DBMSs به د یو واحد پلیټ فارم برخې په توګه ډیری ماډلونه - اړونده او غیر اړونده - وړاندیز وکړي.
داسې بریښي چې دا ځل د ګارټینر شنونکي د دوی وړاندوینې سره سم وو. که تاسو سره پاڼې ته لاړ شئ DBMS په DB-Engines کې، تاسو کولی شئ دا وګورئоد دې ډیری مشران ځانونه په ځانګړي ډول د څو ماډل DBMSs په توګه موقعیت لري. ورته په پاڼه کې د هرې خصوصي درجه بندي سره لیدل کیدی شي.
لاندې جدول DBMS ښیي - مشران په هر خصوصي درجه بندي کې، کوم چې ادعا کوي څو ماډل وي. د هر DBMS لپاره، اصلي ملاتړ شوی ماډل (کوم چې یو وخت یوازینی و) او د دې تر څنګ هغه ماډلونه چې اوس مهال یې ملاتړ شوي ښودل شوي. همدارنګه د DBMSs لیست شوي چې ځانونه د "اصلي څو ماډل" په توګه موقعیت لري او د جوړونکو په وینا، کوم ابتدايي میراثي ماډل نلري.
| DBMS | ابتدايي ماډل | اضافي ماډلونه |
|---|---|---|
| سينه_پوښ | اړونده | ګراف، سند |
| MS SQL | اړونده | ګراف، سند |
| پوسټری ایس ایس ایل | اړونده | ګراف*، سند |
| MarkLogic | مستند | ګراف، اړونده |
| MongoDB | مستند | کلیدي ارزښت، ګراف* |
| ډیټا سټیکس | پراخه کالم | مستند، ګراف |
| Redis | کلیدي ارزښت | مستند، ګراف* |
| ArangoDB | - | ګراف، سند |
| اوینټینډ بی بی | - | ګراف، سند، اړونده |
| Azure کاسموسDB | - | ګراف، سند، اړونده |
په میز کې یادښتونه
په جدول کې ستوري په نښه شوي بیانات چې ریزرویشن ته اړتیا لري:
- د PostgreSQL DBMS د ګراف ډیټا ماډل ملاتړ نه کوي، مګر دا محصول د دې ملاتړ کوي , لکه AgensGraph.
- د MongoDB په تړاو، دا د پوښتنې په ژبه کې د ګراف آپریټرانو شتون په اړه خبرې کول خورا سم دي (, ) د ګراف ماډل مالتړ کولو په پرتله، که څه هم، البته، د دوی پیژندنه د ګراف ماډل مالتړ په لور د فزیکي ذخیره کولو په کچه ځینې اصلاح ته اړتیا لري.
- د ریډیس په اړه، موږ د توسیع معنی لرو .
بیا، د هر ټولګي لپاره، موږ به وښیو چې څنګه د دې ټولګي څخه په DBMS کې د څو ماډلونو ملاتړ پلي کیږي. موږ به اړونده، سند او ګراف ماډلونه تر ټولو مهم وګڼو او د ځانګړو DBMSs مثالونه وکاروو ترڅو وښیو چې څنګه "د ورک شوي" پلي کیږي.
ملټي ماډل DBMS د اړونده ماډل پراساس
مخکښ DBMSs اوس مهال اړونده دي؛ د ګارټینر وړاندوینه نشي کولی ریښتیا وګڼل شي که چیرې RDBMSs د څو ماډلینګ په لور حرکت ونه کړي. او دوی مظاهرې کوي. اوس دا مفکوره چې یو څو ماډل DBMS د سویس چاقو په څیر دی، کوم چې هیڅ شی نشي کولی، مستقیم لیري ایلیسن ته لارښوونه وکړي.
په هرصورت، لیکوال د مایکروسافټ ایس کیو ایل سرور کې د څو ماډلینګ پلي کولو ته ترجیح ورکوي، د بیلګې په توګه د سند او ګراف ماډلونو لپاره د RDBMS ملاتړ به بیان شي.
په MS SQL سرور کې د سند ماډل
د هابري په اړه لا دمخه دوه غوره مقالې شتون لري چې څنګه د MS SQL سرور د سند ماډل لپاره ملاتړ پلي کوي؛ زه به خپل ځان په لنډه بیا ویلو او تبصرې پورې محدود کړم:
په MS SQL سرور کې د سند ماډل ملاتړ کولو لاره د اړونده DBMSs لپاره خورا عام ده: د JSON سندونه وړاندیز شوي چې په عادي متن برخو کې زیرمه شي. د سند ماډل لپاره ملاتړ د دې JSON پارس کولو لپاره ځانګړي آپریټر چمتو کول دي:
- د سکالر خاصیت ارزښتونو استخراج لپاره
- د فرعي اسنادو د استخراج لپاره.
د دواړو آپریټرانو دوهم دلیل د JSONPath په څیر ترکیب کې بیان دی.
په لنډه توګه، موږ کولی شو ووایو چې په دې طریقه ذخیره شوي اسناد په اړونده DBMS کې "لومړي درجې ادارې" ندي، د ټپلونو برعکس. په ځانګړې توګه، په MS SQL سرور کې اوس مهال د JSON اسنادو ساحو کې هیڅ شاخصونه شتون نلري، کوم چې د دې ساحو ارزښتونو په کارولو سره د جدولونو سره یوځای کول ستونزمن کوي او حتی د دې ارزښتونو په کارولو سره اسناد غوره کوي. په هرصورت، دا ممکنه ده چې د داسې ساحې لپاره حساب شوي کالم او په هغې کې یو شاخص جوړ کړئ.
سربیره پردې ، د MS SQL سرور د آپریټر په کارولو سره د میزونو مینځپانګې څخه په اسانۍ سره د JSON سند جوړولو وړتیا چمتو کوي - یو احتمال، په یو مشخص معنی کې، د تیر یو برعکس، دودیز ذخیره. دا روښانه ده چې RDBMS څومره ګړندی وي ، دا طریقه د DBMSs سند ایډیالوژۍ سره په تضاد کې ده ، کوم چې په لازمي ډول د مشهور پوښتنو لپاره چمتو شوي ځوابونه ذخیره کوي ، او کولی شي یوازې د پراختیا اسانه ستونزې حل کړي ، مګر سرعت نه.
په نهایت کې ، د MS SQL سرور تاسو ته اجازه درکوي د سند جوړولو برعکس ستونزه حل کړئ: تاسو کولی شئ JSON په جدولونو کې له مینځه یوسي . که سند په بشپړه توګه فلیټ نه وي، نو تاسو به یې کارولو ته اړتیا ولرئ CROSS APPLY.
په MS SQL سرور کې د ګراف ماډل
د ګراف (LPG) ماډل لپاره ملاتړ هم په بشپړ ډول د مایکروسافټ 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 سرور کې د سند او ګراف ماډلونو پلي کولو توضیحاتو لنډیز کولو لپاره ، زه به یادونه وکړم چې د یو ماډل په سر کې دا ډول پلي کول بریالي نه بریښي ، په عمده ډول د ژبې ډیزاین له نظره. دا اړینه ده چې یوه ژبه له بلې سره وغځول شي، ژبې په بشپړه توګه "اورتوګونل" ندي، د مطابقت قواعد خورا عجیب وي.
د سند ماډل پراساس ملټي ماډل DBMS
پدې برخه کې، زه غواړم د DBMSs په سند کې د څو ماډلونو پلي کول روښانه کړم د مثال په کارولو سره چې د دوی خورا مشهور ندي، MongoDB (لکه څنګه چې ویل شوي، دا یوازې مشروط ګراف آپریټرونه لري. $lookup и $graphLookup، په شارډ شوي راټولولو باندې کار نه کوي) مګر د ډیر بالغ او "شرکت" DBMS مثال په کارولو سره .
نو، اجازه راکړئ چې ټولګه د لاندې ډول د XML اسنادو سیټ ولري (مارک لوجیک تاسو ته اجازه درکوي د JSON اسناد ذخیره کړئ):
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>په مارکلوجیک کې اړونده ماډل
د اسنادو د راټولولو اړونده لید په کارولو سره رامینځته کیدی شي (د عناصرو منځپانګې value په لاندې مثال کې کیدای شي په خپل سري XPath وي):
<template >
<context>/Person</context>
<rows>
<row>
<view-name>Person</view-name>
<columns>
<column>
<name>SSN</name>
<value>@SSN</value>
<type>string</type>
</column>
<column>
<name>name</name>
<value>name</value>
</column>
<column>
<name>surname</name>
<value>surname</value>
</column>
</columns>
</row>
<rows>
</template>تاسو کولی شئ رامینځته شوی لید د SQL پوښتنې سره حل کړئ (د مثال په توګه د ODBC له لارې):
SELECT name, surname FROM Person WHERE name="John"له بده مرغه، د نندارې ټیمپلیټ لخوا رامینځته شوی اړوند لید یوازې د لوستلو وړ دی. کله چې د دې لپاره غوښتنه پروسس کول ، مارک لوجیک به د کارولو هڅه وکړي . پخوا، 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 .
}د اړونده یو برعکس، مارکلوجیک په دوو نورو لارو کې د ګراف ماډل ملاتړ کوي:
- A DBMS د RDF ډیټا بشپړ جلا جلا ذخیره کیدی شي (په دې کې به درې ګونی ویل کیږي) د پورته ذکر شوي برعکس ).
- په ځانګړي سیریل کولو کې RDF په ساده ډول د XML یا JSON اسنادو کې دننه کیدی شي (او بیا به درې ګونی بلل کیږي ). دا شاید د میکانیزمونو لپاره بدیل وي
idrefاو نور.
یو ښه نظر چې څنګه شیان "ریښتیا" په MarkLogic کې کار کوي لخوا ورکړل شوي په دې معنی، دا ټیټه کچه ده، که څه هم هدف یې برعکس دی - د کارول شوي ډیټا ماډل څخه د خلاصون هڅه کول، ترڅو په مختلفو ماډلونو کې د معلوماتو سره ثابت کار یقیني کړي، لیږد، او نور.
څو ماډل DBMS "د اصلي ماډل پرته"
په بازار کې DBMSs هم شتون لري چې خپل ځان په پیل کې د څو ماډل په توګه موقعیت لري، پرته له کوم میراثي اصلي ماډل. پدې کې شامل دي , (د 2018 راهیسې پراختیایی شرکت د SAP پورې اړه لري) او (د مایکروسافټ Azure کلاوډ پلیټ فارم برخې په توګه خدمت).
په حقیقت کې، په ArangoDB او OrientDB کې "اصلي" ماډلونه شتون لري. په دواړو حالتونو کې، دا د دوی خپل ډیټا ماډلونه دي، کوم چې د سند عمومي کول دي. عمومي کول په عمده توګه د ګراف او اړونده نوعیت پوښتنو ترسره کولو وړتیا اسانه کول دي.
دا ماډلونه یوازینی هغه دي چې په ټاکل شوي DBMS کې د کارولو لپاره شتون لري؛ د دوی خپلې پوښتنې ژبې د دوی سره کار کولو لپاره ډیزاین شوي. البته، دا ډول ماډلونه او DBMSs ژمن دي، مګر د معیاري ماډلونو او ژبو سره د مطابقت نشتوالی په میراثي سیسټمونو کې د دې DBMSs کارول ناممکن کوي - د DBMSs ځای په ځای کولو لپاره چې دمخه هلته کارول شوي.
په Habré کې د ArangoDB او OrientDB په اړه لا دمخه یوه په زړه پوري مقاله وه: .
ArangoDB
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 په پرتله خورا عام وي، تاسو کولی شئ دا پوښتنه هڅه وکړئ (یا تاسو کولی شئ کار واخلئ ):
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": "Жан-Жак" }
]که چیرې د پایلې بڼه بیا ډیر "اړخیز" ښکاري، نو تاسو اړتیا لرئ چې کرښه لرې کړئ :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]د OrientDB د پوښتنو ژبه د ګریملین په څیر داخلونو سره د SQL په توګه تشریح کیدی شي. په 2.2 نسخه کې، د سایفر په څیر د غوښتنې فورمه ښکاره شوه، :
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 کاسموسDB
تر یوې اندازې پورې، هغه څه چې د ArangoDB او OrientDB په اړه پورته ویل شوي په Azure CosmosDB باندې تطبیق کیږي. CosmosDB د لاندې معلوماتو لاسرسي APIs چمتو کوي: SQL، MongoDB، Gremlin او Cassandra.
SQL API او MongoDB API د سند ماډل کې ډیټا ته لاسرسي لپاره کارول کیږي. Gremlin API او Cassandra API - په ترتیب سره په ګراف او کالم فارمیټونو کې ډیټا ته لاسرسي لپاره. په ټولو ماډلونو کې ډاټا د CosmosDB داخلي ماډل بڼه کې خوندي کیږي: ("اټوم-ریکارډ-سلسل")، کوم چې یو سند ته هم نږدې دی.
مګر د کارونکي لخوا غوره شوي ډیټا ماډل او کارول شوي API په خدمت کې د حساب رامینځته کولو په وخت کې ټاکل شوي. دا ممکنه نده چې په یو ماډل کې بار شوي ډیټا ته د بل ماډل په شکل کې لاسرسی ومومئ ، لکه څنګه چې د دې په څیر یو څه ښودل شوي:
پدې توګه ، نن ورځ په Azure CosmosDB کې ملټي ماډل یوازې د یو تولید کونکي څخه د مختلف ماډلونو ملاتړ کولو ډیری ډیټابیسونو کارولو وړتیا لري ، کوم چې د څو متغیر ذخیره کولو ټولې ستونزې نه حل کوي.
د ګراف ماډل پراساس څو ماډل DBMS؟
د یادونې وړ حقیقت دا دی چې لاهم په بازار کې د څو ماډل DBMSs شتون نلري چې د ګراف ماډل پراساس وي (پرته له دې چې په ورته وخت کې د دوه ګراف ماډلونو لپاره ملټي ماډل ملاتړ: RDF او LPG؛ دا وګورئ ). ترټولو لوی مشکلات د ګراف ماډل په سر کې د سند ماډل پلي کولو له امله رامینځته کیږي ، نه د اړونده.
د ګراف موډل په سر کې د اړونده ماډل پلي کولو څرنګوالي پوښتنه حتی د وروستي رامینځته کیدو پرمهال هم په پام کې نیول شوې وه. هغه څنګه د مثال په توګه :
د ګراف په طریقه کې هیڅ شی شتون نلري چې د ګراف ډیټابیس کې د پرت رامینځته کولو مخه ونیسي (د مثال په توګه د مناسب شاخص په واسطه) چې د (1) د عادي کلیدي ارزښت جوړو څخه د ټپلونو بیرته راګرځولو او (2) ګروپ کولو سره د تړاو لید وړ کوي. د اړیکو ډول له مخې tuples.
کله چې د ګراف ماډل په سر کې د سند ماډل پلي کول ، تاسو اړتیا لرئ په ذهن کې وساتئ ، د مثال په توګه ، لاندې:
- د JSON سرې عناصر ترتیب شوي ګڼل کیږي، مګر هغه چې د ګراف د یوې څنډې څخه راوتلي ندي؛
- د سند ماډل کې ډاټا معمولا غیر معمولي کیږي؛ تاسو لاهم نه غواړئ د ورته سرایت شوي سند ډیری کاپي ذخیره کړئ، او فرعي اسناد معمولا پیژندونکي نلري؛
- له بلې خوا، د اسنادو DBMSs نظریه دا ده چې اسناد چمتو شوي "مجموعې" دي چې اړتیا نلري هر ځل بیا جوړ شي. دا اړینه ده چې د ګراف ماډل چمتو کړئ د دې وړتیا سره چې ژر تر ژره د بشپړ شوي سند سره سم فرعي ګراف ترلاسه کړئ.
لږ اعلان
د مقالې لیکوال د NitrosBase DBMS پراختیا سره تړاو لري، داخلي ماډل چې ګراف دی، او بهرني ماډلونه - اړونده او سند - د هغې نمایندګي دي. ټول ماډلونه مساوي دي: نږدې هر ډول ډاټا د پوښتنې ژبې په کارولو سره په دوی کې شتون لري چې طبیعي وي. برسېره پردې، په هر نظر کې، ډاټا بدل کیدی شي. بدلونونه به په داخلي ماډل کې منعکس شي او، په وینا، په نورو نظرونو کې.
زه به امید لرم چې په لاندې مقالو کې په نایټروس بیس کې د کوم ماډل میچنګ په څیر ښکاري تشریح کړم.
پایلې
زه امید لرم چې د هغه څه عمومي توضیحات چې د څو ماډلینګ په نوم یادیږي لوستونکي ته لږ یا لږ روښانه شوي وي. ملټي ماډل DBMSs خورا توپیر لري، او "ملټي ماډل مالتړ" کیدای شي مختلف ښکاري. د دې پوهیدو لپاره چې په هره ځانګړې قضیه کې "ملټي ماډل" څه ویل کیږي، دا ګټوره ده چې لاندې پوښتنو ته ځواب ووایاست:
- ایا موږ د دودیز ماډل یا یو ډول "هایبرډ" ماډل ملاتړ کولو په اړه خبرې کوو؟
- ایا ماډلونه "مساوي" دي، یا یو له دوی څخه د نورو موضوع ده؟
- ایا ماډلونه یو بل ته "بې پروا" دي؟ ایا په یوه ماډل کې لیکل شوي معلومات په بل کې لوستل کیدی شي یا حتی له سره لیکل کیدی شي؟
زه فکر کوم چې د څو ماډل DBMS د تړاو په اړه پوښتنې لا دمخه په مثبت ډول ځواب کیدی شي، مګر په زړه پورې پوښتنه دا ده چې کوم ډول ډولونه به په نږدې راتلونکي کې په تقاضا کې ډیر وي. داسې ښکاري چې څو ماډل DBMSs چې د دودیزو ماډلونو مالتړ کوي، په ابتدايي توګه اړونده، به په ډیره تقاضا کې وي؛ د ملټي ماډل DBMSs شهرت، د نوي ماډلونو وړاندیز کوي چې د مختلفو دودیزو ګټو سره یوځای کوي، د ډیر لرې راتلونکي مسله ده.
یوازې راجستر شوي کاروونکي کولی شي په سروې کې برخه واخلي. مهرباني وکړئ
ایا تاسو څو ماډل DBMS کاروئ؟
-
موږ دا نه کاروو، موږ هرڅه په یو DBMS او یو ماډل کې ذخیره کوو
-
موږ د دودیز DBMSs څو ماډل وړتیاوې کاروو
-
موږ د پولیګلوټ دوام تمرین کوو
-
موږ د نوي ملټي ماډل DBMS کاروو (ارنګو، اورینټ، کاسموس ډی بی)
19 کاروونکو رایه ورکړه. 4 کاروونکي منع شوي.
سرچینه: www.habr.com