سیستم های اطلاعاتی مدرن بسیار پیچیده هستند. مهمتر از همه، پیچیدگی آنها به دلیل پیچیدگی داده های پردازش شده در آنها است. پیچیدگی داده ها اغلب در مدل های مختلف داده مورد استفاده نهفته است. بنابراین، برای مثال، هنگامی که داده ها "بزرگ" می شوند، یکی از ویژگی های مشکل ساز نه تنها حجم آن ("حجم")، بلکه تنوع آن ("تنوع") است.
اگر هنوز نقصی در استدلال پیدا نکردید، ادامه مطلب را بخوانید.
مقدار
تداوم چند زبانه
موارد فوق منجر به این واقعیت می شود که گاهی اوقات حتی در چارچوب یک سیستم لازم است از چندین DBMS مختلف برای ذخیره داده ها و حل مشکلات مختلف پردازش آنها استفاده شود که هر کدام از مدل داده های خاص خود را پشتیبانی می کنند. با دست سبک M. Fowler، تعدادی از کتاب های معروف و یکی از مانیفست چابک، این وضعیت نامیده می شود ذخیره سازی چند متغیره ("تداوم چند زبانه").
فاولر همچنین مثال زیر را از سازماندهی ذخیره سازی داده ها در یک برنامه کاربردی با امکانات کامل و پر بار در زمینه تجارت الکترونیک دارد.
البته این مثال تا حدودی اغراق آمیز است، اما برخی ملاحظات به نفع انتخاب یک یا آن DBMS برای هدف مربوطه را می توان یافت، به عنوان مثال، .
واضح است که خدمتگزار بودن در چنین باغ وحشی کار آسانی نیست.
- مقدار کدی که ذخیره سازی داده را انجام می دهد متناسب با تعداد DBMS های استفاده شده افزایش می یابد. مقدار داده های همگام سازی کد اگر متناسب با مربع این عدد نباشد خوب است.
- به عنوان مضربی از تعداد DBMS های مورد استفاده، هزینه های ارائه ویژگی های سازمانی (مقیاس پذیری، تحمل خطا، در دسترس بودن بالا) هر یک از DBMS های مورد استفاده افزایش می یابد.
- اطمینان از ویژگی های سازمانی زیرسیستم ذخیره سازی به عنوان یک کل - به ویژه تراکنش پذیری - غیرممکن است.
از دیدگاه مدیر باغ وحش همه چیز به این صورت است:
- افزایش چند برابری هزینه مجوزها و پشتیبانی فنی از سوی سازنده DBMS.
- مازاد پرسنل و افزایش مهلت.
- ضررهای مالی یا جریمه های مستقیم ناشی از ناهماهنگی داده ها.
افزایش قابل توجهی در هزینه کل مالکیت سیستم (TCO) وجود دارد. آیا راهی برای خروج از وضعیت "گزینه های ذخیره سازی چندگانه" وجود دارد؟
چند مدل
اصطلاح "ذخیره سازی چند متغیره" در سال 2011 مورد استفاده قرار گرفت. آگاهی از مشکلات این رویکرد و جستجوی راه حل چندین سال به طول انجامید و تا سال 2015 از زبان تحلیلگران گارتنر، پاسخ فرموله شد:
- از جانب "»:
آینده DBMS ها، معماری آنها و روش های استفاده از آنها چند مدلی است.
- از جانب "»:
DBMS های عملیاتی پیشرو چندین مدل - رابطه ای و غیر رابطه ای - را به عنوان بخشی از یک پلتفرم ارائه می دهند.
به نظر می رسد این بار تحلیلگران گارتنر با پیش بینی خود درست بوده اند. اگر به صفحه با DBMS در موتورهای DB، می توانید آن را ببینیدоبسیاری از رهبران آن به طور خاص خود را به عنوان DBMS های چند مدلی قرار می دهند. همین را می توان در صفحه با هر رتبه بندی خصوصی مشاهده کرد.
جدول زیر DBMS را نشان می دهد - رهبران هر یک از رتبه بندی های خصوصی که ادعا می کنند چند مدل هستند. برای هر DBMS، مدل اصلی پشتیبانی شده (که زمانی تنها بود) و همراه با آن مدل هایی که در حال حاضر پشتیبانی می شوند نشان داده شده است. همچنین DBMS هایی که خود را به عنوان "در اصل چند مدل" قرار می دهند و به گفته سازندگان، هیچ مدل اولیه ارثی ندارند، فهرست شده اند.
| DBMS | مدل اولیه | مدل های اضافی |
|---|---|---|
| وحی | رابطه ای | نمودار، سند |
| MS SQL | رابطه ای | نمودار، سند |
| PostgreSQL و | رابطه ای | نمودار*، سند |
| MarkLogic | مستند | نمودار، رابطه ای |
| MongoDB | مستند | کلید-مقدار، نمودار* |
| DataStax | ستون عریض | مستند، نمودار |
| Redis | ارزش کلیدی | مستند، نمودار* |
| آرانگو دی بی | - | نمودار، سند |
| OrientDB | - | نمودار، سند، رابطه ای |
| Azure CosmosDB | - | نمودار، سند، رابطه ای |
یادداشت های جدول
ستاره های جدول عباراتی را که نیاز به رزرو دارند نشان می دهند:
- PostgreSQL DBMS از مدل داده های نموداری پشتیبانی نمی کند، اما این محصول از آن پشتیبانی می کند مانند AgensGraph.
- در رابطه با MongoDB، صحیح تر است که در مورد وجود عملگرهای گراف در زبان پرس و جو صحبت کنیم (, ) نسبت به پشتیبانی از مدل گراف، البته، معرفی آنها نیازمند بهینه سازی هایی در سطح ذخیره سازی فیزیکی در جهت پشتیبانی از مدل نمودار بود.
- در رابطه با Redis منظور ما پسوند است .
در مرحله بعد، برای هر یک از کلاس ها، نحوه اجرای پشتیبانی از چندین مدل در DBMS از این کلاس را نشان خواهیم داد. مدلهای رابطه‌ای، سند و نمودار را مهم‌ترین مدل‌ها در نظر می‌گیریم و از نمونه‌هایی از DBMSهای خاص برای نشان دادن نحوه پیاده‌سازی «آنهایی که از دست رفته» استفاده می‌کنیم.
DBMS چند مدل بر اساس مدل رابطه ای
DBMS های پیشرو در حال حاضر رابطه ای هستند؛ اگر RDBMS ها حرکتی را در جهت مدل سازی چندگانه نشان نمی دادند، پیش بینی گارتنر را نمی توان درست در نظر گرفت. و تظاهرات می کنند. اکنون این ایده که یک DBMS چند مدل مانند یک چاقوی سوئیسی است، که نمی تواند کاری را به خوبی انجام دهد، می تواند مستقیماً به لری الیسون هدایت شود.
با این حال، نویسنده پیاده‌سازی چند مدل‌سازی در مایکروسافت SQL Server را ترجیح می‌دهد، که در مثالی از آن پشتیبانی RDBMS برای مدلهای سند و گراف شرح داده خواهد شد.
مدل سند در MS SQL Server
قبلاً دو مقاله عالی در Habré در مورد نحوه اجرای پشتیبانی از مدل سند توسط MS SQL Server وجود داشته است؛ من خودم را به بازگویی و تفسیر مختصری محدود می کنم:
روش پشتیبانی از مدل سند در MS SQL Server برای DBMS های رابطه ای کاملاً معمولی است: اسناد JSON پیشنهاد می شود در فیلدهای متنی معمولی ذخیره شوند. پشتیبانی از مدل سند ارائه عملگرهای ویژه برای تجزیه این JSON است:
- برای استخراج مقادیر ویژگی اسکالر،
- برای استخراج اسناد فرعی
آرگومان دوم هر دو عملگر عبارتی در دستور JSONPath مانند است.
به طور انتزاعی، می توان گفت که اسناد ذخیره شده به این روش، برخلاف تاپل ها، «موجودات درجه یک» در یک DBMS رابطه ای نیستند. به طور خاص، در MS SQL Server در حال حاضر هیچ نمایه ای بر روی فیلدهای اسناد JSON وجود ندارد، که اتصال جداول با استفاده از مقادیر این فیلدها و حتی انتخاب اسناد با استفاده از این مقادیر را دشوار می کند. با این حال، امکان ایجاد یک ستون محاسبه شده برای چنین فیلدی و یک شاخص روی آن وجود دارد.
علاوه بر این، MS SQL Server توانایی ساخت آسان یک سند JSON را از محتویات جداول با استفاده از اپراتور فراهم می کند. - یک امکان، به معنای معین، برخلاف حالت قبلی، ذخیره سازی متعارف. واضح است که مهم نیست که یک RDBMS چقدر سریع باشد، این رویکرد با ایدئولوژی DBMS های اسنادی که اساساً پاسخ های آماده به سؤالات رایج را ذخیره می کنند، در تضاد است و تنها می تواند مشکلات سهولت توسعه را حل کند، اما نه سرعت.
در نهایت، MS SQL Server به شما اجازه می دهد تا مشکل مخالف ساخت سند را حل کنید: می توانید JSON را با استفاده از جداول تجزیه کنید. . اگر سند کاملاً مسطح نیست، باید از آن استفاده کنید CROSS APPLY.
مدل گراف در MS SQL Server
پشتیبانی از مدل گراف (LPG) نیز به طور کامل در مایکروسافت SQL Server پیاده سازی شده است : استفاده از جداول مخصوص برای ذخیره گره ها و ذخیره لبه های گراف پیشنهاد شده است. چنین جداول با استفاده از عبارات ایجاد می شود CREATE TABLE AS NODE и CREATE TABLE AS EDGE بود.
جداول نوع اول مشابه جداول معمولی برای ذخیره رکوردها هستند و تنها تفاوت خارجی آن این است که جدول حاوی یک فیلد سیستمی است. $node_id - شناسه منحصر به فرد گره گراف در پایگاه داده.
به طور مشابه، جداول نوع دوم دارای فیلدهای سیستمی هستند $from_id и $to_id، ورودی های چنین جداول به وضوح ارتباطات بین گره ها را مشخص می کند. یک جدول جداگانه برای ذخیره روابط از هر نوع استفاده می شود.
اجازه دهید این موضوع را با یک مثال توضیح دهیم. اجازه دهید داده های نمودار طرحی مانند شکل نشان داده شده داشته باشند. سپس برای ایجاد ساختار مربوطه در پایگاه داده باید کوئری های DDL زیر را اجرا کنید:
CREATE TABLE Person (
ID INTEGER NOT NULL,
name VARCHAR(100)
) AS NODE;
CREATE TABLE Cafe (
ID INTEGER NOT NULL,
name VARCHAR(100),
) AS NODE;
CREATE TABLE likes (
rating INTEGER
) AS EDGE;
CREATE TABLE friendOf
AS EDGE;
ALTER TABLE likes
ADD CONSTRAINT EC_LIKES CONNECTION (Person TO Cafe);ویژگی اصلی چنین جداول این است که در پرس و جوها در برابر آنها می توان از الگوهای نمودار با نحو سایفر مانند استفاده کرد (اما، "*"و غیره هنوز پشتیبانی نمی شوند). بر اساس اندازه‌گیری‌های عملکرد، همچنین می‌توان فرض کرد که نحوه ذخیره داده‌ها در این جداول با نحوه ذخیره داده‌ها در جداول معمولی متفاوت است و برای اجرای چنین پرس و جوهای نموداری بهینه شده است.
SELECT Cafe.name
FROM Person, likes, Cafe
WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
AND Person.name = 'John';علاوه بر این، استفاده نکردن از این الگوهای نمودار هنگام کار با چنین جداول بسیار دشوار است، زیرا در پرس و جوهای معمولی SQL برای حل مشکلات مشابه، باید تلاش های بیشتری برای به دست آوردن شناسه گره های "گراف" سیستم انجام شود.$node_id, $from_id, $to_id; به همین دلیل، پرس‌و‌جوها برای درج داده‌ها در اینجا نشان داده نمی‌شوند، زیرا غیرضروری دست و پا گیر هستند.
برای خلاصه کردن شرح پیاده‌سازی مدلهای سند و گراف در MS SQL Server، متذکر می‌شوم که چنین پیاده‌سازی‌هایی از یک مدل در بالای مدل دیگر، در درجه اول از نظر طراحی زبان، موفقیت‌آمیز به نظر نمی‌رسند. لازم است یک زبان را با زبان دیگر گسترش دهید، زبان ها کاملاً "متعامد" نیستند، قوانین سازگاری می تواند بسیار عجیب باشد.
DBMS چند مدل بر اساس مدل سند
در این بخش، می‌خواهم پیاده‌سازی چند مدل را در DBMSهای سند با استفاده از مثالی از محبوب‌ترین آنها یعنی MongoDB نشان دهم (همانطور که گفته شد، فقط عملگرهای گراف شرطی دارد. $lookup и $graphLookup، روی مجموعه های خرد شده کار نمی کند)، اما با استفاده از مثال یک DBMS بالغ تر و «سازمانی» .
بنابراین، اجازه دهید مجموعه شامل مجموعه ای از اسناد XML از نوع زیر باشد (MarkLogic همچنین به شما امکان می دهد اسناد JSON را ذخیره کنید):
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>مدل رابطه ای در MarkLogic
یک نمای رابطه ای از مجموعه ای از اسناد را می توان با استفاده از آن ایجاد کرد (محتوای عناصر value در مثال زیر ممکن است یک XPath دلخواه وجود داشته باشد):
<template >
<context>/Person</context>
<rows>
<row>
<view-name>Person</view-name>
<columns>
<column>
<name>SSN</name>
<value>@SSN</value>
<type>string</type>
</column>
<column>
<name>name</name>
<value>name</value>
</column>
<column>
<name>surname</name>
<value>surname</value>
</column>
</columns>
</row>
<rows>
</template>می توانید نمای ایجاد شده را با یک پرس و جوی SQL (مثلاً از طریق ODBC) آدرس دهی کنید:
SELECT name, surname FROM Person WHERE name="John"متأسفانه نمای رابطه ای ایجاد شده توسط قالب نمایشگر فقط خواندنی است. هنگام پردازش درخواست برای آن، MarkLogic سعی می کند از آن استفاده کند . پیش از این، MarkLogic به طور کامل دیدگاه های رابطه ای محدودی داشت و قابل نوشتن هستند، اما اکنون منسوخ شده تلقی می شوند.
مدل نمودار در MarkLogic
با پشتیبانی از مدل گراف (RDF)، همه چیز تقریباً یکسان است. باز هم با کمک شما می توانید یک نمایش RDF از مجموعه ای از اسناد از مثال بالا ایجاد کنید:
<template >
<context>/Person</context>
<vars>
<var>
<name>PREFIX</name>
<val>"http://example.org/example#"</val>
</var>
</vars>
<triples>
<triple>
<subject><value>sem:iri( $PREFIX || @SSN )</value></subject>
<predicate><value>sem:iri( $PREFIX || surname )</value></predicate>
<object><value>xs:string( surname )</value></object>
</triple>
<triple>
<subject><value>sem:iri( $PREFIX || @SSN )</value></subject>
<predicate><value>sem:iri( $PREFIX || name )</value></predicate>
<object><value>xs:string( name )</value></object>
</triple>
</triples>
</template>می توانید نمودار RDF حاصل را با یک پرس و جو SPARQL آدرس دهی کنید:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}برخلاف مدل رابطه‌ای، MarkLogic از مدل نمودار به دو روش دیگر پشتیبانی می‌کند:
- یک DBMS می تواند یک ذخیره سازی مجزای کامل از داده های RDF باشد (سه گانه در آن نامیده می شود بر خلاف مواردی که در بالا توضیح داده شد ).
- RDF در سریال سازی خاص به سادگی می تواند در اسناد XML یا JSON درج شود (و سپس سه قلوها فراخوانی می شوند. ). این احتمالاً جایگزینی برای مکانیسم ها است
idrefغیره
ایده خوبی از نحوه عملکرد «واقعاً» چیزها در MarkLogic ارائه شده است ، از این نظر، سطح پایینی دارد، اگرچه هدف آن بیشتر برعکس است - تلاش برای انتزاع از مدل داده استفاده شده، اطمینان از کار سازگار با داده ها در مدل های مختلف، تراکنش و غیره.
DBMS چند مدل "بدون مدل اصلی"
همچنین DBMS هایی در بازار وجود دارند که خود را در ابتدا به عنوان چند مدل و بدون هیچ مدل اصلی ارثی قرار می دهند. این شامل , (از سال 2018 شرکت توسعه متعلق به SAP است) و (سرویس به عنوان بخشی از پلت فرم ابری Microsoft Azure).
در واقع، مدلهای هسته‌ای در ArangoDB و OrientDB وجود دارد. در هر دو مورد، اینها مدلهای داده خودشان هستند که تعمیم سند یک هستند. تعمیم ها عمدتاً برای تسهیل توانایی انجام پرس و جوهای گراف و ماهیت رابطه ای هستند.
این مدل‌ها تنها مدل‌هایی هستند که برای استفاده در DBMS مشخص‌شده در دسترس هستند؛ زبان‌های پرس و جو خودشان برای کار با آنها طراحی شده‌اند. البته، چنین مدل‌ها و DBMSهایی امیدوارکننده هستند، اما عدم سازگاری با مدل‌ها و زبان‌های استاندارد، استفاده از این DBMSها را در سیستم‌های قدیمی غیرممکن می‌کند - جایگزینی DBMSهایی که قبلاً در آنجا استفاده می‌شدند.
قبلاً یک مقاله فوق العاده در مورد ArangoDB و OrientDB در Habré وجود داشت: .
آرانگو دی بی
ArangoDB ادعا می کند از یک مدل داده گراف پشتیبانی می کند.
گره های یک گراف در ArangoDB اسناد معمولی هستند و یال ها اسنادی از نوع خاصی هستند که همراه با فیلدهای منظم سیستم دارای (_key, _id, _rev) فیلدهای سیستم _from и _to. اسناد در DBMS اسناد به طور سنتی در مجموعه ها ترکیب می شوند. مجموعه اسنادی که لبه ها را نشان می دهند در ArangoDB مجموعه لبه نامیده می شوند. به هر حال، اسناد مجموعه لبه نیز اسناد هستند، بنابراین یال ها در ArangoDB می توانند به عنوان گره نیز عمل کنند.
داده های خام
بگذارید مجموعه داشته باشیم persons، که اسناد آن به شکل زیر است:
[
{
"_id" : "people/alice" ,
"_key" : "alice" ,
"name" : "Алиса"
},
{
"_id" : "people/bob" ,
"_key" : "bob" ,
"name" : "Боб"
}
]بگذارید یک مجموعه نیز وجود داشته باشد cafes:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "Джон Донн"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Жан-Жак"
}
]سپس مجموعه likes ممکن است به این شکل باشد:
[
{
"_id" : "likes/1" ,
"_key" : "1" ,
"_from" : "persons/alice" ,
"_to" : "cafes/jd",
"since" : 2010
},
{
"_id" : "likes/2" ,
"_key" : "2" ,
"_from" : "persons/alice" ,
"_to" : "cafes/jj",
"since" : 2011
} ,
{
"_id" : "likes/3" ,
"_key" : "3" ,
"_from" : "persons/bob" ,
"_to" : "cafes/jd",
"since" : 2012
}
]پرس و جوها و نتایج
یک پرس و جو به سبک گراف در زبان 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
اساس پیاده سازی یک مدل گراف در بالای مدل سند در 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"
}
]همانطور که می بینیم، راس ها همچنین اطلاعات مربوط به یال های ورودی و خروجی را ذخیره می کنند. در Document API باید خود یکپارچگی ارجاعی را نظارت کند و Graph API این کار را بر عهده می گیرد. اما بیایید ببینیم که دسترسی به OrientDB در زبان‌های پرس و جو «خالص» که در زبان‌های برنامه‌نویسی ادغام نشده‌اند چگونه به نظر می‌رسد.
پرس و جوها و نتایج
یک پرس و جو از نظر هدف مشابه با پرس و جو از مثال ArangoDB در OrientDB به این صورت است:
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 با درج هایی مانند Gremlin توصیف کرد. در نسخه 2.2، یک فرم درخواست Cypher مانند ظاهر شد، :
MATCH {CLASS: Person, AS: person}-likes->{CLASS: Cafe, AS: cafe}
RETURN person.name AS person_name, LIST(cafe.name) AS cafe_name
GROUP BY person_nameفرمت نتیجه مانند درخواست قبلی خواهد بود. به این فکر کنید که چه چیزی باید حذف شود تا آن را "رابطه ای" تر کند، مانند همان پرس و جوی اول.
Azure CosmosDB
تا حدی کمتر، آنچه در بالا در مورد ArangoDB و OrientDB گفته شد در مورد Azure CosmosDB نیز صدق می کند. CosmosDB API های دسترسی به داده های زیر را فراهم می کند: SQL، MongoDB، Gremlin و Cassandra.
SQL API و MongoDB API برای دسترسی به داده ها در مدل سند استفاده می شود. Gremlin API و Cassandra API - به ترتیب برای دسترسی به داده ها در قالب های نمودار و ستون. داده ها در همه مدل ها در قالب مدل داخلی CosmosDB ذخیره می شوند: ("atom-record-sequence") که به سند یک نیز نزدیک است.
اما مدل داده انتخاب شده توسط کاربر و API مورد استفاده در زمان ایجاد یک حساب کاربری در سرویس ثابت هستند. دسترسی به داده های بارگذاری شده در یک مدل در قالب مدل دیگر ممکن نیست، همانطور که با چیزی شبیه به این نشان داده شده است:
بنابراین، چند مدل در Azure CosmosDB امروزه تنها توانایی استفاده از چندین پایگاه داده است که مدلهای مختلف را از یک سازنده پشتیبانی می‌کنند، که همه مشکلات ذخیره‌سازی چند متغیره را حل نمی‌کند.
DBMS چند مدلی بر اساس یک مدل گراف؟
نکته قابل توجه این واقعیت است که هنوز هیچ DBMS چند مدلی در بازار وجود ندارد که مبتنی بر یک مدل گراف باشد (به جز پشتیبانی از چند مدل برای دو مدل گراف به طور همزمان: RDF و LPG؛ این را ببینید ). بزرگترین مشکلات ناشی از اجرای یک مدل سند در بالای یک مدل گراف است، نه یک مدل رابطه ای.
این سوال که چگونه می توان یک مدل رابطه ای را در بالای مدل گراف پیاده سازی کرد، حتی در زمان شکل گیری مدل دوم مورد توجه قرار گرفت. چگونه ، برای مثال :
هیچ چیز ذاتی در رویکرد گراف وجود ندارد که از ایجاد یک لایه (مثلاً با نمایه سازی مناسب) در پایگاه داده گراف جلوگیری کند که یک نمای رابطه ای را با (1) بازیابی تاپل ها از جفت های مقادیر کلیدی معمول و (2) گروه بندی تاپل ها بر اساس نوع رابطه
هنگام پیاده سازی یک مدل سند در بالای یک مدل گراف، باید به عنوان مثال موارد زیر را در نظر داشته باشید:
- عناصر یک آرایه JSON مرتب در نظر گرفته می شوند، اما عناصری که از راس یک یال گراف سرچشمه می گیرند، مرتب نیستند.
- داده‌ها در مدل سند معمولاً غیرعادی می‌شوند؛ شما هنوز نمی‌خواهید چندین نسخه از یک سند جاسازی شده را ذخیره کنید، و اسناد فرعی معمولاً شناسه ندارند.
- از سوی دیگر، ایدئولوژی DBMS های اسنادی این است که اسناد "تجمیع" های آماده ای هستند که نیازی به ساخت مجدد ندارند. لازم است مدل گراف را با توانایی به دست آوردن سریع زیرگراف مربوط به سند نهایی ارائه دهید.
مقداری تبلیغات
نویسنده مقاله مربوط به توسعه DBMS NitrosBase است که مدل داخلی آن نمودار است و مدل های خارجی - رابطه ای و سندی - بازنمایی آن هستند. همه مدل ها برابر هستند: تقریباً هر داده ای در هر یک از آنها با استفاده از زبان پرس و جو که برای آن طبیعی است در دسترس است. علاوه بر این، در هر دیدگاه، داده ها را می توان تغییر داد. تغییرات در مدل داخلی و بر این اساس، در دیدگاه های دیگر منعکس خواهد شد.
امیدوارم در یکی از مقالات زیر توضیح دهم که تطبیق مدل در NitrosBase چگونه است.
نتیجه
امیدوارم خطوط کلی آنچه که چند مدل سازی نامیده می شود، کم و بیش برای خواننده روشن شده باشد. DBMS های چند مدل کاملاً متفاوت هستند و "پشتیبانی از چند مدل" می تواند متفاوت به نظر برسد. برای درک آنچه در هر مورد خاص "چند مدل" نامیده می شود، پاسخ به سوالات زیر مفید است:
- آیا ما در مورد حمایت از مدل های سنتی صحبت می کنیم یا نوعی مدل "هیبرید"؟
- آیا مدل ها "برابر" هستند یا یکی از آنها موضوع دیگری است؟
- آیا مدل ها نسبت به یکدیگر "بی تفاوت" هستند؟ آیا می توان داده های نوشته شده در یک مدل را در مدل دیگر خواند یا حتی بازنویسی کرد؟
من فکر می کنم که به سؤال در مورد ارتباط DBMS چند مدل قبلاً می توان پاسخ مثبت داد، اما سؤال جالب این است که کدام نوع از آنها در آینده نزدیک تقاضا بیشتری خواهند داشت. به نظر می رسد که DBMS های چند مدلی که از مدل های سنتی، عمدتاً رابطه ای، پشتیبانی می کنند، تقاضای بیشتری خواهند داشت. محبوبیت DBMS های چند مدل، ارائه مدل های جدید که مزایای مدل های سنتی مختلف را با هم ترکیب می کنند، موضوع آینده دورتری است.
فقط کاربران ثبت نام شده می توانند در نظرسنجی شرکت کنند. ، لطفا.
آیا از DBMS چند مدل استفاده می کنید؟
-
ما از آن استفاده نمی کنیم، همه چیز را در یک DBMS و در یک مدل ذخیره می کنیم
-
ما از قابلیت های چند مدل DBMS های سنتی استفاده می کنیم
-
ما تداوم چند زبانه را تمرین می کنیم
-
ما از DBMS چند مدل جدید (Arango، Orient، CosmosDB) استفاده می کنیم.
19 کاربر رای دادند. 4 کاربر رای ممتنع دادند.
منبع: www.habr.com