ການສໍາພາດ mini ກັບ Oleg Anastasyev: ຄວາມທົນທານຕໍ່ຄວາມຜິດພາດໃນ Apache Cassandra

Odnoklassniki ແມ່ນຜູ້ໃຊ້ທີ່ໃຫຍ່ທີ່ສຸດຂອງ Apache Cassandra ໃນ RuNet ແລະເປັນຫນຶ່ງໃນທີ່ໃຫຍ່ທີ່ສຸດໃນໂລກ. ພວກເຮົາໄດ້ເລີ່ມໃຊ້ Cassandra ໃນປີ 2010 ເພື່ອເກັບຮັກສາການຈັດອັນດັບຮູບພາບ, ແລະໃນປັດຈຸບັນ Cassandra ຈັດການຂໍ້ມູນ petabytes ຂອງຫລາຍພັນຂໍ້, ໃນຄວາມເປັນຈິງ, ພວກເຮົາກໍ່ພັດທະນາຂອງພວກເຮົາເອງ. ຖານຂໍ້ມູນການເຮັດທຸລະກໍາ NewSQL.
ໃນວັນທີ 12 ເດືອນກັນຍາໃນຫ້ອງການ St. Petersburg ຂອງພວກເຮົາພວກເຮົາຈະຈັດຂຶ້ນ ກອງປະຊຸມຄັ້ງທີສອງອຸທິດຕົນເພື່ອ Apache Cassandra. ລໍາໂພງຕົ້ນຕໍຂອງເຫດການຈະເປັນຫົວຫນ້າວິສະວະກອນຂອງ Odnoklassniki Oleg Anastasyev. Oleg ເປັນຜູ້ຊ່ຽວຊານໃນດ້ານລະບົບການແຈກຢາຍແລະຄວາມຜິດ, ລາວໄດ້ເຮັດວຽກກັບ Cassandra ຫຼາຍກວ່າ 10 ປີແລະຊ້ໍາຊ້ອນ. ເວົ້າກ່ຽວກັບຄຸນສົມບັດຂອງການນໍາໃຊ້ຜະລິດຕະພັນນີ້ຢູ່ໃນກອງປະຊຸມ.

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

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

- Oleg, ສະບາຍດີ! ໃນເດືອນພຶດສະພາໄດ້ຈັດຂຶ້ນ ການ​ພົບ​ປະ​ຄັ້ງ​ທໍາ​ອິດ​, ອຸທິດຕົນເພື່ອ Apache Cassandra, ຜູ້ເຂົ້າຮ່ວມເວົ້າວ່າການສົນທະນາໄດ້ດໍາເນີນໄປຈົນເຖິງຕອນກາງຄືນ, ກະລຸນາບອກຂ້າພະເຈົ້າ, ສິ່ງທີ່ທ່ານປະທັບໃຈຂອງການປະຊຸມຄັ້ງທໍາອິດ?

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

ຂ້ອຍສົນໃຈ ແລະມັກມັນແທ້ໆ.

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

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

— ເມື່ອ​ເວົ້າ​ເຖິງ Cassandra ເຈົ້າ​ໝາຍ​ຄວາມ​ວ່າ​ແນວ​ໃດ​ໂດຍ​ຄວາມ​ອົດ​ທົນ​ຕໍ່​ຄວາມ​ຜິດ?

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

— ເຈົ້າສາມາດຍົກຕົວຢ່າງຂອງກຸ່ມຂໍ້ມູນທີ່ໂຫຼດໄດ້ຫຼາຍທີ່ສຸດ ແລະໃຫຍ່ທີ່ສຸດໄດ້ບໍ?

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

- ວ້າວ! ບາງສິ່ງບາງຢ່າງແຕກເລື້ອຍໆເທົ່າໃດ?

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

— ເຈົ້າຈັດການກັບການປະຕິເສດດັ່ງກ່າວແນວໃດ?

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

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

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

— ເຈົ້າຄິດວ່າ Cassandra ຂາດຄວາມອົດທົນຕໍ່ຄວາມຜິດແນວໃດ?

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

Oleg, ຂໍຂອບໃຈທ່ານຫຼາຍສໍາລັບການໃຊ້ເວລາໃນການຕອບຄໍາຖາມ!

ພວກເຮົາລໍຖ້າທຸກຄົນທີ່ຕ້ອງການຕິດຕໍ່ສື່ສານກັບຜູ້ຊ່ຽວຊານໃນພາກສະຫນາມຂອງການປະຕິບັດງານ Apache Cassandra ໃນກອງປະຊຸມໃນວັນທີ 12 ເດືອນກັນຍາໃນຫ້ອງການ St. Petersburg ຂອງພວກເຮົາ.

ມາ, ມັນຈະຫນ້າສົນໃຈ!

ລົງທະບຽນສໍາລັບເຫດການ.

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