ແຈກຢາຍ DBMS ສໍາລັບວິສາຫະກິດ

ທິດສະດີ CAP ແມ່ນພື້ນຖານຂອງທິດສະດີລະບົບແຈກຢາຍ. ແນ່ນອນ, ການຂັດແຍ້ງທີ່ອ້ອມຮອບມັນບໍ່ຫຼຸດລົງ: ຄໍານິຍາມໃນມັນບໍ່ແມ່ນ canonical, ແລະບໍ່ມີຫຼັກຖານທີ່ເຂັ້ມງວດ ... ຢ່າງໃດກໍຕາມ, ຢືນຢູ່ໃນຕໍາແຫນ່ງຂອງຄວາມຮູ້ສຶກທົ່ວໄປປະຈໍາວັນ™ຢ່າງຫນັກແຫນ້ນ, ພວກເຮົາເຂົ້າໃຈ intuitively ວ່າ theorem ແມ່ນຄວາມຈິງ.

ສິ່ງດຽວທີ່ບໍ່ຊັດເຈນແມ່ນຄວາມຫມາຍຂອງຕົວອັກສອນ "P". ເມື່ອກຸ່ມກຸ່ມຖືກແບ່ງອອກ, ມັນຕັດສິນໃຈວ່າຈະບໍ່ຕອບສະໜອງຈົນກວ່າກຸ່ມຈະໄປຮອດ, ຫຼືໃຫ້ຄືນຂໍ້ມູນທີ່ມີຢູ່. ອີງຕາມຜົນໄດ້ຮັບຂອງທາງເລືອກນີ້, ລະບົບໄດ້ຖືກຈັດປະເພດເປັນ CP ຫຼື AP. Cassandra, ສໍາລັບຕົວຢ່າງ, ສາມາດປະຕິບັດໄດ້ໃນທາງໃດກໍ່ຕາມ, ຂຶ້ນກັບການຕັ້ງຄ່າຂອງກຸ່ມ, ແຕ່ຢູ່ໃນຕົວກໍານົດການຂອງແຕ່ລະຄໍາຮ້ອງຂໍສະເພາະ. ແຕ່ຖ້າລະບົບບໍ່ແມ່ນ "P" ແລະມັນແຕກ, ແລ້ວແມ່ນຫຍັງ?

ຄໍາຕອບຂອງຄໍາຖາມນີ້ແມ່ນບໍ່ຄາດຄິດ: ກຸ່ມ CA ບໍ່ສາມາດແບ່ງອອກໄດ້.
ນີ້ແມ່ນກຸ່ມປະເພດໃດທີ່ບໍ່ສາມາດແຍກອອກໄດ້?

ຄຸນລັກສະນະທີ່ສຳຄັນຂອງກຸ່ມດັ່ງກ່າວແມ່ນລະບົບເກັບຮັກສາຂໍ້ມູນຮ່ວມກັນ. ໃນກໍລະນີຫຼາຍທີ່ສຸດ, ນີ້ໝາຍເຖິງການເຊື່ອມຕໍ່ຜ່ານ SAN, ເຊິ່ງຈຳກັດການນຳໃຊ້ວິທີແກ້ໄຂ CA ໃຫ້ກັບວິສາຫະກິດຂະໜາດໃຫຍ່ທີ່ມີຄວາມສາມາດໃນການຮັກສາພື້ນຖານໂຄງລ່າງ SAN. ເພື່ອໃຫ້ຫຼາຍໆ ເຄື່ອງແມ່ຂ່າຍ ເພື່ອເຮັດວຽກກັບຂໍ້ມູນດຽວກັນ, ຕ້ອງມີລະບົບໄຟລ໌ກຸ່ມ. ລະບົບໄຟລ໌ດັ່ງກ່າວມີຢູ່ໃນບັນດາຜະລິດຕະພັນຂອງ HPE (CFS), Veritas (VxCFS), ແລະ IBM (GPFS).

Oracle RAC

ຕົວເລືອກ Real Application Cluster ໄດ້ປະກົດຕົວຄັ້ງທຳອິດໃນປີ 2001 ພ້ອມກັບການປ່ອຍ Oracle 9i. ໃນ cluster ດັ່ງກ່າວ, ຫຼາຍກໍລະນີ ເຄື່ອງແມ່ຂ່າຍ ເຮັດວຽກກັບຖານຂໍ້ມູນດຽວກັນ.
Oracle ສາມາດເຮັດວຽກກັບທັງລະບົບໄຟລ໌ທີ່ເປັນກຸ່ມແລະການແກ້ໄຂຂອງຕົນເອງ - ASM, ການຄຸ້ມຄອງການເກັບຮັກສາອັດຕະໂນມັດ.

ແຕ່ລະສໍາເນົາເກັບຮັກສາວາລະສານຂອງຕົນເອງ. ທຸລະກໍາຖືກປະຕິບັດແລະປະຕິບັດໂດຍຫນຶ່ງຕົວຢ່າງ. ຖ້າ instance ລົ້ມເຫລວ, ຫນຶ່ງໃນ nodes cluster ທີ່ຢູ່ລອດ (ຕົວຢ່າງ) ອ່ານບັນທຶກຂອງມັນແລະຟື້ນຟູຂໍ້ມູນທີ່ສູນເສຍ - ດັ່ງນັ້ນການຮັບປະກັນການມີຢູ່.

ຕົວຢ່າງທັງຫມົດຮັກສາ cache ຂອງຕົນເອງ, ແລະຫນ້າດຽວກັນ (blocks) ສາມາດຢູ່ໃນ cache ຂອງຫຼາຍ instances ໃນເວລາດຽວກັນ. ຍິ່ງໄປກວ່ານັ້ນ, ຖ້າຕົວຢ່າງຫນຶ່ງຕ້ອງການຫນ້າແລະມັນຢູ່ໃນ cache ຂອງຕົວຢ່າງອື່ນ, ມັນສາມາດໄດ້ຮັບຈາກເພື່ອນບ້ານຂອງມັນໂດຍໃຊ້ກົນໄກການ fusion cache ແທນທີ່ຈະອ່ານຈາກແຜ່ນ.

ແຕ່ຈະເກີດຫຍັງຂຶ້ນຖ້າຫນຶ່ງໃນຕົວຢ່າງຕ້ອງການປ່ຽນຂໍ້ມູນ?

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

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

ການປັບປຸງຫນ້າດຽວກັນແບບສຸ່ມໃນທົ່ວ nodes RAC ທີ່ແຕກຕ່າງກັນເຮັດໃຫ້ການປະຕິບັດຖານຂໍ້ມູນຫຼຸດລົງຢ່າງຫຼວງຫຼາຍ, ເຖິງຈຸດທີ່ການປະຕິບັດຂອງກຸ່ມສາມາດຕ່ໍາກວ່າຕົວຢ່າງດຽວ.

ການນໍາໃຊ້ທີ່ຖືກຕ້ອງຂອງ Oracle RAC ແມ່ນການແບ່ງສ່ວນຂໍ້ມູນທາງດ້ານຮ່າງກາຍ (ຕົວຢ່າງ, ການນໍາໃຊ້ກົນໄກຕາຕະລາງການແບ່ງສ່ວນ) ແລະເຂົ້າເຖິງແຕ່ລະຊຸດຂອງພາທິຊັນໂດຍຜ່ານ node ສະເພາະ. ຈຸດ​ປະ​ສົງ​ຕົ້ນ​ຕໍ​ຂອງ RAC ບໍ່​ແມ່ນ​ການ​ຂະ​ຫຍາຍ​ອອກ​ຕາມ​ລວງ​ນອນ​, ແຕ່​ການ​ຮັບ​ປະ​ກັນ​ຄວາມ​ທົນ​ທານ​ຄວາມ​ຜິດ​ພາດ​.

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

• “freezes” ຫນ້າທັງຫມົດທີ່ຢູ່ໃນ cache ຂອງ node ທີ່ຂາດຫາຍໄປ;
• ອ່ານບັນທຶກ (ເຮັດເລື້ມຄືນ) ຂອງ node ທີ່ຂາດຫາຍໄປ ແລະນໍາໃຊ້ຄືນການປ່ຽນແປງທີ່ບັນທຶກໄວ້ໃນບັນທຶກເຫຼົ່ານີ້, ພ້ອມໆກັນກວດເບິ່ງວ່າ nodes ອື່ນໆມີສະບັບທີ່ຜ່ານມາຂອງຫນ້າທີ່ມີການປ່ຽນແປງ;
• ມ້ວນຄືນການເຮັດທຸລະກໍາທີ່ຍັງຄ້າງຢູ່.

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

IBM Pure Data Systems ສໍາລັບທຸລະກໍາ

ການແກ້ໄຂກຸ່ມສໍາລັບ DBMS ປາກົດຢູ່ໃນຫຼັກຊັບ Blue Giant ໃນປີ 2009. ທາງດ້ານອຸດົມການ, ມັນແມ່ນຜູ້ສືບທອດຂອງກຸ່ມ Parallel Sysplex, ສ້າງຂຶ້ນໃນອຸປະກອນ "ປົກກະຕິ". ໃນປີ 2009, DB2 pureScale ຖືກປ່ອຍອອກມາເປັນຊຸດຊອບແວ, ແລະໃນປີ 2012, IBM ໄດ້ສະເຫນີເຄື່ອງໃຊ້ທີ່ເອີ້ນວ່າ Pure Data Systems for Transactions. ມັນບໍ່ຄວນສັບສົນກັບ Pure Data Systems ສໍາລັບການວິເຄາະ, ເຊິ່ງບໍ່ມີຫຍັງຫຼາຍກວ່າການປ່ຽນຊື່ Netezza.

ຢູ່ glance ທໍາອິດ, ສະຖາປັດຕະຍະກໍາ pureScale ແມ່ນຄ້າຍຄືກັນກັບ Oracle RAC: ໃນລັກສະນະດຽວກັນ, ຫຼາຍ nodes ແມ່ນເຊື່ອມຕໍ່ກັບລະບົບການເກັບຮັກສາຂໍ້ມູນທົ່ວໄປ, ແລະແຕ່ລະ node ດໍາເນີນການຕົວຢ່າງ DBMS ຂອງຕົນເອງກັບພື້ນທີ່ຫນ່ວຍຄວາມຈໍາຂອງຕົນເອງແລະບັນທຶກການເຮັດທຸລະກໍາ. ແຕ່, ບໍ່ເຫມືອນກັບ Oracle, DB2 ມີບໍລິການລັອກສະເພາະທີ່ເປັນຕົວແທນໂດຍຂະບວນການ db2LLM*. ໃນ​ການ​ຕັ້ງ​ຄ່າ​ກຸ່ມ​, ການ​ບໍ​ລິ​ການ​ນີ້​ແມ່ນ​ໄດ້​ຖືກ​ຈັດ​ໃສ່​ໃນ node ແຍກ​ຕ່າງ​ຫາກ​, ຊຶ່ງ​ເອີ້ນ​ວ່າ coupling facility (CF​) ໃນ Parallel Sysplex​, ແລະ PowerHA ໃນ Pure Data​.

PowerHA ໃຫ້ບໍລິການຕໍ່ໄປນີ້:

• lock manager;
• cache buffer ທົ່ວໂລກ;
• ພື້ນທີ່ຂອງການສື່ສານ interprocess.

ເພື່ອໂອນຂໍ້ມູນຈາກ PowerHA ໄປໃສ່ຖານຂໍ້ມູນ ແລະ ກັບຄືນໄປບ່ອນ, ການເຂົ້າເຖິງຫນ່ວຍຄວາມຈໍາຫ່າງໄກສອກຫຼີກແມ່ນຖືກນໍາໃຊ້, ດັ່ງນັ້ນການເຊື່ອມຕໍ່ລະຫວ່າງກຸ່ມຕ້ອງສະຫນັບສະຫນູນ RDMA protocol. PureScale ສາມາດໃຊ້ທັງ Infiniband ແລະ RDMA ຜ່ານອີເທີເນັດ.

ຖ້າ node ຕ້ອງການຫນ້າ, ແລະຫນ້ານີ້ບໍ່ຢູ່ໃນ cache, ຫຼັງຈາກນັ້ນ node ຮ້ອງຂໍເອົາຫນ້າໃນ cache ທົ່ວໂລກ, ແລະພຽງແຕ່ຖ້າມັນບໍ່ມີ, ອ່ານມັນຈາກແຜ່ນ. ບໍ່ເຫມືອນກັບ Oracle, ການຮ້ອງຂໍໄປຫາ PowerHA ເທົ່ານັ້ນ, ແລະບໍ່ແມ່ນກັບ nodes ໃກ້ຄຽງ.

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

ຖ້າຫນ້າທີ່ແຖວດັດແກ້ຖືກລັອກຢູ່ແລ້ວ, ຜູ້ຈັດການ lock ຈະອ່ານຫນ້າທີ່ດັດແກ້ຈາກຫນ່ວຍຄວາມຈໍາຂອງ node ທີ່ເຮັດການປ່ຽນແປງ, ປົດລັອກ, ເຮັດໃຫ້ຫນ້າທີ່ຖືກດັດແກ້ຢູ່ໃນ cache ຂອງ nodes ອື່ນໆ, ແລະ. ໃຫ້ lock ຫນ້າກັບ node ທີ່ຮ້ອງຂໍໃຫ້ມັນ.

"ເປື້ອນ", ນັ້ນແມ່ນ, ມີການປ່ຽນແປງ, ຫນ້າເວັບສາມາດຂຽນໃສ່ແຜ່ນໄດ້ທັງຈາກ node ປົກກະຕິແລະຈາກ PowerHA (castout).

ຖ້າຫນຶ່ງໃນ nodes pureScale ລົ້ມເຫລວ, ການຟື້ນຕົວແມ່ນຈໍາກັດພຽງແຕ່ການເຮັດທຸລະກໍາທີ່ຍັງບໍ່ທັນສໍາເລັດໃນເວລາທີ່ລົ້ມເຫລວ: ຫນ້າທີ່ຖືກດັດແກ້ໂດຍ node ໃນການເຮັດທຸລະກໍາທີ່ສໍາເລັດແມ່ນຢູ່ໃນ cache ທົ່ວໂລກໃນ PowerHA. ໂນດຈະຣີສະຕາດໃນການຕັ້ງຄ່າທີ່ຫຼຸດລົງໃນໜຶ່ງໃນເຊີບເວີໃນກຸ່ມ, ກັບຄືນທຸລະກຳທີ່ຍັງຄ້າງຢູ່ ແລະປ່ອຍຕົວລັອກ.

PowerHA ເຮັດວຽກຢູ່ໃນສອງເຊີບເວີ ແລະແມ່ບົດ node replicates ລັດຂອງຕົນ synchronously. ຖ້າໂຫນດ PowerHA ຫຼັກລົ້ມເຫລວ, ກຸ່ມຈະສືບຕໍ່ດໍາເນີນການກັບ node ສໍາຮອງຂໍ້ມູນ.
ແນ່ນອນ, ຖ້າທ່ານເຂົ້າເຖິງຊຸດຂໍ້ມູນໂດຍຜ່ານ node ດຽວ, ການປະຕິບັດໂດຍລວມຂອງ cluster ຈະສູງຂຶ້ນ. PureScale ສາມາດສັງເກດເຫັນໄດ້ວ່າພື້ນທີ່ສະເພາະໃດຫນຶ່ງຂອງຂໍ້ມູນກໍາລັງຖືກປະມວນຜົນໂດຍຫນຶ່ງ node, ແລະຫຼັງຈາກນັ້ນ locks ທັງຫມົດທີ່ກ່ຽວຂ້ອງກັບພື້ນທີ່ນັ້ນຈະໄດ້ຮັບການປະມວນຜົນໃນທ້ອງຖິ່ນໂດຍ node ໂດຍບໍ່ມີການຕິດຕໍ່ສື່ສານກັບ PowerHA. ແຕ່ທັນທີທີ່ແອັບພລິເຄຊັນພະຍາຍາມເຂົ້າເຖິງຂໍ້ມູນນີ້ຜ່ານ node ອື່ນ, ການປະມວນຜົນການລັອກແບບສູນກາງຈະດຳເນີນຕໍ່ໄປ.

ການທົດສອບພາຍໃນຂອງ IBM ກ່ຽວກັບວຽກງານທີ່ອ່ານ 90% ແລະຂຽນ 10%, ເຊິ່ງຄ້າຍຄືກັນກັບປະລິມານການຜະລິດທີ່ແທ້ຈິງ, ສະແດງໃຫ້ເຫັນການຂະຫຍາຍເສັ້ນເກືອບເຖິງ 128 nodes. ເງື່ອນໄຂການທົດສອບ, ແຕ່ຫນ້າເສຍດາຍ, ບໍ່ໄດ້ຖືກເປີດເຜີຍ.

HPE NonStop SQL

ຫຼັກຊັບວິສາຫະກິດ Hewlett-Packard ຍັງມີແພລະຕະຟອມທີ່ມີຢູ່ສູງຂອງຕົນເອງ. ນີ້ແມ່ນເວທີ NonStop, ປ່ອຍອອກສູ່ຕະຫຼາດໃນປີ 1976 ໂດຍ Tandem Computers. ໃນປີ 1997, ບໍລິສັດໄດ້ຖືກຊື້ໂດຍ Compaq, ເຊິ່ງໄດ້ລວມເຂົ້າກັບ Hewlett-Packard ໃນປີ 2002.

NonStop ຖືກນໍາໃຊ້ເພື່ອສ້າງຄໍາຮ້ອງສະຫມັກທີ່ສໍາຄັນ - ຕົວຢ່າງ, HLR ຫຼືການປະມວນຜົນບັດທະນາຄານ. ແພລະຕະຟອມຖືກຈັດສົ່ງໃນຮູບແບບຂອງຊໍແວແລະຮາດແວສະລັບສັບຊ້ອນ (ເຄື່ອງໃຊ້), ເຊິ່ງປະກອບມີຂໍ້ຄອມພິວເຕີ, ລະບົບການເກັບຮັກສາຂໍ້ມູນແລະອຸປະກອນການສື່ສານ. ເຄືອຂ່າຍ ServerNet (ໃນລະບົບທີ່ທັນສະໄຫມ - Infiniband) ໃຫ້ບໍລິການທັງສອງສໍາລັບການແລກປ່ຽນລະຫວ່າງ nodes ແລະສໍາລັບການເຂົ້າເຖິງລະບົບການເກັບຮັກສາຂໍ້ມູນ.

ຮຸ່ນຕົ້ນໆຂອງລະບົບໃຊ້ໂປເຊດເຊີທີ່ເປັນເຈົ້າຂອງທີ່ synchronized ກັບກັນແລະກັນ: ການດໍາເນີນງານທັງຫມົດໄດ້ຖືກປະຕິບັດ synchronously ໂດຍໂປເຊດເຊີຈໍານວນຫນຶ່ງ, ແລະທັນທີທີ່ຫນຶ່ງຂອງໂປເຊດເຊີເກີດຄວາມຜິດພາດ, ມັນຖືກປິດ, ແລະອັນທີສອງຍັງສືບຕໍ່ເຮັດວຽກ. ຕໍ່ມາ, ລະບົບໄດ້ປ່ຽນໄປໃຊ້ໂປເຊດເຊີແບບດັ້ງເດີມ (MIPS ທໍາອິດ, ຫຼັງຈາກນັ້ນ Itanium ແລະສຸດທ້າຍ x86), ແລະກົນໄກອື່ນໆໄດ້ເລີ່ມຕົ້ນທີ່ຈະນໍາໃຊ້ສໍາລັບການ synchronization:

• ຂໍ້ຄວາມ: ແຕ່ລະຂະບວນການຂອງລະບົບມີຄູ່ແຝດ "ເງົາ", ເຊິ່ງຂະບວນການເຄື່ອນໄຫວສົ່ງຂໍ້ຄວາມເປັນໄລຍະໆກ່ຽວກັບສະຖານະພາບຂອງມັນ; ຖ້າຂະບວນການຕົ້ນຕໍລົ້ມເຫລວ, ຂະບວນການເງົາຈະເລີ່ມເຮັດວຽກຈາກເວລາທີ່ກໍານົດໂດຍຂໍ້ຄວາມສຸດທ້າຍ;
• ການລົງຄະແນນສຽງ: ລະບົບການເກັບຮັກສາມີອົງປະກອບຮາດແວພິເສດທີ່ຍອມຮັບການເຂົ້າໃຊ້ຫຼາຍອັນທີ່ຄືກັນ ແລະປະຕິບັດໃຫ້ເຂົາເຈົ້າພຽງແຕ່ຖ້າການເຂົ້າເຖິງກົງກັນ; ແທນທີ່ຈະ synchronization ທາງດ້ານຮ່າງກາຍ, ໂປເຊດເຊີຈະເຮັດວຽກແບບບໍ່ກົງກັນ, ແລະຜົນໄດ້ຮັບຂອງການເຮັດວຽກຂອງພວກມັນຖືກປຽບທຽບພຽງແຕ່ໃນເວລາ I/O.

ຕັ້ງ​ແຕ່​ປີ 1987​, DBMS ທີ່​ກ່ຽວ​ຂ້ອງ​ໄດ້​ດໍາ​ເນີນ​ການ​ຢູ່​ໃນ​ເວ​ທີ​ການ​ບໍ່​ຢຸດ - ທໍາ​ອິດ SQL / MP​, ແລະ​ຕໍ່​ມາ SQL / MX​.

ຖານຂໍ້ມູນທັງຫມົດໄດ້ຖືກແບ່ງອອກເປັນພາກສ່ວນ, ແລະແຕ່ລະພາກສ່ວນແມ່ນຮັບຜິດຊອບສໍາລັບຂະບວນການຂອງຕົນເອງ Data Access Manager (DAM). ມັນສະຫນອງການບັນທຶກຂໍ້ມູນ, caching, ແລະກົນໄກການລັອກ. ການປະມວນຜົນຂໍ້ມູນແມ່ນດໍາເນີນໂດຍ Executor Server Processes ແລ່ນຢູ່ໃນ nodes ດຽວກັນກັບຕົວຈັດການຂໍ້ມູນທີ່ສອດຄ້ອງກັນ. ຕົວກໍານົດເວລາ SQL/MX ແບ່ງວຽກລະຫວ່າງຜູ້ປະຕິບັດແລະລວບລວມຜົນໄດ້ຮັບ. ໃນເວລາທີ່ມັນຈໍາເປັນຕ້ອງເຮັດການປ່ຽນແປງທີ່ຕົກລົງ, ອະນຸສັນຍາສັນຍາສອງໄລຍະທີ່ສະຫນອງໃຫ້ໂດຍຫ້ອງສະຫມຸດ TMF (ສະຖານທີ່ຄຸ້ມຄອງທຸລະກໍາ) ຖືກນໍາໃຊ້.

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

SAP-HANA

ການປ່ອຍຕົວທີ່ຫມັ້ນຄົງຄັ້ງທໍາອິດຂອງ HANA DBMS (1.0) ໄດ້ຈັດຂຶ້ນໃນເດືອນພະຈິກ 2010, ແລະຊຸດ SAP ERP ໄດ້ປ່ຽນເປັນ HANA ໃນເດືອນພຶດສະພາ 2013. ແພລະຕະຟອມແມ່ນອີງໃສ່ເຕັກໂນໂລຢີທີ່ຊື້: ເຄື່ອງຈັກຊອກຫາ TREX (ຊອກຫາຢູ່ໃນບ່ອນເກັບຄໍລໍາ), P*TIME DBMS ແລະ MAX DB.

ຄໍາວ່າ "HANA" ຕົວຂອງມັນເອງແມ່ນຕົວຫຍໍ້, ເຄື່ອງໃຊ້ການວິເຄາະທີ່ມີປະສິດທິພາບສູງ. DBMS ນີ້ແມ່ນສະຫນອງໃນຮູບແບບຂອງລະຫັດທີ່ສາມາດດໍາເນີນການໃນເຄື່ອງແມ່ຂ່າຍ x86 ໃດ, ແຕ່ການຕິດຕັ້ງອຸດສາຫະກໍາແມ່ນອະນຸຍາດໃຫ້ພຽງແຕ່ອຸປະກອນທີ່ໄດ້ຮັບການຢັ້ງຢືນ. ວິທີແກ້ໄຂທີ່ມີຢູ່ຈາກ HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. ບາງການຕັ້ງຄ່າ Lenovo ເຖິງແມ່ນວ່າອະນຸຍາດໃຫ້ດໍາເນີນການໂດຍບໍ່ມີ SAN - ບົດບາດຂອງລະບົບການເກັບຮັກສາທົ່ວໄປແມ່ນຫຼິ້ນໂດຍກຸ່ມ GPFS ໃນແຜ່ນທ້ອງຖິ່ນ.

ບໍ່ເຫມືອນກັບແພລະຕະຟອມທີ່ລະບຸໄວ້ຂ້າງເທິງ, HANA ແມ່ນ DBMS ໃນຫນ່ວຍຄວາມຈໍາ, i.e. ຮູບພາບຂໍ້ມູນຕົ້ນຕໍຖືກເກັບໄວ້ໃນ RAM, ແລະພຽງແຕ່ບັນທຶກແລະການຖ່າຍຮູບແຕ່ລະໄລຍະທີ່ຖືກຂຽນໄວ້ໃນແຜ່ນສໍາລັບການຟື້ນຕົວໃນກໍລະນີຂອງໄພພິບັດ.

ແຕ່ລະ node cluster HANA ແມ່ນຮັບຜິດຊອບສໍາລັບສ່ວນຂອງມັນເອງຂອງຂໍ້ມູນ, ແລະແຜນທີ່ຂໍ້ມູນຖືກເກັບໄວ້ໃນອົງປະກອບພິເສດ - ​​Server ຊື່, ທີ່ຕັ້ງຢູ່ໃນ node ຜູ້ປະສານງານ. ຂໍ້ມູນບໍ່ໄດ້ຊໍ້າກັນລະຫວ່າງ nodes. ຂໍ້ມູນການລັອກຍັງຖືກເກັບໄວ້ໃນແຕ່ລະ node, ແຕ່ລະບົບມີເຄື່ອງກວດຈັບການລັອກທົ່ວໂລກ.

ເມື່ອລູກຄ້າ HANA ເຊື່ອມຕໍ່ກັບ cluster, ມັນຈະດາວໂຫລດ topology ຂອງມັນແລະຫຼັງຈາກນັ້ນສາມາດເຂົ້າເຖິງ node ໃດໂດຍກົງ, ຂຶ້ນກັບຂໍ້ມູນທີ່ຕ້ອງການ. ຖ້າການເຮັດທຸລະກໍາມີຜົນກະທົບຕໍ່ຂໍ້ມູນຂອງໂຫນດດຽວ, ມັນສາມາດຖືກປະຕິບັດຢູ່ໃນທ້ອງຖິ່ນໂດຍໂຫນດນັ້ນ, ແຕ່ຖ້າຂໍ້ມູນຂອງຫຼາຍໂຫນດມີການປ່ຽນແປງ, ໂຫນດເລີ່ມຕົ້ນຕິດຕໍ່ກັບ node ຜູ້ປະສານງານ, ເຊິ່ງເປີດແລະປະສານງານການເຮັດທຸລະກໍາທີ່ແຈກຢາຍ, ປະຕິບັດມັນໂດຍໃຊ້. ໂປຣໂຕຄໍ commit ສອງເຟດທີ່ປັບປຸງໃຫ້ເໝາະສົມ.

node ຜູ້ປະສານງານຖືກຊ້ໍາກັນ, ດັ່ງນັ້ນຖ້າຜູ້ປະສານງານລົ້ມເຫລວ, node ສໍາຮອງຂໍ້ມູນທັນທີທັນໃດ. ແຕ່ຖ້າ node ທີ່ມີຂໍ້ມູນລົ້ມເຫລວ, ວິທີດຽວທີ່ຈະເຂົ້າເຖິງຂໍ້ມູນຂອງມັນແມ່ນເພື່ອ restart node. ຕາມກົດລະບຽບ, ກຸ່ມ HANA ຮັກສາເຊີບເວີສຳຮອງເພື່ອເລີ່ມຕົ້ນໂຫນດທີ່ເສຍໄປໃນມັນໄວເທົ່າທີ່ຈະໄວໄດ້.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com