ການຈໍາລອງລະດັບສູງໃນ Tarantool DBMS

ສະບາຍດີ, ຂ້ອຍກໍາລັງສ້າງແອັບພລິເຄຊັນສໍາລັບ DBMS Tarantool ເປັນແພລະຕະຟອມທີ່ພັດທະນາໂດຍກຸ່ມ Mail.ru ທີ່ປະສົມປະສານ DBMS ທີ່ມີປະສິດທິພາບສູງແລະແອັບພລິເຄຊັນເຊີຟເວີໃນພາສາ Lua. ຄວາມໄວສູງຂອງການແກ້ໄຂໂດຍອີງໃສ່ Tarantool ແມ່ນບັນລຸໄດ້, ໂດຍສະເພາະ, ເນື່ອງຈາກການສະຫນັບສະຫນູນຮູບແບບໃນຫນ່ວຍຄວາມຈໍາຂອງ DBMS ແລະຄວາມສາມາດໃນການປະຕິບັດເຫດຜົນທາງທຸລະກິດຂອງແອັບພລິເຄຊັນໃນພື້ນທີ່ທີ່ຢູ່ດຽວກັບຂໍ້ມູນ. ໃນເວລາດຽວກັນ, ຂໍ້ມູນຄົງຄ້າງຖືກຮັບປະກັນໂດຍໃຊ້ການເຮັດທຸລະກໍາ ACID (ບັນທຶກ WAL ຖືກຮັກສາໄວ້ໃນແຜ່ນ). Tarantool ມີການສະຫນັບສະຫນູນໃນຕົວສໍາລັບການຈໍາລອງແລະ sharding. ເລີ່ມຈາກເວີຊັ່ນ 2.1, ການສອບຖາມໃນພາສາ SQL ແມ່ນຮອງຮັບ. Tarantool ແມ່ນແຫຼ່ງເປີດແລະໄດ້ຮັບອະນຸຍາດພາຍໃຕ້ໃບອະນຸຍາດ BSD ແບບງ່າຍ. ນອກຈາກນີ້ຍັງມີສະບັບວິສາຫະກິດການຄ້າ.

ຮູ້​ສຶກ​ວ່າ​ພະ​ລັງ​ງານ​! (…aka ມີ​ຄວາມ​ສຸກ​ກັບ​ການ​ສະ​ແດງ​)

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

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

ເຂົ້າ. 1. ການຈຳລອງພາຍໃນກຸ່ມ

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

1. ປະຫຍັດການຈະລາຈອນ:

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

2. ບໍ່ມີຄວາມຫຍຸ້ງຍາກໃນການປະຕິບັດການແລກປ່ຽນ HTTP, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດ synchronize ຖານຂໍ້ມູນຫ່າງໄກສອກຫຼີກ.

ເຂົ້າ. 2. Replication over HTTP

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

ເຂົ້າ. 3. ການຈໍາລອງໃນລະບົບ heterogeneous

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

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

ການຫຼຸດຜ່ອນການຈະລາຈອນ

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

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

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

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

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

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

ການຖ່າຍທອດຂໍ້ມູນໂດຍໃຊ້ຕົວນັບລຸ້ນແຖວ

ການປະຕິບັດຂອງເຄື່ອງແມ່ຂ່າຍ / ຕົ້ນສະບັບ

ໃນ MS SQL Server, ມີປະເພດຄໍລໍາພິເສດເພື່ອປະຕິບັດວິທີການນີ້ - rowversion. ແຕ່ລະຖານຂໍ້ມູນມີຕົວນັບທີ່ເພີ່ມຂຶ້ນແຕ່ລະຄັ້ງທີ່ບັນທຶກຖືກເພີ່ມ / ປ່ຽນແປງໃນຕາຕະລາງທີ່ມີຖັນຄ້າຍຄື rowversion. ຄ່າຂອງຕົວນັບນີ້ຈະຖືກມອບໃຫ້ໂດຍອັດຕະໂນມັດໃສ່ຊ່ອງຂໍ້ມູນຂອງຖັນນີ້ໃນບັນທຶກທີ່ເພີ່ມ/ປ່ຽນແປງ. Tarantool DBMS ບໍ່ມີກົນໄກການກໍ່ສ້າງທີ່ຄ້າຍຄືກັນ. ຢ່າງໃດກໍຕາມ, ໃນ Tarantool ມັນບໍ່ຍາກທີ່ຈະປະຕິບັດມັນດ້ວຍຕົນເອງ. ໃຫ້ເບິ່ງວິທີການນີ້ແມ່ນເຮັດໄດ້.

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

ກ່ອນທີ່ຈະດໍາເນີນການຖານຂໍ້ມູນໃດໆໃນ Tarantool, ທ່ານຈໍາເປັນຕ້ອງດໍາເນີນການຄໍາສັ່ງຕໍ່ໄປນີ້:

box.cfg{}

ດັ່ງນັ້ນ, Tarantool ຈະເລີ່ມຂຽນບັນທຶກຖານຂໍ້ມູນແລະບັນທຶກການເຮັດທຸລະກໍາກັບໄດເລກະທໍລີປະຈຸບັນ.

ໃຫ້ສ້າງລໍາດັບ row_version:

box.schema.sequence.create('row_version',
    { if_not_exists = true })

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

ໃຫ້ສ້າງພື້ນທີ່ເປັນຕົວຢ່າງ.

box.schema.space.create('goods', {
    format = {
        {
            name = 'id',
            type = 'unsigned'

        },
        {
            name = 'name',
            type = 'string'

        },
        {
            name = 'code',
            type = 'unsigned'

        },
        {
            name = 'row_ver',
            type = 'unsigned'

        }
    },
    if_not_exists = true
})

ທີ່ນີ້ພວກເຮົາຕັ້ງຊື່ຂອງຊ່ອງ (goods), ຊື່ພາກສະຫນາມແລະປະເພດຂອງເຂົາເຈົ້າ.

ຊ່ອງຂໍ້ມູນການເພີ່ມອັດຕະໂນມັດໃນ Tarantool ກໍ່ຖືກສ້າງໂດຍໃຊ້ລໍາດັບ. ມາສ້າງລະຫັດຫຼັກທີ່ເພີ່ມອັດຕະໂນມັດຕາມຊ່ອງຂໍ້ມູນ id:

box.schema.sequence.create('goods_id',
    { if_not_exists = true })
box.space.goods:create_index('primary', {
    parts = { 'id' },
    sequence = 'goods_id',
    unique = true,
    type = 'HASH',
    if_not_exists = true
})

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

ເພື່ອໃຊ້ຖັນ row_ver ເພື່ອ​ໂອນ​ຂໍ້​ມູນ​ການ​ປ່ຽນ​ແປງ​, ທ່ານ​ຈໍາ​ເປັນ​ຕ້ອງ​ໄດ້​ຜູກ​ມັດ​ຄ່າ​ລໍາ​ດັບ​ກັບ​ພາກ​ສະ​ຫນາມ​ຂອງ​ຖັນ​ນີ້​ row_ver. ແຕ່ບໍ່ຄືກັບກະແຈຫຼັກ, ຄ່າຊ່ອງຖັນ row_ver ຄວນເພີ່ມຂຶ້ນໂດຍຫນຶ່ງບໍ່ພຽງແຕ່ໃນເວລາທີ່ເພີ່ມບັນທຶກໃຫມ່, ແຕ່ຍັງໃນເວລາທີ່ການປ່ຽນແປງທີ່ມີຢູ່ແລ້ວ. ທ່ານສາມາດໃຊ້ຕົວກະຕຸ້ນສໍາລັບການນີ້. Tarantool ມີສອງປະເພດຂອງການກະຕຸ້ນຊ່ອງ: before_replace и on_replace. Triggers ຖືກຍິງທຸກຄັ້ງທີ່ຂໍ້ມູນໃນຊ່ອງມີການປ່ຽນແປງ (ສໍາລັບແຕ່ລະ tuple ທີ່ໄດ້ຮັບຜົນກະທົບຈາກການປ່ຽນແປງ, ຟັງຊັນ trigger ຖືກເປີດຕົວ). ບໍ່​ມັກ on_replace, before_replace-triggers ອະ​ນຸ​ຍາດ​ໃຫ້​ທ່ານ​ເພື່ອ​ປັບ​ປຸງ​ແກ້​ໄຂ​ຂໍ້​ມູນ​ຂອງ tuple ສໍາ​ລັບ​ການ​ທີ່ trigger ໄດ້​ຖືກ​ປະ​ຕິ​ບັດ​. ດັ່ງນັ້ນ, ປະເພດສຸດທ້າຍຂອງຜົນກະທົບຕໍ່ພວກເຮົາ.

box.space.goods:before_replace(function(old, new)
    return box.tuple.new({new[1], new[2], new[3],
        box.sequence.row_version:next()})
end)

ຕົວກະຕຸ້ນຕໍ່ໄປນີ້ແທນຄ່າຊ່ອງຂໍ້ມູນ row_ver tuple ເກັບໄວ້ເປັນມູນຄ່າຕໍ່ໄປຂອງລໍາດັບ row_version.

ເພື່ອໃຫ້ສາມາດສະກັດຂໍ້ມູນຈາກອາວະກາດ goods ໂດຍຖັນ row_ver, ໃຫ້ເຮົາສ້າງດັດສະນີ:

box.space.goods:create_index('row_ver', {
    parts = { 'row_ver' },
    unique = true,
    type = 'TREE',
    if_not_exists = true
})

ປະເພດດັດຊະນີ - ຕົ້ນໄມ້ (TREE), ເນື່ອງຈາກວ່າ ພວກເຮົາຈະຕ້ອງການສະກັດຂໍ້ມູນໃນລໍາດັບຕັ້ງຊັນຂຶ້ນຂອງຄ່າໃນຖັນ row_ver.

ມາເພີ່ມຂໍ້ມູນໃສ່ຊ່ອງຫວ່າງ:

box.space.goods:insert{nil, 'pen', 123}
box.space.goods:insert{nil, 'pencil', 321}
box.space.goods:insert{nil, 'brush', 100}
box.space.goods:insert{nil, 'watercolour', 456}
box.space.goods:insert{nil, 'album', 101}
box.space.goods:insert{nil, 'notebook', 800}
box.space.goods:insert{nil, 'rubber', 531}
box.space.goods:insert{nil, 'ruler', 135}

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

ມາກວດເບິ່ງຜົນການແຊກ:

tarantool> box.space.goods:select()
---
- - [1, 'pen', 123, 1]
  - [2, 'pencil', 321, 2]
  - [3, 'brush', 100, 3]
  - [4, 'watercolour', 456, 4]
  - [5, 'album', 101, 5]
  - [6, 'notebook', 800, 6]
  - [7, 'rubber', 531, 7]
  - [8, 'ruler', 135, 8]
...

ດັ່ງທີ່ທ່ານສາມາດເຫັນໄດ້, ຊ່ອງທໍາອິດແລະສຸດທ້າຍແມ່ນຕື່ມໃສ່ໂດຍອັດຕະໂນມັດ. ໃນປັດຈຸບັນມັນຈະງ່າຍຕໍ່ການຂຽນຫນ້າທີ່ສໍາລັບການອັບໂຫລດຫນ້າຕໍ່ຫນ້າຂອງການປ່ຽນແປງພື້ນທີ່ goods:

local page_size = 5
local function get_goods(row_ver)
    local index = box.space.goods.index.row_ver
    local goods = {}
    local counter = 0
    for _, tuple in index:pairs(row_ver, {
        iterator = 'GT' }) do
        local obj = tuple:tomap({ names_only = true })
        table.insert(goods, obj)
        counter = counter + 1
        if counter >= page_size then
            break
        end
    end
    return goods
end

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

ການເກັບຕົວຢ່າງຂໍ້ມູນໃນ Tarantool ແມ່ນເຮັດຜ່ານດັດສະນີ. ຟັງຊັນ get_goods ໃຊ້ iterator ໂດຍດັດສະນີ row_ver ເພື່ອຮັບຂໍ້ມູນການປ່ຽນແປງ. ປະເພດ Iterator ແມ່ນ GT (ໃຫຍ່ກວ່າ, ໃຫຍ່ກວ່າ). ນີ້ຫມາຍຄວາມວ່າ iterator ຈະຕາມລໍາດັບ traverse ຄ່າດັດຊະນີເລີ່ມຕົ້ນຈາກລະຫັດຜ່ານ (ຄ່າພາກສະຫນາມ. row_ver).

iterator ສົ່ງຄືນ tuples. ເພື່ອໃຫ້ສາມາດໂອນຂໍ້ມູນຜ່ານ HTTP ໄດ້, ມັນ ຈຳ ເປັນຕ້ອງປ່ຽນ tuples ໄປສູ່ໂຄງສ້າງທີ່ສະດວກຕໍ່ການ serialization ຕໍ່ມາ. ຕົວຢ່າງໃຊ້ຟັງຊັນມາດຕະຖານສໍາລັບການນີ້ tomap. ແທນທີ່ຈະໃຊ້ tomap ທ່ານສາມາດຂຽນຫນ້າທີ່ຂອງທ່ານເອງ. ຕົວຢ່າງ, ພວກເຮົາອາດຈະຕ້ອງການປ່ຽນຊື່ຊ່ອງຂໍ້ມູນ name, ບໍ່ຜ່ານພາກສະຫນາມ code ແລະເພີ່ມພາກສະຫນາມ comment:

local function unflatten_goods(tuple)
    local obj = {}
    obj.id = tuple.id
    obj.goods_name = tuple.name
    obj.comment = 'some comment'
    obj.row_ver = tuple.row_ver
    return obj
end

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

ໃຫ້ປະຕິບັດຫນ້າທີ່ get_goods:

tarantool> get_goods(0)

---
- - row_ver: 1
    code: 123
    name: pen
    id: 1
  - row_ver: 2
    code: 321
    name: pencil
    id: 2
  - row_ver: 3
    code: 100
    name: brush
    id: 3
  - row_ver: 4
    code: 456
    name: watercolour
    id: 4
  - row_ver: 5
    code: 101
    name: album
    id: 5
...

ໃຫ້ເອົາຄ່າພາກສະຫນາມ row_ver ຈາກແຖວສຸດທ້າຍແລະໂທຫາຟັງຊັນອີກເທື່ອຫນຶ່ງ:

tarantool> get_goods(5)

---
- - row_ver: 6
    code: 800
    name: notebook
    id: 6
  - row_ver: 7
    code: 531
    name: rubber
    id: 7
  - row_ver: 8
    code: 135
    name: ruler
    id: 8
...

ອີກ​ເທື່ອ​ຫນຶ່ງ:

tarantool> get_goods(8)
---
- []
...

ດັ່ງທີ່ເຈົ້າສາມາດເຫັນໄດ້, ເມື່ອໃຊ້ວິທີນີ້, ຟັງຊັນຈະສົ່ງຄືນບັນທຶກພື້ນທີ່ທັງຫມົດໂດຍຫນ້າ goods. ໜ້າສຸດທ້າຍແມ່ນຕິດຕາມດ້ວຍການເລືອກທີ່ຫວ່າງເປົ່າ.

ຂໍໃຫ້ປ່ຽນແປງພື້ນທີ່:

box.space.goods:update(4, {{'=', 6, 'copybook'}})
box.space.goods:insert{nil, 'clip', 234}
box.space.goods:insert{nil, 'folder', 432}

ພວກເຮົາໄດ້ປ່ຽນຄ່າພາກສະຫນາມ name ສໍາລັບການເຂົ້າຫນຶ່ງແລະເພີ່ມສອງລາຍການໃຫມ່.

ໃຫ້ເຮັດຊ້ຳການເອີ້ນຟັງຊັນສຸດທ້າຍ:

tarantool> get_goods(8)
---



- - row_ver: 9
    code: 800
    name: copybook
    id: 6
  - row_ver: 10
    code: 234
    name: clip
    id: 9
  - row_ver: 11
    code: 432
    name: folder
    id: 10
...

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

ພວກເຮົາຈະອອກຈາກການອອກຜົນໄດ້ຮັບຜ່ານ HTTP ໃນຮູບແບບຂອງ JSON ຢູ່ນອກຂອບເຂດຂອງບົດຄວາມນີ້. ທ່ານສາມາດອ່ານກ່ຽວກັບເລື່ອງນີ້ໄດ້ທີ່ນີ້: https://habr.com/ru/company/mailru/blog/272141/

ການຈັດຕັ້ງປະຕິບັດສ່ວນລູກຄ້າ/ທາດ

ຂໍໃຫ້ພິຈາລະນາເບິ່ງວ່າການປະຕິບັດຂອງຝ່າຍຮັບເປັນແນວໃດ. ໃຫ້ສ້າງພື້ນທີ່ຢູ່ໃນດ້ານການຮັບເພື່ອເກັບຮັກສາຂໍ້ມູນທີ່ດາວໂຫລດມາ:

box.schema.space.create('goods', {
    format = {
        {
            name = 'id',
            type = 'unsigned'

        },
        {
            name = 'name',
            type = 'string'

        },
        {
            name = 'code',
            type = 'unsigned'

        }
    },
    if_not_exists = true
})

box.space.goods:create_index('primary', {
    parts = { 'id' },
    sequence = 'goods_id',
    unique = true,
    type = 'HASH',
    if_not_exists = true
})

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

ນອກຈາກນັ້ນ, ພວກເຮົາຕ້ອງການພື້ນທີ່ເພື່ອຊ່ວຍປະຢັດມູນຄ່າ row_ver:

box.schema.space.create('row_ver', {
    format = {
        {
            name = 'space_name',
            type = 'string'

        },
        {
            name = 'value',
            type = 'string'

        }
    },
    if_not_exists = true
})

box.space.row_ver:create_index('primary', {
    parts = { 'space_name' },
    unique = true,
    type = 'HASH',
    if_not_exists = true
})

ສໍາລັບແຕ່ລະພື້ນທີ່ໂຫຼດ (ພາກສະຫນາມ space_name) ພວກເຮົາຈະບັນທຶກຄ່າທີ່ໂຫລດຫຼ້າສຸດຢູ່ທີ່ນີ້ row_ver (ພາກສະຫນາມ value). ຖັນເຮັດໜ້າທີ່ເປັນກະແຈຫຼັກ space_name.

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

local http_client = require('http.client').new()

ພວກເຮົາຍັງຕ້ອງການຫ້ອງສະຫມຸດສໍາລັບ json deserialization:

local json = require('json')

ນີ້ແມ່ນພຽງພໍທີ່ຈະສ້າງຫນ້າທີ່ໂຫລດຂໍ້ມູນ:

local function load_data(url, row_ver)
    local url = ('%s?rowVer=%s'):format(url,
        tostring(row_ver))
    local body = nil
    local data = http_client:request('GET', url, body, {
        keepalive_idle =  1,
        keepalive_interval = 1
    })
    return json.decode(data.body)
end

ຟັງຊັນປະຕິບັດການຮ້ອງຂໍ HTTP ໄປຫາທີ່ຢູ່ url ແລະສົ່ງມັນ row_ver ເປັນພາລາມິເຕີແລະສົ່ງຄືນຜົນໄດ້ຮັບ deserialized ຂອງຄໍາຮ້ອງຂໍ.

ຟັງຊັນສໍາລັບບັນທຶກຂໍ້ມູນທີ່ໄດ້ຮັບເບິ່ງຄືວ່ານີ້:

local function save_goods(goods)
    local n = #goods
    box.atomic(function()
        for i = 1, n do
            local obj = goods[i]
            box.space.goods:put(
                obj.id, obj.name, obj.code)
        end
    end)
end

ຮອບວຽນຂອງການບັນທຶກຂໍ້ມູນໃສ່ພື້ນທີ່ goods ວາງໄວ້ໃນການເຮັດທຸລະກໍາ (ຫນ້າທີ່ຖືກນໍາໃຊ້ສໍາລັບການນີ້ box.atomic) ເພື່ອຫຼຸດຜ່ອນຈໍານວນການດໍາເນີນງານຂອງແຜ່ນ.

ສຸດທ້າຍ, ຟັງຊັນ synchronization ຊ່ອງທ້ອງຖິ່ນ goods ດ້ວຍແຫຼ່ງທີ່ເຈົ້າສາມາດປະຕິບັດມັນໄດ້ເຊັ່ນນີ້:

local function sync_goods()
    local tuple = box.space.row_ver:get('goods')
    local row_ver = tuple and tuple.value or 0

    —— set your url here:
    local url = 'http://127.0.0.1:81/test/goods/list'

    while true do
        local goods = load_goods(url, row_ver)

        local count = #goods
        if count == 0 then
            return
        end

        save_goods(goods)

        row_ver = goods[count].rowVer
        box.space.row_ver:put({'goods', row_ver})
    end
end

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

ເພື່ອ​ປ້ອງ​ກັນ​ການ​ອຸ​ປະ​ຕິ​ເຫດ looping (ໃນ​ກໍ​ລະ​ນີ​ຂອງ​ຄວາມ​ຜິດ​ພາດ​ໃນ​ໂຄງ​ການ​) ໄດ້​, loop​ while ສາມາດໄດ້ຮັບການທົດແທນໂດຍ for:

for _ = 1, max_req do ...

ເປັນຜົນມາຈາກການປະຕິບັດຫນ້າທີ່ sync_goods ຊ່ອງ goods ເຄື່ອງຮັບຈະມີລຸ້ນຫຼ້າສຸດຂອງບັນທຶກພື້ນທີ່ທັງໝົດ goods ໃນແຫຼ່ງ.

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

ລໍາດັບ row_ver ສາມາດໃຊ້ເພື່ອສົ່ງຂໍ້ມູນຈາກຊ່ອງອື່ນ: ບໍ່ຈໍາເປັນຕ້ອງສ້າງລໍາດັບແຍກຕ່າງຫາກສໍາລັບແຕ່ລະຊ່ອງທີ່ສົ່ງ.

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

ການຄົ້ນພົບ

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

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