ວິທີການເບິ່ງເຂົ້າໄປໃນຕາຂອງ Cassandra ໂດຍບໍ່ມີການສູນເສຍຂໍ້ມູນ, ຄວາມຫມັ້ນຄົງແລະຄວາມເຊື່ອໃນ NoSQL

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

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

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

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

ດັ່ງນັ້ນ, ນີ້ແມ່ນສິ່ງທີ່ປະສົບການໃຫ້ພວກເຮົາ

ແມ່ນແລ້ວ, node ລົ້ມເຫລວບໍ່ແມ່ນຄວາມໂສກເສົ້າ. ນີ້ແມ່ນຄວາມສໍາຄັນຂອງຄວາມທົນທານຕໍ່ຄວາມຜິດຂອງ Cassandra. ແຕ່ node ສາມາດມີຊີວິດຢູ່ແລະໃນເວລາດຽວກັນເລີ່ມທົນທຸກໃນການປະຕິບັດ. ຍ້ອນວ່າມັນຫັນອອກ, ນີ້ທັນທີຜົນກະທົບຕໍ່ການປະຕິບັດຂອງກຸ່ມທັງຫມົດ.

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

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

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

ພວກເຮົາປະສົບບັນຫາໃນການໂອນຂໍ້ມູນໄປຫາເຂດທົດສອບ (5 ຂໍ້ໃນການທົດສອບທຽບກັບ 20 ໃນ prom). ໃນກໍລະນີນີ້, ການຖິ້ມຂີ້ເຫຍື້ອບໍ່ສາມາດໃຊ້ໄດ້.

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

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

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

ພວກເຮົາຕັດສິນໃຈແນວໃດ

ເພື່ອປ້ອງກັນບໍ່ໃຫ້ node ຈົມລົງ, SWAP ໄດ້ຖືກປິດໃຊ້ງານ. ແລະໃນປັດຈຸບັນ, ຖ້າຂາດຄວາມຈໍາ, node ຄວນຈະລົງແລະບໍ່ສ້າງການຢຸດ gc ຂະຫນາດໃຫຍ່.

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

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

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

ພວກເຮົາພິຈາລະນາສອງທາງເລືອກ. ໃນທາງເລືອກທໍາອິດ, ພວກເຮົາຂຽນການໂທບໍ່ພຽງແຕ່ຢູ່ໃນ C*, ແຕ່ຍັງຢູ່ໃນຖານຂໍ້ມູນ Oracle ທີ່ເກັບໄວ້. ພຽງແຕ່, ບໍ່ເຫມືອນກັບ C*, ຖານຂໍ້ມູນນີ້ເກັບຮັກສາການໂທພຽງແຕ່ສໍາລັບເດືອນປະຈຸບັນ (ຄວາມເລິກການເກັບຮັກສາການໂທພຽງພໍສໍາລັບກໍລະນີການສາກໄຟ). ໃນທີ່ນີ້ພວກເຮົາເຫັນບັນຫາຕໍ່ໄປນີ້ທັນທີ: ຖ້າພວກເຮົາຂຽນ synchronously, ພວກເຮົາຈະສູນເສຍຂໍ້ດີທັງຫມົດຂອງ C * ທີ່ກ່ຽວຂ້ອງກັບການແຊກໄວ; ຖ້າພວກເຮົາຂຽນ asynchronously, ບໍ່ມີການຮັບປະກັນວ່າການໂທທີ່ຈໍາເປັນທັງຫມົດເຂົ້າໄປໃນ Oracle ທັງຫມົດ. ມີຫນຶ່ງບວກ, ແຕ່ຂະຫນາດໃຫຍ່ຫນຶ່ງ: ສໍາລັບການດໍາເນີນງານ, ນັກພັດທະນາ PL / SQL ທີ່ຄຸ້ນເຄີຍຄືກັນ, i.e. ພວກເຮົາປະຕິບັດຮູບແບບ "Facade". ພວກເຮົາປະຕິບັດກົນໄກທີ່ unloads ການໂທຈາກ C *, ດຶງຂໍ້ມູນບາງຢ່າງສໍາລັບການເສີມສ້າງຈາກຕາຕະລາງທີ່ສອດຄ້ອງກັນໃນ Oracle, ເຂົ້າຮ່ວມກັບຕົວຢ່າງຜົນໄດ້ຮັບແລະໃຫ້ພວກເຮົາຜົນໄດ້ຮັບ, ເຊິ່ງພວກເຮົາຈະໃຊ້ບາງຢ່າງ (ມ້ວນຄືນ, ເຮັດຊ້ໍາ, ວິເຄາະ, ຊົມເຊີຍ). Cons: ຂະບວນການແມ່ນຂ້ອນຂ້າງຫຼາຍຂັ້ນຕອນ, ແລະນອກຈາກນັ້ນ, ບໍ່ມີການໂຕ້ຕອບສໍາລັບພະນັກງານປະຕິບັດງານ.

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

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

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

ເພື່ອຮັບປະກັນການມີ Cassandra ຢ່າງຕໍ່ເນື່ອງ, ທ່ານຕ້ອງການ dba ແລະບໍ່ພຽງແຕ່ລາວເທົ່ານັ້ນ. ທຸກໆຄົນທີ່ເຮັດວຽກກັບແອັບພລິເຄຊັນຕ້ອງເຂົ້າໃຈບ່ອນແລະວິທີການເບິ່ງສະຖານະການໃນປະຈຸບັນແລະວິທີການວິນິດໄສບັນຫາຢ່າງທັນເວລາ. ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາໃຊ້ DataStax OpsCenter ຢ່າງຈິງຈັງ (ການບໍລິຫານແລະການຕິດຕາມການໂຫຼດຂອງວຽກ), ຕົວຊີ້ວັດລະບົບ Cassandra Driver (ຈໍານວນເວລາຫມົດເວລາສໍາລັບການຂຽນເຖິງ C*, ຈໍານວນເວລາຫມົດເວລາສໍາລັບການອ່ານຈາກ C*, latency ສູງສຸດ, ແລະອື່ນໆ), ຕິດຕາມກວດກາການດໍາເນີນງານ. ຄໍາຮ້ອງສະຫມັກຂອງມັນເອງ, ເຮັດວຽກຮ່ວມກັບ Cassandra.

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

ດັ່ງນັ້ນ, ສໍາລັບໃນປັດຈຸບັນ ຢຸດຢູ່ໃນລະດັບຄວາມສອດຄ່ອງສໍາລັບການຂຽນ EACH_QUORUM, ສໍາລັບການອ່ານ - LOCAL_QUORUM

ຄວາມປະທັບໃຈສັ້ນໆ ແລະບົດສະຫຼຸບ

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

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

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

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

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

ສໍາລັບຕົວຢ່າງ, ຕິດຕາມການອັບເດດຂອງ Cassandra ໃຫ້ທັນເວລາເພາະ​ວ່າ​ບາງ​ບັນ​ຫາ​ທີ່​ພວກ​ເຮົາ​ໄດ້​ຮັບ​ແມ່ນ​ແລ້ວ​ຮູ້​ຈັກ​ແລະ​ການ​ແກ້​ໄຂ​.

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

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

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

ບໍ່ແມ່ນສິ່ງທີ່ບໍ່ດີ ທັນທີສະຫນອງການຄັດຕິດ TTL ແລະທໍາຄວາມສະອາດຂໍ້ມູນລ້າສະໄຫມ.

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

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

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

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

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