HighLoad++, Mikhail Tyulenev (MongoDB): ຄວາມສອດຄ່ອງຂອງສາເຫດ: ຈາກທິດສະດີເຖິງການປະຕິບັດ

ກອງປະຊຸມ HighLoad++ ຕໍ່ໄປຈະຈັດຂຶ້ນໃນວັນທີ 6 ແລະ 7 ເມສາ 2020 ທີ່ St.
ລາຍລະອຽດ ແລະປີ້ ການເຊື່ອມຕໍ່. HighLoad++ Siberia 2019. Hall "Krasnoyarsk". ວັນທີ 25 ມິຖຸນາ, 12:00 ໂມງ. ເຫຼົ່າ​ນີ້​ແລະ​ ການ ນຳ ສະ ເໜີ.

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

Mikhail Tyulenev (ຕໍ່ໄປນີ້ເອີ້ນວ່າ MT): – ຂ້າພະເຈົ້າຈະເວົ້າກ່ຽວກັບຄວາມສອດຄ່ອງ Causal - ນີ້ແມ່ນຄຸນສົມບັດທີ່ພວກເຮົາເຮັດວຽກຢູ່ໃນ MongoDB. ຂ້ອຍເຮັດວຽກຢູ່ໃນກຸ່ມຂອງລະບົບແຈກຢາຍ, ພວກເຮົາໄດ້ເຮັດມັນປະມານສອງປີກ່ອນ.

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

ຂ້າພະເຈົ້າຈະເວົ້າກ່ຽວກັບວິທີທີ່ພວກເຮົາ, ຜູ້ບໍລິໂພກຂອງການຄົ້ນຄວ້າທາງວິຊາການ, ກະກຽມບາງສິ່ງບາງຢ່າງຈາກມັນທີ່ພວກເຮົາສາມາດນໍາສະເຫນີໃຫ້ຜູ້ໃຊ້ຂອງພວກເຮົາເປັນອາຫານທີ່ກຽມພ້ອມທີ່ສະດວກແລະປອດໄພໃນການນໍາໃຊ້.

ຄວາມສອດຄ່ອງຂອງສາເຫດ. ໃຫ້ກໍານົດແນວຄວາມຄິດ

ເພື່ອເລີ່ມຕົ້ນດ້ວຍ, ຂ້ອຍຕ້ອງການເວົ້າໃນຄໍາສັບທົ່ວໄປວ່າຄວາມສອດຄ່ອງຂອງ Causal ແມ່ນຫຍັງ. ມີສອງຕົວລະຄອນ - Leonard ແລະ Penny (ຊຸດໂທລະທັດ "The Big Bang Theory"):

ໃຫ້ເວົ້າວ່າ Penny ຢູ່ໃນເອີຣົບແລະ Leonard ຕ້ອງການໃຫ້ນາງເປັນງານລ້ຽງທີ່ຫນ້າປະຫລາດໃຈ. ແລະລາວບໍ່ສາມາດຄິດຫຍັງດີໄປກວ່າການຖິ້ມນາງອອກຈາກລາຍຊື່ໝູ່ຂອງລາວ, ສົ່ງການອັບເດດໃຫ້ໝູ່ຂອງລາວທັງໝົດໃນຟີດວ່າ: “ຂໍໃຫ້ເພນນີມີຄວາມສຸກ!” (ນາງຢູ່ໃນເອີຣົບ, ໃນຂະນະທີ່ນາງນອນ, ນາງບໍ່ເຫັນສິ່ງທັງຫມົດນີ້ແລະບໍ່ສາມາດເຫັນມັນ, ເພາະວ່ານາງບໍ່ໄດ້ຢູ່ທີ່ນັ້ນ). ໃນທີ່ສຸດ, ນາງໄດ້ລຶບໂພສນີ້, ລຶບມັນອອກຈາກຟີດ ແລະ ກູ້ການເຂົ້າເຖິງຄືນມາເພື່ອບໍ່ໃຫ້ນາງສັງເກດເຫັນຫຍັງ ແລະບໍ່ມີເລື່ອງຫຍາບຄາຍ.
ນີ້ແມ່ນທັງຫມົດທີ່ດີແລະດີ, ແຕ່ໃຫ້ສົມມຸດວ່າລະບົບໄດ້ຖືກແຈກຢາຍແລະສິ່ງທີ່ຜິດພາດເລັກນ້ອຍ. ຕົວຢ່າງ, ມັນອາດຈະເກີດຂື້ນວ່າການຈໍາກັດການເຂົ້າເຖິງຂອງ Penny ເກີດຂຶ້ນຫຼັງຈາກການປະກາດນີ້ປາກົດ, ຖ້າເຫດການບໍ່ກ່ຽວຂ້ອງກັນໂດຍເຫດແລະຜົນ. ຕົວຈິງແລ້ວ, ນີ້ແມ່ນຕົວຢ່າງຂອງເວລາທີ່ຄວາມສອດຄ່ອງຂອງ Causal ແມ່ນຕ້ອງການເພື່ອປະຕິບັດຫນ້າທີ່ທຸລະກິດ (ໃນກໍລະນີນີ້).

ໃນຄວາມເປັນຈິງ, ເຫຼົ່ານີ້ແມ່ນຂ້ອນຂ້າງບໍ່ມີຄຸນສົມບັດຂອງຖານຂໍ້ມູນ - ມີຄົນຈໍານວນຫນ້ອຍຫຼາຍສະຫນັບສະຫນູນພວກເຂົາ. ໃຫ້ກ້າວໄປສູ່ແບບຈໍາລອງ.

ຮູບແບບຄວາມສອດຄ່ອງ

ຮູບແບບຄວາມສອດຄ່ອງໃນຖານຂໍ້ມູນແມ່ນຫຍັງ? ນີ້ແມ່ນການຮັບປະກັນບາງຢ່າງທີ່ລະບົບແຈກຢາຍໃຫ້ຂໍ້ມູນກ່ຽວກັບສິ່ງທີ່ລູກຄ້າສາມາດໄດ້ຮັບແລະໃນລໍາດັບໃດ.

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

ດັ່ງນັ້ນ, ຮູບແບບຄວາມສອດຄ່ອງແມ່ນໃຊ້ກັບລະບົບແຈກຢາຍເທົ່ານັ້ນ. ລະບົບທັງໝົດທີ່ເຄີຍມີຢູ່ກ່ອນໜ້ານີ້ ແລະ ເຮັດວຽກຢູ່ໃນການປັບຂະໜາດແນວຕັ້ງດຽວກັນບໍ່ໄດ້ປະສົບກັບບັນຫາດັ່ງກ່າວ. ມີ Buffer Cache ອັນໜຶ່ງ, ແລະທຸກຢ່າງຖືກອ່ານຈາກມັນສະເໝີ.

ຕົວແບບທີ່ເຂັ້ມແຂງ

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

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

ມີຄຸນສົມບັດທີ່ເຂັ້ມແຂງອີກອັນຫນຶ່ງທີ່ສະຫນັບສະຫນູນໃນ Spanner - ເອີ້ນວ່າຄວາມສອດຄ່ອງພາຍນອກ. ພວກເຮົາຈະເວົ້າກ່ຽວກັບມັນຕໍ່ມາເລັກນ້ອຍ.

ສາເຫດ

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

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

ໃນທີ່ສຸດ

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

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

ຂ້ອຍຕ້ອງການໃຫ້ຕົວຢ່າງປຽບທຽບບາງຢ່າງ:

ລູກສອນເຫຼົ່ານີ້ຫມາຍຄວາມວ່າແນວໃດ?

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

ທິດສະດີ CAP

ເມື່ອທ່ານເຫັນຄວາມສອດຄ່ອງຂອງຄໍາສັບຕ່າງໆ, ຄວາມພ້ອມ - ແມ່ນຫຍັງມາສູ່ໃຈຂອງເຈົ້າ? ຖືກຕ້ອງແລ້ວ - ທິດສະດີ CAP! ດຽວນີ້ຂ້ອຍຢາກຂັບໄລ່ເລື່ອງນິທານອອກມາ... ມັນບໍ່ແມ່ນຂ້ອຍ - ມັນແມ່ນ Martin Kleppmann, ຜູ້ທີ່ຂຽນບົດຄວາມທີ່ປະເສີດ, ປື້ມທີ່ປະເສີດ.

ທິດສະດີ CAP ແມ່ນຫຼັກການທີ່ສ້າງຂຶ້ນໃນຊຸມປີ 2000 ວ່າຄວາມສອດຄ່ອງ, ມີ, ການແບ່ງສ່ວນ: ເອົາສອງອັນ, ແລະທ່ານບໍ່ສາມາດເລືອກສາມ. ມັນແມ່ນຫຼັກການທີ່ແນ່ນອນ. ມັນໄດ້ຖືກພິສູດວ່າເປັນທິດສະດີບົດສອງສາມປີຕໍ່ມາໂດຍ Gilbert ແລະ Lynch. ຫຼັງຈາກນັ້ນ, ນີ້ໄດ້ເລີ່ມຕົ້ນທີ່ຈະຖືກນໍາໃຊ້ເປັນ mantra - ລະບົບໄດ້ເລີ່ມຕົ້ນທີ່ຈະແບ່ງອອກເປັນ CA, CP, AP ແລະອື່ນໆ.

ທິດສະດີນີ້ໄດ້ຖືກພິສູດຢ່າງແທ້ຈິງສໍາລັບກໍລະນີຕໍ່ໄປນີ້ ... ທໍາອິດ, ການມີຢູ່ໄດ້ຖືກພິຈາລະນາບໍ່ແມ່ນມູນຄ່າຢ່າງຕໍ່ເນື່ອງຈາກສູນຫາຮ້ອຍ (0 - ລະບົບແມ່ນ "ຕາຍ", 100 - ຕອບສະຫນອງຢ່າງໄວວາ; ພວກເຮົາຖືກນໍາໃຊ້ເພື່ອພິຈາລະນາມັນ) , ແຕ່ເປັນຊັບສິນຂອງ algorithm , ເຊິ່ງຮັບປະກັນວ່າສໍາລັບການປະຕິບັດທັງຫມົດຂອງມັນມັນຈະສົ່ງຄືນຂໍ້ມູນ.

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

ທັງໝົດນີ້ເພື່ອຫຍັງ? ຍິ່ງໄປກວ່ານັ້ນ, ທິດສະດີ CAP ໃນຮູບແບບທີ່ມັນຖືກພິສູດແລ້ວແມ່ນບໍ່ສາມາດປະຕິບັດໄດ້ແລະບໍ່ຄ່ອຍຖືກນໍາໃຊ້. ໃນຮູບແບບທິດສະດີ, ມັນຈໍາກັດບາງຢ່າງ. ມັນ turns ອອກຫຼັກການສະເພາະໃດຫນຶ່ງທີ່ຖືກຕ້ອງ intuitively, ແຕ່ໂດຍທົ່ວໄປຍັງບໍ່ໄດ້ຮັບການພິສູດ.

ຄວາມສອດຄ່ອງຂອງສາເຫດແມ່ນຕົວແບບທີ່ເຂັ້ມແຂງທີ່ສຸດ

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

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

MongoDB ເຮືອນຄົວພາຍໃນ

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

MongoDB (ຕໍ່ໄປນີ້ເອີ້ນວ່າ "MongoDB") ແມ່ນລະບົບການແຈກຢາຍທີ່ສະຫນັບສະຫນູນການຂະຫຍາຍອອກຕາມລວງນອນ, ນັ້ນແມ່ນ, sharding; ແລະພາຍໃນແຕ່ລະ shard ມັນຍັງສະຫນັບສະຫນູນການຊ້ໍາຊ້ອນຂໍ້ມູນ, ນັ້ນແມ່ນ, replication.

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

Router Query, ເຊິ່ງແຈກຢາຍການຮ້ອງຂໍ, ສໍາລັບລູກຄ້າແມ່ນລູກຄ້າບາງຄົນທີ່ມັນເຮັດວຽກ. ມັນຮູ້ຢູ່ແລ້ວວ່າບ່ອນໃດແລະຂໍ້ມູນໃດຕັ້ງຢູ່ແລະຊີ້ບອກການຮ້ອງຂໍທັງຫມົດໄປຫາ shard ທີ່ຖືກຕ້ອງ.

ຈຸດສໍາຄັນອີກອັນຫນຶ່ງ: MongoDB ເປັນແມ່ບົດດຽວ. ມີຫນຶ່ງປະຖົມ - ມັນສາມາດເອົາບັນທຶກທີ່ສະຫນັບສະຫນູນກະແຈທີ່ມັນມີ. ທ່ານບໍ່ສາມາດຂຽນ Multi-master ໄດ້.

ພວກເຮົາໄດ້ອອກລຸ້ນ 4.2 - ສິ່ງທີ່ຫນ້າສົນໃຈໃຫມ່ປາກົດຢູ່ທີ່ນັ້ນ. ໂດຍສະເພາະ, ພວກເຂົາເຈົ້າໄດ້ໃສ່ Lucene - ຄົ້ນຫາ - ຄື java ປະຕິບັດໄດ້ໂດຍກົງເຂົ້າໄປໃນ Mongo, ແລະຢູ່ທີ່ນັ້ນມັນເປັນໄປໄດ້ທີ່ຈະດໍາເນີນການຄົ້ນຫາຜ່ານ Lucene, ຄືກັນກັບໃນ Elastica.

ແລະພວກເຂົາໄດ້ເຮັດຜະລິດຕະພັນໃຫມ່ - ຕາຕະລາງ, ມັນຍັງມີຢູ່ໃນ Atlas (Cloud ຂອງ Mongo ຂອງຕົນເອງ). ພວກເຂົາເຈົ້າມີລະດັບຟຣີ - ທ່ານສາມາດຫຼິ້ນປະມານກັບມັນ. ຂ້າ​ພະ​ເຈົ້າ​ມັກ​ຕາ​ຕະ​ລາງ - ການ​ເບິ່ງ​ຂໍ້​ມູນ​, intuitive ຫຼາຍ​.

ສ່ວນປະກອບຄວາມສອດຄ່ອງຂອງສາເຫດ

ຂ້າພະເຈົ້າໄດ້ນັບປະມານ 230 ບົດຄວາມທີ່ໄດ້ຮັບການຕີພິມໃນຫົວຂໍ້ນີ້ - ຈາກ Leslie Lampert. ບັດນີ້ຈາກຄວາມຊົງຈໍາຂອງຂ້ອຍຂ້ອຍຈະຖ່າຍທອດບາງສ່ວນຂອງວັດສະດຸເຫຼົ່ານີ້ໃຫ້ກັບເຈົ້າ.

ມັນທັງຫມົດໄດ້ເລີ່ມຕົ້ນດ້ວຍບົດຄວາມໂດຍ Leslie Lampert, ເຊິ່ງໄດ້ຂຽນໃນຊຸມປີ 1970. ດັ່ງທີ່ເຈົ້າສາມາດເຫັນໄດ້, ການຄົ້ນຄວ້າບາງຢ່າງກ່ຽວກັບຫົວຂໍ້ນີ້ຍັງດໍາເນີນຢູ່. ໃນປັດຈຸບັນຄວາມສອດຄ່ອງຂອງ Causal ກໍາລັງປະສົບກັບຄວາມສົນໃຈໃນການພັດທະນາລະບົບການແຈກຢາຍ.

Restrictions

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

• ກ່ອນອື່ນ ໝົດ, "MongoDB" ແມ່ນແມ່ບົດດຽວ, ດັ່ງທີ່ຂ້ອຍເວົ້າແລ້ວ (ນີ້ເຮັດໃຫ້ງ່າຍຫຼາຍ).
• ພວກເຮົາເຊື່ອວ່າລະບົບຄວນສະຫນັບສະຫນູນປະມານ 10 ພັນ shards. ພວກ​ເຮົາ​ບໍ່​ສາ​ມາດ​ເຮັດ​ໃຫ້​ການ​ຕັດ​ສິນ​ໃຈ​ສະ​ຖາ​ປັດ​ຕະ​ທີ່​ຈະ​ຈໍາ​ກັດ​ຢ່າງ​ຊັດ​ເຈນ​ຄ່າ​ນີ້​.
• ພວກເຮົາມີເມຄ, ແຕ່ພວກເຮົາສົມມຸດວ່າບຸກຄົນໃດຫນຶ່ງຄວນຈະຍັງມີໂອກາດໃນເວລາທີ່ລາວດາວໂຫລດ binary, ແລ່ນມັນຢູ່ໃນຄອມພິວເຕີ້ຂອງລາວ, ແລະທຸກສິ່ງທຸກຢ່າງເຮັດວຽກໄດ້ດີ.
• ພວກເຮົາສົມມຸດບາງສິ່ງບາງຢ່າງທີ່ການຄົ້ນຄວ້າບໍ່ຄ່ອຍສົມມຸດວ່າ: ລູກຄ້າພາຍນອກສາມາດເຮັດສິ່ງໃດກໍ່ຕາມທີ່ເຂົາເຈົ້າຕ້ອງການ. MongoDB ແມ່ນແຫຼ່ງເປີດ. ດັ່ງນັ້ນ, ລູກຄ້າສາມາດສະຫລາດແລະໃຈຮ້າຍ - ພວກເຂົາສາມາດຕ້ອງການທີ່ຈະທໍາລາຍທຸກສິ່ງທຸກຢ່າງ. ພວກເຮົາຄາດຄະເນວ່າ Byzantine Feilors ອາດຈະມາຈາກ.
• ສໍາລັບລູກຄ້າພາຍນອກທີ່ຢູ່ນອກຂອບເຂດ, ມີຂໍ້ຈໍາກັດທີ່ສໍາຄັນ: ຖ້າຄຸນສົມບັດນີ້ຖືກປິດໃຊ້ງານ, ບໍ່ຄວນສັງເກດເຫັນການເສື່ອມໂຊມຂອງການປະຕິບັດ.
• ຈຸດອື່ນໂດຍທົ່ວໄປແມ່ນການຕໍ່ຕ້ານທາງວິຊາການ: ຄວາມເຂົ້າກັນໄດ້ຂອງຮຸ່ນທີ່ຜ່ານມາແລະໃນອະນາຄົດ. ໄດເວີເກົ່າຕ້ອງສະຫນັບສະຫນູນການປັບປຸງໃຫມ່, ແລະຖານຂໍ້ມູນຕ້ອງສະຫນັບສະຫນູນໄດເວີເກົ່າ.

ໂດຍທົ່ວໄປ, ທັງຫມົດນີ້ imposes ຂໍ້ຈໍາກັດ.

ອົງປະກອບຄວາມສອດຄ່ອງຂອງສາເຫດ

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

ການຕິດຕາມການເພິ່ງພາອາໄສຢ່າງເຕັມທີ່

ເປັນຫຍັງມັນຈຶ່ງຈໍາເປັນ? ດັ່ງນັ້ນເມື່ອຂໍ້ມູນຖືກ replicated, ແຕ່ລະບັນທຶກ, ແຕ່ລະການປ່ຽນແປງຂໍ້ມູນປະກອບດ້ວຍຂໍ້ມູນກ່ຽວກັບການປ່ຽນແປງທີ່ມັນຂຶ້ນກັບ. ການປ່ຽນແປງຄັ້ງທຳອິດ ແລະໄຮ້ສາລະແມ່ນເມື່ອແຕ່ລະຂໍ້ຄວາມທີ່ມີບັນທຶກມີຂໍ້ມູນກ່ຽວກັບຂໍ້ຄວາມທີ່ຜ່ານມາ:

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

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

ການຕິດຕາມການເພິ່ງພາອາໄສຢ່າງຈະແຈ້ງ

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

ນາງເຫັນວ່າບັນທຶກ 5 ແມ່ນຂຶ້ນກັບບັນທຶກ 1, 2, 3, 4 - ຕາມຄວາມເຫມາະສົມ, ນາງລໍຖ້າກ່ອນທີ່ລູກຄ້າຈະໄດ້ຮັບການປ່ຽນແປງທີ່ເຮັດໂດຍການຕັດສິນໃຈເຂົ້າເຖິງຂອງ Penny, ເມື່ອການປ່ຽນແປງທີ່ຜ່ານມາທັງຫມົດໄດ້ຜ່ານຖານຂໍ້ມູນແລ້ວ.

ນີ້ບໍ່ເຫມາະສົມກັບພວກເຮົາ, ເພາະວ່າຍັງມີຂໍ້ມູນຫຼາຍເກີນໄປ, ແລະມັນຈະຊ້າລົງ. ມີ​ວິ​ທີ​ການ​ອື່ນ ...

ໂມງ Lamport

ເຂົາເຈົ້າມີອາຍຸຫຼາຍ. ໂມງ Lamport ຫມາຍຄວາມວ່າການຂຶ້ນກັບເຫຼົ່ານີ້ຖືກພັບເຂົ້າໄປໃນຟັງຊັນ scalar, ເຊິ່ງເອີ້ນວ່າ Lamport Clock.

ຟັງຊັນ scalar ແມ່ນບາງຕົວເລກທີ່ບໍ່ມີຕົວຕົນ. ມັນມັກຈະຖືກເອີ້ນວ່າເວລາທີ່ມີເຫດຜົນ. ດ້ວຍແຕ່ລະເຫດການ, ວຽກງານຕ້ານການນີ້ເພີ່ມຂຶ້ນ. Counter, ເຊິ່ງປະຈຸບັນເປັນທີ່ຮູ້ຈັກກັບຂະບວນການ, ສົ່ງຂໍ້ຄວາມແຕ່ລະຄົນ. ມັນເປັນທີ່ຊັດເຈນວ່າຂະບວນການສາມາດອອກຈາກ sync, ພວກເຂົາສາມາດມີເວລາທີ່ແຕກຕ່າງກັນຫມົດ. ແນວໃດກໍ່ຕາມ, ລະບົບຈະດຸ່ນດ່ຽງໂມງດ້ວຍການສົ່ງຂໍ້ຄວາມດັ່ງກ່າວ. ຈະເກີດຫຍັງຂຶ້ນໃນກໍລະນີນີ້?

ຂ້ອຍແບ່ງ shard ໃຫຍ່ນັ້ນອອກເປັນສອງຢ່າງເພື່ອເຮັດໃຫ້ມັນຊັດເຈນ: ຫມູ່ເພື່ອນສາມາດອາໄສຢູ່ໃນຫນຶ່ງ node, ເຊິ່ງປະກອບດ້ວຍຊິ້ນສ່ວນຂອງການເກັບກໍາ, ແລະ Feed ສາມາດອາໄສຢູ່ໃນ node ອື່ນ, ເຊິ່ງປະກອບດ້ວຍຊິ້ນສ່ວນຂອງການເກັບກໍານີ້. ມັນເປັນທີ່ຊັດເຈນວ່າພວກເຂົາສາມາດອອກຈາກເສັ້ນໄດ້ແນວໃດ? ຟີດທຳອິດຈະບອກວ່າ: “ເຮັດຊ້ຳ”, ແລະຫຼັງຈາກນັ້ນ Friends. ຖ້າລະບົບບໍ່ໄດ້ໃຫ້ການຄໍ້າປະກັນບາງປະເພດວ່າ Feed ຈະບໍ່ຖືກສະແດງຈົນກ່ວາ Friends dependencies ໃນການເກັບກໍາ Friends ຈະຖືກສົ່ງ, ຫຼັງຈາກນັ້ນພວກເຮົາຈະມີສະຖານະການທີ່ຂ້າພະເຈົ້າໄດ້ກ່າວເຖິງ.

ທ່ານເຫັນວ່າເວລາ counter time ໃນ Feed ເພີ່ມຂຶ້ນຢ່າງມີເຫດຜົນແນວໃດ:

ດັ່ງນັ້ນຄຸນສົມບັດຕົ້ນຕໍຂອງໂມງ Lamport ແລະຄວາມສອດຄ່ອງ Causal (ອະທິບາຍໂດຍຜ່ານໂມງ Lamport) ແມ່ນນີ້: ຖ້າພວກເຮົາມີເຫດການ A ແລະ B, ແລະເຫດການ B ແມ່ນຂຶ້ນກັບເຫດການ A *, ຫຼັງຈາກນັ້ນມັນດັ່ງຕໍ່ໄປນີ້ວ່າ LogicalTime ຂອງເຫດການ A ແມ່ນຫນ້ອຍກວ່າ. LogicalTime ຈາກເຫດການ B.

* ບາງຄັ້ງພວກເຂົາຍັງເວົ້າວ່າ A ເກີດຂຶ້ນກ່ອນ B, ນັ້ນແມ່ນ, A ເກີດຂຶ້ນກ່ອນ B - ນີ້ແມ່ນຄວາມສໍາພັນທີ່ແນ່ນອນທີ່ບາງສ່ວນສັ່ງໃຫ້ຊຸດທັງຫມົດຂອງເຫດການທີ່ເກີດຂຶ້ນໂດຍທົ່ວໄປ.

ກົງກັນຂ້າມແມ່ນບໍ່ຖືກຕ້ອງ. ນີ້ແມ່ນຕົວຈິງແລ້ວຫນຶ່ງໃນຂໍ້ເສຍປຽບຕົ້ນຕໍຂອງໂມງ Lamport - ຄໍາສັ່ງບາງສ່ວນ. ມີແນວຄວາມຄິດກ່ຽວກັບເຫດການພ້ອມໆກັນ, ນັ້ນແມ່ນ, ເຫດການທີ່ທັງສອງ (A ເກີດຂຶ້ນກ່ອນ B) ຫຼື (A ເກີດຂຶ້ນກ່ອນ B). ຕົວຢ່າງຫນຶ່ງຈະເປັນການເພີ່ມຂະຫນານຂອງ Leonard ຂອງຄົນອື່ນເປັນເພື່ອນ (ບໍ່ແມ່ນແຕ່ Leonard, ແຕ່ Sheldon, ສໍາລັບການຍົກຕົວຢ່າງ).
ນີ້ແມ່ນຊັບສິນທີ່ຖືກນໍາໃຊ້ເລື້ອຍໆໃນເວລາທີ່ເຮັດວຽກກັບໂມງ Lamport: ພວກເຂົາເບິ່ງຫນ້າທີ່ໂດຍສະເພາະແລະຈາກນີ້ພວກເຂົາສະຫຼຸບວ່າບາງທີເຫດການເຫຼົ່ານີ້ແມ່ນຂຶ້ນກັບ. ເນື່ອງຈາກວ່າວິທີຫນຶ່ງແມ່ນຄວາມຈິງ: ຖ້າ LogicalTime A ຫນ້ອຍກວ່າ LogicalTime B, ຫຼັງຈາກນັ້ນ B ບໍ່ສາມາດເກີດຂຶ້ນກ່ອນ A; ແລະຖ້າຫຼາຍກວ່ານັ້ນ, ບາງທີ.

ໂມງ vector

ການພັດທະນາຢ່າງມີເຫດຜົນຂອງໂມງ Lamport ແມ່ນໂມງ Vector. ພວກມັນແຕກຕ່າງກັນທີ່ແຕ່ລະ node ທີ່ຢູ່ນີ້ປະກອບດ້ວຍໂມງແຍກຂອງຕົນເອງ, ແລະພວກມັນຖືກຖ່າຍທອດເປັນ vector.
ໃນກໍລະນີນີ້, ທ່ານເຫັນວ່າດັດຊະນີ zeroth ຂອງ vector ແມ່ນຮັບຜິດຊອບສໍາລັບ Feed, ແລະດັດຊະນີທໍາອິດຂອງ vector ແມ່ນສໍາລັບ Friends (ແຕ່ລະຂໍ້ເຫຼົ່ານີ້). ແລະໃນປັດຈຸບັນພວກເຂົາຈະເພີ່ມຂຶ້ນ: ດັດຊະນີສູນຂອງ "ອາຫານ" ເພີ່ມຂຶ້ນເມື່ອຂຽນ - 1, 2, 3:

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

ຖ້າພວກເຮົາມີ 10 ພັນ shards, ພວກເຮົາບໍ່ສາມາດໂອນ 10 ພັນອົງປະກອບ, ເຖິງແມ່ນວ່າພວກເຮົາຈະບີບອັດມັນຫຼືມີອັນອື່ນ - payload ຈະຍັງນ້ອຍກວ່າປະລິມານຂອງ vector ທັງຫມົດນີ້ຫຼາຍເທົ່າ. ດັ່ງນັ້ນ, ຫົວໃຈ ແລະ ແຂ້ວຂອງພວກເຮົາ, ພວກເຮົາປະຖິ້ມວິທີການນີ້ ແລະກ້າວໄປສູ່ອັນອື່ນ.

Spanner TrueTime. ໂມງປະລໍາມະນູ

ຂ້າພະເຈົ້າເວົ້າວ່າຈະມີເລື່ອງກ່ຽວກັບ Spanner. ນີ້ແມ່ນສິ່ງທີ່ເຢັນ, ກົງໄປກົງມາຂອງສະຕະວັດທີ XNUMX: ໂມງປະລໍາມະນູ, synchronization GPS.

ຄວາມຄິດແນວໃດ? "Spanner" ແມ່ນລະບົບ Google ທີ່ບໍ່ດົນມານີ້ມີໃຫ້ແກ່ຄົນ (ພວກເຂົາເພີ່ມ SQL ໃສ່ມັນ). ແຕ່ລະທຸລະກໍາມີເວລາປະທັບຕາ. ນັບຕັ້ງແຕ່ເວລາຖືກ synchronized*, ແຕ່ລະເຫດການສາມາດຖືກກໍານົດເວລາສະເພາະ - ໂມງປະລໍາມະນູມີເວລາລໍຖ້າ, ຫຼັງຈາກນັ້ນເວລາທີ່ແຕກຕ່າງກັນແມ່ນຮັບປະກັນວ່າ "ເກີດຂຶ້ນ".

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

* ນີ້ແມ່ນບັນຫາຕົ້ນຕໍກັບໂມງ Lampart - ພວກມັນບໍ່ເຄີຍ synchronous ໃນລະບົບແຈກຢາຍ. ພວກເຂົາສາມາດແຍກກັນໄດ້; ເຖິງແມ່ນວ່າມີ NTP, ພວກເຂົາຍັງເຮັດວຽກບໍ່ໄດ້ດີຫຼາຍ. "Spanner" ມີໂມງປະລໍາມະນູແລະ synchronization, ເບິ່ງຄືວ່າ, ແມ່ນ microseconds.

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

ໂມງປະສົມ

ນີ້ແມ່ນສິ່ງທີ່ຫມາຍຕິກຢູ່ໃນ MongoDB ເມື່ອຮັບປະກັນຄວາມສອດຄ່ອງຂອງ Causal. ພວກມັນປະສົມກັນແນວໃດ? ປະສົມແມ່ນຄ່າສະກຸນ, ແຕ່ມັນມີສອງອົງປະກອບ:

• ທໍາອິດແມ່ນຍຸກຂອງ Unix (ເວລາຫຼາຍວິນາທີໄດ້ຜ່ານໄປນັບຕັ້ງແຕ່ "ການເລີ່ມຕົ້ນຂອງໂລກຄອມພິວເຕີ").
• ອັນທີສອງແມ່ນການເພີ່ມຂຶ້ນບາງຢ່າງ, ຍັງເປັນ 32-bit unsigned int.

ນັ້ນແມ່ນທັງຫມົດ, ຕົວຈິງແລ້ວ. ມີວິທີການນີ້: ພາກສ່ວນທີ່ຮັບຜິດຊອບສໍາລັບເວລາແມ່ນ synchronized ກັບໂມງຕະຫຼອດເວລາ; ທຸກໆຄັ້ງທີ່ມີການອັບເດດເກີດຂຶ້ນ, ສ່ວນນີ້ຈະຖືກ synchronized ກັບໂມງແລະມັນ turns ໃຫ້ເຫັນວ່າເວລາແມ່ນສະເຫມີຫຼາຍຫຼືຫນ້ອຍທີ່ຖືກຕ້ອງ, ແລະ increment ຊ່ວຍໃຫ້ທ່ານສາມາດຈໍາແນກລະຫວ່າງເຫດການທີ່ເກີດຂຶ້ນໃນຈຸດດຽວກັນໃນເວລາ.

ເປັນຫຍັງອັນນີ້ຈຶ່ງສຳຄັນສຳລັບ MongoDB? ເນື່ອງຈາກວ່າມັນອະນຸຍາດໃຫ້ທ່ານເຮັດບາງປະເພດຂອງຮ້ານອາຫານສໍາຮອງໃນເວລາໃດຫນຶ່ງ, ນັ້ນແມ່ນ, ເຫດການຖືກດັດສະນີໂດຍເວລາ. ນີ້ເປັນສິ່ງສໍາຄັນໃນເວລາທີ່ເຫດການສະເພາະໃດຫນຶ່ງແມ່ນຈໍາເປັນ; ສໍາລັບຖານຂໍ້ມູນ, ເຫດການແມ່ນການປ່ຽນແປງໃນຖານຂໍ້ມູນທີ່ເກີດຂື້ນໃນຊ່ວງເວລາທີ່ແນ່ນອນ.

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

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

synchronization ໂມງ

ມີວິທີການ synchronization ຫຼາຍອະທິບາຍໃນວັນນະຄະດີວິທະຍາສາດ. ຂ້ອຍເວົ້າກ່ຽວກັບ synchronization ເມື່ອພວກເຮົາມີສອງ shards ທີ່ແຕກຕ່າງກັນ. ຖ້າ​ຫາກ​ວ່າ​ມີ​ຫນຶ່ງ​ຊຸດ replica​, ບໍ່​ຈໍາ​ເປັນ​ຕ້ອງ​ສໍາ​ລັບ​ການ synchronization ໃດ​: ນີ້​ແມ່ນ "ແມ່​ບົດ​ດຽວ​"​; ພວກເຮົາມີ OpLog, ເຊິ່ງການປ່ຽນແປງທັງຫມົດຫຼຸດລົງ - ໃນກໍລະນີນີ້, ທຸກສິ່ງທຸກຢ່າງໄດ້ຖືກຈັດລໍາດັບຕາມລໍາດັບໃນ "Oplog" ຕົວຂອງມັນເອງ. ແຕ່ຖ້າພວກເຮົາມີສອງ shards ທີ່ແຕກຕ່າງກັນ, ການ synchronization ເວລາແມ່ນສໍາຄັນຢູ່ທີ່ນີ້. ນີ້ແມ່ນບ່ອນທີ່ໂມງ vector ຊ່ວຍຫຼາຍ! ແຕ່ພວກເຮົາບໍ່ມີພວກມັນ.

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

ແນ່ນອນ, ເວລາທີ່ແທ້ຈິງແມ່ນເປັນສິ່ງທີ່ປະເສີດ. ແຕ່, ອີກເທື່ອຫນຶ່ງ, ນີ້ອາດຈະເປັນອະນາຄົດ ... ເຖິງແມ່ນວ່າມັນສາມາດເຮັດໄດ້ແລ້ວໃນ Atlas, ມີ "Amazon" synchronizers ທີ່ໄວແລ້ວ. ແຕ່ມັນຈະບໍ່ສາມາດໃຊ້ໄດ້ກັບທຸກຄົນ.

ການນິນທາແມ່ນເວລາທີ່ຂໍ້ຄວາມທັງໝົດລວມເຖິງເວລາ. ນີ້ແມ່ນປະມານສິ່ງທີ່ພວກເຮົາໃຊ້. ທຸກໆຂໍ້ຄວາມລະຫວ່າງ nodes, driver, data node router, ຢ່າງແທ້ຈິງທຸກສິ່ງທຸກຢ່າງສໍາລັບ MongoDB ແມ່ນບາງອົງປະກອບ, ອົງປະກອບຖານຂໍ້ມູນທີ່ປະກອບດ້ວຍໂມງທີ່ເຮັດວຽກ. ພວກເຂົາເຈົ້າມີຄວາມຫມາຍຂອງເວລາປະສົມຢູ່ທົ່ວທຸກແຫ່ງ, ມັນຖືກຖ່າຍທອດ. 64 ບິດ? ນີ້ອະນຸຍາດໃຫ້, ນີ້ແມ່ນເປັນໄປໄດ້.

ມັນເຮັດວຽກຮ່ວມກັນແນວໃດ?

ທີ່ນີ້ຂ້ອຍກໍາລັງເບິ່ງຊຸດ replica ຫນຶ່ງເພື່ອເຮັດໃຫ້ມັນງ່າຍຂຶ້ນເລັກນ້ອຍ. ມີປະຖົມ ແລະ ມັດທະຍົມ. Secondary ເຮັດ replication ແລະບໍ່ສະເຫມີ synchronized ກັບປະຖົມ.

ການແຊກເຂົ້າໄປໃນ "Primery" ທີ່ມີຄ່າເວລາທີ່ແນ່ນອນ. ໃສ່ນີ້ເພີ່ມການນັບພາຍໃນໂດຍ 11, ຖ້ານີ້ແມ່ນສູງສຸດ. ຫຼື​ມັນ​ຈະ​ກວດ​ສອບ​ຄ່າ​ໂມງ​ແລະ sync ກັບ​ໂມງ​ຖ້າ​ຫາກ​ວ່າ​ຄ່າ​ໂມງ​ຫຼາຍ​ກວ່າ. ນີ້ອະນຸຍາດໃຫ້ທ່ານຈັດລະບຽບໂດຍທີ່ໃຊ້ເວລາ.

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

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

ຄ່າທີ່ຖືກຂຽນໄວ້ໃນ "Oplog" ຖືກສົ່ງຄືນ - ພວກເຮົາຮູ້ວ່າ "Oplog" ມີຄ່ານີ້ແລ້ວ, ແລະເວລາຂອງມັນແມ່ນ 12. ໃນປັດຈຸບັນ, ໃຫ້ເວົ້າວ່າ, ການອ່ານເລີ່ມຕົ້ນຈາກ node ອື່ນ (ຮອງ), ແລະມັນສົ່ງຕໍ່ afterClusterTime ໃນ. ຂໍ້ຄວາມ. ລາວ​ເວົ້າ​ວ່າ: “ຂ້ອຍ​ຕ້ອງການ​ທຸກ​ສິ່ງ​ທີ່​ເກີດ​ຂຶ້ນ​ຢ່າງ​ໜ້ອຍ​ຫຼັງ​ຈາກ​ທີ 12 ຫຼື​ໃນ​ລະຫວ່າງ​ສິບ​ສອງ” (ເບິ່ງ​ຮູບ​ຂ້າງ​ເທິງ).

ນີ້ແມ່ນສິ່ງທີ່ເອີ້ນວ່າ Causal ສອດຄ່ອງ (CAT). ມີແນວຄວາມຄິດດັ່ງກ່າວໃນທິດສະດີວ່ານີ້ແມ່ນບາງສ່ວນຂອງເວລາ, ເຊິ່ງສອດຄ່ອງໃນຕົວຂອງມັນເອງ. ໃນກໍລະນີນີ້, ພວກເຮົາສາມາດເວົ້າໄດ້ວ່ານີ້ແມ່ນສະພາບຂອງລະບົບທີ່ໄດ້ສັງເກດເຫັນໃນເວລາ 12.

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

ນັ້ນແມ່ນຫຼາຍວິທີທີ່ມັນເຮັດວຽກທັງຫມົດ. ເກືອບ​ທັງ​ຫມົດ.

"ເກືອບ" ຫມາຍຄວາມວ່າແນວໃດ? ໃຫ້ສົມມຸດວ່າມີບາງຄົນທີ່ໄດ້ອ່ານແລະເຂົ້າໃຈວິທີການທັງຫມົດນີ້ເຮັດວຽກ. ຂ້າພະເຈົ້າຮັບຮູ້ວ່າທຸກໆຄັ້ງທີ່ ClusterTime ເກີດຂື້ນ, ມັນປັບປຸງໂມງທີ່ມີເຫດຜົນພາຍໃນ, ແລະຫຼັງຈາກນັ້ນການເຂົ້າຕໍ່ໄປຈະເພີ່ມຂຶ້ນຫນຶ່ງຄັ້ງ. ຟັງຊັນນີ້ໃຊ້ເວລາ 20 ເສັ້ນ. ສົມມຸດວ່າບຸກຄົນນີ້ສົ່ງຕົວເລກ 64-bit ທີ່ໃຫຍ່ທີ່ສຸດ, ລົບຫນຶ່ງ.

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

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

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

ວິທີການຂອງພວກເຮົາແມ່ນເພື່ອເຂົ້າສູ່ລະບົບ clusterTime

ນີ້ແມ່ນວິທີທີ່ມັນຖືກຖ່າຍທອດໃນຂໍ້ຄວາມ (ກ່ອນຂໍ້ຄວາມສີຟ້າ). ແຕ່ພວກເຮົາກໍ່ເລີ່ມສ້າງລາຍເຊັນ (ຂໍ້ຄວາມສີຟ້າ):

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

ມັນຫມາຍຄວາມວ່າແນວໃດທີ່ຈະໃຊ້ຄວາມສອດຄ່ອງ Causal ໃນກໍລະນີນີ້? ນີ້ແມ່ນເພື່ອສະແດງພາລາມິເຕີ afterClusterTime. ໂດຍບໍ່ມີການນີ້, ມັນພຽງແຕ່ຈະຜ່ານມູນຄ່າຢ່າງໃດກໍ່ຕາມ. ການນິນທາ, ເລີ່ມຕົ້ນຈາກເວີຊັນ 3.6, ເຮັດວຽກສະເໝີ.

ຖ້າພວກເຮົາອອກຈາກການຜະລິດລາຍເຊັນຄົງທີ່, ມັນຈະເຮັດໃຫ້ລະບົບຊ້າລົງເຖິງແມ່ນວ່າໃນລັກສະນະທີ່ບໍ່ມີຄຸນສົມບັດ, ເຊິ່ງບໍ່ຕອບສະຫນອງວິທີການແລະຄວາມຕ້ອງການຂອງພວກເຮົາ. ດັ່ງນັ້ນພວກເຮົາໄດ້ເຮັດຫຍັງ?

ເຮັດໄວ!

ມັນ​ເປັນ​ສິ່ງ​ທີ່​ງ່າຍ​ດາຍ​ຫຼາຍ​, ແຕ່ trick ແມ່ນ​ຫນ້າ​ສົນ​ໃຈ - ຂ້າ​ພະ​ເຈົ້າ​ຈະ​ແບ່ງ​ປັນ​ມັນ​, ບາງ​ທີ​ຄົນ​ຈະ​ສົນ​ໃຈ​.
ພວກເຮົາມີ hash ທີ່ເກັບຮັກສາຂໍ້ມູນທີ່ລົງນາມ. ຂໍ້ມູນທັງຫມົດຜ່ານ cache. cache ບໍ່ໄດ້ເຊັນເວລາສະເພາະ, ແຕ່ Range. ເມື່ອຄ່າບາງຢ່າງມາຮອດ, ພວກເຮົາສ້າງ Range, mask out the last 16 bits, and we sign this value:

ໂດຍການໄດ້ຮັບລາຍເຊັນດັ່ງກ່າວ, ພວກເຮົາເລັ່ງລະບົບ (ຂ້ອນຂ້າງ) 65 ພັນຄັ້ງ. ມັນເຮັດວຽກໄດ້ດີ: ເມື່ອພວກເຮົາດໍາເນີນການທົດລອງ, ເວລາຕົວຈິງຫຼຸດລົງ 10 ພັນເທື່ອເມື່ອພວກເຮົາມີການປັບປຸງຕາມລໍາດັບ. ມັນເປັນທີ່ຊັດເຈນວ່າເມື່ອພວກເຂົາບໍ່ລົງຮອຍກັນ, ນີ້ບໍ່ໄດ້ຜົນ. ແຕ່ໃນກໍລະນີປະຕິບັດສ່ວນໃຫຍ່ມັນເຮັດວຽກ. ການປະສົມປະສານຂອງລາຍເຊັນ Range ພ້ອມກັບລາຍເຊັນໄດ້ແກ້ໄຂບັນຫາຄວາມປອດໄພ.

ພວກເຮົາໄດ້ຮຽນຮູ້ຫຍັງ?

ບົດຮຽນທີ່ພວກເຮົາໄດ້ຮຽນຮູ້ຈາກນີ້:

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

  ໂດຍທົ່ວໄປແລ້ວ, ມີຄວາມແຕກຕ່າງທີ່ແນ່ນອນໃນຄວາມຄິດໃນເວລາທີ່ມີກອງປະຊຸມທາງວິຊາການ (Sigmon, ສໍາລັບການຍົກຕົວຢ່າງ) - ທຸກຄົນສຸມໃສ່ແນວຄວາມຄິດໃຫມ່. ມີອັນໃດໃໝ່ກ່ຽວກັບສູດການຄິດໄລ່ຂອງພວກເຮົາ? ບໍ່ມີຫຍັງໃຫມ່ໂດຍສະເພາະຢູ່ທີ່ນີ້. ຄວາມແປກໃໝ່ແທນທີ່ຈະຢູ່ໃນວິທີທີ່ພວກເຮົາປະສົມວິທີການທີ່ມີຢູ່ຮ່ວມກັນ. ເພາະສະນັ້ນ, ສິ່ງທໍາອິດແມ່ນການອ່ານຄລາສສິກ, ເລີ່ມຕົ້ນດ້ວຍ Lampart.

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

  ບໍ່ມີຫຍັງໃໝ່ແທ້ໆຢູ່ທີ່ນີ້! ແຕ່ທັນທີທີ່ພວກເຮົາປະສົມມັນທັງຫມົດ ... ມັນຄືກັນກັບການເວົ້າວ່າສູດສະຫຼັດ Olivier ແມ່ນບໍ່ມີເຫດຜົນ, ເພາະວ່າໄຂ່, mayonnaise ແລະແຕງໄດ້ຖືກປະດິດຂື້ນແລ້ວ ... ມັນກ່ຽວກັບເລື່ອງດຽວກັນ.

ຂ້ອຍຈະສໍາເລັດດ້ວຍສິ່ງນີ້. ຂອບ​ໃຈ!

ຄໍາຖາມຂອງທ່ານ

ຄໍາຖາມຈາກຜູ້ຊົມ (ຕໍ່ໄປນີ້ເອີ້ນວ່າ B): – ຂໍ​ຂອບ​ໃຈ​ທ່ານ, Mikhail, ສໍາ​ລັບ​ການ​ລາຍ​ງານ! ຫົວຂໍ້ກ່ຽວກັບເວລາແມ່ນຫນ້າສົນໃຈ. ທ່ານກຳລັງໃຊ້ການນິນທາ. ພວກເຂົາເວົ້າວ່າທຸກຄົນມີເວລາຂອງຕົນເອງ, ທຸກຄົນຮູ້ເວລາທ້ອງຖິ່ນຂອງພວກເຂົາ. ດັ່ງທີ່ຂ້າພະເຈົ້າເຂົ້າໃຈມັນ, ພວກເຮົາມີຄົນຂັບ - ສາມາດມີລູກຄ້າຫຼາຍຄົນທີ່ມີຄົນຂັບລົດ, ຜູ້ວາງແຜນການສອບຖາມ, ຍາກເກີນໄປ ... ແລະລະບົບຈະລົງມາແນວໃດຖ້າພວກເຮົາມີຄວາມແຕກຕ່າງກັນຢ່າງກະທັນຫັນ: ຜູ້ໃດຜູ້ຫນຶ່ງຕັດສິນໃຈວ່າມັນແມ່ນສໍາລັບ ນາ​ທີ​ຂ້າງ​ຫນ້າ​, ຜູ້​ໃດ​ຜູ້​ຫນຶ່ງ​ນາ​ທີ​ຫລັງ​? ເຮົາຈະໄປຮອດໃສ?

MT: - ຄໍາ​ຖາມ​ທີ່​ຍິ່ງ​ໃຫຍ່​ທີ່​ແທ້​ຈິງ​! ຂ້າພະເຈົ້າພຽງແຕ່ຢາກເວົ້າກ່ຽວກັບ shards. ຖ້າຂ້ອຍເຂົ້າໃຈຄໍາຖາມຢ່າງຖືກຕ້ອງ, ພວກເຮົາມີສະຖານະການດັ່ງຕໍ່ໄປນີ້: ມີ shard 1 ແລະ shard 2, ການອ່ານເກີດຂື້ນຈາກສອງ shard ນີ້ - ພວກມັນມີຄວາມແຕກຕ່າງກັນ, ພວກມັນບໍ່ພົວພັນກັບກັນແລະກັນ, ເພາະວ່າເວລາທີ່ພວກເຂົາຮູ້ແຕກຕ່າງກັນ, ໂດຍສະເພາະເວລາທີ່ພວກມັນມີຢູ່ໃນ oplogs.
ໃຫ້ເວົ້າວ່າ shard 1 ສ້າງເປັນລ້ານບັນທຶກ, shard 2 ບໍ່ມີຫຍັງເລີຍ, ແລະການຮ້ອງຂໍມາເຖິງສອງ shards. ແລະອັນທໍາອິດມີ afterClusterTime ຫຼາຍກວ່າຫນຶ່ງລ້ານ. ໃນສະຖານະການດັ່ງກ່າວ, ດັ່ງທີ່ຂ້າພະເຈົ້າໄດ້ອະທິບາຍ, shard 2 ຈະບໍ່ຕອບສະຫນອງທັງຫມົດ.

ໃນ: – ຂ້າ​ພະ​ເຈົ້າ​ຕ້ອງ​ການ​ທີ່​ຈະ​ຮູ້​ວ່າ​ເຂົາ​ເຈົ້າ synchronize ແລະ​ເລືອກ​ເອົາ​ຫນຶ່ງ​ທີ່​ໃຊ້​ເວ​ລາ​ຢ່າງ​ມີ​ເຫດ​ຜົນ​?

MT: - ງ່າຍ​ຫຼາຍ​ເພື່ອ synchronize​. Shard, ເມື່ອ afterClusterTime ມາຫາລາວແລະລາວບໍ່ໄດ້ຊອກຫາເວລາໃນ "Oplog", ບໍ່ມີການອະນຸມັດ. ນັ້ນແມ່ນ, ລາວຍົກສູງເວລາດ້ວຍມືຂອງລາວກັບມູນຄ່ານີ້. ນີ້ຫມາຍຄວາມວ່າມັນບໍ່ມີເຫດການທີ່ກົງກັບຄໍາຮ້ອງຂໍນີ້. ລາວສ້າງເຫດການນີ້ປອມແລະດັ່ງນັ້ນຈຶ່ງກາຍເປັນ Causal Consistent.

ໃນ: – ຈະ​ເປັນ​ແນວ​ໃດ​ຖ້າ​ຫາກ​ວ່າ​ຫຼັງ​ຈາກ​ນີ້​ບາງ​ເຫດ​ການ​ອື່ນໆ​ມາ​ຫາ​ເຂົາ​ໄດ້​ສູນ​ເສຍ​ບາງ​ບ່ອນ​ໃນ​ເຄືອ​ຂ່າຍ​?

MT: – Shard ຖືກ​ອອກ​ແບບ​ໃນ​ວິ​ທີ​ການ​ທີ່​ພວກ​ເຂົາ​ເຈົ້າ​ຈະ​ບໍ່​ໄດ້​ມາ​ອີກ​ເທື່ອ​ຫນຶ່ງ​, ເນື່ອງ​ຈາກ​ວ່າ​ມັນ​ເປັນ​ແມ່​ບົດ​ດຽວ​. ຖ້າລາວລົງທະບຽນແລ້ວ, ເຂົາເຈົ້າຈະບໍ່ມາ, ແຕ່ຈະມາຕໍ່ມາ. ມັນບໍ່ສາມາດເກີດຂຶ້ນໄດ້ວ່າບາງສິ່ງບາງຢ່າງຕິດຢູ່ບ່ອນໃດບ່ອນຫນຶ່ງ, ຫຼັງຈາກນັ້ນລາວບໍ່ໄດ້ຂຽນ, ແລະຫຼັງຈາກນັ້ນເຫດການເຫຼົ່ານີ້ມາຮອດ - ແລະຄວາມສອດຄ່ອງຂອງ Causal ແມ່ນແຕກຫັກ. ໃນເວລາທີ່ລາວບໍ່ໄດ້ຂຽນ, ພວກເຂົາທຸກຄົນຄວນຈະມາຕໍ່ໄປ (ລາວຈະລໍຖ້າພວກເຂົາ).

ໃນ: – ຂ້າ​ພະ​ເຈົ້າ​ມີ​ຄໍາ​ຖາມ​ຈໍາ​ນວນ​ຫນຶ່ງ​ກ່ຽວ​ກັບ​ການ​ຄິວ​. ຄວາມສອດຄ່ອງຂອງເຫດຜົນສົມມຸດວ່າມີຄິວສະເພາະຂອງການປະຕິບັດທີ່ຕ້ອງໄດ້ຮັບການປະຕິບັດ. ຈະເກີດຫຍັງຂຶ້ນຖ້າໜຶ່ງໃນຊຸດຂອງພວກເຮົາຫາຍໄປ? ມາຮອດນີ້ ວັນທີ 10, 11... ວັນທີ 12 ຫາຍໄປ, ແລະ ຄົນອື່ນກໍລໍຖ້າໃຫ້ມັນກາຍເປັນຈິງ. ແລະທັນທີທັນໃດລົດຂອງພວກເຮົາເສຍຊີວິດ, ພວກເຮົາບໍ່ສາມາດເຮັດຫຍັງໄດ້. ມີຄວາມຍາວສູງສຸດຂອງແຖວທີ່ສະສົມກ່ອນທີ່ຈະຖືກປະຕິບັດບໍ? ຄວາມລົ້ມເຫຼວຮ້າຍແຮງອັນໃດເກີດຂຶ້ນເມື່ອລັດໃດນຶ່ງສູນເສຍໄປ? ຍິ່ງໄປກວ່ານັ້ນ, ຖ້າພວກເຮົາຂຽນລົງວ່າມີລັດທີ່ຜ່ານມາ, ພວກເຮົາຄວນຈະເລີ່ມຕົ້ນຈາກມັນແນວໃດ? ແຕ່​ເຂົາ​ເຈົ້າ​ບໍ່​ໄດ້​ຂັບ​ໄລ່​ລາວ​ອອກ!

MT: – ຍັງ​ເປັນ​ຄໍາ​ຖາມ​ທີ່​ຍິ່ງ​ໃຫຍ່​! ພວກເຮົາກໍາລັງເຮັດຫຍັງ? MongoDB ມີແນວຄວາມຄິດຂອງ quorum writes, quorum ອ່ານ. ໃນກໍລະນີໃດທີ່ຂໍ້ຄວາມສາມາດສູນເສຍ? ໃນເວລາທີ່ການຂຽນບໍ່ແມ່ນກຸ່ມຫຼືໃນເວລາທີ່ການອ່ານບໍ່ແມ່ນກຸ່ມ (ຂີ້ເຫຍື້ອບາງປະເພດອາດຈະຕິດຢູ່).
ກ່ຽວກັບຄວາມສອດຄ່ອງຂອງ Causal, ການທົດສອບການທົດລອງຂະຫນາດໃຫຍ່ໄດ້ຖືກປະຕິບັດ, ຜົນໄດ້ຮັບແມ່ນວ່າໃນກໍລະນີທີ່ຂຽນແລະອ່ານບໍ່ແມ່ນກຸ່ມ, ການລະເມີດຄວາມສອດຄ່ອງຂອງ Causal ເກີດຂື້ນ. ແທ້ທີ່ເຈົ້າເວົ້າ!

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

ໃນ: - ເມື່ອພວກເຮົາສ້າງຕົວຢ່າງທີ່ປະຕິບັດ sharding ສໍາລັບພວກເຮົາ (ບໍ່ແມ່ນນາຍ, ແຕ່ສໍາລອງ, ຕາມລໍາດັບ), ມັນອີງໃສ່ເວລາ Unix ຂອງເຄື່ອງຈັກຂອງຕົນເອງຫຼືເວລາຂອງ "ນາຍ"; ມັນຊິ້ງເປັນເທື່ອທຳອິດ ຫຼືເປັນຊ່ວງໄລຍະບໍ?

MT: - ຂ້າ​ພະ​ເຈົ້າ​ຈະ​ອະ​ທິ​ບາຍ​ໃນ​ປັດ​ຈຸ​ບັນ​. Shard (ເຊັ່ນ: ການແບ່ງພາຕິຊັນຕາມລວງນອນ) - ມີ Primary ຢູ່ສະເໝີ. ແລະ shard ສາມາດມີ "ຕົ້ນສະບັບ" ແລະສາມາດ replicas ໄດ້. ແຕ່ shard ສະເຫມີສະຫນັບສະຫນູນການບັນທຶກ, ເນື່ອງຈາກວ່າມັນຕ້ອງສະຫນັບສະຫນູນບາງໂດເມນ (shard ມີ Primary).

ໃນ: - ດັ່ງນັ້ນທຸກສິ່ງທຸກຢ່າງແມ່ນຂຶ້ນກັບ "ນາຍ" ແທ້ໆບໍ? ໃຊ້ເວລາແມ່ແບບສະເໝີບໍ?

MT: - ແມ່ນແລ້ວ. ເຈົ້າສາມາດເວົ້າໃນຕົວເລກວ່າ: ໂມງຖືກຕີເມື່ອການເຂົ້າໄປໃນ "ແມ່ບົດ", ເຂົ້າໄປໃນ "Oplog" ເກີດຂື້ນ.

ໃນ: - ພວກເຮົາມີລູກຄ້າທີ່ເຊື່ອມຕໍ່ແລະບໍ່ຈໍາເປັນຕ້ອງຮູ້ຫຍັງກ່ຽວກັບເວລາບໍ?

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

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

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

ໃນ: - ຊັ້ນໃຫມ່ຂອງວິທະຍາສາດການຄິດໄລ່ - ປະເພດຂໍ້ມູນ CRDT (ປະເພດຂໍ້ມູນແບບຈໍາລອງທີ່ບໍ່ມີຂໍ້ຂັດແຍ່ງ) - ມີຄວາມກ່ຽວຂ້ອງຢ່າງແຂງແຮງກັບຫົວຂໍ້ຂອງຄວາມສອດຄ່ອງຂອງເຫດການ. ທ່ານໄດ້ພິຈາລະນາການລວມເອົາຂໍ້ມູນປະເພດເຫຼົ່ານີ້ເຂົ້າໄປໃນຖານຂໍ້ມູນແລະເຈົ້າສາມາດເວົ້າກ່ຽວກັບມັນໄດ້ແນວໃດ?

MT: - ຄໍາ​ຖາມ​ທີ່​ດີ! CRDT ມີຄວາມຫມາຍສໍາລັບການຂຽນຂໍ້ຂັດແຍ່ງ: ໃນ MongoDB, ຕົ້ນສະບັບດຽວ.

ໃນ: – ຂ້າ​ພະ​ເຈົ້າ​ມີ​ຄໍາ​ຖາມ​ຈາກ devops ໄດ້​. ໃນໂລກທີ່ແທ້ຈິງ, ມີສະຖານະການ Jesuitical ດັ່ງກ່າວໃນເວລາທີ່ຄວາມລົ້ມເຫຼວຂອງ Byzantine ເກີດຂຶ້ນ, ແລະຄົນຊົ່ວຮ້າຍພາຍໃນຂອບເຂດທີ່ຖືກປົກປ້ອງເລີ່ມຕົ້ນທີ່ຈະເຂົ້າໄປໃນພິທີການ, ສົ່ງຊຸດຫັດຖະກໍາດ້ວຍວິທີພິເສດບໍ?

MT: – ຄົນ​ຊົ່ວ​ຢູ່​ໃນ​ເຂດ​ອ້ອມ​ຂ້າງ​ຄື​ກັບ​ມ້າ Trojan! ຄົນຊົ່ວຢູ່ໃນບໍລິເວນອ້ອມຮອບສາມາດເຮັດສິ່ງທີ່ບໍ່ດີຫຼາຍ.

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

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

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

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

MT: "ຂ້ອຍບໍ່ເຄີຍໄດ້ຍິນເລື່ອງດັ່ງກ່າວ." ຄວາມຈິງທີ່ວ່າທ່ານສາມາດ crash server ໃນວິທີການນີ້ແມ່ນບໍ່ມີຄວາມລັບ. ລົ້ມເຫລວພາຍໃນ, ມາຈາກໂປໂຕຄອນ, ເປັນຜູ້ໃຊ້ທີ່ໄດ້ຮັບອະນຸຍາດທີ່ສາມາດຂຽນບາງສິ່ງບາງຢ່າງເຊັ່ນນີ້ໃນຂໍ້ຄວາມ ... ໃນຄວາມເປັນຈິງ, ມັນເປັນໄປບໍ່ໄດ້, ເພາະວ່າມັນຈະຍັງຖືກກວດສອບ. ມັນເປັນໄປໄດ້ທີ່ຈະປິດການພິສູດຢືນຢັນນີ້ສໍາລັບຜູ້ໃຊ້ທີ່ບໍ່ຕ້ອງການ - ແລ້ວນັ້ນແມ່ນບັນຫາຂອງພວກເຂົາ; ພວກເຂົາເຈົ້າ, ປະມານການເວົ້າ, ທໍາລາຍຝາດ້ວຍຕົນເອງແລະທ່ານສາມາດຍູ້ຊ້າງຢູ່ໃນນັ້ນ, ເຊິ່ງຈະ trampt ... ແຕ່ໂດຍທົ່ວໄປ, ທ່ານສາມາດແຕ່ງຕົວເປັນຊ່າງສ້ອມແປງ, ມາແລະດຶງມັນອອກ!

ໃນ: - ຂໍ​ຂອບ​ໃຈ​ສໍາ​ລັບ​ການ​ລາຍ​ງານ​. Sergey (Yandex). ມີຄວາມຄົງທີ່ໃນ Mong ທີ່ຈໍາກັດຈໍານວນສະມາຊິກລົງຄະແນນສຽງໃນຊຸດ Replica, ແລະຄົງທີ່ນີ້ແມ່ນ 7 (ເຈັດ). ເປັນຫຍັງອັນນີ້ຈຶ່ງເປັນຄົງທີ່? ເປັນຫຍັງຈຶ່ງບໍ່ແມ່ນຕົວກໍານົດການບາງປະເພດ?

MT: - ພວກ​ເຮົາ​ມີ Replica Sets ກັບ 40 nodes. ສະເຫມີມີສ່ວນໃຫຍ່. ບໍ່ຮູ້ວ່າລຸ້ນໃດ...

ໃນ: – ໃນ Replica Set ທ່ານສາມາດເອີ້ນໃຊ້ສະມາຊິກທີ່ບໍ່ໄດ້ລົງຄະແນນສຽງໄດ້, ແຕ່ມີສະມາຊິກທີ່ລົງຄະແນນສູງສຸດ 7 ຄົນ. ສູນຂໍ້ມູນຫນຶ່ງສາມາດປິດໄດ້ງ່າຍ, ແລະເຄື່ອງອື່ນສາມາດຕົກອອກໄດ້.

MT: – ອັນນີ້ແມ່ນເກີນຂອບເຂດຂອງບົດລາຍງານແລ້ວ. ນີ້ແມ່ນຄໍາຖາມທົ່ວໄປ. ບາງທີຂ້ອຍສາມາດບອກເຈົ້າກ່ຽວກັບມັນຕໍ່ມາ.

ບາງໂຄສະນາ🙂

ຂອບໃຈສໍາລັບການຢູ່ກັບພວກເຮົາ. ເຈົ້າມັກບົດຄວາມຂອງພວກເຮົາບໍ? ຕ້ອງການເບິ່ງເນື້ອຫາທີ່ຫນ້າສົນໃຈຫຼາຍບໍ? ສະຫນັບສະຫນູນພວກເຮົາໂດຍການວາງຄໍາສັ່ງຫຼືແນະນໍາໃຫ້ຫມູ່ເພື່ອນ, cloud VPS ສໍາລັບນັກພັດທະນາຈາກ $4.99, ການປຽບທຽບທີ່ເປັນເອກະລັກຂອງເຊີບເວີລະດັບເຂົ້າ, ເຊິ່ງຖືກປະດິດໂດຍພວກເຮົາສໍາລັບທ່ານ: ຄວາມຈິງທັງໝົດກ່ຽວກັບ VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps ຈາກ $19 ຫຼືວິທີການແບ່ງປັນເຄື່ອງແມ່ຂ່າຍ? (ສາມາດໃຊ້ໄດ້ກັບ RAID1 ແລະ RAID10, ສູງສຸດ 24 cores ແລະສູງສຸດ 40GB DDR4).

Dell R730xd 2x ລາຄາຖືກກວ່າຢູ່ໃນສູນຂໍ້ມູນ Equinix Tier IV ໃນ Amsterdam? ທີ່ນີ້ເທົ່ານັ້ນ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV ຈາກ $199 ໃນປະເທດເນເທີແລນ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ຈາກ $99! ອ່ານກ່ຽວກັບ ວິທີການສ້າງໂຄງສ້າງພື້ນຖານຂອງບໍລິສັດ. ຫ້ອງຮຽນທີ່ມີການນໍາໃຊ້ເຄື່ອງແມ່ຂ່າຍຂອງ Dell R730xd E5-2650 v4 ມູນຄ່າ 9000 ເອີໂຣສໍາລັບເງິນບໍ?

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