ລະບົບຂໍ້ມູນຂ່າວສານທີ່ທັນສະໄຫມແມ່ນຂ້ອນຂ້າງສັບສົນ. ບໍ່ຢ່າງຫນ້ອຍ, ຄວາມສັບສົນຂອງພວກເຂົາແມ່ນຍ້ອນຄວາມສັບສົນຂອງຂໍ້ມູນທີ່ປຸງແຕ່ງຢູ່ໃນພວກມັນ. ຄວາມສັບສົນຂອງຂໍ້ມູນມັກຈະຢູ່ໃນຄວາມຫລາກຫລາຍຂອງແບບຈໍາລອງຂໍ້ມູນທີ່ໃຊ້. ດັ່ງນັ້ນ, ສໍາລັບຕົວຢ່າງ, ເມື່ອຂໍ້ມູນກາຍເປັນ "ໃຫຍ່", ຫນຶ່ງໃນລັກສະນະທີ່ເປັນບັນຫາແມ່ນບໍ່ພຽງແຕ່ປະລິມານຂອງມັນ ("ປະລິມານ"), ແຕ່ຍັງຫຼາກຫຼາຍຂອງມັນ ("ແນວພັນ").

ຖ້າຫາກວ່າທ່ານຍັງບໍ່ທັນພົບຂໍ້ບົກພ່ອງໃນການສົມເຫດສົມຜົນ, ຫຼັງຈາກນັ້ນອ່ານຕໍ່ໄປ.

ເນື້ອໃນ

Polyglot ຄົງຢູ່
ຫຼາຍແບບ
DBMS ຫຼາຍຮູບແບບໂດຍອີງໃສ່ຕົວແບບທີ່ກ່ຽວຂ້ອງ
     ຮູບແບບເອກະສານໃນ MS SQL Server
     ຮູບແບບກຣາຟໃນ MS SQL Server
DBMS ຫຼາຍຮູບແບບໂດຍອີງໃສ່ຮູບແບບເອກະສານ
     ຮູບແບບຄວາມສໍາພັນໃນ MarkLogic
     ຮູບແບບກາຟໃນ MarkLogic
DBMS ຫຼາຍແບບ "ໂດຍບໍ່ມີຮູບແບບຕົ້ນຕໍ"
     ArangoDB
     OrientDB
     Azure CosmosDB
DBMS ຫຼາຍຮູບແບບໂດຍອີງໃສ່ຮູບແບບກາຟ?
ສະຫລຸບ
Poll

Polyglot ຄົງຢູ່

ຂ້າງເທິງນີ້ນໍາໄປສູ່ຄວາມຈິງທີ່ວ່າບາງຄັ້ງເຖິງແມ່ນວ່າຢູ່ໃນກອບຂອງລະບົບຫນຶ່ງມັນຈໍາເປັນຕ້ອງໃຊ້ DBMSs ທີ່ແຕກຕ່າງກັນຫຼາຍເພື່ອເກັບຂໍ້ມູນແລະແກ້ໄຂບັນຫາຕ່າງໆໃນການປຸງແຕ່ງພວກມັນ, ແຕ່ລະຄົນສະຫນັບສະຫນູນຮູບແບບຂໍ້ມູນຂອງຕົນເອງ. ດ້ວຍມືເບົາຂອງ M. Fowler, ຜູ້ຂຽນ ປື້ມທີ່ມີຊື່ສຽງຈໍານວນຫນຶ່ງແລະຫນຶ່ງໃນ ຜູ້ຂຽນຮ່ວມ Agile Manifesto, ສະຖານະການນີ້ເອີ້ນວ່າ ການເກັບຮັກສາຫຼາຍຊະນິດ (“ຄວາມຄົງຕົວຂອງ polyglot”).

Fowler ຍັງມີຕົວຢ່າງຕໍ່ໄປນີ້ຂອງການຈັດຕັ້ງການເກັບຮັກສາຂໍ້ມູນໃນຄໍາຮ້ອງສະຫມັກທີ່ມີຄຸນສົມບັດເຕັມທີ່ແລະໂຫຼດສູງໃນພາກສະຫນາມຂອງອີຄອມເມີຊ.

ຕົວຢ່າງນີ້, ແນ່ນອນ, ແມ່ນຂ້ອນຂ້າງເກີນໄປ, ແຕ່ບາງການພິຈາລະນາໃນການເລືອກຫນຶ່ງຫຼືອື່ນ DBMS ສໍາລັບຈຸດປະສົງທີ່ສອດຄ້ອງກັນສາມາດພົບເຫັນ, ສໍາລັບການຍົກຕົວຢ່າງ,. ທີ່ນີ້.

ເຫັນໄດ້ແຈ້ງວ່າການເປັນຄົນຮັບໃຊ້ໃນສວນສັດນັ້ນບໍ່ແມ່ນເລື່ອງງ່າຍ.

ຈໍານວນລະຫັດທີ່ປະຕິບັດການເກັບຮັກສາຂໍ້ມູນເຕີບໂຕໃນອັດຕາສ່ວນຂອງຈໍານວນ DBMS ທີ່ໃຊ້; ຈໍານວນລະຫັດ synchronizing ຂໍ້ມູນແມ່ນດີຖ້າຫາກວ່າບໍ່ອັດຕາສ່ວນກັບສີ່ຫຼ່ຽມຂອງຕົວເລກນີ້.
ເນື່ອງຈາກຈໍານວນ DBMSs ຫຼາຍໆຄັ້ງທີ່ໃຊ້, ຄ່າໃຊ້ຈ່າຍໃນການສະຫນອງຄຸນລັກສະນະວິສາຫະກິດ (ຂະຫນາດ, ຄວາມທົນທານຕໍ່ຄວາມຜິດ, ຄວາມພ້ອມສູງ) ຂອງແຕ່ລະ DBMS ທີ່ໃຊ້ເພີ່ມຂຶ້ນ.
ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະຮັບປະກັນລັກສະນະວິສາຫະກິດຂອງລະບົບຍ່ອຍການເກັບຮັກສາທັງຫມົດ - ໂດຍສະເພາະການເຮັດທຸລະກໍາ.

ຈາກທັດສະນະຂອງຜູ້ອໍານວຍການສວນສັດ, ທຸກສິ່ງທຸກຢ່າງເບິ່ງຄືວ່າ:

ການເພີ່ມຂຶ້ນຂອງຄ່າໃຊ້ຈ່າຍຂອງໃບອະນຸຍາດແລະການສະຫນັບສະຫນູນດ້ານວິຊາການຈາກຜູ້ຜະລິດ DBMS.
ພະນັກງານເກີນກຳນົດ ແລະກຳນົດເວລາເພີ່ມຂຶ້ນ.
ການສູນເສຍທາງດ້ານການເງິນໂດຍກົງຫຼືການລົງໂທດເນື່ອງຈາກຂໍ້ມູນບໍ່ສອດຄ່ອງກັນ.

ມີການເພີ່ມຂຶ້ນຢ່າງຫຼວງຫຼາຍໃນຄ່າໃຊ້ຈ່າຍທັງຫມົດຂອງການເປັນເຈົ້າຂອງລະບົບ (TCO). ມີວິທີໃດອອກຈາກສະຖານະການຂອງ "ທາງເລືອກໃນການເກັບຮັກສາຫຼາຍ"?

ຫຼາຍແບບ

ຄໍາວ່າ "ການເກັບຮັກສາ multivariate" ໄດ້ຖືກນໍາໃຊ້ໃນປີ 2011. ຄວາມຮັບຮູ້ກ່ຽວກັບບັນຫາຂອງວິທີການແລະການຊອກຫາວິທີແກ້ໄຂໃຊ້ເວລາຫຼາຍປີ, ແລະໃນປີ 2015, ຜ່ານປາກຂອງນັກວິເຄາະ Gartner, ຄໍາຕອບໄດ້ຖືກສ້າງຂື້ນ:

ຈາກ "ຄູ່ມືການຕະຫຼາດສໍາລັບ NoSQL DBMSs - 2015"
ອະນາຄົດຂອງ DBMSs, ສະຖາປັດຕະຍະກໍາແລະວິທີການນໍາໃຊ້ພວກມັນແມ່ນຫຼາຍແບບ.
ຈາກ "Magic Quadrant ສໍາລັບ ODBMS - 2016"
DBMSs ຊັ້ນນໍາຂອງການດໍາເນີນງານຈະສະເຫນີຫຼາຍຮູບແບບ - ທີ່ກ່ຽວຂ້ອງແລະບໍ່ກ່ຽວຂ້ອງ - ເປັນສ່ວນຫນຶ່ງຂອງເວທີດຽວ.

ມັນເບິ່ງຄືວ່າເວລານີ້ນັກວິເຄາະ Gartner ຖືກຕ້ອງກັບການຄາດຄະເນຂອງພວກເຂົາ. ຖ້າທ່ານໄປຫາຫນ້າດ້ວຍ ການຈັດອັນດັບຫຼັກ DBMS ໃນ DB-Engines, ທ່ານສາມາດເບິ່ງວ່າоຜູ້ນໍາສ່ວນໃຫຍ່ຂອງຕົນວາງຕໍາແຫນ່ງໂດຍສະເພາະເປັນ DBMSs ຫຼາຍແບບ. ດຽວກັນສາມາດເຫັນໄດ້ໃນຫນ້າທີ່ມີການຈັດອັນດັບສ່ວນຕົວໃດໆ.

ຕາຕະລາງຂ້າງລຸ່ມນີ້ສະແດງໃຫ້ເຫັນ DBMS - ຜູ້ນໍາໃນແຕ່ລະການຈັດອັນດັບສ່ວນຕົວ, ເຊິ່ງອ້າງວ່າມີຫຼາຍແບບ. ສໍາລັບແຕ່ລະ DBMS, ຮູບແບບທີ່ສະຫນັບສະຫນູນຕົ້ນສະບັບ (ທີ່ເຄີຍເປັນຫນຶ່ງຄັ້ງດຽວ) ແລະພ້ອມກັບມັນແບບຈໍາລອງທີ່ສະຫນັບສະຫນູນໃນປັດຈຸບັນແມ່ນຊີ້ໃຫ້ເຫັນ. ຍັງມີລາຍຊື່ DBMSs ທີ່ຕັ້ງຕົວເອງເປັນ "ຫຼາຍແບບເດີມ" ແລະ, ອີງຕາມຜູ້ສ້າງ, ບໍ່ມີຮູບແບບການສືບທອດເບື້ອງຕົ້ນໃດໆ.

DBMS	ຮູບແບບເບື້ອງຕົ້ນ	ຮູບແບບເພີ່ມເຕີມ
Oracle	ຄວາມສຳພັນ	ກຣາບ, ເອກະສານ
MS SQL	ຄວາມສຳພັນ	ກຣາບ, ເອກະສານ
PostgreSQL	ຄວາມສຳພັນ	ກຣາບ*, ເອກະສານ
MarkLogic	ສາລະຄະດີ	ກຣາບ, ຄວາມສຳພັນ
MongoDB	ສາລະຄະດີ	Key-value, ກຣາບ*
DataStax	ຖັນກວ້າງ	ສາລະຄະດີ, ກຣາຟ
Redis	ຄີ-ຄ່າ	ສາລະຄະດີ, ກຣາບ *
ArangoDB	-	ກຣາບ, ເອກະສານ
OrientDB	-	ກຣາບ, ເອກະສານ, ຄວາມສຳພັນ
Azure CosmosDB	-	ກຣາບ, ເອກະສານ, ຄວາມສຳພັນ

ຫມາຍເຫດໃນຕາຕະລາງ

ເຄື່ອງໝາຍດາວໃນຕາຕະລາງໝາຍເຫດທີ່ຕ້ອງການຈອງ:

PostgreSQL DBMS ບໍ່ຮອງຮັບຮູບແບບຂໍ້ມູນກາຟ, ແຕ່ຜະລິດຕະພັນນີ້ສະຫນັບສະຫນູນມັນ ອີງໃສ່ມັນ, ເຊັ່ນ AgensGraph.
ກ່ຽວຂ້ອງກັບ MongoDB, ມັນຖືກຕ້ອງກວ່າທີ່ຈະເວົ້າກ່ຽວກັບການມີຕົວປະຕິບັດການກາຟໃນພາສາສອບຖາມ ($lookup, $graphLookup) ກ່ວາກ່ຽວກັບການສະຫນັບສະຫນູນຮູບແບບກາຟ, ເຖິງແມ່ນວ່າ, ແນ່ນອນ, ການແນະນໍາຂອງພວກເຂົາຮຽກຮ້ອງໃຫ້ມີການເພີ່ມປະສິດທິພາບບາງຢ່າງໃນລະດັບການເກັບຮັກສາທາງດ້ານຮ່າງກາຍໃນທິດທາງຂອງການສະຫນັບສະຫນູນຮູບແບບກາຟ.
ກ່ຽວຂ້ອງກັບ Redis, ພວກເຮົາຫມາຍເຖິງການຂະຫຍາຍ RedisGraph.

ຕໍ່ໄປ, ສໍາລັບແຕ່ລະຊັ້ນຮຽນ, ພວກເຮົາຈະສະແດງວິທີການສະຫນັບສະຫນູນສໍາລັບຫຼາຍໆແບບຖືກປະຕິບັດໃນ DBMS ຈາກຫ້ອງຮຽນນີ້. ພວກເຮົາຈະພິຈາລະນາຕົວແບບທີ່ກ່ຽວຂ້ອງ, ເອກະສານແລະກາຟທີ່ມີຄວາມສໍາຄັນທີ່ສຸດແລະນໍາໃຊ້ຕົວຢ່າງຂອງ DBMSs ສະເພາະເພື່ອສະແດງໃຫ້ເຫັນວ່າ "ສິ່ງທີ່ຂາດຫາຍໄປ" ໄດ້ຖືກປະຕິບັດ.

DBMS ຫຼາຍຮູບແບບໂດຍອີງໃສ່ຕົວແບບທີ່ກ່ຽວຂ້ອງ

DBMSs ຊັ້ນນໍາໃນປະຈຸບັນແມ່ນມີຄວາມກ່ຽວຂ້ອງ; ການຄາດຄະເນຂອງ Gartner ບໍ່ສາມາດຖືວ່າເປັນຄວາມຈິງຖ້າ RDBMSs ບໍ່ໄດ້ສະແດງການເຄື່ອນໄຫວໃນທິດທາງຂອງການສ້າງແບບຈໍາລອງຫຼາຍ. ແລະພວກເຂົາສະແດງໃຫ້ເຫັນ. ໃນປັດຈຸບັນຄວາມຄິດທີ່ວ່າ DBMS ຫຼາຍຮຸ່ນແມ່ນຄ້າຍຄືມີດສະວິດເຊີແລນ, ເຊິ່ງບໍ່ສາມາດເຮັດຫຍັງໄດ້ດີ, ສາມາດຖືກນໍາໄປຫາ Larry Ellison ໂດຍກົງ.

ຢ່າງໃດກໍຕາມ, ຜູ້ຂຽນມັກການປະຕິບັດແບບຈໍາລອງຫຼາຍຮູບແບບໃນ Microsoft SQL Server, ໃນຕົວຢ່າງທີ່ RDBMS ສະຫນັບສະຫນູນສໍາລັບຮູບແບບເອກະສານແລະກາຟຈະຖືກອະທິບາຍ.

ຮູບແບບເອກະສານໃນ MS SQL Server

ມີສອງບົດຄວາມທີ່ດີເລີດກ່ຽວກັບ Habre ກ່ຽວກັບວິທີການ MS SQL Server ປະຕິບັດການສະຫນັບສະຫນູນສໍາລັບຮູບແບບເອກະສານ;

ວິທີການສະຫນັບສະຫນູນຮູບແບບເອກະສານໃນ MS SQL Server ແມ່ນຂ້ອນຂ້າງປົກກະຕິສໍາລັບ DBMSs ທີ່ກ່ຽວຂ້ອງ: ເອກະສານ JSON ຖືກສະເຫນີໃຫ້ຖືກເກັບໄວ້ໃນຊ່ອງຂໍ້ຄວາມທໍາມະດາ. ສະຫນັບສະຫນູນຮູບແບບເອກະສານແມ່ນເພື່ອສະຫນອງການປະຕິບັດພິເສດເພື່ອວິເຄາະ JSON ນີ້:

JSON_VALUE ເພື່ອສະກັດຄ່າຄຸນສົມບັດ scalar,
JSON_QUERY ເພື່ອສະກັດເອກະສານຍ່ອຍ.

ການໂຕ້ຖຽງທີສອງຂອງທັງສອງຕົວປະຕິບັດການແມ່ນການສະແດງອອກໃນ syntax ຄ້າຍຄື JSONPath.

ຢ່າງແທ້ຈິງ, ພວກເຮົາສາມາດເວົ້າໄດ້ວ່າເອກະສານທີ່ເກັບໄວ້ໃນລັກສະນະນີ້ບໍ່ແມ່ນ "ຫນ່ວຍງານຊັ້ນທໍາອິດ" ໃນ DBMS ທີ່ກ່ຽວຂ້ອງ, ບໍ່ເຫມືອນກັບ tuples. ໂດຍສະເພາະ, ໃນ MS SQL Server ປະຈຸບັນບໍ່ມີດັດສະນີໃນພາກສະຫນາມຂອງເອກະສານ JSON, ເຊິ່ງເຮັດໃຫ້ມັນຍາກທີ່ຈະເຂົ້າຮ່ວມຕາຕະລາງໂດຍໃຊ້ຄ່າຂອງຊ່ອງຂໍ້ມູນເຫຼົ່ານີ້ແລະແມ້ກະທັ້ງເລືອກເອກະສານໂດຍໃຊ້ຄ່າເຫຼົ່ານີ້. ຢ່າງໃດກໍ່ຕາມ, ມັນເປັນໄປໄດ້ທີ່ຈະສ້າງຄໍລໍາຄໍານວນສໍາລັບພາກສະຫນາມດັ່ງກ່າວແລະດັດສະນີກ່ຽວກັບມັນ.

ນອກຈາກນັ້ນ, MS SQL Server ສະຫນອງຄວາມສາມາດໃນການສ້າງເອກະສານ JSON ຢ່າງສະດວກຈາກເນື້ອໃນຂອງຕາຕະລາງໂດຍໃຊ້ຕົວປະຕິບັດການ. FOR JSON PATH - ຄວາມເປັນໄປໄດ້, ໃນຄວາມຫມາຍທີ່ແນ່ນອນ, ກົງກັນຂ້າມກັບອັນທີ່ຜ່ານມາ, ການເກັບຮັກສາທໍາມະດາ. ມັນເປັນທີ່ຊັດເຈນວ່າບໍ່ວ່າ RDBMS ຈະໄວປານໃດ, ວິທີການນີ້ຂັດກັບອຸດົມການຂອງເອກະສານ DBMSs, ເຊິ່ງເກັບຮັກສາຄໍາຕອບທີ່ກຽມພ້ອມສໍາລັບການສອບຖາມທີ່ນິຍົມ, ແລະພຽງແຕ່ສາມາດແກ້ໄຂບັນຫາຂອງຄວາມງ່າຍຂອງການພັດທະນາ, ແຕ່ບໍ່ແມ່ນຄວາມໄວ.

ສຸດທ້າຍ, MS SQL Server ຊ່ວຍໃຫ້ທ່ານສາມາດແກ້ໄຂບັນຫາກົງກັນຂ້າມຂອງການກໍ່ສ້າງເອກະສານ: ທ່ານສາມາດ decompose JSON ເຂົ້າໄປໃນຕາຕະລາງໂດຍໃຊ້ OPENJSON. ຖ້າເອກະສານບໍ່ລຽບ, ທ່ານຈະຕ້ອງໃຊ້ CROSS APPLY.

ຮູບແບບກຣາຟໃນ MS SQL Server

ການສະຫນັບສະຫນູນສໍາລັບຮູບແບບກາຟ (LPG) ຍັງຖືກປະຕິບັດຢ່າງເຕັມສ່ວນໃນ Microsoft SQL Server ຄາດຄະເນ: ສະເໜີໃຫ້ໃຊ້ຕາຕະລາງພິເສດເພື່ອເກັບ nodes ແລະເກັບຂອບກາຟ. ຕາຕະລາງດັ່ງກ່າວຖືກສ້າງຂື້ນໂດຍໃຊ້ການສະແດງອອກ CREATE TABLE AS NODE и CREATE TABLE AS EDGE respectively

ຕາຕະລາງຂອງປະເພດທໍາອິດແມ່ນຄ້າຍຄືກັນກັບຕາຕະລາງທໍາມະດາສໍາລັບການເກັບຮັກສາບັນທຶກ, ຄວາມແຕກຕ່າງພາຍນອກພຽງແຕ່ວ່າຕາຕະລາງປະກອບມີພາກສະຫນາມລະບົບ. $node_id — ຕົວລະບຸສະເພາະຂອງເສັ້ນກຣາຟພາຍໃນຖານຂໍ້ມູນ.

ເຊັ່ນດຽວກັນ, ຕາຕະລາງຂອງປະເພດທີສອງມີຊ່ອງຂໍ້ມູນລະບົບ $from_id и $to_id, ລາຍການໃນຕາຕະລາງດັ່ງກ່າວກໍານົດຢ່າງຊັດເຈນການເຊື່ອມຕໍ່ລະຫວ່າງ nodes. ຕາຕະລາງແຍກຕ່າງຫາກຖືກນໍາໃຊ້ເພື່ອເກັບຮັກສາຄວາມສໍາພັນຂອງແຕ່ລະປະເພດ.

ໃຫ້ພວກເຮົາຍົກຕົວຢ່າງນີ້ດ້ວຍຕົວຢ່າງ. ໃຫ້ຂໍ້ມູນກຣາຟມີໂຄງຮ່າງຄືກັບທີ່ສະແດງຢູ່ໃນຮູບ. ຫຼັງຈາກນັ້ນ, ເພື່ອສ້າງໂຄງສ້າງທີ່ສອດຄ້ອງກັນໃນຖານຂໍ້ມູນ, ທ່ານຈໍາເປັນຕ້ອງດໍາເນີນການສອບຖາມ 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);

ຄວາມສະເພາະຂອງຕາຕະລາງດັ່ງກ່າວແມ່ນວ່າໃນການສອບຖາມຕໍ່ກັບພວກມັນມັນເປັນໄປໄດ້ທີ່ຈະໃຊ້ຮູບແບບກາຟທີ່ມີ syntax ຄ້າຍຄື Cypher (ຢ່າງໃດກໍ່ຕາມ, ".*"etc. ຍັງບໍ່ໄດ້ຮັບການສະຫນັບສະຫນູນ). ອີງຕາມການວັດແທກການປະຕິບັດ, ມັນຍັງສາມາດສົມມຸດວ່າວິທີການເກັບຂໍ້ມູນໃນຕາຕະລາງເຫຼົ່ານີ້ແມ່ນແຕກຕ່າງຈາກວິທີການເກັບຂໍ້ມູນໃນຕາຕະລາງປົກກະຕິແລະຖືກປັບປຸງໃຫ້ເຫມາະສົມສໍາລັບການປະຕິບັດການສອບຖາມກາຟດັ່ງກ່າວ.

SELECT Cafe.name
  FROM Person, likes, Cafe
  WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
  AND Person.name = 'John';

ຍິ່ງໄປກວ່ານັ້ນ, ມັນເປັນການຍາກທີ່ຈະບໍ່ໃຊ້ຮູບແບບກາຟເຫຼົ່ານີ້ໃນເວລາທີ່ເຮັດວຽກກັບຕາຕະລາງດັ່ງກ່າວ, ເນື່ອງຈາກວ່າໃນແບບສອບຖາມ SQL ທໍາມະດາເພື່ອແກ້ໄຂບັນຫາທີ່ຄ້າຍຄືກັນ, ມັນຈໍາເປັນຕ້ອງພະຍາຍາມເພີ່ມເຕີມເພື່ອໃຫ້ໄດ້ລະບົບ "graph" node identifiers ($node_id, $from_id, $to_id; ສໍາລັບເຫດຜົນດຽວກັນ, ຄໍາຖາມສໍາລັບການໃສ່ຂໍ້ມູນບໍ່ໄດ້ສະແດງໃຫ້ເຫັນຢູ່ທີ່ນີ້ຍ້ອນວ່າພວກເຂົາມີຄວາມຫຍຸ້ງຍາກທີ່ບໍ່ຈໍາເປັນ).

ເພື່ອສະຫຼຸບລາຍລະອຽດຂອງການປະຕິບັດຂອງເອກະສານແລະຮູບແບບກາຟໃນ MS SQL Server, ຂ້ອຍຈະສັງເກດວ່າການຈັດຕັ້ງປະຕິບັດແບບຈໍາລອງແບບຫນຶ່ງຢູ່ເທິງສຸດຂອງຄົນອື່ນເບິ່ງຄືວ່າບໍ່ປະສົບຜົນສໍາເລັດ, ຕົ້ນຕໍຈາກທັດສະນະຂອງການອອກແບບພາສາ. ມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະຂະຫຍາຍພາສາຫນຶ່ງກັບອີກພາສາຫນຶ່ງ, ພາສາບໍ່ແມ່ນ "orthogonal", ກົດລະບຽບການເຂົ້າກັນໄດ້ຂ້ອນຂ້າງແປກປະຫຼາດ.

DBMS ຫຼາຍຮູບແບບໂດຍອີງໃສ່ຮູບແບບເອກະສານ

ໃນພາກນີ້, ຂ້າພະເຈົ້າຢາກຈະສະແດງໃຫ້ເຫັນເຖິງການປະຕິບັດແບບຈໍາລອງຫຼາຍແບບໃນເອກະສານ DBMSs ໂດຍໃຊ້ຕົວຢ່າງຂອງ MongoDB ທີ່ບໍ່ເປັນທີ່ນິຍົມທີ່ສຸດ (ດັ່ງທີ່ໄດ້ກ່າວ, ມັນມີພຽງແຕ່ຕົວປະຕິບັດການກາຟທີ່ມີເງື່ອນໄຂເທົ່ານັ້ນ. $lookup и $graphLookup, ບໍ່ໄດ້ເຮັດວຽກກ່ຽວກັບການເກັບ sharded), ແຕ່ການນໍາໃຊ້ຕົວຢ່າງຂອງ DBMS ແກ່ຫຼາຍແລະ "ວິສາຫະກິດ" MarkLogic.

ດັ່ງນັ້ນ, ໃຫ້ຊຸດເກັບລວບລວມເອກະສານ XML ຂອງປະເພດຕໍ່ໄປນີ້ (MarkLogic ຍັງອະນຸຍາດໃຫ້ທ່ານເກັບຮັກສາເອກະສານ JSON):

<Person INN="631803299804">
  <name>John</name>
  <surname>Smith</surname>
</Person>

ຮູບແບບຄວາມສໍາພັນໃນ MarkLogic

ທັດສະນະທີ່ກ່ຽວຂ້ອງຂອງການເກັບກໍາເອກະສານສາມາດຖືກສ້າງຂື້ນໂດຍໃຊ້ ສະແດງແມ່ແບບ (ເນື້ອໃນຂອງອົງປະກອບ value ໃນຕົວຢ່າງຂ້າງລຸ່ມນີ້ສາມາດມີ XPath arbitrary):

<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 ໃນ serialization ພິເສດສາມາດຖືກໃສ່ເຂົ້າໄປໃນເອກະສານ XML ຫຼື JSON (ແລະ triplets ຫຼັງຈາກນັ້ນຈະຖືກເອີ້ນ. ບໍ່ມີການຈັດການ). ນີ້ອາດຈະເປັນທາງເລືອກຂອງກົນໄກ idref ແລະອື່ນໆ.

ຄວາມຄິດທີ່ດີຂອງວິທີການທີ່ "ຈິງ" ເຮັດວຽກຢູ່ໃນ MarkLogic ໄດ້ຖືກມອບໃຫ້ໂດຍ Optical API, ໃນຄວາມຫມາຍນີ້, ມັນແມ່ນລະດັບຕ່ໍາ, ເຖິງແມ່ນວ່າຈຸດປະສົງຂອງມັນແມ່ນກົງກັນຂ້າມ - ເພື່ອພະຍາຍາມບໍ່ມີຕົວຕົນຈາກຕົວແບບຂໍ້ມູນທີ່ໃຊ້, ເພື່ອຮັບປະກັນການເຮັດວຽກທີ່ສອດຄ່ອງກັບຂໍ້ມູນໃນຮູບແບບຕ່າງໆ, ການເຮັດທຸລະກໍາ, ແລະອື່ນໆ.

DBMS ຫຼາຍແບບ "ໂດຍບໍ່ມີຮູບແບບຕົ້ນຕໍ"

ຍັງມີ DBMSs ຢູ່ໃນຕະຫຼາດທີ່ຕັ້ງຕົວເອງເປັນຫຼາຍແບບໃນເບື້ອງຕົ້ນ, ໂດຍບໍ່ມີຕົວແບບຕົ້ນຕໍທີ່ສືບທອດ. ເຫຼົ່ານີ້ລວມມີ ArangoDB, OrientDB (ນັບຕັ້ງແຕ່ປີ 2018 ບໍລິສັດພັດທະນາຂຶ້ນກັບ SAP) ແລະ CosmosDB (ການບໍລິການເປັນສ່ວນຫນຶ່ງຂອງ Microsoft Azure cloud platform).

ໃນຄວາມເປັນຈິງ, ມີຮູບແບບ "ຫຼັກ" ໃນ ArangoDB ແລະ OrientDB. ໃນທັງສອງກໍລະນີ, ເຫຼົ່ານີ້ແມ່ນຕົວແບບຂໍ້ມູນຂອງຕົນເອງ, ເຊິ່ງແມ່ນທົ່ວໄປຂອງເອກະສານຫນຶ່ງ. Generalizations ສ່ວນໃຫຍ່ແມ່ນເພື່ອອໍານວຍຄວາມສະດວກໃນການປະຕິບັດການສອບຖາມຂອງເສັ້ນສະແດງແລະລັກສະນະຄວາມສໍາພັນ.

ຮູບແບບເຫຼົ່ານີ້ແມ່ນຕົວດຽວທີ່ມີຢູ່ສໍາລັບການນໍາໃຊ້ໃນ DBMS ທີ່ກໍານົດໄວ້; ພາສາແບບສອບຖາມຂອງເຂົາເຈົ້າເອງຖືກອອກແບບມາເພື່ອເຮັດວຽກກັບພວກເຂົາ. ແນ່ນອນ, ແບບຈໍາລອງແລະ DBMSs ດັ່ງກ່າວມີແນວໂນ້ມ, ແຕ່ການຂາດຄວາມເຂົ້າກັນໄດ້ກັບແບບມາດຕະຖານແລະພາສາເຮັດໃຫ້ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະໃຊ້ DBMSs ເຫຼົ່ານີ້ໃນລະບົບມໍລະດົກ - ເພື່ອທົດແທນ DBMSs ທີ່ນໍາໃຊ້ແລ້ວຢູ່ທີ່ນັ້ນ.

ມີບົດຄວາມທີ່ຍອດຢ້ຽມກ່ຽວກັບ ArangoDB ແລະ OrientDB ຢູ່ Habre: ເຂົ້າຮ່ວມໃນຖານຂໍ້ມູນ NoSQL.

ArangoDB

ArangoDB ອ້າງວ່າສະຫນັບສະຫນູນຮູບແບບຂໍ້ມູນກາຟ.

ຂໍ້ຂອງກາຟໃນ ArangoDB ແມ່ນເອກະສານທົ່ວໄປ, ແລະຂອບແມ່ນເອກະສານຂອງປະເພດພິເສດທີ່, ພ້ອມກັບລະບົບປົກກະຕິ, ມີ (_key, _id, _rev) ຂົງເຂດລະບົບ _from и _to. ເອກະສານໃນເອກະສານ DBMSs ແມ່ນຖືກລວມເຂົ້າເປັນການເກັບກໍາ. ການເກັບກໍາເອກະສານທີ່ເປັນຕົວແທນຂອງຂອບແມ່ນເອີ້ນວ່າການເກັບກໍາຂອບໃນ ArangoDB. ໂດຍວິທີທາງການ, ເອກະສານການລວບລວມແຂບຍັງເປັນເອກະສານ, ດັ່ງນັ້ນຂອບໃນ ArangoDB ຍັງສາມາດເຮັດຫນ້າທີ່ເປັນຂໍ້ໄດ້.

ຂໍ້ມູນເບື້ອງຕົ້ນ

ໃຫ້ພວກເຮົາມີການເກັບກໍາ persons, ເອກະສານມີລັກສະນະດັ່ງນີ້:

[
  {
    "_id"  : "people/alice" ,
    "_key" : "alice" ,
    "name" : "Алиса"
  },
  {
    "_id"  : "people/bob" ,
    "_key" : "bob" ,
    "name" : "Боб"  
  }
]

ໃຫ້ມີການເກັບ cafes:

[
  {
    "_id" : "cafes/jd" ,
    "_key" : "jd" ,
    "name" : "Джон Донн"  
  },
  {
    "_id" : "cafes/jj" ,
    "_key" : "jj" ,
    "name" : "Жан-Жак"
  }
]

ຫຼັງຈາກນັ້ນ, ການເກັບກໍາ likes ອາດຈະເບິ່ງຄືແນວນີ້:

[
  {
    "_id" : "likes/1" ,
    "_key" : "1" ,
    "_from" : "persons/alice" ,
    "_to" : "cafes/jd",
    "since" : 2010 
  },
  {
    "_id" : "likes/2" ,
    "_key" : "2" ,
    "_from" : "persons/alice" ,
    "_to" : "cafes/jj",
    "since" : 2011 
  } ,
  {
    "_id" : "likes/3" ,
    "_key" : "3" ,
    "_from" : "persons/bob" ,
    "_to" : "cafes/jd",
    "since" : 2012 
  }
]

ຄໍາຖາມແລະຜົນໄດ້ຮັບ

ການສອບຖາມແບບກຣາຟໃນພາສາ AQL ທີ່ໃຊ້ໃນ ArangoDB, ກັບຄືນມາໃນຮູບແບບທີ່ມະນຸດສາມາດອ່ານໄດ້ກ່ຽວກັບຜູ້ທີ່ມັກຄາເຟ່ໃດ, ມີລັກສະນະນີ້:

FOR p IN persons
  FOR c IN OUTBOUND p likes
  RETURN { person : p.name , likes : c.name }

ໃນຮູບແບບການພົວພັນ, ບ່ອນທີ່ພວກເຮົາກໍາລັງ "ຄອມພິວເຕີ້" ຄວາມສໍາພັນແທນທີ່ຈະເກັບຮັກສາພວກມັນ, ຄໍາຖາມນີ້ສາມາດຖືກຂຽນຄືນໃຫມ່ເຊັ່ນນີ້ (ໂດຍວິທີທາງການ, ໂດຍບໍ່ມີການເກັບກໍາຂໍ້ມູນ. likes ສາມາດເຮັດໄດ້ໂດຍບໍ່ມີການ):

FOR p IN persons
  FOR l IN likes
  FILTER p._key == l._from
    FOR c IN cafes
    FILTER l._to == c._key
    RETURN { person : p.name , likes : c.name }

ຜົນໄດ້ຮັບໃນທັງສອງກໍລະນີຈະຄືກັນ:

[
  { "person" : "Алиса" , likes : "Жан-Жак" } ,
  { "person" : "Алиса" , likes : "Джон Донн" } ,
  { "person" : "Боб" , likes : "Джон Донн" }
]

ການສອບຖາມເພີ່ມເຕີມ ແລະຜົນໄດ້ຮັບ

ຖ້າຮູບແບບຜົນໄດ້ຮັບຂ້າງເທິງເບິ່ງຄືວ່າປົກກະຕິສໍາລັບ DBMS ທີ່ກ່ຽວຂ້ອງກ່ວາສໍາລັບເອກະສານ DBMS, ທ່ານສາມາດລອງແບບສອບຖາມນີ້ (ຫຼືທ່ານສາມາດນໍາໃຊ້. COLLECT):

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

ຖ້າຮູບແບບຜົນໄດ້ຮັບອີກເທື່ອຫນຶ່ງເບິ່ງຄືວ່າ "ຄວາມສໍາພັນ", ທ່ານຈໍາເປັນຕ້ອງເອົາເສັ້ນອອກ UNWIND():

[
  { "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
  { "person_name": "Боб",  "cafe_name": [ "Жан-Жак" ' }
]

ພາສາສອບຖາມຂອງ OrientDB ສາມາດຖືກອະທິບາຍເປັນ SQL ດ້ວຍການໃສ່ແບບ Gremlin. ໃນເວີຊັນ 2.2, ແບບຟອມການຮ້ອງຂໍທີ່ຄ້າຍຄື Cypher ປາກົດຂຶ້ນ, 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

ຮູບແບບຜົນໄດ້ຮັບຈະຄືກັນກັບການຮ້ອງຂໍທີ່ຜ່ານມາ. ຄິດກ່ຽວກັບສິ່ງທີ່ຕ້ອງຖືກໂຍກຍ້າຍອອກເພື່ອເຮັດໃຫ້ມັນ "ມີຄວາມກ່ຽວຂ້ອງ", ຄືກັບການສອບຖາມທໍາອິດ.

Azure CosmosDB

ໃນຂອບເຂດຫນ້ອຍ, ສິ່ງທີ່ໄດ້ກ່າວມາຂ້າງເທິງກ່ຽວກັບ ArangoDB ແລະ OrientDB ໃຊ້ກັບ Azure CosmosDB. CosmosDB ໃຫ້ APIs ການເຂົ້າເຖິງຂໍ້ມູນຕໍ່ໄປນີ້: SQL, MongoDB, Gremlin ແລະ Cassandra.

SQL API ແລະ MongoDB API ຖືກນໍາໃຊ້ເພື່ອເຂົ້າເຖິງຂໍ້ມູນໃນຮູບແບບເອກະສານ. Gremlin API ແລະ Cassandra API - ສໍາລັບການເຂົ້າເຖິງຂໍ້ມູນໃນຮູບແບບກາຟແລະຄໍລໍາ, ຕາມລໍາດັບ. ຂໍ້ມູນໃນຕົວແບບທັງຫມົດແມ່ນໄດ້ຖືກບັນທຶກໄວ້ໃນຮູບແບບ CosmosDB ພາຍໃນ: ARS (“ອາຕອມ-ບັນທຶກ-ລຳດັບ”), ເຊິ່ງໃກ້ກັບເອກະສານໜຶ່ງ.

ແຕ່ຮູບແບບຂໍ້ມູນທີ່ເລືອກໂດຍຜູ້ໃຊ້ແລະ API ທີ່ໃຊ້ໄດ້ຖືກແກ້ໄຂໃນເວລາທີ່ສ້າງບັນຊີໃນການບໍລິການ. ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະເຂົ້າເຖິງຂໍ້ມູນທີ່ໂຫລດຢູ່ໃນຮູບແບບຫນຶ່ງໃນຮູບແບບຂອງຕົວແບບອື່ນ, ດັ່ງທີ່ສະແດງໂດຍບາງສິ່ງບາງຢ່າງເຊັ່ນນີ້:

ດັ່ງນັ້ນ, ຫຼາຍແບບໃນ Azure CosmosDB ໃນມື້ນີ້ແມ່ນພຽງແຕ່ຄວາມສາມາດໃນການນໍາໃຊ້ຖານຂໍ້ມູນຈໍານວນຫນຶ່ງທີ່ສະຫນັບສະຫນູນຮູບແບບທີ່ແຕກຕ່າງກັນຈາກຜູ້ຜະລິດຫນຶ່ງ, ເຊິ່ງບໍ່ໄດ້ແກ້ໄຂບັນຫາທັງຫມົດຂອງການເກັບຮັກສາຫຼາຍຕົວແປ.

DBMS ຫຼາຍຮູບແບບໂດຍອີງໃສ່ຮູບແບບກາຟ?

ສິ່ງທີ່ຫນ້າສັງເກດແມ່ນຄວາມຈິງທີ່ວ່າບໍ່ມີ DBMSs ຫຼາຍແບບຢູ່ໃນຕະຫຼາດແມ່ນອີງໃສ່ຮູບແບບກາຟ (ຍົກເວັ້ນການສະຫນັບສະຫນູນຫຼາຍແບບສໍາລັບສອງຮູບແບບກາຟພ້ອມໆກັນ: RDF ແລະ LPG; ເບິ່ງນີ້ໃນ. ການພິມເຜີຍແຜ່ທີ່ຜ່ານມາ). ຄວາມຫຍຸ້ງຍາກທີ່ສຸດແມ່ນເກີດມາຈາກການປະຕິບັດຕົວແບບເອກະສານຢູ່ເທິງສຸດຂອງຮູບແບບກາຟ, ແທນທີ່ຈະເປັນຕົວແບບທີ່ກ່ຽວຂ້ອງ.

ຄໍາຖາມກ່ຽວກັບວິທີການປະຕິບັດຕົວແບບທີ່ກ່ຽວຂ້ອງຢູ່ເທິງສຸດຂອງຕົວແບບກາຟໄດ້ຖືກພິຈາລະນາເຖິງແມ່ນວ່າໃນລະຫວ່າງການສ້າງຕົວແບບສຸດທ້າຍ. ແນວໃດ ເວົ້າຕົວຢ່າງເຊັ່ນ David McGovern:

ບໍ່ມີຫຍັງປະກົດຂຶ້ນໃນວິທີການຂອງກາຟທີ່ປ້ອງກັນການສ້າງຊັ້ນ (ຕົວຢ່າງ, ໂດຍການດັດສະນີທີ່ເຫມາະສົມ) ໃນຖານຂໍ້ມູນກາຟທີ່ຊ່ວຍໃຫ້ການເບິ່ງຄວາມສໍາພັນກັບ (1) ການຟື້ນຕົວຂອງ tuples ຈາກຄູ່ມູນຄ່າທີ່ສໍາຄັນປົກກະຕິແລະ (2) ການຈັດກຸ່ມຂອງ tuples ຕາມປະເພດຄວາມສໍາພັນ.

ເມື່ອປະຕິບັດຕົວແບບເອກະສານຢູ່ເທິງສຸດຂອງຮູບແບບກາຟ, ທ່ານຈໍາເປັນຕ້ອງຈື່ໄວ້, ຕົວຢ່າງ, ຕໍ່ໄປນີ້:

ອົງປະກອບຂອງອາເຣ JSON ຖືກພິຈາລະນາເປັນລໍາດັບ, ແຕ່ສິ່ງທີ່ອອກມາຈາກຈຸດສູງສຸດຂອງຂອບຂອງກຣາບບໍ່ແມ່ນ;
ຂໍ້ມູນໃນຕົວແບບເອກະສານແມ່ນປົກກະຕິແລ້ວຖືກເຮັດໃຫ້ຜິດປົກກະຕິ; ທ່ານຍັງບໍ່ຕ້ອງການທີ່ຈະເກັບຮັກສາສໍາເນົາຫຼາຍສະບັບຂອງເອກະສານທີ່ຝັງດຽວກັນ, ແລະເອກະສານຍ່ອຍປົກກະຕິແລ້ວບໍ່ມີຕົວລະບຸ;
ໃນທາງກົງກັນຂ້າມ, ອຸດົມການຂອງເອກະສານ DBMSs ແມ່ນວ່າເອກະສານແມ່ນ "ການລວບລວມ" ທີ່ກຽມພ້ອມທີ່ບໍ່ຈໍາເປັນຕ້ອງສ້າງໃຫມ່ໃນແຕ່ລະຄັ້ງ. ມັນຈໍາເປັນຕ້ອງໃຫ້ຕົວແບບກາຟທີ່ມີຄວາມສາມາດໃນການໄດ້ຮັບເສັ້ນຍ່ອຍທີ່ສອດຄ່ອງກັບເອກະສານສໍາເລັດຮູບຢ່າງໄວວາ.

ການໂຄສະນາເລັກນ້ອຍ

ຜູ້ຂຽນຂອງບົດຄວາມແມ່ນກ່ຽວຂ້ອງກັບການພັດທະນາ NitrosBase DBMS, ຮູບແບບພາຍໃນທີ່ເປັນກາຟ, ແລະຕົວແບບພາຍນອກ - ຄວາມສໍາພັນແລະເອກະສານ - ເປັນຕົວແທນຂອງມັນ. ຮູບແບບທັງຫມົດແມ່ນເທົ່າທຽມກັນ: ເກືອບທຸກຂໍ້ມູນແມ່ນມີຢູ່ໃນທຸກຂອງພວກເຂົາໂດຍໃຊ້ພາສາແບບສອບຖາມທີ່ເປັນທໍາມະຊາດ. ຍິ່ງໄປກວ່ານັ້ນ, ໃນທັດສະນະໃດກໍ່ຕາມ, ຂໍ້ມູນສາມາດປ່ຽນແປງໄດ້. ການປ່ຽນແປງຈະສະທ້ອນໃຫ້ເຫັນໃນຮູບແບບພາຍໃນແລະ, ຕາມຄວາມເຫມາະສົມ, ໃນທັດສະນະອື່ນໆ.

ຂ້າພະເຈົ້າຫວັງວ່າຈະອະທິບາຍການຈັບຄູ່ແບບຈໍາລອງແບບໃດໃນ NitrosBase ໃນຫນຶ່ງໃນບົດຄວາມຕໍ່ໄປນີ້.

ສະຫລຸບ

ຂ້າພະເຈົ້າຫວັງວ່າໂຄງຮ່າງທົ່ວໄປຂອງສິ່ງທີ່ເອີ້ນວ່າແບບຈໍາລອງຫຼາຍໄດ້ກາຍເປັນຫຼາຍຫຼືຫນ້ອຍທີ່ຈະແຈ້ງໃຫ້ຜູ້ອ່ານ. DBMSs ຫຼາຍແບບແມ່ນແຕກຕ່າງກັນ, ແລະ "ການສະຫນັບສະຫນູນຫຼາຍແບບ" ສາມາດເບິ່ງແຕກຕ່າງກັນ. ເພື່ອເຂົ້າໃຈສິ່ງທີ່ເອີ້ນວ່າ "ຫຼາຍແບບ" ໃນແຕ່ລະກໍລະນີສະເພາະ, ມັນເປັນປະໂຫຍດທີ່ຈະຕອບຄໍາຖາມຕໍ່ໄປນີ້:

ພວກເຮົາເວົ້າກ່ຽວກັບການສະຫນັບສະຫນຸນແບບດັ້ງເດີມຫຼືບາງຮູບແບບ "ປະສົມ"?
ແບບຈໍາລອງແມ່ນ "ເທົ່າທຽມກັນ", ຫຼືຫນຶ່ງໃນນັ້ນແມ່ນຫົວຂໍ້ຂອງຄົນອື່ນ?
ແບບຈໍາລອງ "indifferent" ກັບກັນແລະກັນ? ຂໍ້ມູນທີ່ຖືກຂຽນໄວ້ໃນຕົວແບບຫນຶ່ງສາມາດອ່ານໃນແບບອື່ນຫຼືແມ້ກະທັ້ງຂຽນທັບໄດ້ບໍ?

ຂ້າພະເຈົ້າຄິດວ່າຄໍາຖາມກ່ຽວກັບຄວາມກ່ຽວຂ້ອງຂອງ DBMS ຫຼາຍແບບສາມາດຕອບໄດ້ໃນທາງບວກ, ແຕ່ຄໍາຖາມທີ່ຫນ້າສົນໃຈແມ່ນປະເພດໃດທີ່ມີຄວາມຕ້ອງການຫຼາຍໃນອະນາຄົດອັນໃກ້ນີ້. ມັນເບິ່ງຄືວ່າ DBMSs ຫຼາຍແບບທີ່ສະຫນັບສະຫນູນແບບດັ້ງເດີມ, ຄວາມສໍາພັນຕົ້ນຕໍ, ຈະມີຄວາມຕ້ອງການຫຼາຍກວ່າເກົ່າ; ຄວາມນິຍົມຂອງ DBMSs ຫຼາຍຮຸ່ນ, ສະເຫນີຮູບແບບໃຫມ່ທີ່ປະສົມປະສານຄວາມໄດ້ປຽບຂອງແບບດັ້ງເດີມຕ່າງໆ, ເປັນເລື່ອງຂອງອະນາຄົດທີ່ຫ່າງໄກຫຼາຍ.

ພຽງແຕ່ຜູ້ໃຊ້ລົງທະບຽນສາມາດເຂົ້າຮ່ວມໃນການສໍາຫຼວດ. ເຂົ້າສູ່ລະບົບກະລຸນາ.