ສະຖາປັດຕະຍະກໍາການເອີ້ນເກັບເງິນຮຸ່ນໃຫມ່: ການຫັນປ່ຽນກັບການຫັນປ່ຽນໄປສູ່ Tarantool

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

Tarantool ເຮັດຫຍັງກັບມັນ? ພວກເຂົາຈະເວົ້າກ່ຽວກັບມັນ Oleg Ivlev и Andrey Knyazev. Oleg ເປັນຫົວຫນ້າສະຖາປະນິກຂອງບໍລິສັດ MegaFon ມີປະສົບການເຮັດວຽກຢູ່ໃນບໍລິສັດຕ່າງປະເທດ, Andrey ເປັນຜູ້ອໍານວຍການລະບົບທຸລະກິດ. ຈາກການຖອດຖອນບົດລາຍງານຂອງເຂົາເຈົ້າກ່ຽວກັບ ກອງປະຊຸມ Tarantool 2018 ທ່ານຈະໄດ້ຮຽນຮູ້ວ່າເປັນຫຍັງ R&D ແມ່ນຈໍາເປັນໃນບໍລິສັດ, Tarantool ແມ່ນຫຍັງ, ຄວາມບໍ່ສະຫງົບຂອງການປັບຂະຫນາດແລະໂລກາພິວັດໄດ້ກາຍເປັນເງື່ອນໄຂເບື້ອງຕົ້ນສໍາລັບການປະກົດຕົວຂອງຖານຂໍ້ມູນນີ້ໃນບໍລິສັດ, ກ່ຽວກັບສິ່ງທ້າທາຍດ້ານເຕັກໂນໂລຢີ, ການຫັນປ່ຽນສະຖາປັດຕະຍະກໍາ, ແລະວິທີການ technostack ຂອງ MegaFon ແມ່ນຄ້າຍຄືກັນກັບ Netflix. , Google ແລະ Amazon.

ໂຄງການ "ການເອີ້ນເກັບເງິນລວມ"

ໂຄງການທີ່ຕັ້ງຢູ່ໃນຄໍາຖາມແມ່ນເອີ້ນວ່າ "Unified Billing". ມັນຢູ່ທີ່ນີ້ທີ່ Tarantool ສະແດງໃຫ້ເຫັນຄຸນນະພາບທີ່ດີທີ່ສຸດຂອງມັນ.

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

MegaFon ແມ່ນແປດບໍລິສັດໃນຫນຶ່ງ. ໃນປີ 2009, ການຈັດຕັ້ງໃຫມ່ໄດ້ສໍາເລັດ: ສາຂາໃນທົ່ວລັດເຊຍໄດ້ລວມເຂົ້າເປັນບໍລິສັດດຽວ, MegaFon OJSC (ປະຈຸບັນ PJSC). ດັ່ງນັ້ນ, ບໍລິສັດມີ 8 ລະບົບການເອີ້ນເກັບເງິນດ້ວຍວິທີແກ້ໄຂ "ປັບແຕ່ງ" ຂອງຕົນເອງ, ລັກສະນະສາຂາແລະໂຄງສ້າງອົງການຈັດຕັ້ງທີ່ແຕກຕ່າງກັນ, ໄອທີແລະການຕະຫຼາດ.

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

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

ການປັບຂະໜາດຕາມແນວຕັ້ງ. ເຖິງແມ່ນວ່າຮາດແວທີ່ເຢັນທີ່ສຸດໃນເວລານັ້ນບໍ່ໄດ້ຕອບສະຫນອງຄວາມຕ້ອງການ. ວຽກງານດັ່ງກ່າວໄດ້ນໍາໃຊ້ອຸປະກອນ Hewlett-Packard ຈາກສາຍ Superdome Hi-End, ແຕ່ມັນບໍ່ຕອບສະຫນອງຄວາມຕ້ອງການຂອງເຖິງແມ່ນວ່າສອງສາຂາ. ຂ້າພະເຈົ້າຕ້ອງການການຂະຫຍາຍອອກຕາມລວງນອນໂດຍບໍ່ມີຄ່າໃຊ້ຈ່າຍໃນການດໍາເນີນງານຂະຫນາດໃຫຍ່ແລະການລົງທຶນທຶນ.

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

ສິ່ງທ້າທາຍດ້ານເຕັກໂນໂລຢີ

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

ຂະຫຍາຍໄດ້

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

ພວກ​ເຮົາ​ໄດ້​ກາຍ​ເປັນ​ການ​ປຽບ​ທຽບ​ໃນ​ຂະ​ຫນາດ​ກັບ​ຜູ້ນ​ອິນ​ເຕີ​ເນັດ​ຂະ​ຫນາດ​ໃຫຍ່​ເຊັ່ນ Mail.ru ຫຼື Netflix​.

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

ພູມສາດຂອງປະເທດທີ່ກວ້າງຂວາງຂອງພວກເຮົາ

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

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

ຄວາມ​ທົນ​ທານ​ຄວາມ​ຜິດ​ພາດ​

ນີ້ແມ່ນອີກດ້ານຫນຶ່ງຂອງການເປັນສູນກາງ.

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

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

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

ປະສົບການໂລກ

ເປັນເລື່ອງແປກທີ່, ພວກເຮົາບໍ່ໄດ້ພົບເຫັນການອ້າງອີງດຽວໃນໂທລະຄົມທົ່ວໂລກ.

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

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

ຂະ ໜາດ

ຕົວເລກຈໍານວນຫນ້ອຍສໍາລັບຕົວຢ່າງ.

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

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

2 ພັນລ້ານທຸລະກໍາ ຍອດເງິນມີການປ່ຽນແປງປະຈໍາວັນ - ເຫຼົ່ານີ້ແມ່ນການຈ່າຍເງິນ, ຄ່າບໍລິການ, ໂທແລະເຫດການອື່ນໆ. ຂໍ້ມູນ 200 TB ແມ່ນມີການປ່ຽນແປງຢ່າງຈິງຈັງ, ປ່ຽນແປງຊ້າລົງເລັກນ້ອຍ 8 PB ຂອງ​ຂໍ້​ມູນ​, ແລະນີ້ບໍ່ແມ່ນບ່ອນເກັບມ້ຽນ, ແຕ່ເປັນຂໍ້ມູນສົດໃນໃບບິນດຽວ. ຂະຫນາດໂດຍສູນຂໍ້ມູນ - 5 ພັນເຄື່ອງແມ່ຂ່າຍໃນ 14 ເວັບໄຊທ໌.

ເຕັກໂນໂລຍີ stack

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

stack ແມ່ນຄ້າຍຄືກັນກັບ stacks ຂອງຜູ້ນທີ່ສໍາຄັນອື່ນໆ: Netflix, Twitter, Viber. ມັນປະກອບດ້ວຍ 6 ອົງປະກອບ, ແຕ່ພວກເຮົາຕ້ອງການສັ້ນແລະເປັນເອກະພາບ.

ຄວາມຍືດຫຍຸ່ນແມ່ນດີ, ແຕ່ໃນບໍລິສັດຂະຫນາດໃຫຍ່ບໍ່ມີທາງທີ່ບໍ່ມີການລວມຕົວ.

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

ເປັນຫຍັງ Tarantool?

ມີ 4 ເງື່ອນໄຂງ່າຍໆວ່າເປັນຫຍັງພວກເຮົາເລືອກຖານຂໍ້ມູນນີ້.

ຄວາມໄວ. ພວກເຮົາໄດ້ດໍາເນີນການທົດສອບການໂຫຼດໃນລະບົບອຸດສາຫະກໍາ MegaFon. Tarantool ຊະນະ - ມັນສະແດງໃຫ້ເຫັນການປະຕິບັດທີ່ດີທີ່ສຸດ.

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

Tarantool ກວມເອົາຄວາມຕ້ອງການຂອງບໍລິສັດເຖິງແມ່ນວ່າໃນໄລຍະຍາວ.

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

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

ຄວາມ​ຫນ້າ​ເຊື່ອ​ຖື. MegaFon ລົງທຶນໃນຄວາມຫນ້າເຊື່ອຖື, ອາດຈະເປັນຫຼາຍກ່ວາຄົນອື່ນ. ດັ່ງນັ້ນ, ເມື່ອພວກເຮົາເບິ່ງ Tarantool, ພວກເຮົາຮູ້ວ່າພວກເຮົາຕ້ອງເຮັດໃຫ້ມັນຕອບສະຫນອງຄວາມຕ້ອງການຂອງພວກເຮົາ.

ພວກເຮົາໄດ້ລົງທຶນເວລາແລະການເງິນຂອງພວກເຮົາ, ແລະຮ່ວມກັນກັບ Mail.ru ພວກເຮົາສ້າງສະບັບວິສາຫະກິດ, ເຊິ່ງປະຈຸບັນຖືກນໍາໃຊ້ໃນບໍລິສັດອື່ນໆຈໍານວນຫນຶ່ງ.

Tarantool-enterprise ພໍໃຈພວກເຮົາຢ່າງສົມບູນໃນດ້ານຄວາມປອດໄພ, ຄວາມຫນ້າເຊື່ອຖື, ແລະການຕັດໄມ້.

ການຮ່ວມມື

ສິ່ງທີ່ສໍາຄັນທີ່ສຸດສໍາລັບຂ້ອຍແມ່ນ ການຕິດຕໍ່ໂດຍກົງກັບຜູ້ພັດທະນາ. ນີ້ແມ່ນສິ່ງທີ່ພວກຈາກ Tarantool ໃຫ້ສິນບົນ.

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

- ຕົກລົງ, ເອົາຂໍ້ກໍານົດໄວ້ຢູ່ລຸ່ມສຸດຂອງກອງນັ້ນ - ມື້ຫນຶ່ງ, ພວກເຮົາອາດຈະໄປຫາພວກເຂົາ.

ຫຼາຍໆຄົນມີແຜນທີ່ເສັ້ນທາງສໍາລັບ 2-3 ປີຂ້າງຫນ້າ, ແລະມັນເກືອບເປັນໄປບໍ່ໄດ້ທີ່ຈະປະສົມປະສານຢູ່ທີ່ນັ້ນ, ແຕ່ນັກພັດທະນາ Tarantool ຈັບໃຈກັບການເປີດກວ້າງຂອງພວກເຂົາ, ແລະບໍ່ພຽງແຕ່ຈາກ MegaFon, ແລະປັບລະບົບຂອງພວກເຂົາໃຫ້ກັບລູກຄ້າ. ມັນເຢັນແລະພວກເຮົາກໍ່ມັກມັນ.

ບ່ອນທີ່ພວກເຮົາໃຊ້ Tarantool

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

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

ຄໍາຮ້ອງສະຫມັກທີສອງແມ່ນຫົວຂໍ້ທີ່ມີທ່າອ່ຽງທີ່ເອີ້ນວ່າ IT ສອງຄວາມໄວ. ນີ້ແມ່ນຍ້ອນວ່າທີ່ປຶກສາຈາກທຸກໆມຸມກ່າວວ່າບໍລິສັດຄວນໄປບ່ອນນັ້ນ.

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

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

Microservices ບາງທີອາດເປັນບົດບາດຕົ້ນຕໍຂອງ Tarantool ຢູ່ MegaFon.

ບ່ອນທີ່ພວກເຮົາວາງແຜນທີ່ຈະໃຊ້ Tarantool

ຖ້າພວກເຮົາປຽບທຽບໂຄງການການເອີ້ນເກັບເງິນທີ່ປະສົບຜົນສໍາເລັດຂອງພວກເຮົາກັບໂຄງການການຫັນປ່ຽນທີ່ Deutsche Telekom, Svyazcom, Vodafone India, ມັນເປັນເລື່ອງແປກທີ່ເຄື່ອນໄຫວແລະສ້າງສັນ. ໃນຂະບວນການປະຕິບັດໂຄງການນີ້, ບໍ່ພຽງແຕ່ MegaFon ແລະໂຄງສ້າງຂອງມັນໄດ້ຖືກຫັນປ່ຽນ, ແຕ່ຍັງ Tarantool-enterprise ປາກົດຢູ່ Mail.ru, ແລະຜູ້ຂາຍຂອງພວກເຮົາ Nexign (ອະດີດ Peter-Service) - BSS Box (ການແກ້ໄຂການເອີ້ນເກັບເງິນໃນກ່ອງ).

ນີ້ແມ່ນ, ໃນຄວາມຫມາຍ, ໂຄງການປະຫວັດສາດສໍາລັບຕະຫຼາດລັດເຊຍ. ມັນ​ສາ​ມາດ​ປຽບ​ທຽບ​ກັບ​ສິ່ງ​ທີ່​ໄດ້​ອະ​ທິ​ບາຍ​ໃນ​ຫນັງ​ສື "Mythical Man-Month​" ໂດຍ Frederick Brooks​. ຫຼັງຈາກນັ້ນ, ໃນຊຸມປີ 60, IBM ໄດ້ຈ້າງ 360 ຄົນເພື່ອພັດທະນາລະບົບປະຕິບັດການ OS / 5 ໃຫມ່ສໍາລັບ mainframes. ພວກເຮົາມີຫນ້ອຍ - 000, ແຕ່ຂອງພວກເຮົາແມ່ນຢູ່ໃນ vests, ແລະຄໍານຶງເຖິງການນໍາໃຊ້ແຫຼ່ງເປີດແລະວິທີການໃຫມ່, ພວກເຮົາເຮັດວຽກຫຼາຍ.

ຂ້າງລຸ່ມນີ້ແມ່ນໂດເມນຂອງໃບບິນຫຼື, ເວົ້າຢ່າງກວ້າງຂວາງກວ່າ, ລະບົບທຸລະກິດ. ຄົນຈາກວິສາຫະກິດຮູ້ຈັກ CRM ເປັນຢ່າງດີ. ທຸກໆຄົນຄວນມີລະບົບອື່ນຢູ່ແລ້ວ: API ເປີດ, API Gateway.

ເປີດ API

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

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

CRM

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

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

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

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

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

ຮູບທີ່ຜ່ານມາແມ່ນໂດເມນທີ່ພວກເຮົາຈະໃຊ້ Tarantool. CRM ຕົວຂອງມັນເອງ, ແນ່ນອນ, ແມ່ນກວ້າງກວ່າແລະພວກເຮົາຈະໃຊ້ມັນຢູ່ໃນຫຼັກຂອງມັນເອງ.

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

ໂດຍທົ່ວໄປ, ມີສອງວິທີການນໍາໃຊ້ Tarantool. ຫນ້າທໍາອິດ - ສ້າງຖານຄວາມຈໍາທັງຫມົດໃນລະດັບ microservice. ເທົ່າທີ່ຂ້າພະເຈົ້າເຂົ້າໃຈ, VimpelCom ກໍາລັງປະຕິບັດຕາມເສັ້ນທາງນີ້, ການສ້າງຖານຄວາມຈໍາຂອງລູກຄ້າ.

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

ວິທີນີ້ມີການ synchronization ຫນ້ອຍ - ລະບົບຫນຶ່ງແມ່ນຮັບຜິດຊອບສໍາລັບທັງ cache ແລະຕົ້ນສະບັບຕົ້ນຕໍ.

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

RTO ແລະ RPO

ມີສອງເງື່ອນໄຂໃນ IT - OTR и RPO.

ເປົ້າໝາຍເວລາຟື້ນຟູ ແມ່ນເວລາທີ່ມັນໃຊ້ເວລາເພື່ອຟື້ນຟູການບໍລິການຫຼັງຈາກຄວາມລົ້ມເຫລວ. RTO = 0 ຫມາຍຄວາມວ່າເຖິງແມ່ນວ່າບາງສິ່ງບາງຢ່າງລົ້ມເຫລວ, ການບໍລິການຍັງສືບຕໍ່ເຮັດວຽກ.

ຈຸດ​ປະ​ສົງ​ການ​ຟື້ນ​ຕົວ​ - ນີ້ແມ່ນເວລາການຟື້ນຕົວຂໍ້ມູນ, ຂໍ້ມູນຫຼາຍປານໃດທີ່ພວກເຮົາສາມາດສູນເສຍໃນໄລຍະເວລາທີ່ແນ່ນອນ. RPO = 0 ຫມາຍຄວາມວ່າພວກເຮົາບໍ່ໄດ້ສູນເສຍຂໍ້ມູນ.

ວຽກງານ Tarantool

ໃຫ້ພະຍາຍາມແກ້ໄຂບັນຫາສໍາລັບ Tarantool.

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

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

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

ການແກ້ໄຂຂອງພວກເຮົາ: ການສ້າງການລົງທະບຽນທີ່ແຈກຢາຍຂອງແອັບພລິເຄຊັນໃນ Tarantool - a geo-distributed cluster. ໃນແຜນວາດ, ເຫຼົ່ານີ້ແມ່ນສາມສູນປະມວນຜົນຂໍ້ມູນທີ່ແຕກຕ່າງກັນ - ສອງກ່ອນ Urals, ຫນຶ່ງເກີນ Urals, ແລະພວກເຮົາແຈກຢາຍການຮ້ອງຂໍທັງຫມົດໃນບັນດາສູນເຫຼົ່ານີ້.

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

ໃນເບື້ອງຕົ້ນພວກເຮົາກໍາລັງສ້າງການແກ້ໄຂການແຈກຢາຍທາງພູມສາດ - ຄວາມທົນທານຕໍ່ຄວາມຜິດພາດແມ່ນສໍາຄັນຕໍ່ພວກເຮົາ.

ດັ່ງນັ້ນພວກເຮົາມີກຸ່ມ, ແຕ່ສິ່ງທີ່ກ່ຽວກັບ RPO = 0 ແລະ RTO = 0? ການແກ້ໄຂແມ່ນງ່າຍດາຍ, ຂຶ້ນກັບຫົວຂໍ້.

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

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

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

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

Cassandra ແລະ Tarantool ຮ່ວມກັນ

ມີ​ກໍ​ລະ​ນີ​ອື່ນ - "ການສະແດງຍອດເງິນ". ນີ້ແມ່ນກໍລະນີທີ່ຫນ້າສົນໃຈຂອງການນໍາໃຊ້ຮ່ວມກັນຂອງ Cassandra ແລະ Tarantool.

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

Cassandra ຊ່ວຍໃຫ້ທ່ານສາມາດປັບຂະຫນາດຕາມແນວນອນກັບຂະຫນາດໃດກໍ່ຕາມ.

ພວກເຮົາຮູ້ສຶກສະດວກສະບາຍກັບ Cassandra, ແຕ່ມັນມີບັນຫາຫນຶ່ງ - ມັນບໍ່ດີໃນການອ່ານ. ທຸກຢ່າງແມ່ນ OK ໃນການບັນທຶກ, 30 ຕໍ່ວິນາທີບໍ່ແມ່ນບັນຫາ - ບັນຫາການອ່ານ.

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

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

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

ສະຫລຸບ

ເຫຼົ່ານີ້ແມ່ນຕົວຢ່າງຂອງການນໍາໃຊ້ Tarantool. ພວກເຮົາມັກການເປີດກວ້າງຂອງ Mail.ru ແລະຄວາມເຕັມໃຈທີ່ຈະພິຈາລະນາກໍລະນີຕ່າງໆ.

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

ບົດລາຍງານຂອງ Oleg ແລະ Andrey ແມ່ນຫນຶ່ງໃນທີ່ດີທີ່ສຸດໃນກອງປະຊຸມ Tarantool ປີທີ່ຜ່ານມາ, ແລະໃນວັນທີ 17 ເດືອນມິຖຸນາ Oleg Ivlev ຈະເວົ້າຢູ່ທີ່ ກອງປະຊຸມ T+ 2019 ກັບບົດລາຍງານ "ເປັນຫຍັງ Tarantool ໃນວິສາຫະກິດ". Alexander Deulin ຍັງຈະໃຫ້ການນໍາສະເຫນີຈາກ MegaFon "Tarantool Caches ແລະ Replication ຈາກ Oracle". ຂໍໃຫ້ຊອກຫາສິ່ງທີ່ມີການປ່ຽນແປງ, ແຜນການໃດໄດ້ຖືກປະຕິບັດ. ເຂົ້າຮ່ວມ - ກອງປະຊຸມແມ່ນບໍ່ເສຍຄ່າ, ສິ່ງທີ່ທ່ານຕ້ອງເຮັດແມ່ນ ລົງທະບຽນ... ທັງ ໝົດ ຍອມຮັບບົດລາຍງານ ແລະໂຄງການກອງປະຊຸມໄດ້ຖືກສ້າງຕັ້ງຂຶ້ນ: ກໍລະນີໃຫມ່, ປະສົບການໃຫມ່ໃນການນໍາໃຊ້ Tarantool, ຖາປັດຕະຍະ, ວິສາຫະກິດ, tutorials ແລະ microservices.

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