නවීන තොරතුරු පද්ධති ඉතා සංකීර්ණයි. සියල්ලටම වඩා, ඒවායේ සංකීර්ණත්වය ඔවුන් තුළ සැකසූ දත්තවල සංකීර්ණත්වය නිසාය. දත්තවල සංකීර්ණත්වය බොහෝ විට භාවිතා වන විවිධ දත්ත ආකෘති තුළ පවතී. උදාහරණයක් ලෙස, දත්ත "විශාල" බවට පත් වූ විට, ගැටළුකාරී ලක්ෂණ වලින් එකක් වන්නේ එහි පරිමාව ("පරිමාව") පමණක් නොව, එහි විවිධත්වය ("විවිධ") වේ.
ඔබ තවමත් තර්කයේ දෝෂයක් සොයා නොගත්තේ නම්, පසුව කියවන්න.
අන්තර්ගතය
බහු භාෂා නොනැසී පැවතීම
ඉහත සඳහන් කර ඇත්තේ සමහර විට එක් පද්ධතියක රාමුව තුළ පවා දත්ත ගබඩා කිරීමට සහ ඒවා සැකසීමේ විවිධ ගැටළු විසඳීමට විවිධ DBMS කිහිපයක් භාවිතා කිරීම අවශ්ය වන අතර, ඒ සෑම එකක්ම තමන්ගේම දත්ත ආකෘතියට සහය දක්වයි. M. Fowler ගේ සැහැල්ලු හස්තයෙන්, ප්රසිද්ධ පොත් ගණනාවක් සහ එකක් Agile Manifesto, මෙම තත්වය හැඳින්වේ බහු-විචල්‍ය ගබඩාව ("බහු භාෂා ස්ථීරභාවය").
ඊ-වාණිජ්‍යය ක්ෂේත්‍රයේ සම්පූර්ණ විශේෂාංග සහිත සහ ඉහළ බරක් සහිත යෙදුමක දත්ත ගබඩා කිරීම සංවිධානය කිරීමේ පහත උදාහරණය ද ෆෝලර් සතුව ඇත.
මෙම උදාහරණය, ඇත්ත වශයෙන්ම, තරමක් අතිශයෝක්තියට නංවා ඇත, නමුත් අනුරූප අරමුණ සඳහා එකක් හෝ වෙනත් DBMS තෝරා ගැනීමට පක්ෂව සමහර සලකා බැලීම් සොයාගත හැකිය, උදාහරණයක් ලෙස, .
එවැනි සත්වෝද්යානයක සේවකයෙකු වීම පහසු නොවන බව පැහැදිලිය.
- දත්ත ගබඩා කිරීම සිදු කරන කේත ප්‍රමාණය භාවිතා කරන DBMS ගණනට සමානුපාතිකව වර්ධනය වේ; මෙම අංකයේ වර්ගයට සමානුපාතික නොවේ නම් කේත සමමුහුර්ත දත්ත ප්‍රමාණය හොඳයි.
- භාවිතා කරන ලද DBMS සංඛ්‍යාවේ ගුණාකාරයක් ලෙස, භාවිතා කරන එක් එක් DBMS වල ව්‍යවසාය ලක්ෂණ (පරිමාණය කිරීම, දෝෂ ඉවසීම, ඉහළ පවතින බව) සැපයීමේ පිරිවැය වැඩි වේ.
- සමස්තයක් ලෙස ගබඩා උප පද්ධතියේ ව්‍යවසාය ලක්ෂණ සහතික කිරීම කළ නොහැක - විශේෂයෙන් ගනුදෙනුව.
සත්වෝද්යාන අධ්යක්ෂවරයාගේ දෘෂ්ටි කෝණයෙන්, සෑම දෙයක්ම මේ ආකාරයෙන් පෙනේ:
- DBMS නිෂ්පාදකයාගේ බලපත්‍ර සහ තාක්ෂණික සහායවල මිලෙහි බහුවිධ වැඩිවීමක්.
- අතිරික්ත කාර්ය මණ්ඩලය සහ නියමිත කාලසීමාවන් වැඩි කිරීම.
- දත්ත නොගැලපීම හේතුවෙන් සෘජු මූල්‍ය පාඩු හෝ දඬුවම්.
පද්ධතියේ සම්පූර්ණ හිමිකාරිත්වයේ (TCO) සැලකිය යුතු වැඩි වීමක් ඇත. "බහු ගබඩා විකල්ප" තත්වයෙන් මිදීමට මාර්ගයක් තිබේද?
බහු මාදිලිය
"බහුවිචල්ය ගබඩාව" යන යෙදුම 2011 දී භාවිතයට පැමිණියේය. ප්‍රවේශයේ ගැටළු පිළිබඳ දැනුවත්භාවය සහ විසඳුමක් සෙවීම සඳහා වසර කිහිපයක් ගත වූ අතර 2015 වන විට ගාට්නර් විශ්ලේෂකයින්ගේ කටින් පිළිතුර සකස් කරන ලදී:
- සිට "»:
DBMS වල අනාගතය, ඒවායේ ගෘහ නිර්මාණ ශිල්පය සහ ඒවා භාවිතා කරන ආකාරය බහු-ආකෘති වේ.
- සිට "»:
ප්‍රමුඛ මෙහෙයුම් DBMS තනි වේදිකාවක කොටසක් ලෙස-සම්බන්ධතා සහ සම්බන්ධ නොවන-බහු මාදිලි ඉදිරිපත් කරනු ඇත.
මෙවර ගාට්නර් විශ්ලේෂකයින් ඔවුන්ගේ අනාවැකිය නිවැරදි බව පෙනේ. ඔබ සමඟ පිටුවට ගියහොත් DB-Engines මත DBMS, ඔබට එය දැකිය හැකියоඑහි බොහෝ නායකයින් බහු-ආකෘති DBMS ලෙස විශේෂයෙන් ස්ථානගත කර ඇත. ඕනෑම පුද්ගලික ශ්රේණිගත කිරීමක් සහිත පිටුවේ ද එයම දැකිය හැකිය.
පහත වගුවේ දැක්වෙන්නේ DBMS - එක් එක් පුද්ගලික ශ්රේණිගත කිරීම්වල ප්‍රමුඛයන් වන අතර, ඒවා බහු-ආකෘතියක් ලෙස ප්‍රකාශ කරයි. එක් එක් DBMS සඳහා, මුල් සහය දක්වන මාදිලිය (එය වරක් එකම එකක් විය) සහ ඒ සමඟ දැනට සහය දක්වන මාදිලි දක්වා ඇත. "මුලින් බහු-ආකෘතිය" ලෙස ස්ථානගත වන DBMS ද ලැයිස්තුගත කර ඇති අතර, නිර්මාණකරුවන්ට අනුව, කිසිදු ආරම්භක උරුම ආකෘතියක් නොමැත.
| DBMS | ආරම්භක ආකෘතිය | අතිරේක ආකෘති |
|---|---|---|
| ඔරකල් | සම්බන්ධක | ප්රස්තාරය, ලේඛනය |
| MS SQL | සම්බන්ධක | ප්රස්තාරය, ලේඛනය |
| PostgreSQL | සම්බන්ධක | ප්රස්තාරය*, ලේඛනය |
| මාර්ක්ලොජික් | වාර්තාමය | ප්රස්තාරය, සම්බන්ධක |
| MongoDB | වාර්තාමය | ප්රධාන අගය, ප්‍රස්ථාරය* |
| ඩේටාස්ටැක්ස් | පුළුල් තීරුව | වාර්තාමය, ප්රස්තාරය |
| Redis | ප්රධාන වටිනාකම | වාර්තාමය, ප්‍රස්ථාරය* |
| අරන්ගෝ ඩී බී | - | ප්රස්තාරය, ලේඛනය |
| ඔරියන්ට් ඩීබී | - | ප්රස්තාරය, ලේඛනය, සම්බන්ධය |
| Azure CosmosDB | - | ප්රස්තාරය, ලේඛනය, සම්බන්ධය |
මේසය මත සටහන්
වගුවේ ඇති තරු ලකුණු වෙන් කිරීම් අවශ්ය ප්‍රකාශ සලකුණු කරයි:
- PostgreSQL DBMS ප්‍රස්තාර දත්ත ආකෘතියට සහය නොදක්වයි, නමුත් මෙම නිෂ්පාදනය එයට සහය දක්වයි , AgensGraph වැනි.
- MongoDB සම්බන්ධයෙන්, විමසුම් භාෂාවේ ප්රස්ථාර ක්‍රියාකරුවන් සිටීම ගැන කතා කිරීම වඩාත් නිවැරදිය (, ) ප්රස්ථාර ආකෘතියට සහය දැක්වීමට වඩා, ඇත්ත වශයෙන්ම, ඒවායේ හඳුන්වාදීම සඳහා ප්රස්ථාර ආකෘතියට සහාය දක්වන දිශාවට භෞතික ගබඩා මට්ටමින් යම් ප්‍රශස්තිකරණයක් අවශ්ය විය.
- Redis සම්බන්ධව, අපි දිගුව අදහස් කරමු .
ඊළඟට, එක් එක් පන්තිය සඳහා, මෙම පන්තියේ සිට DBMS හි මාදිලි කිහිපයක් සඳහා සහය ක්රියාත්මක වන ආකාරය අපි පෙන්වමු. අපි සම්බන්ධතා, ලේඛන සහ ප්රස්ථාර ආකෘති වඩාත් වැදගත් ලෙස සලකන අතර "අතුරුදහන් වූ ඒවා" ක්රියාත්මක කරන ආකාරය පෙන්වීමට විශේෂිත DBMS වල උදාහරණ භාවිතා කරමු.
සම්බන්ධතා ආකෘතිය මත පදනම් වූ බහු-මාදිලි DBMS
දැනට ප්‍රමුඛ පෙළේ DBMS සම්බන්ධයි; RDBMS බහු-ආකෘතිකරණයේ දිශාවට චලනය නොපෙන්වන්නේ නම් ගාට්නර්ගේ පුරෝකථනය සත්‍ය ලෙස සැලකිය නොහැක. සහ ඔවුන් විදහා දක්වයි. දැන් බහු මාදිලියේ DBMS යනු කිසිවක් හොඳින් කළ නොහැකි ස්විස් පිහියක් වැනි ය යන අදහස කෙලින්ම ලැරී එලිසන් වෙත යොමු කළ හැකිය.
කෙසේ වෙතත්, කතුවරයා මයික්‍රොසොෆ්ට් SQL සේවාදායකයේ බහු-ආකෘතිය ක්රියාත්මක කිරීමට කැමැත්තක් දක්වයි, ලේඛන සහ ප්රස්ථාර ආකෘති සඳහා RDBMS සහාය විස්තර කෙරෙන උදාහරණය මත.
MS SQL සේවාදායකයේ ලේඛන ආකෘතිය
MS SQL සේවාදායකය ලේඛන ආකෘතිය සඳහා සහය ක්රියාත්මක කරන ආකාරය පිළිබඳව Habré හි දැනටමත් විශිෂ්ට ලිපි දෙකක් තිබේ; මම කෙටි නැවත කියවීමට සහ විවරණයකට සීමා කරමි:
MS SQL සේවාදායකයේ ලේඛන ආකෘතියට සහය දැක්වීමේ ක්‍රමය සම්බන්ධිත DBMS සඳහා සාමාන්‍ය වේ: JSON ලේඛන සාමාන්‍ය පෙළ ක්ෂේත්‍රවල ගබඩා කිරීමට යෝජනා කෙරේ. ලේඛන ආකෘතිය සඳහා සහය වන්නේ මෙම JSON විග්‍රහ කිරීමට විශේෂ ක්‍රියාකරුවන් සැපයීමයි:
- Scalar attribute අගයන් උකහා ගැනීමට,
- උප ලේඛන උපුටා ගැනීමට.
ක්‍රියාකරුවන් දෙදෙනාගේම දෙවන තර්කය JSONPath වැනි වාක්‍ය ඛණ්ඩයේ ප්‍රකාශනයකි.
වියුක්තව, මේ ආකාරයෙන් ගබඩා කර ඇති ලේඛන ටියුපල් මෙන් නොව, සම්බන්ධතා DBMS හි "පළමු පන්තියේ ආයතන" නොවන බව අපට පැවසිය හැකිය. විශේෂයෙන්, MS SQL සේවාදායකයේ දැනට JSON ලේඛන ක්ෂේත්‍රවල දර්ශක නොමැත, එමඟින් මෙම ක්ෂේත්‍රවල අගයන් භාවිතා කරමින් වගු සම්බන්ධ කිරීම දුෂ්කර වන අතර මෙම අගයන් භාවිතා කරමින් ලේඛන තෝරා ගැනීම පවා අපහසු වේ. කෙසේ වෙතත්, එවැනි ක්ෂේත්රයක් සඳහා ගණනය කළ තීරුවක් සහ එය මත දර්ශකයක් නිර්මාණය කළ හැකිය.
මීට අමතරව, MS SQL සේවාදායකය මඟින් ක්‍රියාකරු භාවිතයෙන් වගු වල අන්තර්ගතයෙන් JSON ලේඛනයක් පහසුවෙන් තැනීමේ හැකියාව ලබා දේ. - හැකියාවක්, එක්තරා අර්ථයකින්, පෙර එකට ප්‍රතිවිරුද්ධ, සාම්ප්‍රදායික ගබඩා කිරීම. RDBMS කෙතරම් වේගවත් වුවද, මෙම ප්‍රවේශය ජනප්‍රිය විමසුම් සඳහා සූදානම් කළ පිළිතුරු ගබඩා කරන ලේඛන DBMS වල දෘෂ්ටිවාදයට පටහැනි වන අතර සංවර්ධනයේ පහසුව පිළිබඳ ගැටළු පමණක් විසඳිය හැකි නමුත් වේගය නොවන බව පැහැදිලිය.
අවසාන වශයෙන්, MS SQL සේවාදායකය ඔබට ලේඛන තැනීමේ ප්‍රතිලෝම ගැටළුව විසඳීමට ඉඩ දෙයි: ඔබට JSON භාවිතයෙන් වගු වලට වියෝජනය කළ හැකිය. . ලේඛනය සම්පූර්ණයෙන්ම සමතලා නොවේ නම්, ඔබ භාවිතා කිරීමට අවශ්ය වනු ඇත CROSS APPLY.
MS SQL සේවාදායකයේ ප්‍රස්තාර ආකෘතිය
ප්රස්ථාර (LPG) ආකෘතිය සඳහා වන සහය Microsoft 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 සේවාදායකයේ ලේඛනය සහ ප්‍රස්තාර ආකෘති ක්රියාත්මක කිරීම පිළිබඳ විස්තරය සාරාංශ කිරීමට, මූලික වශයෙන් භාෂා නිර්මාණයේ දෘෂ්ටි කෝණයෙන් එක් ආකෘතියක් තවත් එකක් මත ක්රියාත්මක කිරීම සාර්ථක නොවන බව මම සටහන් කරමි. එක් භාෂාවක් තවත් භාෂාවක් සමඟ දිගු කිරීම අවශ්ය වේ, භාෂා සම්පූර්ණයෙන්ම “ඕර්තගෝනල්” නොවේ, අනුකූලතා නීති තරමක් විකාර විය හැකිය.
ලේඛන ආකෘතිය මත පදනම් වූ බහු-ආකෘති DBMS
මෙම කොටසේදී, මම ඒවායින් වඩාත්ම ජනප්‍රිය නොවන මොන්ගෝ ඩීබී හි උදාහරණය භාවිතා කරමින් ලේඛන ඩීබීඑම්එස් වල බහු-මාදිලිය ක්රියාත්මක කිරීම නිරූපණය කිරීමට කැමැත්තෙමි (කියූ පරිදි, එහි ඇත්තේ කොන්දේසි සහිත ප්රස්ථාර ක්‍රියාකරුවන් පමණි. $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>ඔබට SPARQL විමසුමකින් ලැබෙන RDF ප්‍රස්ථාරය ඇමතීමට හැකිය:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}Relational එක මෙන් නොව MarkLogic වෙනත් ආකාර දෙකකින් ප්රස්ථාර ආකෘතියට සහය දක්වයි:
- DBMS යනු RDF දත්තවල පූර්ණ-පරිපූර්ණ වෙනම ගබඩාවක් විය හැකිය (එහි ත්‍රිත්ව ලෙස හැඳින්වේ ඉහත විස්තර කර ඇති ඒවාට ප්රතිවිරුද්ධව ).
- විශේෂ අනුක්‍රමිකකරණයේ ඇති RDF සරලව XML හෝ JSON ලේඛනවලට ඇතුළත් කළ හැක (එවිට ත්‍රිත්ව ලෙස හැඳින්වේ. ) මෙය බොහෝ විට යාන්ත්රණ සඳහා විකල්පයක් විය හැකිය
idrefසහ වෙනත් අය.
MarkLogic හි දේවල් "සැබවින්ම" ක්‍රියා කරන ආකාරය පිළිබඳ හොඳ අදහසක් ලබා දී ඇත , මෙම අර්ථයෙන් ගත් කල, එය පහත් මට්ටමේ ය, නමුත් එහි අරමුණ ප්‍රතිවිරුද්ධ වුවත් - භාවිතා කරන දත්ත ආකෘතියෙන් වියුක්ත කිරීමට උත්සාහ කිරීම, විවිධ මාදිලිවල දත්ත සමඟ ස්ථාවර වැඩ කිරීම සහතික කිරීම, ගනුදෙනු කිරීම යනාදිය.
බහු මාදිලියේ DBMS "ප්රධාන ආකෘතියක් නොමැතිව"
ප්‍රවේණිගත ප්රධාන ආකෘතියක් නොමැතිව, මුලින් බහු-මාදිලි ලෙස ස්ථානගත කරන DBMS ද වෙළඳපොලේ ඇත. මේවාට ඇතුළත් වේ , (2018 සිට සංවර්ධන සමාගම SAP ට අයත් වේ) සහ (Microsoft Azure cloud වේදිකාවේ කොටසක් ලෙස සේවාව).
ඇත්ත වශයෙන්ම, ArangoDB සහ OrientDB හි "core" මාදිලි ඇත. අවස්ථා දෙකේදීම, මේවා ඔවුන්ගේම දත්ත ආකෘති වන අතර ඒවා ලේඛනයේ සාමාන්‍යකරණය වේ. සාමාන්‍යකරණය ප්රධාන වශයෙන් ප්‍රස්ථාරයක සහ සම්බන්ධතා ස්වභාවයේ විමසුම් සිදු කිරීමේ හැකියාව පහසු කිරීම සඳහා වේ.
මෙම ආකෘති නිශ්චිත DBMS හි භාවිතය සඳහා ඇති එකම ඒවා වේ; ඔවුන්ගේම විමසුම් භාෂා ඔවුන් සමඟ වැඩ කිරීමට නිර්මාණය කර ඇත. ඇත්ත වශයෙන්ම, එවැනි ආකෘති සහ ඩීබීඑම්එස් පොරොන්දු වේ, නමුත් සම්මත ආකෘති සහ භාෂා සමඟ නොගැලපීම නිසා පැරණි පද්ධතිවල මෙම ඩීබීඑම්එස් භාවිතා කිරීමට නොහැකි වේ - එහි දැනටමත් භාවිතා කර ඇති ඩීබීඑම්එස් ප්‍රතිස්ථාපනය කිරීමට.
Habré හි ArangoDB සහ OrientDB ගැන දැනටමත් අපූරු ලිපියක් තිබුණි: .
අරන්ගෝ ඩී බී
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
}
]විමසුම් සහ ප්රතිඵල
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 සඳහා සාමාන්‍ය බව පෙනේ නම්, ඔබට මෙම විමසුම උත්සාහ කළ හැකිය (නැතහොත් ඔබට භාවිතා කළ හැක ):
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 ද පැමිණෙන සහ පිටතට යන දාර පිළිබඳ තොරතුරු ගබඩා කරයි. හිදී Document API විසින් යොමු අඛණ්ඩතාව නිරීක්ෂණය කළ යුතු අතර, Graph 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 හි විමසුම් භාෂාව Gremlin වැනි ඇතුළු කිරීම් සහිත 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 CosmosDB
ArangoDB සහ OrientDB ගැන ඉහත කී දේ අඩු ප්‍රමාණයකට Azure CosmosDB සඳහා අදාළ වේ. CosmosDB පහත දත්ත ප්‍රවේශ API සපයයි: SQL, MongoDB, Gremlin සහ Cassandra.
SQL API සහ MongoDB API ලේඛන ආකෘතියේ දත්ත වෙත ප්‍රවේශ වීමට භාවිතා කරයි. Gremlin API සහ Cassandra API - පිළිවෙලින් ප්රස්ථාර සහ තීරු ආකෘතිවල දත්ත වෙත ප්‍රවේශ වීම සඳහා. සියලුම මාදිලිවල දත්ත CosmosDB අභ්යන්තර ආකෘති ආකෘතියෙන් සුරකිනු ලැබේ: (“පරමාණු-වාර්තා අනුපිළිවෙල”), එය ලේඛනයට සමීප වේ.
නමුත් පරිශීලකයා විසින් තෝරා ගන්නා ලද දත්ත ආකෘතිය සහ භාවිතා කරන API සේවාවෙහි ගිණුමක් නිර්මාණය කරන අවස්ථාවේදී සවි කර ඇත. මෙවැනි දෙයකින් නිදර්ශනය කර ඇති පරිදි, එක් ආකෘතියක පටවා ඇති දත්ත වෙනත් ආකෘතියක ආකෘතියකින් ප්‍රවේශ විය නොහැක:
මේ අනුව, අද වන විට Azure CosmosDB හි බහු-ආකෘතිය යනු එක් නිෂ්පාදකයෙකුගෙන් විවිධ මාදිලි සඳහා සහය දක්වන දත්ත සමුදායන් කිහිපයක් භාවිතා කිරීමේ හැකියාව පමණක් වන අතර එමඟින් බහු-විචල්‍ය ගබඩා කිරීමේ සියලුම ගැටළු විසඳන්නේ නැත.
ප්රස්ථාර ආකෘතියක් මත පදනම් වූ බහු-ආකෘති DBMS?
ප්රස්ථාර ආකෘතියක් මත පදනම් වූ බහු-මාදිලි DBMS තවමත් වෙළඳපොලේ නොමැති වීම සැලකිය යුතු කරුණකි (සමකාලීන ප්රස්ථාර ආකෘති දෙකක් සඳහා බහු-ආකෘති සහාය හැර: RDF සහ LPG; මෙය බලන්න ) විශාලතම දුෂ්කරතාවයන් ඇති වන්නේ ප්රස්ථාර ආකෘතියක් මත ලේඛන ආකෘතියක් ක්‍රියාවට නැංවීම, සම්බන්ධකයකට වඩා ය.
ප්රස්ථාර ආකෘතියට ඉහළින් සම්බන්ධතා ආකෘතියක් ක්රියාත්මක කරන්නේ කෙසේද යන ප්‍රශ්නය දෙවැන්න සෑදීමේදී පවා සලකා බලන ලදී. කෙසේද උදාහරණයක් ලෙස :
(1) සාමාන්‍ය ප්රධාන අගය යුගල වලින් ටියුපල් ප්‍රතිසාධනය සහ (2) කාණ්ඩගත කිරීම සමඟින් සම්බන්ධතා දර්ශනයක් සක්‍රීය කරන ප්රස්ථාර දත්ත ගබඩාවක ස්තරයක් (උදා: සුදුසු සුචිගත කිරීම මගින්) නිර්මාණය කිරීම වළක්වන ප්රස්ථාර ප්‍රවේශයට ආවේනික කිසිවක් නොමැත. සම්බන්ධතා වර්ගය අනුව tuples.
ප්රස්ථාර ආකෘතියක් මත ලේඛන ආකෘතියක් ක්රියාත්මක කිරීමේදී, ඔබ මතක තබා ගත යුතුය, උදාහරණයක් ලෙස, පහත සඳහන් දේ:
- JSON අරාවක මූලද්‍රව්‍ය අනුපිළිවෙල ලෙස සලකනු ලැබේ, නමුත් ප්‍රස්ථාරයේ කෙළවරක ශීර්ෂයෙන් නිකුත් වන ඒවා එසේ නොවේ;
- ලේඛන ආකෘතියේ දත්ත සාමාන්‍යයෙන් විකෘති කර ඇත; ඔබට තවමත් එකම කාවැද්දූ ලේඛනයේ පිටපත් කිහිපයක් ගබඩා කිරීමට අවශ්ය නැත, සහ උප ලේඛනවල සාමාන්‍යයෙන් හඳුනාගැනීම් නොමැත;
- අනෙක් අතට, ලේඛන DBMS හි දෘෂ්ටිවාදය නම්, ලේඛන සෑම විටම අලුතින් ගොඩ නැගීමට අවශ්ය නොවන සූදානම් කළ "සමස්තයන්" වේ. නිමි ලේඛනයට අනුරූප වන උපස්ථරයක් ඉක්මනින් ලබා ගැනීමේ හැකියාව සමඟ ප්රස්ථාර ආකෘතිය සැපයීම අවශ්ය වේ.
පොඩි ඇඩ්වර්ටයිසින් එකක්
ලිපියේ කතුවරයා NitrosBase DBMS සංවර්ධනයට සම්බන්ධ වන අතර එහි අභ්යන්තර ආකෘතිය ප්‍රස්ථාරය වන අතර බාහිර ආකෘති - සම්බන්ධතා සහ ලේඛනය - එහි නිරූපණය වේ. සියලුම ආකෘතීන් සමාන වේ: ඕනෑම දත්තයක් පාහේ ඒවාට ස්වභාවික විමසුම් භාෂාවක් භාවිතා කර ඇත. එපමණක් නොව, ඕනෑම දර්ශනයකින්, දත්ත වෙනස් කළ හැකිය. වෙනස්කම් අභ්යන්තර ආකෘතියේ සහ, ඒ අනුව, වෙනත් අදහස්වල පිළිබිඹු වනු ඇත.
NitrosBase හි ආකෘති ගැළපීම කෙබඳුද යන්න පහත ලිපියෙන් එකකින් විස්තර කිරීමට බලාපොරොත්තු වෙමි.
නිගමනය
බහු-ආකෘතිය ලෙස හඳුන්වන දෙයෙහි සාමාන්‍ය දළ සටහන් පාඨකයාට අඩු වැඩි වශයෙන් පැහැදිලි වී ඇතැයි මම බලාපොරොත්තු වෙමි. Multi-model DBMSs බෙහෙවින් වෙනස් වන අතර, "බහු මාදිලියේ සහාය" වෙනස් ලෙස පෙනෙනු ඇත. එක් එක් විශේෂිත අවස්ථාවක "බහු මාදිලිය" යනුවෙන් හඳුන්වන්නේ කුමක්ද යන්න තේරුම් ගැනීමට, පහත සඳහන් ප්රශ්නවලට පිළිතුරු සැපයීම ප්රයෝජනවත් වේ:
- අපි කතා කරන්නේ සාම්ප්‍රදායික ආකෘතීන් හෝ යම් ආකාරයක "දෙමුහුන්" ආකෘතියක් සඳහා සහාය වීම ගැනද?
- ආකෘති "සමාන" ද, නැතහොත් ඒවායින් එකක් අනෙක් අයගේ විෂය ද?
- ආකෘති එකිනෙකාට "උදාසීන" ද? එක් ආකෘතියක ලියා ඇති දත්ත තවත් ආකෘතියකින් කියවිය හැකිද හෝ උඩින් ලිවිය හැකිද?
බහු මාදිලියේ DBMS හි අදාළත්වය පිළිබඳ ප්‍රශ්නයට දැනටමත් ධනාත්මකව පිළිතුරු දිය හැකි යැයි මම සිතමි, නමුත් සිත්ගන්නා ප්‍රශ්නය වන්නේ නුදුරු අනාගතයේ දී වැඩි ඉල්ලුමක් ඇති ඒවායින් කුමන වර්ගද යන්නයි. සාම්ප්‍රදායික මාදිලි සඳහා සහය දක්වන බහු-ආකෘති DBMS, මූලික වශයෙන් සම්බන්ධක, වැඩි ඉල්ලුමක් ඇති බව පෙනේ; බහු මාදිලියේ DBMS වල ජනප්‍රියතාවය, විවිධ සාම්ප්‍රදායික ඒවායේ වාසි ඒකාබද්ධ කරන නව මාදිලි ඉදිරිපත් කිරීම, වඩාත් දුරස්ථ අනාගතයේ කාරණයකි.
සමීක්ෂණයට සහභාගී විය හැක්කේ ලියාපදිංචි පරිශීලකයින්ට පමණි. කරුණාකර.
ඔබ බහු මාදිලියේ DBMS භාවිතා කරන්නේද?
-
අපි එය භාවිතා නොකරමු, අපි සෑම දෙයක්ම එක් DBMS සහ එක් ආකෘතියක් තුළ ගබඩා කරමු
-
අපි සාම්ප්‍රදායික DBMS වල බහු-ආකෘති හැකියාවන් භාවිතා කරමු
-
අපි බහුභාෂා නොපසුබට උත්සාහය පුරුදු කරමු
-
අපි නව බහු මාදිලියේ DBMS (Arango, Orient, CosmosDB) භාවිතා කරන්නෙමු.
පරිශීලකයින් 19 දෙනෙක් ඡන්දය දුන්හ. පරිශීලකයින් 4 දෙනෙක් ඡන්දය දීමෙන් වැළකී සිටියහ.
මූලාශ්රය: www.habr.com