ആധുനിക വിവര സംവിധാനങ്ങൾ വളരെ സങ്കീർണ്ണമാണ്. എല്ലാത്തിനുമുപരി, അവയുടെ സങ്കീർണ്ണത അവയിൽ പ്രോസസ്സ് ചെയ്ത ഡാറ്റയുടെ സങ്കീർണ്ണത മൂലമാണ്. ഡാറ്റയുടെ സങ്കീർണ്ണത പലപ്പോഴും ഉപയോഗിക്കുന്ന ഡാറ്റ മോഡലുകളുടെ വൈവിധ്യത്തിലാണ്. അതിനാൽ, ഉദാഹരണത്തിന്, ഡാറ്റ "വലിയ" ആകുമ്പോൾ, പ്രശ്നകരമായ സ്വഭാവങ്ങളിലൊന്ന് അതിന്റെ വോളിയം ("വോളിയം"), മാത്രമല്ല അതിന്റെ വൈവിധ്യവും ("വെറൈറ്റി") ആണ്.

നിങ്ങൾ ഇതുവരെ ന്യായവാദത്തിൽ ഒരു പിഴവ് കണ്ടെത്തിയില്ലെങ്കിൽ, തുടർന്ന് വായിക്കുക.

ഉള്ളടക്കം

ബഹുഭാഷാ സ്ഥിരത
മൾട്ടി മോഡൽ
റിലേഷണൽ മോഡലിനെ അടിസ്ഥാനമാക്കിയുള്ള മൾട്ടി മോഡൽ DBMS
     MS SQL സെർവറിലെ ഡോക്യുമെന്റ് മോഡൽ
     MS SQL സെർവറിലെ ഗ്രാഫ് മോഡൽ
ഡോക്യുമെന്റ് മോഡലിനെ അടിസ്ഥാനമാക്കിയുള്ള മൾട്ടി മോഡൽ DBMS
     മാർക്ക്ലോജിക്കിലെ റിലേഷണൽ മോഡൽ
     MarkLogic ലെ ഗ്രാഫ് മോഡൽ
മൾട്ടി മോഡൽ DBMS "ഒരു പ്രധാന മോഡൽ ഇല്ലാതെ"
     അരങ്കോഡിബി
     ഓറിയന്റ് DB
     അസൂർ കോസ്മോസ്ഡിബി
ഒരു ഗ്രാഫ് മോഡലിനെ അടിസ്ഥാനമാക്കിയുള്ള മൾട്ടി മോഡൽ DBMS?
തീരുമാനം
വോട്ട്നേടൽ

ബഹുഭാഷാ സ്ഥിരത

ചിലപ്പോൾ ഒരു സിസ്റ്റത്തിന്റെ ചട്ടക്കൂടിനുള്ളിൽ പോലും ഡാറ്റ സംഭരിക്കുന്നതിനും അവ പ്രോസസ്സ് ചെയ്യുന്നതിലെ വിവിധ പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നതിനും നിരവധി വ്യത്യസ്ത ഡിബിഎംഎസുകൾ ഉപയോഗിക്കേണ്ടത് ആവശ്യമാണ്, അവയിൽ ഓരോന്നും അതിന്റേതായ ഡാറ്റ മോഡലിനെ പിന്തുണയ്ക്കുന്നു. എം.ഫൗളറുടെ നേരിയ കൈകൊണ്ട്, രചയിതാവ് പ്രശസ്തമായ നിരവധി പുസ്തകങ്ങളും അതിലൊന്നും സഹ-രചയിതാക്കൾ എജൈൽ മാനിഫെസ്റ്റോ, ഈ സാഹചര്യത്തെ വിളിക്കുന്നു മൾട്ടി-വേരിയന്റ് സ്റ്റോറേജ് ("പോളിഗ്ലോട്ട് പെർസിസ്റ്റൻസ്").

ഇ-കൊമേഴ്‌സ് ഫീൽഡിൽ ഫുൾ ഫീച്ചർ ചെയ്തതും ഉയർന്ന ലോഡുള്ളതുമായ ആപ്ലിക്കേഷനിൽ ഡാറ്റ സ്റ്റോറേജ് സംഘടിപ്പിക്കുന്നതിനുള്ള ഇനിപ്പറയുന്ന ഉദാഹരണവും ഫൗളറിനുണ്ട്.

ഈ ഉദാഹരണം, തീർച്ചയായും, അതിശയോക്തിപരമാണ്, എന്നാൽ അനുബന്ധ ആവശ്യത്തിനായി ഒന്നോ അല്ലെങ്കിൽ മറ്റൊരു DBMS തിരഞ്ഞെടുക്കുന്നതിന് അനുകൂലമായ ചില പരിഗണനകൾ കണ്ടെത്താനാകും, ഉദാഹരണത്തിന്, ഇവിടെ.

അത്തരമൊരു മൃഗശാലയിൽ ഒരു സേവകനാകുന്നത് എളുപ്പമല്ലെന്ന് വ്യക്തമാണ്.

• ഉപയോഗിച്ച DBMS-കളുടെ എണ്ണത്തിന് ആനുപാതികമായി ഡാറ്റ സംഭരണം നടത്തുന്ന കോഡിന്റെ അളവ് വർദ്ധിക്കുന്നു; ഈ സംഖ്യയുടെ വർഗ്ഗത്തിന് ആനുപാതികമല്ലെങ്കിൽ കോഡ് സമന്വയിപ്പിക്കുന്ന ഡാറ്റയുടെ അളവ് നല്ലതാണ്.
• ഉപയോഗിച്ച DBMS-കളുടെ എണ്ണത്തിന്റെ ഗുണിതമായി, ഓരോ DBMS-കളുടെയും എന്റർപ്രൈസ് സവിശേഷതകൾ (സ്കേലബിളിറ്റി, തെറ്റ് സഹിഷ്ണുത, ഉയർന്ന ലഭ്യത) നൽകുന്നതിനുള്ള ചെലവ് വർദ്ധിക്കുന്നു.
• മൊത്തത്തിൽ സ്റ്റോറേജ് സബ്സിസ്റ്റത്തിന്റെ എന്റർപ്രൈസ് സവിശേഷതകൾ ഉറപ്പാക്കുന്നത് അസാധ്യമാണ് - പ്രത്യേകിച്ച് ഇടപാട്.

മൃഗശാല ഡയറക്ടറുടെ കാഴ്ചപ്പാടിൽ, എല്ലാം ഇതുപോലെ കാണപ്പെടുന്നു:

• DBMS നിർമ്മാതാവിൽ നിന്നുള്ള ലൈസൻസുകളുടെയും സാങ്കേതിക പിന്തുണയുടെയും വിലയിൽ ഒന്നിലധികം വർദ്ധനവ്.
• അധിക ജീവനക്കാരും വർധിച്ച സമയപരിധിയും.
• ഡാറ്റാ പൊരുത്തക്കേട് കാരണം നേരിട്ടുള്ള സാമ്പത്തിക നഷ്ടങ്ങൾ അല്ലെങ്കിൽ പിഴകൾ.

സിസ്റ്റത്തിന്റെ ഉടമസ്ഥതയിലുള്ള മൊത്തം ചെലവിൽ (TCO) ഗണ്യമായ വർദ്ധനവ് ഉണ്ട്. "ഒന്നിലധികം സംഭരണ ​​​​ഓപ്‌ഷനുകളുടെ" സാഹചര്യത്തിൽ നിന്ന് എന്തെങ്കിലും വഴിയുണ്ടോ?

മൾട്ടി മോഡൽ

"മൾട്ടിവേരിയേറ്റ് സ്റ്റോറേജ്" എന്ന പദം 2011-ൽ ഉപയോഗത്തിൽ വന്നു. സമീപനത്തിന്റെ പ്രശ്നങ്ങളെക്കുറിച്ചുള്ള അവബോധവും പരിഹാരത്തിനായുള്ള തിരയലും നിരവധി വർഷങ്ങളെടുത്തു, 2015 ആയപ്പോഴേക്കും ഗാർട്ട്നർ അനലിസ്റ്റുകളുടെ വായിലൂടെ ഉത്തരം രൂപീകരിച്ചു:

• നിന്ന് "NoSQL DBMS-കൾക്കായുള്ള മാർക്കറ്റ് ഗൈഡ് - 2015"
  

  DBMS-കളുടെ ഭാവി, അവയുടെ ആർക്കിടെക്ചറുകൾ, അവ ഉപയോഗിക്കുന്ന രീതികൾ എന്നിവ മൾട്ടി മോഡൽ ആണ്.

• നിന്ന് "ODBMS - 2016-നുള്ള മാജിക് ക്വാഡ്രന്റ്"
  

  മുൻനിര ഓപ്പറേഷൻ ഡിബിഎംഎസുകൾ ഒരൊറ്റ പ്ലാറ്റ്‌ഫോമിന്റെ ഭാഗമായി ഒന്നിലധികം മോഡലുകൾ-റിലേഷണൽ, നോൺ റിലേഷണൽ-ഓഫർ ചെയ്യും.

ഇത്തവണ ഗാർട്ട്നർ അനലിസ്റ്റുകൾ അവരുടെ പ്രവചനം ശരിയാണെന്ന് തോന്നുന്നു. കൂടെ പേജിൽ പോയാൽ പ്രധാന റേറ്റിംഗ് DB-എഞ്ചിനുകളിൽ DBMS, നിങ്ങൾക്ക് അത് കാണാൻ കഴിയുംоഅതിന്റെ മിക്ക നേതാക്കളും പ്രത്യേകമായി മൾട്ടി മോഡൽ ഡിബിഎംഎസുകളായി നിലകൊള്ളുന്നു. ഏതെങ്കിലും സ്വകാര്യ റേറ്റിംഗ് ഉള്ള പേജിൽ ഇത് തന്നെ കാണാം.

ചുവടെയുള്ള പട്ടിക DBMS-നെ കാണിക്കുന്നു - ഓരോ സ്വകാര്യ റേറ്റിംഗിലെയും നേതാക്കൾ, അത് മൾട്ടി മോഡൽ എന്ന് അവകാശപ്പെടുന്നു. ഓരോ DBMS-നും, യഥാർത്ഥ പിന്തുണയുള്ള മോഡലും (ഒരിക്കൽ ഇത് മാത്രമായിരുന്നു) കൂടാതെ നിലവിൽ പിന്തുണയ്ക്കുന്ന മോഡലുകളും സൂചിപ്പിച്ചിരിക്കുന്നു. "യഥാർത്ഥത്തിൽ മൾട്ടി-മോഡൽ" ആയി സ്വയം സ്ഥാപിക്കുന്ന DBMS-കളും ലിസ്റ്റുചെയ്തിരിക്കുന്നു, കൂടാതെ സ്രഷ്‌ടാക്കളുടെ അഭിപ്രായത്തിൽ, പ്രാരംഭ പാരമ്പര്യ മാതൃകകളൊന്നും ഇല്ല.

ഡി.ബി.എം.എസ്	പ്രാരംഭ മോഡൽ	അധിക മോഡലുകൾ
ഒറാക്കിൾ	റിലേഷണൽ	ഗ്രാഫ്, പ്രമാണം
MS SQL	റിലേഷണൽ	ഗ്രാഫ്, പ്രമാണം
PostgreSQL എന്നീ	റിലേഷണൽ	ഗ്രാഫ്*, പ്രമാണം
മാർക്ക്ലോജിക്	ഡോക്യുമെന്ററി	ഗ്രാഫ്, റിലേഷണൽ
മോംഗോഡിബി	ഡോക്യുമെന്ററി	പ്രധാന മൂല്യം, ഗ്രാഫ്*
ഡാറ്റാസ്റ്റാക്സ്	വിശാലമായ നിര	ഡോക്യുമെന്ററി, ഗ്രാഫ്
രെദിസ്	പ്രധാന മൂല്യം	ഡോക്യുമെന്ററി, ഗ്രാഫ്*
അരങ്കോഡിബി	-	ഗ്രാഫ്, പ്രമാണം
ഓറിയന്റ് DB	-	ഗ്രാഫ്, ഡോക്യുമെന്റ്, റിലേഷണൽ
അസൂർ കോസ്മോസ്ഡിബി	-	ഗ്രാഫ്, ഡോക്യുമെന്റ്, റിലേഷണൽ

മേശപ്പുറത്ത് കുറിപ്പുകൾ

പട്ടികയിലെ നക്ഷത്രചിഹ്നങ്ങൾ റിസർവേഷനുകൾ ആവശ്യമുള്ള പ്രസ്താവനകളെ അടയാളപ്പെടുത്തുന്നു:

• PostgreSQL DBMS ഗ്രാഫ് ഡാറ്റ മോഡലിനെ പിന്തുണയ്ക്കുന്നില്ല, എന്നാൽ ഈ ഉൽപ്പന്നം അതിനെ പിന്തുണയ്ക്കുന്നു അതിനെ അടിസ്ഥാനമാക്കി, AgensGraph പോലുള്ളവ.
• മോംഗോഡിബിയുമായി ബന്ധപ്പെട്ട്, അന്വേഷണ ഭാഷയിൽ ഗ്രാഫ് ഓപ്പറേറ്റർമാരുടെ സാന്നിധ്യത്തെക്കുറിച്ച് സംസാരിക്കുന്നത് കൂടുതൽ ശരിയാണ് ($lookup, $graphLookup) ഗ്രാഫ് മോഡലിനെ പിന്തുണയ്ക്കുന്നതിനെക്കാൾ, തീർച്ചയായും, അവയുടെ ആമുഖത്തിന് ഗ്രാഫ് മോഡലിനെ പിന്തുണയ്ക്കുന്ന ദിശയിൽ ഫിസിക്കൽ സ്റ്റോറേജ് തലത്തിൽ ചില ഒപ്റ്റിമൈസേഷനുകൾ ആവശ്യമായിരുന്നു.
• റെഡിസുമായി ബന്ധപ്പെട്ട്, ഞങ്ങൾ അർത്ഥമാക്കുന്നത് വിപുലീകരണം എന്നാണ് റെഡിസ്ഗ്രാഫ്.

അടുത്തതായി, ഓരോ ക്ലാസുകൾക്കും, ഈ ക്ലാസിൽ നിന്ന് DBMS-ൽ നിരവധി മോഡലുകൾക്കുള്ള പിന്തുണ എങ്ങനെ നടപ്പിലാക്കുന്നുവെന്ന് ഞങ്ങൾ കാണിക്കും. റിലേഷണൽ, ഡോക്യുമെന്റ്, ഗ്രാഫ് മോഡലുകൾ ഏറ്റവും പ്രധാനപ്പെട്ടവയായി ഞങ്ങൾ പരിഗണിക്കും കൂടാതെ "കാണാതായവ" എങ്ങനെ നടപ്പിലാക്കുന്നു എന്ന് കാണിക്കാൻ നിർദ്ദിഷ്ട DBMS-കളുടെ ഉദാഹരണങ്ങൾ ഉപയോഗിക്കും.

റിലേഷണൽ മോഡലിനെ അടിസ്ഥാനമാക്കിയുള്ള മൾട്ടി മോഡൽ DBMS

നിലവിൽ മുൻനിരയിലുള്ള DBMS-കൾ ബന്ധമുള്ളവയാണ്; RDBMS-കൾ മൾട്ടി-മോഡലിങ്ങിന്റെ ദിശയിൽ ചലനം കാണിക്കുന്നില്ലെങ്കിൽ ഗാർട്ട്നറുടെ പ്രവചനം ശരിയാണെന്ന് കണക്കാക്കാനാവില്ല. അവർ പ്രകടിപ്പിക്കുകയും ചെയ്യുന്നു. ഇപ്പോൾ ഒരു മൾട്ടി മോഡൽ DBMS ഒരു സ്വിസ് കത്തി പോലെയാണ്, അത് നന്നായി ചെയ്യാൻ കഴിയില്ല, ലാറി എലിസണിലേക്ക് നേരിട്ട് നയിക്കാനാകും.

എന്നിരുന്നാലും, മൈക്രോസോഫ്റ്റ് SQL സെർവറിൽ മൾട്ടി-മോഡലിംഗ് നടപ്പിലാക്കാൻ രചയിതാവ് മുൻഗണന നൽകുന്നു, ഇതിന്റെ ഉദാഹരണത്തിൽ ഡോക്യുമെന്റ്, ഗ്രാഫ് മോഡലുകൾക്കുള്ള RDBMS പിന്തുണ വിവരിക്കും.

MS SQL സെർവറിലെ ഡോക്യുമെന്റ് മോഡൽ

ഡോക്യുമെന്റ് മോഡലിനുള്ള പിന്തുണ MS SQL സെർവർ എങ്ങനെ നടപ്പിലാക്കുന്നു എന്നതിനെക്കുറിച്ച് ഹബ്രെയെക്കുറിച്ച് ഇതിനകം രണ്ട് മികച്ച ലേഖനങ്ങൾ ഉണ്ടായിട്ടുണ്ട്; ഒരു ഹ്രസ്വമായ പുനരാഖ്യാനത്തിനും വ്യാഖ്യാനത്തിനും ഞാൻ എന്നെത്തന്നെ പരിമിതപ്പെടുത്തും:

• SQL സെർവർ 2016-ൽ JSON-നൊപ്പം പ്രവർത്തിക്കുന്നു
• SQL സെർവർ 2017 JSON

MS SQL സെർവറിലെ ഡോക്യുമെന്റ് മോഡലിനെ പിന്തുണയ്ക്കുന്നതിനുള്ള മാർഗ്ഗം റിലേഷണൽ DBMS-കൾക്ക് വളരെ സാധാരണമാണ്: JSON പ്രമാണങ്ങൾ സാധാരണ ടെക്സ്റ്റ് ഫീൽഡുകളിൽ സൂക്ഷിക്കാൻ നിർദ്ദേശിക്കപ്പെട്ടിരിക്കുന്നു. ഈ JSON പാഴ്‌സ് ചെയ്യുന്നതിന് പ്രത്യേക ഓപ്പറേറ്റർമാരെ നൽകുന്നതാണ് ഡോക്യുമെന്റ് മോഡലിനുള്ള പിന്തുണ:

• JSON_VALUE സ്കെയിലർ ആട്രിബ്യൂട്ട് മൂല്യങ്ങൾ വേർതിരിച്ചെടുക്കാൻ,
• JSON_QUERY ഉപ-രേഖകൾ വേർതിരിച്ചെടുക്കാൻ.

രണ്ട് ഓപ്പറേറ്റർമാരുടെയും രണ്ടാമത്തെ വാദം JSONPath പോലുള്ള വാക്യഘടനയിലെ ഒരു പദപ്രയോഗമാണ്.

അമൂർത്തമായി, ഈ രീതിയിൽ സംഭരിച്ചിരിക്കുന്ന ഡോക്യുമെന്റുകൾ tuples-ൽ നിന്ന് വ്യത്യസ്തമായി ഒരു റിലേഷണൽ DBMS-ൽ "ഫസ്റ്റ്-ക്ലാസ് എന്റിറ്റികൾ" അല്ലെന്ന് നമുക്ക് പറയാം. പ്രത്യേകിച്ചും, MS SQL സെർവറിൽ നിലവിൽ JSON പ്രമാണങ്ങളുടെ ഫീൽഡുകളിൽ സൂചികകളൊന്നുമില്ല, ഇത് ഈ ഫീൽഡുകളുടെ മൂല്യങ്ങൾ ഉപയോഗിച്ച് പട്ടികകളിൽ ചേരുന്നതും ഈ മൂല്യങ്ങൾ ഉപയോഗിച്ച് പ്രമാണങ്ങൾ തിരഞ്ഞെടുക്കുന്നതും ബുദ്ധിമുട്ടാക്കുന്നു. എന്നിരുന്നാലും, അത്തരമൊരു ഫീൽഡിനായി ഒരു കണക്കുകൂട്ടിയ കോളവും അതിൽ ഒരു സൂചികയും സൃഷ്ടിക്കാൻ കഴിയും.

കൂടാതെ, MS SQL സെർവർ, ഓപ്പറേറ്റർ ഉപയോഗിച്ച് പട്ടികകളിലെ ഉള്ളടക്കത്തിൽ നിന്ന് സൗകര്യപ്രദമായി ഒരു JSON പ്രമാണം നിർമ്മിക്കാനുള്ള കഴിവ് നൽകുന്നു. FOR JSON PATH - ഒരു സാധ്യത, ഒരു പ്രത്യേക അർത്ഥത്തിൽ, മുമ്പത്തേതിന് വിപരീതമായി, പരമ്പരാഗത സംഭരണം. ഒരു ആർ‌ഡി‌ബി‌എം‌എസ് എത്ര വേഗതയുള്ളതാണെങ്കിലും, ഈ സമീപനം ഡോക്യുമെന്റ് ഡി‌ബി‌എം‌എസുകളുടെ പ്രത്യയശാസ്ത്രത്തിന് വിരുദ്ധമാണെന്ന് വ്യക്തമാണ്, ഇത് പ്രധാനമായും ജനപ്രിയ ചോദ്യങ്ങൾക്കുള്ള റെഡിമെയ്ഡ് ഉത്തരങ്ങൾ സംഭരിക്കുന്നു, മാത്രമല്ല വികസനത്തിന്റെ എളുപ്പത്തിലുള്ള പ്രശ്നങ്ങൾ മാത്രമേ പരിഹരിക്കാൻ കഴിയൂ, പക്ഷേ വേഗതയല്ല.

അവസാനമായി, ഡോക്യുമെന്റ് നിർമ്മാണത്തിന്റെ വിപരീത പ്രശ്നം പരിഹരിക്കാൻ MS SQL സെർവർ നിങ്ങളെ അനുവദിക്കുന്നു: നിങ്ങൾക്ക് 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; അതേ കാരണത്താൽ, ഡാറ്റ ചേർക്കുന്നതിനുള്ള അന്വേഷണങ്ങൾ അനാവശ്യമായി ബുദ്ധിമുട്ടുള്ളതിനാൽ ഇവിടെ കാണിക്കുന്നില്ല).

MS SQL സെർവറിലെ ഡോക്യുമെന്റിന്റെയും ഗ്രാഫ് മോഡലുകളുടെയും നിർവ്വഹണങ്ങളുടെ വിവരണം സംഗ്രഹിക്കുന്നതിന്, ഒരു മോഡലിന് മുകളിൽ മറ്റൊന്ന് നടപ്പിലാക്കുന്നത് വിജയകരമാണെന്ന് തോന്നുന്നില്ല, പ്രാഥമികമായി ഭാഷാ രൂപകൽപ്പനയുടെ വീക്ഷണകോണിൽ നിന്ന്. ഒരു ഭാഷ മറ്റൊന്നുമായി വിപുലീകരിക്കേണ്ടത് ആവശ്യമാണ്, ഭാഷകൾ പൂർണ്ണമായും “ഓർത്തോഗണൽ” അല്ല, അനുയോജ്യത നിയമങ്ങൾ തികച്ചും വിചിത്രമായിരിക്കും.

ഡോക്യുമെന്റ് മോഡലിനെ അടിസ്ഥാനമാക്കിയുള്ള മൾട്ടി മോഡൽ DBMS

ഈ വിഭാഗത്തിൽ, ഡോക്യുമെന്റ് ഡിബിഎംഎസുകളിൽ മൾട്ടി-മോഡൽ നടപ്പിലാക്കുന്നത് അവയിൽ ഏറ്റവും ജനപ്രിയമല്ലാത്ത മോംഗോഡിബിയുടെ ഉദാഹരണം ഉപയോഗിച്ച് ചിത്രീകരിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു (പറഞ്ഞതുപോലെ, ഇതിന് സോപാധിക ഗ്രാഫ് ഓപ്പറേറ്റർമാർ മാത്രമേയുള്ളൂ. $lookup и $graphLookup, ഷെർഡഡ് കളക്ഷനുകളിൽ പ്രവർത്തിക്കുന്നില്ല), എന്നാൽ കൂടുതൽ പക്വതയുള്ളതും “എന്റർപ്രൈസ്” DBMS ന്റെ ഉദാഹരണം ഉപയോഗിക്കുന്നു മാർക്ക്ലോജിക്.

അതിനാൽ, ശേഖരത്തിൽ ഇനിപ്പറയുന്ന തരത്തിലുള്ള XML പ്രമാണങ്ങളുടെ ഒരു കൂട്ടം അടങ്ങിയിരിക്കട്ടെ (JSON പ്രമാണങ്ങൾ സംഭരിക്കുന്നതിന് MarkLogic നിങ്ങളെ അനുവദിക്കുന്നു):

<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-ന് പൂർണ്ണമായും പരിമിതമായ ആപേക്ഷിക വീക്ഷണങ്ങൾ ഉണ്ടായിരുന്നു സൂചിക അടിസ്ഥാനമാക്കിയുള്ളത് എഴുതാവുന്നതാണ്, എന്നാൽ ഇപ്പോൾ അവ ഒഴിവാക്കപ്പെട്ടതായി കണക്കാക്കപ്പെടുന്നു.

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 ഗ്രാഫ് മോഡലിനെ മറ്റ് രണ്ട് വഴികളിൽ പിന്തുണയ്ക്കുന്നു:

1. ഒരു DBMS എന്നത് RDF ഡാറ്റയുടെ പൂർണ്ണമായ വേറിട്ട സംഭരണമാണ് (അതിലെ ട്രിപ്പിൾറ്റുകൾ എന്ന് വിളിക്കപ്പെടും നിയന്ത്രിച്ചു മുകളിൽ വിവരിച്ചതിൽ നിന്ന് വ്യത്യസ്തമായി എക്‌സ്‌ട്രാക്റ്റുചെയ്‌തു).
2. സ്പെഷ്യൽ സീരിയലൈസേഷനിലെ RDF, XML അല്ലെങ്കിൽ JSON ഡോക്യുമെന്റുകളിലേക്ക് ലളിതമായി ചേർക്കാവുന്നതാണ് (അപ്പോൾ ട്രിപ്പിൾസ് എന്ന് വിളിക്കപ്പെടും. നിയന്ത്രിക്കാത്തത്). ഇത് ഒരുപക്ഷേ മെക്കാനിസങ്ങൾക്കുള്ള ഒരു ബദലാണ് idref മറ്റുള്ളവരും.

MarkLogic-ൽ കാര്യങ്ങൾ "യഥാർത്ഥത്തിൽ" എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിനെക്കുറിച്ചുള്ള ഒരു നല്ല ആശയം നൽകിയിരിക്കുന്നു ഒപ്റ്റിക്കൽ API, ഈ അർത്ഥത്തിൽ, ഇത് താഴ്ന്ന നിലയാണ്, അതിന്റെ ഉദ്ദേശ്യം വിപരീതമാണെങ്കിലും - ഉപയോഗിച്ച ഡാറ്റ മോഡലിൽ നിന്ന് സംഗ്രഹിക്കാൻ ശ്രമിക്കുക, വ്യത്യസ്ത മോഡലുകളിലെ ഡാറ്റയുമായി സ്ഥിരതയുള്ള പ്രവർത്തനം ഉറപ്പാക്കുക, ഇടപാട് മുതലായവ.

മൾട്ടി മോഡൽ DBMS "ഒരു പ്രധാന മോഡൽ ഇല്ലാതെ"

പാരമ്പര്യമായി ലഭിച്ച പ്രധാന മോഡലുകളൊന്നുമില്ലാതെ, തുടക്കത്തിൽ മൾട്ടി-മോഡലായി തങ്ങളെത്തന്നെ പ്രതിഷ്ഠിക്കുന്ന DBMS-കളും വിപണിയിലുണ്ട്. ഇതിൽ ഉൾപ്പെടുന്നവ അരങ്കോഡിബി, ഓറിയന്റ് DB (2018 മുതൽ വികസന കമ്പനി എസ്എപിയുടേതാണ്) കൂടാതെ കോസ്മോസ്ഡിബി (മൈക്രോസോഫ്റ്റ് അസൂർ ക്ലൗഡ് പ്ലാറ്റ്‌ഫോമിന്റെ ഭാഗമായുള്ള സേവനം).

വാസ്തവത്തിൽ, ArangoDB, OrientDB എന്നിവയിൽ "കോർ" മോഡലുകൾ ഉണ്ട്. രണ്ട് സാഹചര്യങ്ങളിലും, ഇവ അവരുടെ സ്വന്തം ഡാറ്റ മോഡലുകളാണ്, അവ ഡോക്യുമെന്റ് ഒന്നിന്റെ പൊതുവൽക്കരണമാണ്. ഒരു ഗ്രാഫിന്റെയും റിലേഷണൽ സ്വഭാവത്തിന്റെയും അന്വേഷണങ്ങൾ നടത്താനുള്ള കഴിവ് സുഗമമാക്കുന്നതിനാണ് സാമാന്യവൽക്കരണം പ്രധാനമായും.

നിർദ്ദിഷ്‌ട DBMS-ൽ ഉപയോഗിക്കുന്നതിന് ഈ മോഡലുകൾ മാത്രമേ ലഭ്യമാകൂ; അവരോടൊപ്പം പ്രവർത്തിക്കാൻ അവരുടെ സ്വന്തം അന്വേഷണ ഭാഷകൾ രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്നു. തീർച്ചയായും, അത്തരം മോഡലുകളും ഡിബിഎംഎസുകളും വാഗ്ദാനമാണ്, എന്നാൽ സ്റ്റാൻഡേർഡ് മോഡലുകളുമായും ഭാഷകളുമായും അനുയോജ്യതയുടെ അഭാവം ഈ ഡിബിഎംഎസുകൾ ലെഗസി സിസ്റ്റങ്ങളിൽ ഉപയോഗിക്കുന്നത് അസാധ്യമാക്കുന്നു-അവിടെ ഇതിനകം ഉപയോഗിച്ചിരുന്ന ഡിബിഎംഎസുകൾക്ക് പകരമായി.

Habré-യിൽ ArangoDB, OrientDB എന്നിവയെക്കുറിച്ച് ഇതിനകം ഒരു അത്ഭുതകരമായ ലേഖനം ഉണ്ടായിരുന്നു: NoSQL ഡാറ്റാബേസുകളിൽ ചേരുക.

അരങ്കോഡിബി

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 : ["Джон Донн"] }
]

ഓറിയന്റ് DB

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": [ "Жан-Жак" ' }
]

ഓറിയന്റ്ഡിബിയുടെ അന്വേഷണ ഭാഷയെ ഗ്രെംലിൻ പോലുള്ള ഇൻസെർട്ടുകളുള്ള 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 എന്നിവ ഉപയോഗിക്കുന്നു. Gremlin API, Cassandra API - യഥാക്രമം ഗ്രാഫ്, കോളം ഫോർമാറ്റുകളിൽ ഡാറ്റ ആക്സസ് ചെയ്യുന്നതിന്. എല്ലാ മോഡലുകളിലെയും ഡാറ്റ CosmosDB ആന്തരിക മോഡൽ ഫോർമാറ്റിൽ സംരക്ഷിക്കപ്പെടുന്നു: ARS (“ആറ്റം-റെക്കോർഡ്-സീക്വൻസ്”), ഇത് ഡോക്യുമെന്റ് ഒന്നിന് സമീപമാണ്.

എന്നാൽ സേവനത്തിൽ ഒരു അക്കൗണ്ട് സൃഷ്ടിക്കുന്ന സമയത്ത് ഉപയോക്താവ് തിരഞ്ഞെടുത്ത ഡാറ്റാ മോഡലും ഉപയോഗിച്ച API ഉം നിശ്ചയിച്ചിരിക്കുന്നു. ഒരു മോഡലിൽ ലോഡ് ചെയ്‌ത ഡാറ്റ മറ്റൊരു മോഡലിന്റെ ഫോർമാറ്റിൽ ആക്‌സസ് ചെയ്യാൻ സാധ്യമല്ല, ഇതുപോലുള്ള ഒന്ന് ചിത്രീകരിച്ചിരിക്കുന്നു:

അതിനാൽ, ഇന്ന് അസൂർ കോസ്മോസ്ഡിബിയിലെ മൾട്ടി മോഡൽ ഒരു നിർമ്മാതാവിൽ നിന്ന് വ്യത്യസ്ത മോഡലുകളെ പിന്തുണയ്ക്കുന്ന നിരവധി ഡാറ്റാബേസുകൾ ഉപയോഗിക്കാനുള്ള കഴിവ് മാത്രമാണ്, ഇത് മൾട്ടി-വേരിയന്റ് സ്റ്റോറേജിന്റെ എല്ലാ പ്രശ്നങ്ങളും പരിഹരിക്കില്ല.

ഒരു ഗ്രാഫ് മോഡലിനെ അടിസ്ഥാനമാക്കിയുള്ള മൾട്ടി മോഡൽ DBMS?

ഒരു ഗ്രാഫ് മോഡലിനെ അടിസ്ഥാനമാക്കിയുള്ള മൾട്ടി-മോഡൽ ഡിബിഎംഎസുകളൊന്നും ഇതുവരെ വിപണിയിലില്ല എന്നത് ശ്രദ്ധേയമാണ് (ഒരേസമയം രണ്ട് ഗ്രാഫ് മോഡലുകൾക്കുള്ള മൾട്ടി മോഡൽ പിന്തുണ ഒഴികെ: RDF, LPG; ഇതിൽ കാണുക മുൻ പ്രസിദ്ധീകരണം). ഒരു ഗ്രാഫ് മോഡലിന് മുകളിൽ ഒരു ഡോക്യുമെന്റ് മോഡൽ നടപ്പിലാക്കുന്നതാണ് ഏറ്റവും വലിയ ബുദ്ധിമുട്ടുകൾ ഉണ്ടാകുന്നത്.

ഗ്രാഫ് മോഡലിന് മുകളിൽ ഒരു റിലേഷണൽ മോഡൽ എങ്ങനെ നടപ്പിലാക്കാം എന്ന ചോദ്യം രണ്ടാമത്തേതിന്റെ രൂപീകരണ സമയത്ത് പോലും പരിഗണിച്ചിരുന്നു. എങ്ങനെ സംസാരിച്ചുഉദാഹരണത്തിന് ഡേവിഡ് മക്ഗവർൺ:

ഒരു ഗ്രാഫ് ഡാറ്റാബേസിൽ ഒരു ലെയർ (ഉദാഹരണത്തിന്, അനുയോജ്യമായ ഇൻഡക്‌സിംഗ് വഴി) സൃഷ്ടിക്കുന്നതിനെ തടയുന്ന ഒന്നും ഗ്രാഫ് സമീപനത്തിൽ അന്തർലീനമല്ല, അത് (1) സാധാരണ കീ വാല്യു ജോഡികളിൽ നിന്ന് ട്യൂപ്പിൾസ് വീണ്ടെടുക്കുന്നതിലൂടെയും (2) ഗ്രൂപ്പിംഗിലൂടെയും ആപേക്ഷിക കാഴ്ച പ്രാപ്തമാക്കുന്നു. ബന്ധ തരം അനുസരിച്ച് tuples.

ഒരു ഗ്രാഫ് മോഡലിന് മുകളിൽ ഒരു ഡോക്യുമെന്റ് മോഡൽ നടപ്പിലാക്കുമ്പോൾ, നിങ്ങൾ മനസ്സിൽ സൂക്ഷിക്കേണ്ടതുണ്ട്, ഉദാഹരണത്തിന്, ഇനിപ്പറയുന്നവ:

• ഒരു JSON അറേയുടെ മൂലകങ്ങൾ ക്രമീകരിച്ചതായി കണക്കാക്കപ്പെടുന്നു, എന്നാൽ ഗ്രാഫിന്റെ അരികിൽ നിന്ന് പുറപ്പെടുന്നവ അങ്ങനെയല്ല;
• ഡോക്യുമെന്റ് മോഡലിലെ ഡാറ്റ സാധാരണയായി ഡീനോർമലൈസ് ചെയ്യപ്പെടുന്നു; ഒരേ എംബഡഡ് ഡോക്യുമെന്റിന്റെ നിരവധി പകർപ്പുകൾ നിങ്ങൾക്ക് ഇപ്പോഴും സംഭരിക്കാൻ താൽപ്പര്യമില്ല, കൂടാതെ ഉപഡോക്യുമെന്റുകൾക്ക് സാധാരണയായി ഐഡന്റിഫയറുകൾ ഉണ്ടാകില്ല;
• മറുവശത്ത്, ഡോക്യുമെന്റ് ഡിബിഎംഎസുകളുടെ പ്രത്യയശാസ്ത്രം ഡോക്യുമെന്റുകൾ റെഡിമെയ്ഡ് "അഗ്രഗേറ്റുകൾ" ആണ്, അത് ഓരോ തവണയും പുതുതായി നിർമ്മിക്കേണ്ടതില്ല. പൂർത്തിയായ ഡോക്യുമെന്റിന് അനുയോജ്യമായ ഒരു സബ്ഗ്രാഫ് വേഗത്തിൽ നേടാനുള്ള കഴിവ് ഗ്രാഫ് മോഡലിന് നൽകേണ്ടത് ആവശ്യമാണ്.

ഒരു ചെറിയ പരസ്യം

ലേഖനത്തിന്റെ രചയിതാവ് NitrosBase DBMS ന്റെ വികസനവുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു, ഇതിന്റെ ആന്തരിക മാതൃക ഗ്രാഫ് ആണ്, ബാഹ്യ മോഡലുകൾ - റിലേഷണൽ, ഡോക്യുമെന്റ് - അതിന്റെ പ്രതിനിധാനങ്ങളാണ്. എല്ലാ മോഡലുകളും തുല്യമാണ്: അവയിലൊന്നിലും സ്വാഭാവികമായ ഒരു അന്വേഷണ ഭാഷ ഉപയോഗിച്ച് മിക്കവാറും എല്ലാ ഡാറ്റയും ലഭ്യമാണ്. മാത്രമല്ല, ഏത് കാഴ്ചയിലും, ഡാറ്റ മാറ്റാൻ കഴിയും. മാറ്റങ്ങൾ ആന്തരിക മാതൃകയിലും അതനുസരിച്ച് മറ്റ് കാഴ്ചകളിലും പ്രതിഫലിക്കും.

ഇനിപ്പറയുന്ന ലേഖനങ്ങളിലൊന്നിൽ NitrosBase-ൽ മോഡൽ പൊരുത്തപ്പെടുത്തൽ എങ്ങനെയുണ്ടെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു.

തീരുമാനം

മൾട്ടി-മോഡലിംഗ് എന്ന് വിളിക്കപ്പെടുന്നതിന്റെ പൊതുവായ രൂപരേഖകൾ വായനക്കാരന് ഏറെക്കുറെ വ്യക്തമായതായി ഞാൻ പ്രതീക്ഷിക്കുന്നു. മൾട്ടി മോഡൽ DBMS-കൾ തികച്ചും വ്യത്യസ്തമാണ്, കൂടാതെ "മൾട്ടി മോഡൽ പിന്തുണ" വ്യത്യസ്തമായി കാണാവുന്നതാണ്. ഓരോ നിർദ്ദിഷ്ട കേസിലും "മൾട്ടി മോഡൽ" എന്ന് വിളിക്കുന്നത് എന്താണെന്ന് മനസിലാക്കാൻ, ഇനിപ്പറയുന്ന ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നത് ഉപയോഗപ്രദമാണ്:

1. ഞങ്ങൾ പരമ്പരാഗത മോഡലുകളെ പിന്തുണയ്ക്കുന്നതിനെക്കുറിച്ചാണോ അല്ലെങ്കിൽ ഏതെങ്കിലും തരത്തിലുള്ള "ഹൈബ്രിഡ്" മോഡലിനെക്കുറിച്ചാണോ സംസാരിക്കുന്നത്?
2. മോഡലുകൾ "തുല്യം" ആണോ, അതോ അവയിലൊന്ന് മറ്റുള്ളവരുടെ വിഷയമാണോ?
3. മോഡലുകൾ പരസ്പരം "നിസംഗത" ആണോ? ഒരു മോഡലിൽ എഴുതിയ ഡാറ്റ മറ്റൊന്നിൽ വായിക്കാനോ അല്ലെങ്കിൽ തിരുത്തിയെഴുതാനോ കഴിയുമോ?

മൾട്ടി-മോഡൽ ഡിബിഎംഎസിന്റെ പ്രസക്തിയെക്കുറിച്ചുള്ള ചോദ്യത്തിന് ഇതിനകം പോസിറ്റീവായി ഉത്തരം നൽകാൻ കഴിയുമെന്ന് ഞാൻ കരുതുന്നു, എന്നാൽ സമീപഭാവിയിൽ ഏത് തരത്തിലുള്ള അവയ്ക്ക് കൂടുതൽ ഡിമാൻഡുണ്ടാകും എന്നതാണ് രസകരമായ ചോദ്യം. പരമ്പരാഗത മോഡലുകളെ പിന്തുണയ്ക്കുന്ന മൾട്ടി-മോഡൽ DBMS-കൾക്ക്, പ്രാഥമികമായി റിലേഷണൽ, കൂടുതൽ ഡിമാൻഡിൽ ആയിരിക്കുമെന്ന് തോന്നുന്നു; മൾട്ടി മോഡൽ ഡിബിഎംഎസുകളുടെ ജനപ്രീതി, വിവിധ പരമ്പരാഗത മോഡലുകളുടെ ഗുണങ്ങൾ സംയോജിപ്പിക്കുന്ന പുതിയ മോഡലുകൾ വാഗ്ദാനം ചെയ്യുന്നത് കൂടുതൽ വിദൂര ഭാവിയുടെ കാര്യമാണ്.

രജിസ്റ്റർ ചെയ്ത ഉപയോക്താക്കൾക്ക് മാത്രമേ സർവേയിൽ പങ്കെടുക്കാൻ കഴിയൂ. സൈൻ ഇൻദയവായി.

നിങ്ങൾ മൾട്ടി മോഡൽ DBMS ഉപയോഗിക്കുന്നുണ്ടോ?

• ഞങ്ങൾ അത് ഉപയോഗിക്കുന്നില്ല, ഞങ്ങൾ എല്ലാം ഒരു ഡിബിഎംഎസിലും ഒരു മോഡലിലും സംഭരിക്കുന്നു

• പരമ്പരാഗത DBMS-കളുടെ മൾട്ടി മോഡൽ കഴിവുകൾ ഞങ്ങൾ ഉപയോഗിക്കുന്നു

• ഞങ്ങൾ പോളിഗ്ലോട്ട് പെർസിസ്റ്റൻസ് പരിശീലിക്കുന്നു

• ഞങ്ങൾ പുതിയ മൾട്ടി മോഡൽ DBMS ഉപയോഗിക്കുന്നു (അരങ്കോ, ഓറിയന്റ്, കോസ്മോസ്ഡിബി)

19 ഉപയോക്താക്കൾ വോട്ട് ചെയ്തു. 4 ഉപയോക്താക്കൾ വിട്ടുനിന്നു.

അവലംബം: www.habr.com