ການບີບອັດຂໍ້ມູນໃນ Apache Ignite. ປະສົບການຂອງ Sber

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

ດັ່ງນັ້ນ, ດ້ວຍການເປີດໃຊ້ໂຫມດຄົງທີ່, ເປັນຜົນມາຈາກການປ່ຽນແປງຂອງຂໍ້ມູນໃນຖານຄວາມຈໍາ, Ignite ເລີ່ມຂຽນໃສ່ແຜ່ນ:

1. ເນື້ອໃນຂອງຖານຄວາມຈໍາ
2. ຂຽນບັນທຶກລ່ວງຫນ້າ (ຕໍ່ໄປນີ້ພຽງແຕ່ WAL)

ມີກົນໄກສໍາລັບການບີບອັດ WAL ສໍາລັບໄລຍະຫນຶ່ງໃນປັດຈຸບັນ, ເອີ້ນວ່າ WAL compaction. Apache Ignite 2.8 ທີ່ປ່ອຍອອກມາເມື່ອບໍ່ດົນມານີ້ໄດ້ແນະນໍາສອງກົນໄກເພີ່ມເຕີມທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດບີບອັດຂໍ້ມູນໃນແຜ່ນ: ການບີບອັດຫນ້າແຜ່ນສໍາລັບການບີບອັດເນື້ອຫາຂອງແຄສແລະການບີບອັດຫນ້າ WAL ສໍາລັບການບີບອັດບາງລາຍການ WAL. ລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບສາມກົນໄກເຫຼົ່ານີ້ຂ້າງລຸ່ມນີ້.

ການບີບອັດຫນ້າແຜ່ນ

ວິທີການເຮັດວຽກນີ້

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

ຂໍ້ມູນຖືກເກັບໄວ້ໃນແຜ່ນໃນຮູບແບບຕໍ່ໄປນີ້: ໄຟລ໌ແຍກຕ່າງຫາກແມ່ນສ້າງຂື້ນສໍາລັບແຕ່ລະພາທິຊັນຂອງແຕ່ລະກຸ່ມ cache; ໃນໄຟລ໌ນີ້, ຫນ້າເວັບຈະປາກົດຂຶ້ນຕາມລໍາດັບ. ຕົວລະບຸໜ້າເຕັມມີຕົວລະບຸກຸ່ມແຄດ, ໝາຍເລກພາທິຊັນ ແລະດັດຊະນີໜ້າຢູ່ໃນໄຟລ໌. ດັ່ງນັ້ນ, ການນໍາໃຊ້ຕົວລະບຸຫນ້າເຕັມ, ພວກເຮົາສາມາດກໍານົດໄຟລ໌ແລະຄ່າຊົດເຊີຍໃນໄຟລ໌ສໍາລັບແຕ່ລະຫນ້າ. ທ່ານສາມາດອ່ານເພີ່ມເຕີມກ່ຽວກັບຄວາມຊົງຈໍາຂອງຫນ້າໃນບົດຄວາມ Apache Ignite Wiki: Ignite Persistent Store - under the hood.

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

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

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

ເພື່ອຫຼີກເວັ້ນການແກ້ໄຂບັນຫາເຫຼົ່ານີ້ໃນລະດັບຂອງມັນເອງ, ການບີບອັດຫນ້າຂອງແຜ່ນໃນ Apache Ignite ໃຊ້ກົນໄກລະບົບໄຟລ໌ທີ່ເອີ້ນວ່າໄຟລ໌ sparse. ໄຟລ໌ກະແຈກກະຈາຍແມ່ນອັນໜຶ່ງທີ່ບາງພື້ນທີ່ທີ່ບໍ່ມີສູນສາມາດໝາຍເປັນ "ຮູ". ໃນກໍລະນີນີ້, ບໍ່ມີບລັອກລະບົບໄຟລ໌ໃດຈະຖືກຈັດສັນເພື່ອເກັບຮັກສາຮູເຫຼົ່ານີ້, ເຮັດໃຫ້ປະຫຍັດພື້ນທີ່ດິດ.

ມັນເປັນເຫດຜົນວ່າເພື່ອປົດປ່ອຍບລັອກລະບົບໄຟລ໌, ຂະຫນາດຂອງຮູຕ້ອງໃຫຍ່ກວ່າຫຼືເທົ່າກັບບລັອກລະບົບໄຟລ໌, ເຊິ່ງກໍານົດຂອບເຂດຈໍາກັດເພີ່ມເຕີມຂອງຂະຫນາດຫນ້າແລະ Apache Ignite: ສໍາລັບການບີບອັດມີຜົນກະທົບໃດໆ, ຂະໜາດຂອງໜ້າຈະຕ້ອງໃຫຍ່ກວ່າຂະໜາດຂອງລະບົບໄຟລ໌ຢ່າງເຂັ້ມງວດ. ຖ້າຂະຫນາດຂອງຫນ້າເທົ່າກັບຂະຫນາດບລັອກ, ພວກເຮົາຈະບໍ່ສາມາດປົດປ່ອຍບລັອກດຽວໄດ້, ເພາະວ່າເພື່ອປົດປ່ອຍບລັອກດຽວ, ຫນ້າທີ່ຖືກບີບອັດຕ້ອງຄອບຄອງ 0 ໄບຕ໌. ຖ້າຂະຫນາດຫນ້າເທົ່າກັບຂະຫນາດຂອງ 2 ຫຼື 4 ບລັອກ, ພວກເຮົາຈະສາມາດປ່ອຍຕົວໄດ້ຢ່າງຫນ້ອຍຫນຶ່ງບລັອກຖ້າຫນ້າເວັບຂອງພວກເຮົາຖືກບີບອັດຢ່າງຫນ້ອຍ 50% ຫຼື 75% ຕາມລໍາດັບ.

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

ໃນການປະຕິບັດໃນປະຈຸບັນ, Ignite ສາມາດເຮັດວຽກກັບໄຟລ໌ທີ່ແຕກຫັກພາຍໃຕ້ Linux OS; ດັ່ງນັ້ນ, ການບີບອັດຫນ້າຂອງແຜ່ນສາມາດຖືກເປີດໃຊ້ພຽງແຕ່ເມື່ອໃຊ້ Ignite ໃນລະບົບປະຕິບັດການນີ້.

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

ຜົນກະທົບດ້ານການປະຕິບັດ

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

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

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

ດັ່ງນັ້ນຜົນກະທົບຂອງການດໍາເນີນການອ່ານແມ່ນ:

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

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

ວິທີການເປີດໃຊ້ແລະການຕັ້ງຄ່າ

ດັ່ງທີ່ໄດ້ກ່າວມາຂ້າງເທິງ, ສະບັບຕໍາ່ສຸດທີ່ຂອງ Apache Ignite ທີ່ສະຫນັບສະຫນູນການບີບອັດຫນ້າແຜ່ນແມ່ນ 2.8 ແລະພຽງແຕ່ລະບົບປະຕິບັດການ Linux ເທົ່ານັ້ນທີ່ສະຫນັບສະຫນູນ. ເປີດ​ໃຊ້​ງານ​ແລະ​ການ​ຕັ້ງ​ຄ່າ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

• ຕ້ອງມີໂມດູນການບີບອັດໄຟໃນຊັ້ນຮຽນ. ໂດຍຄ່າເລີ່ມຕົ້ນ, ມັນຕັ້ງຢູ່ໃນການແຈກຢາຍ Apache Ignite ໃນ libs/optional directory ແລະບໍ່ໄດ້ລວມຢູ່ໃນ class-path. ທ່ານພຽງແຕ່ສາມາດຍ້າຍໄດເລກະທໍລີຂຶ້ນລະດັບຫນຶ່ງໄປຫາ libs ແລະຫຼັງຈາກນັ້ນເມື່ອທ່ານດໍາເນີນການຜ່ານ ignite.sh ມັນຈະຖືກເປີດໃຊ້ໂດຍອັດຕະໂນມັດ.
• ຄົງຕ້ອງຖືກເປີດໃຊ້ງານ (ເປີດໃຊ້ຜ່ານ DataRegionConfiguration.setPersistenceEnabled(true)).
• ຂະໜາດໜ້າຈະຕ້ອງໃຫຍ່ກວ່າຂະໜາດບລັອກຂອງລະບົບໄຟລ໌ (ທ່ານສາມາດຕັ້ງມັນໄດ້ໂດຍໃຊ້ DataStorageConfiguration.setPageSize() ).
• ສໍາລັບແຕ່ລະ cache ທີ່ຂໍ້ມູນຕ້ອງໄດ້ຮັບການບີບອັດ, ທ່ານຕ້ອງກໍານົດວິທີການບີບອັດແລະ (ທາງເລືອກ) ລະດັບການບີບອັດ (ວິທີການ. CacheConfiguration.setDiskPageCompression() , CacheConfiguration.setDiskPageCompressionLevel()).

ການບີບອັດ WAL

ວິທີການເຮັດວຽກນີ້

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

ການປ້ອນຂໍ້ມູນໃນ WAL ຖືກແບ່ງອອກເປັນເຫດຜົນ ແລະທາງກາຍຍະພາບ. Boolean ແມ່ນກະແຈແລະຄຸນຄ່າຂອງຕົວມັນເອງ. ທາງດ້ານຮ່າງກາຍ - ສະທ້ອນໃຫ້ເຫັນເຖິງການປ່ຽນແປງໃນຫນ້າໃນຮ້ານຫນ້າ. ໃນຂະນະທີ່ບັນທຶກຢ່າງມີເຫດຜົນສາມາດເປັນປະໂຫຍດສໍາລັບບາງກໍລະນີອື່ນໆ, ການບັນທຶກທາງດ້ານຮ່າງກາຍແມ່ນຈໍາເປັນພຽງແຕ່ສໍາລັບການຟື້ນຕົວໃນກໍລະນີຂອງອຸປະຕິເຫດແລະການບັນທຶກແມ່ນຈໍາເປັນພຽງແຕ່ນັບຕັ້ງແຕ່ການກວດກາສົບຜົນສໍາເລັດສຸດທ້າຍ. ໃນທີ່ນີ້ພວກເຮົາຈະບໍ່ເຂົ້າໄປໃນລາຍລະອຽດແລະອະທິບາຍວ່າເປັນຫຍັງມັນເຮັດວຽກແບບນີ້, ແຕ່ຜູ້ທີ່ສົນໃຈສາມາດອ້າງອີງເຖິງບົດຄວາມທີ່ໄດ້ກ່າວມາແລ້ວໃນ Apache Ignite Wiki: Ignite Persistent Store - under the hood.

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

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

ຜົນກະທົບດ້ານການປະຕິບັດ

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

ວິທີການເປີດໃຊ້ແລະການຕັ້ງຄ່າ

ທ່ານສາມາດເປີດໃຊ້ການບີບອັດ WAL ໂດຍໃຊ້ຄຸນສົມບັດ WalCompactionEnabled в DataStorageConfiguration (DataStorageConfiguration.setWalCompactionEnabled(true)). ນອກຈາກນີ້, ການນໍາໃຊ້ວິທີການ DataStorageConfiguration.setWalCompactionLevel(), ທ່ານສາມາດກໍານົດລະດັບການບີບອັດຖ້າຫາກວ່າທ່ານບໍ່ພໍໃຈກັບຄ່າເລີ່ມຕົ້ນ (BEST_SPEED).

ການບີບອັດພາບຖ່າຍໜ້າ WAL

ວິທີການເຮັດວຽກນີ້

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

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

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

ເຊັ່ນດຽວກັນກັບການບີບອັດໜ້າດິສກ໌, ການບີບອັດພາບຖ່າຍໜ້າ WAL ສາມາດໃຊ້ ZSTD, LZ4, Snappy compression algorithms, ເຊັ່ນດຽວກັນກັບໂໝດ SKIP_GARBAGE.

ຜົນກະທົບດ້ານການປະຕິບັດ

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

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

ໂດຍທາງອ້ອມ, ການຫຼຸດຜ່ອນຂະຫນາດ WAL ຍັງມີຜົນກະທົບ (ໃນທາງບວກ) streams ທີ່ dump ພາກສ່ວນ WAL ເຂົ້າໄປໃນຮວບຮວມແລະສາຍນ້ໍາ WAL compaction.

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

ວິທີການເປີດໃຊ້ແລະການຕັ້ງຄ່າ

ເວີຊັນຕໍ່າສຸດ Apache Ignite: 2.8. ເປີດ​ໃຊ້​ງານ​ແລະ​ການ​ຕັ້ງ​ຄ່າ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

• ຕ້ອງມີໂມດູນການບີບອັດໄຟໃນຊັ້ນຮຽນ. ໂດຍຄ່າເລີ່ມຕົ້ນ, ມັນຕັ້ງຢູ່ໃນການແຈກຢາຍ Apache Ignite ໃນ libs/optional directory ແລະບໍ່ໄດ້ລວມຢູ່ໃນ class-path. ທ່ານພຽງແຕ່ສາມາດຍ້າຍໄດເລກະທໍລີຂຶ້ນລະດັບຫນຶ່ງໄປຫາ libs ແລະຫຼັງຈາກນັ້ນເມື່ອທ່ານດໍາເນີນການຜ່ານ ignite.sh ມັນຈະຖືກເປີດໃຊ້ໂດຍອັດຕະໂນມັດ.
• ຄົງຕ້ອງຖືກເປີດໃຊ້ງານ (ເປີດໃຊ້ຜ່ານ DataRegionConfiguration.setPersistenceEnabled(true)).
• ຮູບແບບການບີບອັດຕ້ອງຖືກຕັ້ງໂດຍໃຊ້ວິທີການ DataStorageConfiguration.setWalPageCompression(), ການບີບອັດຖືກປິດໃຊ້ງານໂດຍຄ່າເລີ່ມຕົ້ນ (ໂໝດປິດໃຊ້ງານ).
• ທາງເລືອກອື່ນ, ທ່ານສາມາດກໍານົດລະດັບການບີບອັດໂດຍໃຊ້ວິທີການ DataStorageConfiguration.setWalPageCompression(), ເບິ່ງ javadoc ສໍາລັບວິທີການສໍາລັບຄ່າທີ່ຖືກຕ້ອງສໍາລັບແຕ່ລະໂຫມດ.

ສະຫລຸບ

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

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