આધુનિક માહિતી પ્રણાલીઓ ખૂબ જટિલ છે. ઓછામાં ઓછું નથી, તેમની જટિલતા તેમનામાં પ્રક્રિયા કરાયેલ ડેટાની જટિલતાને કારણે છે. ડેટાની જટિલતા ઘણીવાર ઉપયોગમાં લેવાતા ડેટા મોડલ્સની વિવિધતામાં રહે છે. તેથી, ઉદાહરણ તરીકે, જ્યારે ડેટા "મોટો" બને છે, ત્યારે સમસ્યારૂપ લાક્ષણિકતાઓમાંની એક માત્ર તેનું વોલ્યુમ ("વોલ્યુમ") જ નહીં, પણ તેની વિવિધતા ("વિવિધતા") પણ છે.

જો તમને હજી સુધી તર્કમાં કોઈ ખામી ન જણાય, તો આગળ વાંચો.

અનુક્રમણિકા

પોલીગ્લોટ દ્રઢતા
મલ્ટિ-મોડલ
રિલેશનલ મોડલ પર આધારિત મલ્ટિ-મોડલ DBMS
     MS SQL સર્વરમાં દસ્તાવેજ મોડેલ
     MS SQL સર્વરમાં ગ્રાફ મોડેલ
દસ્તાવેજ મોડેલ પર આધારિત મલ્ટી-મોડલ DBMS
     MarkLogic માં રિલેશનલ મોડલ
     MarkLogic માં ગ્રાફ મોડેલ
મલ્ટી-મોડલ DBMS "મુખ્ય મોડલ વિના"
     ArangoDB
     ઑરિએન્ટડીબી
     એઝુર કોસ્મોસડીબી
ગ્રાફ મોડેલ પર આધારિત મલ્ટિ-મોડલ DBMS?
નિષ્કર્ષ
મતદાન

પોલીગ્લોટ દ્રઢતા

ઉપરોક્ત એ હકીકત તરફ દોરી જાય છે કે કેટલીકવાર એક સિસ્ટમના માળખામાં પણ ડેટા સંગ્રહિત કરવા અને તેમની પ્રક્રિયાની વિવિધ સમસ્યાઓ હલ કરવા માટે વિવિધ DBMS નો ઉપયોગ કરવો જરૂરી છે, જેમાંથી દરેક તેના પોતાના ડેટા મોડેલને સમર્થન આપે છે. એમ. ફોલરના હળવા હાથથી, લેખક સંખ્યાબંધ પ્રખ્યાત પુસ્તકો અને એક સહ-લેખકો ચપળ મેનિફેસ્ટો, આ પરિસ્થિતિ કહેવાય છે મલ્ટિ-વેરિયન્ટ સ્ટોરેજ ("પોલીગ્લોટ પર્સિસ્ટન્સ").

ફાઉલર પાસે ઈ-કોમર્સ ક્ષેત્રે સંપૂર્ણ સુવિધાયુક્ત અને ઉચ્ચ-લોડ એપ્લિકેશનમાં ડેટા સ્ટોરેજ ગોઠવવાનું નીચેનું ઉદાહરણ પણ છે.

આ ઉદાહરણ, અલબત્ત, કંઈક અંશે અતિશયોક્તિપૂર્ણ છે, પરંતુ અનુરૂપ હેતુ માટે એક અથવા બીજા DBMS પસંદ કરવાની તરફેણમાં કેટલીક વિચારણાઓ મળી શકે છે, ઉદાહરણ તરીકે, અહીં.

તે સ્પષ્ટ છે કે આવા પ્રાણી સંગ્રહાલયમાં નોકર બનવું સરળ નથી.

• કોડનો જથ્થો કે જે ડેટા સ્ટોરેજ કરે છે તે વપરાયેલ DBMS ની સંખ્યાના પ્રમાણમાં વધે છે; કોડ સિંક્રનાઇઝિંગ ડેટાની માત્રા સારી છે જો આ સંખ્યાના વર્ગના પ્રમાણસર ન હોય.
• ઉપયોગમાં લેવાતા DBMS ની સંખ્યાના ગુણાંક તરીકે, ઉપયોગમાં લેવાતા દરેક DBMS ની એન્ટરપ્રાઇઝ લાક્ષણિકતાઓ (સ્કેલેબિલિટી, ફોલ્ટ સહિષ્ણુતા, ઉચ્ચ ઉપલબ્ધતા) પ્રદાન કરવાના ખર્ચમાં વધારો થાય છે.
• એકંદરે સ્ટોરેજ સબસિસ્ટમની એન્ટરપ્રાઇઝ લાક્ષણિકતાઓની ખાતરી કરવી અશક્ય છે - ખાસ કરીને વ્યવહારિકતા.

પ્રાણી સંગ્રહાલયના ડિરેક્ટરના દૃષ્ટિકોણથી, બધું આના જેવું લાગે છે:

• DBMS ઉત્પાદક તરફથી લાયસન્સ અને ટેક્નિકલ સપોર્ટની કિંમતમાં બહુવિધ વધારો.
• ઓવરસ્ટાફિંગ અને સમયમર્યાદામાં વધારો.
• ડેટાની અસંગતતાને કારણે સીધું નાણાકીય નુકસાન અથવા દંડ.

સિસ્ટમની માલિકીની કુલ કિંમત (TCO) માં નોંધપાત્ર વધારો થયો છે. શું "મલ્ટીપલ સ્ટોરેજ વિકલ્પો" ની પરિસ્થિતિમાંથી બહાર નીકળવાનો કોઈ રસ્તો છે?

મલ્ટિ-મોડલ

"મલ્ટિવેરિયેટ સ્ટોરેજ" શબ્દનો ઉપયોગ 2011 માં થયો. અભિગમની સમસ્યાઓની જાગૃતિ અને ઉકેલની શોધમાં ઘણા વર્ષો લાગ્યા, અને 2015 સુધીમાં, ગાર્ટનર વિશ્લેષકોના મુખ દ્વારા, જવાબ ઘડવામાં આવ્યો:

• થી "NoSQL DBMSs માટે બજાર માર્ગદર્શિકા - 2015"
  

  ડીબીએમએસનું ભાવિ, તેમના આર્કિટેક્ચર અને તેનો ઉપયોગ કરવાની રીતો મલ્ટિ-મોડલ છે.

• થી "ODBMS - 2016 માટે જાદુઈ ચતુર્થાંશ"
  

  અગ્રણી ઓપરેશનલ DBMSs એક જ પ્લેટફોર્મના ભાગ રૂપે બહુવિધ મોડલ-રિલેશનલ અને નોન-રિલેશનલ- ઓફર કરશે.

એવું લાગે છે કે આ વખતે ગાર્ટનર વિશ્લેષકો તેમની આગાહી સાથે સાચા હતા. જો તમે સાથે પૃષ્ઠ પર જાઓ મુખ્ય રેટિંગ DB-એન્જિન પર DBMS, તમે તે જોઈ શકો છોоતેના મોટા ભાગના નેતાઓ પોતાને ખાસ કરીને મલ્ટિ-મોડલ ડીબીએમએસ તરીકે સ્થાન આપે છે. તે જ કોઈપણ ખાનગી રેટિંગ સાથે પૃષ્ઠ પર જોઈ શકાય છે.

નીચે આપેલ કોષ્ટક DBMS બતાવે છે - દરેક ખાનગી રેટિંગમાંના નેતાઓ, જે મલ્ટિ-મોડલ હોવાનો દાવો કરે છે. દરેક DBMS માટે, અસલ સપોર્ટેડ મોડલ (જે એક સમયે એકમાત્ર હતું) અને તેની સાથે હાલમાં સપોર્ટેડ મોડલ્સ સૂચવવામાં આવે છે. DBMSs પણ સૂચિબદ્ધ છે જે પોતાને "મૂળ રૂપે મલ્ટિ-મોડલ" તરીકે સ્થાન આપે છે અને, સર્જકોના મતે, તેમની પાસે કોઈ પ્રારંભિક વારસાગત મોડેલ નથી.

ડીબીએમએસ	પ્રારંભિક મોડેલ	વધારાના મોડેલો
ઓરેકલ	સંબંધી	આલેખ, દસ્તાવેજ
એમએસ એસક્યુએલ	સંબંધી	આલેખ, દસ્તાવેજ
પોસ્ટગ્રે એસક્યુએલ	સંબંધી	ગ્રાફ*, દસ્તાવેજ
માર્કલોજિક	દસ્તાવેજી	ગ્રાફ, રિલેશનલ
MongoDB	દસ્તાવેજી	કી-વેલ્યુ, ગ્રાફ*
ડેટા સ્ટોક્સ	પહોળી-સ્તંભ	દસ્તાવેજી, ગ્રાફ
Redis	કી-મૂલ્ય	દસ્તાવેજી, ગ્રાફ*
ArangoDB	-	આલેખ, દસ્તાવેજ
ઑરિએન્ટડીબી	-	આલેખ, દસ્તાવેજ, સંબંધી
એઝુર કોસ્મોસડીબી	-	આલેખ, દસ્તાવેજ, સંબંધી

ટેબલ પર નોંધો

કોષ્ટકમાં ફૂદડી ચિહ્નિત નિવેદનો કે જેને રિઝર્વેશનની જરૂર છે:

• PostgreSQL DBMS ગ્રાફ ડેટા મોડલને સપોર્ટ કરતું નથી, પરંતુ આ પ્રોડક્ટ તેને સપોર્ટ કરે છે તેના આધારે, જેમ કે AgensGraph.
• MongoDB ના સંબંધમાં, ક્વેરી ભાષામાં ગ્રાફ ઓપરેટર્સની હાજરી વિશે વાત કરવી વધુ યોગ્ય છે ($lookup, $graphLookup) ગ્રાફ મોડેલને ટેકો આપવા કરતાં, જો કે, અલબત્ત, તેમના પરિચય માટે ગ્રાફ મોડેલને ટેકો આપવાની દિશામાં ભૌતિક સંગ્રહ સ્તરે કેટલાક ઑપ્ટિમાઇઝેશનની જરૂર હતી.
• રેડિસના સંબંધમાં, અમારો અર્થ એક્સ્ટેંશન છે રેડિસગ્રાફ.

આગળ, દરેક વર્ગ માટે, અમે બતાવીશું કે આ વર્ગમાંથી DBMS માં કેટલાંક મોડલ્સ માટે સપોર્ટ કેવી રીતે લાગુ કરવામાં આવે છે. અમે રિલેશનલ, ડોક્યુમેન્ટ અને ગ્રાફ મોડલ્સને સૌથી મહત્વપૂર્ણ ગણીશું અને "ગુમ થયેલ લોકો" ને કેવી રીતે લાગુ કરવામાં આવે છે તે બતાવવા માટે ચોક્કસ DBMS ના ઉદાહરણોનો ઉપયોગ કરીશું.

રિલેશનલ મોડલ પર આધારિત મલ્ટિ-મોડલ DBMS

અગ્રણી DBMSs હાલમાં રિલેશનલ છે; જો RDBMS મલ્ટી-મોડલિંગની દિશામાં હિલચાલ ન બતાવે તો ગાર્ટનરની આગાહી સાચી ગણી શકાય નહીં. અને તેઓ નિદર્શન કરે છે. હવે એ વિચાર કે મલ્ટી-મોડલ DBMS એ સ્વિસ છરી જેવું છે, જે કંઈપણ સારી રીતે કરી શકતું નથી, તે સીધા લેરી એલિસનને નિર્દેશિત કરી શકાય છે.

લેખક, જો કે, માઈક્રોસોફ્ટ એસક્યુએલ સર્વરમાં મલ્ટી-મોડેલિંગના અમલીકરણને પસંદ કરે છે, જેના ઉદાહરણ પર દસ્તાવેજ અને ગ્રાફ મોડલ્સ માટે RDBMS સપોર્ટનું વર્ણન કરવામાં આવશે.

MS SQL સર્વરમાં દસ્તાવેજ મોડેલ

MS SQL સર્વર કેવી રીતે દસ્તાવેજ મોડલ માટે સમર્થન લાગુ કરે છે તે વિશે હેબ્રે પર પહેલાથી જ બે ઉત્તમ લેખો છે; હું મારી જાતને સંક્ષિપ્ત રિટેલિંગ અને કોમેન્ટ્રી સુધી મર્યાદિત કરીશ:

• SQL સર્વર 2016 માં JSON સાથે કામ કરવું
• SQL સર્વર 2017 JSON

MS SQL સર્વરમાં દસ્તાવેજ મોડેલને ટેકો આપવાની રીત રિલેશનલ DBMSs માટે એકદમ લાક્ષણિક છે: JSON દસ્તાવેજોને સામાન્ય ટેક્સ્ટ ફીલ્ડમાં સંગ્રહિત કરવાની દરખાસ્ત છે. આ JSON ને વિશ્લેષિત કરવા માટે ખાસ ઓપરેટરોને પ્રદાન કરવા માટે દસ્તાવેજ મોડેલ માટે આધાર છે:

• JSON_VALUE સ્કેલર એટ્રિબ્યુટ મૂલ્યો કાઢવા માટે,
• JSON_QUERY પેટા-દસ્તાવેજો કાઢવા માટે.

બંને ઓપરેટરોની બીજી દલીલ JSONPath-જેવી સિન્ટેક્સમાં અભિવ્યક્તિ છે.

અમૂર્ત રીતે, અમે કહી શકીએ કે આ રીતે સંગ્રહિત દસ્તાવેજો ટ્યુપલ્સથી વિપરીત રિલેશનલ ડીબીએમએસમાં "પ્રથમ-વર્ગની સંસ્થાઓ" નથી. ખાસ કરીને, MS SQL સર્વરમાં હાલમાં JSON દસ્તાવેજોના ક્ષેત્રો પર કોઈ અનુક્રમણિકા નથી, જે આ ક્ષેત્રોના મૂલ્યોનો ઉપયોગ કરીને કોષ્ટકોમાં જોડાવાનું મુશ્કેલ બનાવે છે અને આ મૂલ્યોનો ઉપયોગ કરીને દસ્તાવેજો પણ પસંદ કરે છે. જો કે, આવા ક્ષેત્ર માટે ગણતરી કરેલ કૉલમ અને તેના પર અનુક્રમણિકા બનાવવાનું શક્ય છે.

વધુમાં, MS SQL સર્વર ઑપરેટરનો ઉપયોગ કરીને કોષ્ટકોના સમાવિષ્ટોમાંથી JSON દસ્તાવેજને અનુકૂળ રીતે બનાવવાની ક્ષમતા પ્રદાન કરે છે. FOR JSON PATH - એક સંભાવના, ચોક્કસ અર્થમાં, અગાઉના એકની વિરુદ્ધ, પરંપરાગત સંગ્રહ. તે સ્પષ્ટ છે કે RDBMS ગમે તેટલું ઝડપી હોય, આ અભિગમ દસ્તાવેજ DBMSs ની વિચારધારાનો વિરોધાભાસ કરે છે, જે આવશ્યકપણે લોકપ્રિય પ્રશ્નોના તૈયાર જવાબો સંગ્રહિત કરે છે, અને માત્ર વિકાસની સરળતાની સમસ્યાઓ હલ કરી શકે છે, પરંતુ ઝડપ નહીં.

છેલ્લે, એમએસ એસક્યુએલ સર્વર તમને દસ્તાવેજ નિર્માણની વિપરીત સમસ્યા હલ કરવાની મંજૂરી આપે છે: તમે JSON ને કોષ્ટકોમાં વિઘટન કરી શકો છો OPENJSON. જો દસ્તાવેજ સંપૂર્ણપણે સપાટ નથી, તો તમારે ઉપયોગ કરવાની જરૂર પડશે CROSS APPLY.

MS 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; આ જ કારણસર, ડેટા દાખલ કરવા માટેની ક્વેરી અહીં દર્શાવવામાં આવી નથી કારણ કે તે બિનજરૂરી રીતે બોજારૂપ છે).

એમએસ એસક્યુએલ સર્વરમાં દસ્તાવેજ અને ગ્રાફ મોડેલોના અમલીકરણના વર્ણનનો સારાંશ આપવા માટે, હું નોંધ કરીશ કે એક મોડેલના બીજા મોડેલના આવા અમલીકરણો મુખ્યત્વે ભાષા ડિઝાઇનના દૃષ્ટિકોણથી સફળ લાગતા નથી. એક ભાષાને બીજી ભાષા સાથે લંબાવવી જરૂરી છે, ભાષાઓ સંપૂર્ણપણે "ઓર્થોગોનલ" નથી, સુસંગતતા નિયમો તદ્દન વિચિત્ર હોઈ શકે છે.

દસ્તાવેજ મોડેલ પર આધારિત મલ્ટી-મોડલ DBMS

આ વિભાગમાં, હું તેમાંના સૌથી વધુ લોકપ્રિય ન હોય તેવા, મોંગોડીબી (જેમ કહ્યું હતું કે, તેમાં ફક્ત શરતી ગ્રાફ ઓપરેટર્સ છે) ના ઉદાહરણનો ઉપયોગ કરીને દસ્તાવેજ ડીબીએમએસમાં મલ્ટિ-મોડલના અમલીકરણને સમજાવવા માંગુ છું. $lookup и $graphLookup, શાર્ડેડ કલેક્શન પર કામ કરતા નથી), પરંતુ વધુ પરિપક્વ અને "એન્ટરપ્રાઇઝ" DBMS ના ઉદાહરણનો ઉપયોગ કરીને માર્કલોજિક.

તેથી, સંગ્રહમાં નીચેના પ્રકારના XML દસ્તાવેજોનો સમૂહ શામેલ થવા દો (માર્કલોજિક તમને 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 માં ગ્રાફ મોડેલ

ગ્રાફ (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 .
}

રિલેશનલ એકથી વિપરીત, માર્કલોજિક ગ્રાફ મોડેલને અન્ય બે રીતે સપોર્ટ કરે છે:

1. ડીબીએમએસ એ આરડીએફ ડેટાનો સંપૂર્ણ કક્ષાનો અલગ સ્ટોરેજ હોઈ શકે છે (તેમાં ત્રિપુટી કહેવામાં આવશે સંચાલિત ઉપર વર્ણવેલ તેનાથી વિપરીત કાractedવામાં).
2. સ્પેશિયલ સીરીયલાઇઝેશનમાં આરડીએફને ફક્ત XML અથવા JSON દસ્તાવેજોમાં દાખલ કરી શકાય છે (અને પછી ટ્રિપ્લેટ્સ કહેવામાં આવશે. અનિયંત્રિત). આ કદાચ મિકેનિઝમનો વિકલ્પ છે idref અને અન્ય

માર્કલોજિકમાં વસ્તુઓ "ખરેખર" કેવી રીતે કાર્ય કરે છે તેનો સારો વિચાર દ્વારા આપવામાં આવે છે ઓપ્ટિકલ API, આ અર્થમાં, તે નિમ્ન-સ્તરનું છે, જો કે તેનો હેતુ તેનાથી વિપરીત છે - ઉપયોગમાં લેવાતા ડેટા મોડેલમાંથી અમૂર્ત કરવાનો પ્રયાસ કરવા, વિવિધ મોડેલોમાં ડેટા સાથે સુસંગત કાર્યની ખાતરી કરવા, વ્યવહારક્ષમતા, વગેરે.

મલ્ટી-મોડલ DBMS "મુખ્ય મોડલ વિના"

બજારમાં એવા DBMSs પણ છે જે પોતાને કોઈ વારસાગત મુખ્ય મોડલ વિના શરૂઆતમાં મલ્ટિ-મોડલ તરીકે સ્થાન આપે છે. આનો સમાવેશ થાય છે ArangoDB, ઑરિએન્ટડીબી (2018 થી વિકાસ કંપની SAP ની છે) અને કોસ્મોસડીબી (Microsoft Azure ક્લાઉડ પ્લેટફોર્મના ભાગ રૂપે સેવા).

હકીકતમાં, ArangoDB અને OrientDB માં "કોર" મોડલ છે. બંને કિસ્સાઓમાં, આ તેમના પોતાના ડેટા મોડેલો છે, જે દસ્તાવેજ એકનું સામાન્યીકરણ છે. સામાન્યીકરણો મુખ્યત્વે ગ્રાફ અને રિલેશનલ પ્રકૃતિની ક્વેરી કરવાની ક્ષમતાને સરળ બનાવવા માટે છે.

ઉલ્લેખિત DBMS માં ઉપયોગ માટે આ મોડેલો જ ઉપલબ્ધ છે; તેમની પોતાની ક્વેરી ભાષાઓ તેમની સાથે કામ કરવા માટે ડિઝાઇન કરવામાં આવી છે. અલબત્ત, આવા મોડલ અને ડીબીએમએસ આશાસ્પદ છે, પરંતુ માનક મોડલ અને ભાષાઓ સાથે સુસંગતતાનો અભાવ લેગસી સિસ્ટમ્સમાં આ ડીબીએમએસનો ઉપયોગ કરવાનું અશક્ય બનાવે છે - ત્યાં પહેલાથી ઉપયોગમાં લેવાતા ડીબીએમએસને બદલવા માટે.

Habré પર ArangoDB અને OrientDB વિશે પહેલેથી જ એક અદ્ભુત લેખ હતો: NoSQL ડેટાબેસેસમાં જોડાઓ.

ArangoDB

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 માટે વધુ લાક્ષણિક લાગે છે, તો તમે આ ક્વેરી અજમાવી શકો છો (અથવા તમે ઉપયોગ કરી શકો છો 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 તરીકે વર્ણવી શકાય છે. સંસ્કરણ 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 નીચેના ડેટા એક્સેસ API પૂરી પાડે છે: SQL, MongoDB, Gremlin અને Cassandra.

SQL API અને MongoDB API નો ઉપયોગ દસ્તાવેજ મોડેલમાં ડેટા ઍક્સેસ કરવા માટે થાય છે. ગ્રેમલિન API અને Cassandra API - અનુક્રમે ગ્રાફ અને કૉલમ ફોર્મેટમાં ડેટા ઍક્સેસ કરવા માટે. તમામ મોડલનો ડેટા CosmosDB આંતરિક મોડલ ફોર્મેટમાં સાચવવામાં આવે છે: એઆરએસ ("એટમ-રેકોર્ડ-સિક્વન્સ"), જે એક દસ્તાવેજની નજીક પણ છે.

પરંતુ સેવામાં એકાઉન્ટ બનાવતી વખતે વપરાશકર્તા દ્વારા પસંદ કરાયેલ ડેટા મોડલ અને ઉપયોગમાં લેવાયેલ API નિશ્ચિત કરવામાં આવે છે. એક મોડેલમાં લોડ થયેલ ડેટાને બીજા મોડેલના ફોર્મેટમાં એક્સેસ કરવું શક્ય નથી, જેમ કે આના જેવું કંઈક દ્વારા સચિત્ર છે:

આમ, Azure CosmosDB માં મલ્ટિ-મોડલ આજે માત્ર એક ઉત્પાદકના વિવિધ મોડલ્સને સપોર્ટ કરતા અનેક ડેટાબેસેસનો ઉપયોગ કરવાની ક્ષમતા છે, જે મલ્ટી-વેરિયન્ટ સ્ટોરેજની તમામ સમસ્યાઓને હલ કરતું નથી.

ગ્રાફ મોડેલ પર આધારિત મલ્ટિ-મોડલ DBMS?

નોંધનીય એ હકીકત છે કે બજારમાં હજી સુધી કોઈ મલ્ટિ-મૉડલ DBMS નથી કે જે ગ્રાફ મૉડલ પર આધારિત હોય (એકસાથે બે ગ્રાફ મૉડલ્સ માટે મલ્ટિ-મૉડલ સપોર્ટ સિવાય: RDF અને LPG; આમાં જુઓ અગાઉનું પ્રકાશન). સૌથી મોટી મુશ્કેલીઓ ગ્રાફ મૉડલની ટોચ પર દસ્તાવેજ મૉડલના અમલીકરણને કારણે થાય છે, રિલેશનલને બદલે.

ગ્રાફ મૉડલની ટોચ પર રિલેશનલ મૉડલને કેવી રીતે અમલમાં મૂકવું તે પ્રશ્ન બાદમાંની રચના દરમિયાન પણ ધ્યાનમાં લેવામાં આવ્યો હતો. કેવી રીતે બોલ્યાઉદાહરણ તરીકે ડેવિડ મેકગવર્ન:

ગ્રાફના અભિગમમાં એવું કંઈ નથી કે જે ગ્રાફ ડેટાબેઝ પર એક સ્તર (દા.ત., યોગ્ય અનુક્રમણિકા દ્વારા) બનાવવાનું અટકાવે છે જે (1) સામાન્ય કી વેલ્યુ જોડીઓમાંથી ટ્યુપલ્સની પુનઃપ્રાપ્તિ અને (2) જૂથીકરણ સાથે સંબંધિત દૃશ્યને સક્ષમ કરે છે. સંબંધ પ્રકાર દ્વારા tuples.

ગ્રાફ મોડેલની ટોચ પર દસ્તાવેજ મોડેલનો અમલ કરતી વખતે, તમારે ધ્યાનમાં રાખવાની જરૂર છે, ઉદાહરણ તરીકે, નીચેના:

• JSON એરેના ઘટકોને ક્રમબદ્ધ ગણવામાં આવે છે, પરંતુ ગ્રાફની ધારના શિરોબિંદુમાંથી નીકળતા તત્વો નથી;
• દસ્તાવેજ મોડેલમાંનો ડેટા સામાન્ય રીતે અસાધારણ હોય છે; તમે હજી પણ સમાન એમ્બેડેડ દસ્તાવેજની ઘણી નકલો સંગ્રહિત કરવા માંગતા નથી, અને પેટા દસ્તાવેજોમાં સામાન્ય રીતે ઓળખકર્તા હોતા નથી;
• બીજી બાજુ, દસ્તાવેજ DBMSs ની વિચારધારા એ છે કે દસ્તાવેજો તૈયાર "એગ્રિગેટ્સ" છે જેને દર વખતે નવેસરથી બનાવવાની જરૂર નથી. તૈયાર દસ્તાવેજને અનુરૂપ સબગ્રાફ ઝડપથી મેળવવાની ક્ષમતા સાથે ગ્રાફ મોડેલ પ્રદાન કરવું જરૂરી છે.

થોડી જાહેરાત

લેખના લેખક નાઇટ્રોસબેઝ ડીબીએમએસના વિકાસ સાથે સંબંધિત છે, જેનું આંતરિક મોડેલ ગ્રાફ છે, અને બાહ્ય મોડેલો - સંબંધ અને દસ્તાવેજ - તેની રજૂઆત છે. બધા મોડેલો સમાન છે: લગભગ કોઈપણ ડેટા તેમાંના કોઈપણમાં પ્રાકૃતિક ક્વેરી ભાષાનો ઉપયોગ કરીને ઉપલબ્ધ છે. તદુપરાંત, કોઈપણ દૃશ્યમાં, ડેટા બદલી શકાય છે. ફેરફારો આંતરિક મોડેલમાં પ્રતિબિંબિત થશે અને તે મુજબ, અન્ય દૃશ્યોમાં.

હું આસ્થાપૂર્વક વર્ણન કરીશ કે નીચેના લેખોમાંના એકમાં NitrosBase માં મોડેલ મેચિંગ કેવું દેખાય છે.

નિષ્કર્ષ

હું આશા રાખું છું કે મલ્ટિ-મોડેલિંગ જેને કહેવાય છે તેની સામાન્ય રૂપરેખાઓ વાચક માટે વધુ કે ઓછા સ્પષ્ટ થઈ ગઈ છે. મલ્ટી-મોડલ DBMSs તદ્દન અલગ છે, અને "મલ્ટી-મોડલ સપોર્ટ" અલગ દેખાઈ શકે છે. દરેક ચોક્કસ કેસમાં "મલ્ટિ-મોડલ" શું કહેવાય છે તે સમજવા માટે, નીચેના પ્રશ્નોના જવાબ આપવાનું ઉપયોગી છે:

1. શું આપણે પરંપરાગત મોડલ અથવા અમુક પ્રકારના "હાઇબ્રિડ" મોડેલને ટેકો આપવા વિશે વાત કરી રહ્યા છીએ?
2. શું મોડેલો "સમાન" છે, અથવા તેમાંથી એક અન્યનો વિષય છે?
3. શું મોડેલો એકબીજા પ્રત્યે "ઉદાસીન" છે? શું એક મોડેલમાં લખાયેલ ડેટા બીજામાં વાંચી શકાય છે અથવા ઓવરરાઈટ પણ થઈ શકે છે?

મને લાગે છે કે મલ્ટિ-મોડેલ ડીબીએમએસની સુસંગતતા વિશેના પ્રશ્નનો પહેલેથી જ સકારાત્મક જવાબ આપી શકાય છે, પરંતુ રસપ્રદ પ્રશ્ન એ છે કે નજીકના ભવિષ્યમાં તેમાંથી કયા પ્રકારની માંગ વધુ હશે. એવું લાગે છે કે મલ્ટિ-મોડલ DBMSs કે જે પરંપરાગત મોડલ્સને સમર્થન આપે છે, મુખ્યત્વે રિલેશનલ, વધુ માંગમાં હશે; મલ્ટિ-મૉડલ DBMSsની લોકપ્રિયતા, નવા મૉડલ ઑફર કરે છે જે વિવિધ પરંપરાગતના ફાયદાઓને જોડે છે, તે વધુ દૂરના ભવિષ્યની બાબત છે.

ફક્ત નોંધાયેલા વપરાશકર્તાઓ જ સર્વેમાં ભાગ લઈ શકે છે. સાઇન ઇન કરો, મહેરબાની કરીને.

શું તમે મલ્ટી-મોડલ DBMS નો ઉપયોગ કરો છો?

• અમે તેનો ઉપયોગ કરતા નથી, અમે દરેક વસ્તુને એક DBMS અને એક મોડેલમાં સંગ્રહિત કરીએ છીએ

• અમે પરંપરાગત DBMSs ની મલ્ટિ-મોડલ ક્ષમતાઓનો ઉપયોગ કરીએ છીએ

• અમે પોલીગ્લોટ દ્રઢતાનો અભ્યાસ કરીએ છીએ

• અમે નવા મલ્ટિ-મોડલ DBMS (Arango, Orient, CosmosDB) નો ઉપયોગ કરીએ છીએ

19 વપરાશકર્તાઓએ મત ​​આપ્યો. 4 વપરાશકર્તાઓ દૂર રહ્યા.

સોર્સ: www.habr.com