ການ​ຈົດ​ທະ​ບຽນ​ການ​ແຜ່​ກະ​ຈາຍ​ສໍາ​ລັບ Wheelsets​: ເປັນ​ປະ​ສົບ​ການ​ກັບ Hyperledger Fabric​

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

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

ບັນຫາ: Blockchains ຍັງບໍ່ຂະຫຍາຍເທື່ອ

ໃນມື້ນີ້, ຄວາມພະຍາຍາມຂອງນັກພັດທະນາຈໍານວນຫຼາຍແມ່ນແນໃສ່ເຮັດໃຫ້ blockchain ເປັນເທກໂນໂລຍີທີ່ສະດວກສະບາຍຢ່າງແທ້ຈິງ, ແລະບໍ່ແມ່ນລະເບີດທີ່ໃຊ້ເວລາໃນ wrapper ທີ່ສວຍງາມ. ຊ່ອງທາງຂອງລັດ, ການລວບລວມໃນແງ່ດີ, plasma ແລະ sharding ອາດຈະກາຍເປັນເລື່ອງ ທຳ ມະດາ. ບາງມື້. ຫຼືບາງທີ TON ຈະເລື່ອນການເປີດຕົວອີກເທື່ອຫນຶ່ງເປັນເວລາຫົກເດືອນ, ແລະກຸ່ມ Plasma ຕໍ່ໄປຈະຢຸດເຊົາ. ພວກ​ເຮົາ​ສາ​ມາດ​ເຊື່ອ​ໃນ​ແຜນ​ທີ່​ການ​ຕໍ່​ໄປ​ແລະ​ອ່ານ​ເອ​ກະ​ສານ​ສີ​ຂາວ​ທີ່​ສວຍ​ງາມ​ໃນ​ຕອນ​ກາງ​ຄືນ​, ແຕ່​ວ່າ​ນີ້​ແລະ​ປັດ​ຈຸ​ບັນ​ພວກ​ເຮົາ​ຈໍາ​ເປັນ​ຕ້ອງ​ເຮັດ​ບາງ​ສິ່ງ​ບາງ​ຢ່າງ​ທີ່​ພວກ​ເຮົາ​ມີ​. ເອົາ shit ສໍາເລັດ.

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

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

Mainnet Ethereum ປະຈຸບັນກໍາລັງແລ່ນຢູ່ທີ່ ~30 tps. ເນື່ອງຈາກວ່ານີ້ຢ່າງດຽວ, ມັນເປັນການຍາກທີ່ຈະຮັບຮູ້ວ່າມັນເປັນ blockchain ໃນທຸກວິທີທີ່ເຫມາະສົມກັບຄວາມຕ້ອງການຂອງບໍລິສັດ. ໃນ​ບັນ​ດາ​ການ​ແກ້​ໄຂ​ທີ່​ອະ​ນຸ​ຍາດ​ມີ​ມາດ​ຕະ​ຖານ​ທີ່​ສະ​ແດງ​ໃຫ້​ເຫັນ 2000 tps (.ກຸ່ມ) ຫຼື 3000 tps (ຜ້າ Hyperledger, ມີຫນ້ອຍລົງໃນສິ່ງພິມ, ແຕ່ທ່ານຈໍາເປັນຕ້ອງຄໍານຶງເຖິງວ່າດັດຊະນີໄດ້ຖືກປະຕິບັດຢູ່ໃນເຄື່ອງຈັກເປັນເອກະສັນເກົ່າ). ແມ່ນ ຄວາມພະຍາຍາມໃນການປຸງແຕ່ງຜ້າຮາກ, ເຊິ່ງບໍ່ໄດ້ໃຫ້ຜົນໄດ້ຮັບທີ່ຮ້າຍແຮງທີ່ສຸດ, 20000 tps, ແຕ່ມາຮອດປັດຈຸບັນນີ້ແມ່ນພຽງແຕ່ການຄົ້ນຄວ້າທາງວິຊາການ, ລໍຖ້າການປະຕິບັດທີ່ຫມັ້ນຄົງຂອງມັນ. ມັນບໍ່ຫນ້າຈະເປັນໄປໄດ້ວ່າບໍລິສັດທີ່ສາມາດທີ່ຈະຮັກສາພະແນກຂອງນັກພັດທະນາ blockchain ຈະເອົາໃຈໃສ່ກັບຕົວຊີ້ວັດດັ່ງກ່າວ. ແຕ່ບັນຫາແມ່ນບໍ່ພຽງແຕ່ throughput, ຍັງມີ latency.

ການເລື່ອນເວລາ

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

ໃຫ້ພວກເຮົາເບິ່ງຢ່າງໃກ້ຊິດກ່ຽວກັບວົງຈອນຊີວິດການເຮັດທຸລະກໍາໃນ Hyperledger Fabric ເພື່ອເຂົ້າໃຈບ່ອນທີ່ໃຊ້ເວລາແລະມັນກ່ຽວຂ້ອງກັບຕົວກໍານົດການຜະລິດຕັນ.

ເອົາມາຈາກທີ່ນີ້: hyperledger-fabric.readthedocs.io/en/release-1.4/arch-deep-dive.html#swimlane

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

ແຕ່ນັ້ນບໍ່ແມ່ນທັງຫມົດ. ຄໍາວ່າ "ຜູ້ສັ່ງສ້າງເປັນບລັອກ" ບໍ່ພຽງແຕ່ເຊື່ອງຄໍາສັ່ງຂອງທຸລະກໍາ, ແຕ່ຍັງ 3 ການຮ້ອງຂໍເຄືອຂ່າຍຕາມລໍາດັບຈາກຜູ້ນໍາໄປຫາຜູ້ຕິດຕາມແລະກັບຄືນ: ຜູ້ນໍາເພີ່ມຂໍ້ຄວາມໃສ່ບັນທຶກ, ສົ່ງໃຫ້ຜູ້ຕິດຕາມ, ຕໍ່ມາເພີ່ມມັນ. ກັບບັນທຶກຂອງເຂົາເຈົ້າ, ສົ່ງການຢືນຢັນການຈໍາລອງສົບຜົນສໍາເລັດກັບຜູ້ນໍາ, ຜູ້ນໍາຄໍາຫມັ້ນສັນຍາຂໍ້ຄວາມ, ສົ່ງຄໍາຫມັ້ນສັນຍາກັບຜູ້ຕິດຕາມ, ຜູ້ຕິດຕາມຫມັ້ນສັນຍາ. ຂະ​ຫນາດ​ນ້ອຍ​ກວ່າ​ແລະ​ເວ​ລາ​ຂອງ​ການ​ສ້າງ​ຕັ້ງ​ຕັນ​, ການ​ບໍ​ລິ​ການ​ສັ່ງ​ຊື້​ຫຼາຍ​ຄັ້ງ​ຈະ​ມີ​ການ​ສ້າງ​ເປັນ​ເອ​ກະ​ສັນ​.. Hyperledger Fabric ມີສອງຕົວກໍານົດການສໍາລັບການສ້າງຕັນ: BatchTimeout - ເວລາການສ້າງຕັນແລະ BatchSize - ຂະຫນາດຂອງຕັນ (ຈໍານວນການເຮັດທຸລະກໍາແລະຂະຫນາດຂອງ block ຕົວຂອງມັນເອງໃນ bytes). ທັນທີທີ່ຫນຶ່ງຂອງພາລາມິເຕີເຖິງຂອບເຂດຈໍາກັດ, ຕັນໃຫມ່ຈະຖືກປ່ອຍອອກມາ. ເສັ້ນຄໍາສັ່ງຫຼາຍ, ອັນນີ້ຈະໃຊ້ເວລາດົນຂຶ້ນ. ດັ່ງນັ້ນ, ທ່ານຈໍາເປັນຕ້ອງເພີ່ມ BatchTimeout ແລະ BatchSize. ແຕ່ເນື່ອງຈາກ RWSets ໄດ້ຮັບການສະບັບ, ຕັນຂະຫນາດໃຫຍ່ທີ່ພວກເຮົາເຮັດ, ຄວາມເປັນໄປໄດ້ຂອງຂໍ້ຂັດແຍ່ງ MVCC ສູງຂຶ້ນ. ນອກຈາກນັ້ນ, ເມື່ອ BatchTimeout ເພີ່ມຂຶ້ນ, UX ເສຍຫາຍຢ່າງຮ້າຍແຮງ. ໂຄງການຕໍ່ໄປນີ້ສໍາລັບການແກ້ໄຂບັນຫາເຫຼົ່ານີ້ເບິ່ງຄືວ່າສົມເຫດສົມຜົນແລະຈະແຈ້ງສໍາລັບຂ້ອຍ.

ວິທີການຫຼີກເວັ້ນການລໍຖ້າສໍາລັບການສຸດທ້າຍຂອງຕັນແລະບໍ່ສູນເສຍຄວາມສາມາດໃນການຕິດຕາມສະຖານະການທຸລະກໍາ

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

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

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

ຂັ້ນຕອນຕໍ່ໄປແມ່ນເພື່ອເຮັດໃຫ້ການໂຕ້ຕອບຂອງລູກຄ້າກັບລະບົບ asynchronous ເພື່ອບໍ່ໃຫ້ລໍຖ້າ 15, 30 ຫຼື 10000000 ວິນາທີ, ເຊິ່ງພວກເຮົາຈະກໍານົດເປັນ BatchTimeout. ແຕ່ໃນເວລາດຽວກັນ, ມັນຈໍາເປັນຕ້ອງຮັກສາຄວາມສາມາດໃນການກວດສອບວ່າການປ່ຽນແປງທີ່ລິເລີ່ມໂດຍການເຮັດທຸລະກໍາແມ່ນ / ບໍ່ໄດ້ຖືກບັນທຶກໄວ້ໃນ blockchain.
ຖານຂໍ້ມູນສາມາດຖືກນໍາໃຊ້ເພື່ອເກັບຮັກສາສະຖານະການທຸລະກໍາ. ທາງເລືອກທີ່ງ່າຍດາຍທີ່ສຸດແມ່ນ CouchDB ເນື່ອງຈາກວ່າມັນງ່າຍຕໍ່ການໃຊ້: ຖານຂໍ້ມູນມີ UI ອອກຈາກກ່ອງ, REST API, ແລະທ່ານສາມາດຕັ້ງຄ່າການຈໍາລອງແລະ sharding ໄດ້ຢ່າງງ່າຍດາຍສໍາລັບມັນ. ທ່ານພຽງແຕ່ສາມາດສ້າງຄໍເລັກຊັນແຍກຕ່າງຫາກໃນຕົວຢ່າງ CouchDB ດຽວກັນທີ່ໃຊ້ Fabric ເພື່ອເກັບຮັກສາສະຖານະຂອງໂລກຂອງມັນ. ພວກເຮົາຈໍາເປັນຕ້ອງເກັບຮັກສາເອກະສານປະເພດເຫຼົ່ານີ້.

{
 Status string // Статус транзакции: "pending", "done", "failed"
 TxID: string // ID транзакции
 Error: string // optional, сообщение об ошибке
}

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

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

ພວກເຮົາເລືອກ BoltDB ເພື່ອເກັບຮັກສາສະຖານະການເຮັດທຸລະກໍາເພາະວ່າພວກເຮົາຕ້ອງການປະຫຍັດຫນ່ວຍຄວາມຈໍາແລະບໍ່ຕ້ອງການທີ່ຈະເສຍເວລາໃນການໂຕ້ຕອບເຄືອຂ່າຍກັບເຄື່ອງແມ່ຂ່າຍຖານຂໍ້ມູນແຍກຕ່າງຫາກ, ໂດຍສະເພາະໃນເວລາທີ່ການໂຕ້ຕອບນີ້ເກີດຂຶ້ນໂດຍໃຊ້ໂປໂຕຄອນຂໍ້ຄວາມທໍາມະດາ. ໂດຍວິທີທາງການ, ບໍ່ວ່າທ່ານຈະໃຊ້ CouchDB ເພື່ອປະຕິບັດໂຄງການທີ່ອະທິບາຍໄວ້ຂ້າງເທິງຫຼືພຽງແຕ່ເກັບຮັກສາລັດຂອງໂລກ, ໃນກໍລະນີໃດກໍ່ຕາມ, ມັນມີຄວາມຫມາຍທີ່ຈະເພີ່ມປະສິດທິພາບວິທີການເກັບຮັກສາຂໍ້ມູນໃນ CouchDB. ໂດຍຄ່າເລີ່ມຕົ້ນ, ໃນ CouchDB, ຂະຫນາດຂອງ b-tree nodes ແມ່ນ 1279 bytes, ເຊິ່ງມີຂະຫນາດນ້ອຍກວ່າຂະຫນາດຂອງຂະແຫນງການຢູ່ໃນແຜ່ນ, ຊຶ່ງຫມາຍຄວາມວ່າທັງການອ່ານແລະການດຸ່ນດ່ຽງຂອງຕົ້ນໄມ້ຈະຕ້ອງມີການເຂົ້າເຖິງທາງດ້ານຮ່າງກາຍຫຼາຍຂຶ້ນກັບແຜ່ນ. ຂະຫນາດທີ່ເຫມາະສົມແມ່ນສອດຄ່ອງກັບມາດຕະຖານ ຮູບແບບຂັ້ນສູງ ແລະແມ່ນ 4 ກິໂລໄບ. ເພື່ອເພີ່ມປະສິດທິພາບພວກເຮົາຈໍາເປັນຕ້ອງກໍານົດພາລາມິເຕີ btree_chunk_size ເທົ່າກັບ 4096 ໃນໄຟລ໌ການຕັ້ງຄ່າ CouchDB. ສໍາລັບ BoltDB ການແຊກແຊງຄູ່ມືດັ່ງກ່າວ ບໍ່ຕ້ອງການ.

Backpressure: ຍຸດທະສາດ buffer

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

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

ຫຼຸດລົງ: ພວກເຮົາສາມາດອ້າງວ່າພວກເຮົາມີຄວາມສາມາດປະມວນຜົນການເຮັດທຸລະກໍາ X ຫຼາຍທີ່ສຸດໃນ T ວິນາທີ. ການຮ້ອງຂໍທັງໝົດທີ່ເກີນຂີດຈຳກັດນີ້ຈະຖືກຍົກເລີກ. ນີ້ແມ່ນຂ້ອນຂ້າງງ່າຍດາຍ, ແຕ່ຫຼັງຈາກນັ້ນທ່ານສາມາດລືມກ່ຽວກັບ UX.

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

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

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

ເຄື່ອງມືອື່ນໆ

ບໍ່ມີຫຍັງເວົ້າຢູ່ທີ່ນີ້ກ່ຽວກັບ chaincode, ເພາະວ່າ, ຕາມກົດລະບຽບ, ບໍ່ມີຫຍັງທີ່ຈະເພີ່ມປະສິດທິພາບໃນມັນ. Chaincode ຄວນງ່າຍດາຍແລະປອດໄພເທົ່າທີ່ເປັນໄປໄດ້ - ນັ້ນແມ່ນສິ່ງທີ່ຕ້ອງການຂອງມັນ. ໂຄງຮ່າງການຊ່ວຍໃຫ້ພວກເຮົາຂຽນລະຫັດໂສ້ໄດ້ງ່າຍໆ ແລະປອດໄພ CCKit ຈາກ S7 Techlab ແລະເຄື່ອງວິເຄາະສະຖິດ ຟື້ນຟູ ^CC.

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

ສະຫລຸບ

ວິທີການນີ້ຊ່ວຍໃຫ້ທ່ານສາມາດປ່ຽນແທນ Hyperledger Fabric ໄດ້ຢ່າງງ່າຍດາຍກັບ Quorum, ເຄືອຂ່າຍ Ethereum ເອກະຊົນອື່ນໆ (PoA ຫຼືແມ້ກະທັ້ງ PoW), ຫຼຸດລົງຢ່າງຫຼວງຫຼາຍຂອງ throughput ຕົວຈິງ, ແຕ່ໃນເວລາດຽວກັນຮັກສາ UX ປົກກະຕິ (ທັງຜູ້ໃຊ້ໃນຕົວທ່ອງເວັບແລະລະບົບປະສົມປະສານ). ເມື່ອປ່ຽນແທນ Fabric ກັບ Ethereum ໃນໂຄງການ, ທ່ານພຽງແຕ່ຕ້ອງການປ່ຽນເຫດຜົນຂອງການບໍລິການ / ຜູ້ອອກແບບຄືນໃຫມ່ຈາກການປະມວນຜົນຄວາມຂັດແຍ້ງ MVCC ໄປຫາ atomic nonce increment ແລະການສົ່ງຄືນ. Buffering ແລະ​ການ​ເກັບ​ຮັກ​ສາ​ສະ​ຖາ​ນະ​ເຮັດ​ໃຫ້​ມັນ​ເປັນ​ໄປ​ໄດ້​ທີ່​ຈະ decouple ເວ​ລາ​ຕອບ​ສະ​ຫນອງ​ຈາກ​ເວ​ລາ​ການ​ສ້າງ block ໄດ້​. ໃນປັດຈຸບັນທ່ານສາມາດເພີ່ມຫລາຍພັນຂໍ້ຄໍາສັ່ງແລະບໍ່ຕ້ອງຢ້ານວ່າຕັນໄດ້ຖືກສ້າງຕັ້ງຂຶ້ນເລື້ອຍໆເກີນໄປແລະໂຫຼດການບໍລິການຄໍາສັ່ງ.

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

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