Postgres: bloat, pg_repack ແລະຂໍ້ຈໍາກັດທີ່ເລື່ອນເວລາ

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

ບົດຄວາມຈະປະກອບດ້ວຍທິດສະດີເລັກນ້ອຍກ່ຽວກັບວິທີການ bloat ເກີດຂຶ້ນ, ວິທີທີ່ທ່ານສາມາດຕໍ່ສູ້ກັບມັນ, ກ່ຽວກັບຂໍ້ຈໍາກັດທີ່ເລື່ອນເວລາແລະບັນຫາທີ່ພວກເຂົານໍາເອົາການຂະຫຍາຍ pg_repack.

ບົດຄວາມນີ້ຖືກຂຽນໂດຍອີງໃສ່ ຄຳເວົ້າຂອງຂ້ອຍ ທີ່ PgConf.Russia 2020.

ເປັນຫຍັງຈິ່ງເກີດການອັກເສບ?

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

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

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

ຫຼັງຈາກນັ້ນ, ພວກເຮົາປັບປຸງຫນຶ່ງໃນລາຍການ, ດັ່ງນັ້ນຈຶ່ງເຮັດໃຫ້ສະບັບເກົ່າບໍ່ກ່ຽວຂ້ອງ.

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

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

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

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

ເມື່ອຈໍານວນຫນ້າເປົ່າຫຼື sparse ດັ່ງກ່າວກາຍເປັນຂະຫນາດໃຫຍ່, ເຊິ່ງເອີ້ນວ່າ bloat, ມັນເລີ່ມສົ່ງຜົນກະທົບຕໍ່ການປະຕິບັດ.

ທຸກສິ່ງທຸກຢ່າງທີ່ອະທິບາຍຂ້າງເທິງນີ້ແມ່ນກົນໄກຂອງການປະກົດຕົວຂອງ bloat ໃນຕາຕະລາງ. ໃນດັດຊະນີນີ້ເກີດຂຶ້ນໃນຫຼາຍວິທີດຽວກັນ.

ຂ້ອຍມີອາການທ້ອງອືດບໍ?

ມີຫຼາຍວິທີໃນການກໍານົດວ່າທ່ານມີ bloat. ແນວຄວາມຄິດຂອງທໍາອິດແມ່ນການນໍາໃຊ້ສະຖິຕິ Postgres ພາຍໃນ, ເຊິ່ງປະກອບດ້ວຍຂໍ້ມູນປະມານກ່ຽວກັບຈໍານວນແຖວໃນຕາຕະລາງ, ຈໍານວນແຖວ "ສົດ" ແລະອື່ນໆ, ທ່ານສາມາດຊອກຫາຕົວແປທີ່ກຽມພ້ອມຫຼາຍໃນອິນເຕີເນັດ. ພວກເຮົາເອົາເປັນພື້ນຖານ ສະຄຣິບ ຈາກຜູ້ຊ່ຽວຊານ PostgreSQL, ເຊິ່ງສາມາດປະເມີນຕາຕະລາງ bloat ພ້ອມກັບ toast ແລະ bloat btree indexes. ໃນປະສົບການຂອງພວກເຮົາ, ຄວາມຜິດພາດຂອງມັນແມ່ນ 10-20%.

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

ພວກເຮົາພິຈາລະນາມູນຄ່າ bloat ຂະຫນາດນ້ອຍ, ເຖິງ 20%, ຍອມຮັບໄດ້. ມັນສາມາດໄດ້ຮັບການພິຈາລະນາເປັນ analogue ຂອງ fillfactor ສໍາລັບ ຕາຕະລາງ и ດັດຊະນີ. ຢູ່ທີ່ 50% ແລະສູງກວ່າ, ບັນຫາການປະຕິບັດອາດຈະເລີ່ມຕົ້ນ.

ວິທີການຕໍ່ສູ້ກັບ bloat

Postgres ມີຫຼາຍວິທີທີ່ຈະຈັດການກັບ bloat ອອກຈາກກ່ອງ, ແຕ່ພວກມັນບໍ່ເຫມາະສົມສໍາລັບທຸກຄົນ.

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

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

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

ຈະເຮັດແນວໃດໃນສະຖານະການທີ່ທ່ານໄດ້ສ້າງຕັ້ງ AUTOVACUUM, ແຕ່ bloat ຍັງສືບຕໍ່ຂະຫຍາຍຕົວ.

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

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

ທີມງານ REINDEX ຄ້າຍຄືກັບສອງອັນທີ່ຜ່ານມາ, ແຕ່ສ້າງດັດສະນີສະເພາະຫຼືດັດສະນີທັງຫມົດຂອງຕາຕະລາງ. locks ອ່ອນເພຍເລັກນ້ອຍ: ShareLock ໃນຕາຕະລາງ (ປ້ອງກັນການດັດແປງ, ແຕ່ອະນຸຍາດໃຫ້ເລືອກ) ແລະ AccessExclusiveLock ຢູ່ໃນດັດຊະນີທີ່ຖືກສ້າງໃຫມ່ (ບລັອກການສອບຖາມໂດຍໃຊ້ດັດຊະນີນີ້). ຢ່າງໃດກໍຕາມ, ໃນສະບັບທີ 12 ຂອງ Postgres ຕົວກໍານົດການໄດ້ປາກົດ ພ້ອມກັນ, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດສ້າງດັດສະນີຄືນໃຫມ່ໄດ້ໂດຍບໍ່ຕ້ອງຂັດຂວາງການເພີ່ມເຕີມ, ການດັດແກ້, ຫຼືການລຶບບັນທຶກພ້ອມໆກັນ.

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

ດັ່ງນັ້ນ, ຖ້າດັດສະນີມີວິທີທີ່ຈະກໍາຈັດການ bloat "ໃນການບິນ", ຫຼັງຈາກນັ້ນບໍ່ມີຕາຕະລາງ. ນີ້ແມ່ນບ່ອນທີ່ສ່ວນຂະຫຍາຍພາຍນອກຕ່າງໆເຂົ້າມາມີບົດບາດ: pg_repack (ເມື່ອກ່ອນແມ່ນ pg_reorg), pgcompact, pgcompactable ແລະ​ອື່ນໆ. ໃນບົດຄວາມນີ້, ຂ້າພະເຈົ້າຈະບໍ່ໄດ້ປຽບທຽບພວກເຂົາແລະພຽງແຕ່ເວົ້າກ່ຽວກັບ pg_repack, ເຊິ່ງ, ຫຼັງຈາກການດັດແກ້ບາງຢ່າງ, ພວກເຮົາໃຊ້ຕົວເຮົາເອງ.

pg_repack ເຮັດວຽກແນວໃດ

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

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

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

ທຸກສິ່ງທຸກຢ່າງເບິ່ງຄືວ່າດີໃນທິດສະດີ, ແຕ່ສິ່ງທີ່ເກີດຂື້ນໃນການປະຕິບັດ? ພວກເຮົາໄດ້ທົດສອບ pg_repack ໂດຍບໍ່ມີການໂຫຼດແລະພາຍໃຕ້ການໂຫຼດ, ແລະກວດເບິ່ງການເຮັດວຽກຂອງມັນໃນກໍລະນີຂອງການຢຸດກ່ອນໄວອັນຄວນ (ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ການນໍາໃຊ້ Ctrl+C). ການທົດສອບທັງໝົດແມ່ນເປັນບວກ.

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

pancake ທໍາອິດທີ່ຂາຍ

ໃນກຸ່ມທໍາອິດພວກເຮົາໄດ້ຮັບຄວາມຜິດພາດກ່ຽວກັບການລະເມີດຂໍ້ຈໍາກັດທີ່ເປັນເອກະລັກ:

$ ./pg_repack -t tablename -o id
INFO: repacking table "tablename"
ERROR: query failed: 
    ERROR: duplicate key value violates unique constraint "index_16508"
DETAIL:  Key (id, index)=(100500, 42) already exists.

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

ຂໍ້ຈໍາກັດທີ່ເລື່ອນເວລາ: ເປັນຫຍັງພວກມັນຈຶ່ງຈໍາເປັນແລະວິທີການເຮັດວຽກ

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

create table cars
(
  name text constraint pk_cars primary key,
  ord integer not null constraint uk_cars unique
);

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

begin;
  update cars set ord = 2 where name = 'audi';
  update cars set ord = 1 where name = 'bmw';
commit;

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

[23305] ERROR: duplicate key value violates unique constraint “uk_cars”
Detail: Key (ord)=(2) already exists.

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

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

ທາງ​ເລືອກ​ທີ​ສາມ​: ເຮັດ​ໃຫ້​ຂໍ້​ຈໍາ​ກັດ​ເລື່ອນ​ເວ​ລາ​ເພື່ອ​ໃຫ້​ມັນ​ຖືກ​ກວດ​ສອບ​ພຽງ​ແຕ່​ໃນ​ເວ​ລາ​ທີ່​ຄໍາ​ຫມັ້ນ​ສັນ​ຍາ​:

create table cars
(
  name text constraint pk_cars primary key,
  ord integer not null constraint uk_cars unique deferrable initially deferred
);

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

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

ໂດຍທົ່ວໄປ, ອີງຕາມປະເພດຂອງຂໍ້ຈໍາກັດ, Postgres ມີສາມລະດັບຂອງ granularity ສໍາລັບການກວດສອບໃຫ້ເຂົາເຈົ້າ: ແຖວ, ການເຮັດທຸລະກໍາ, ແລະລະດັບການສະແດງອອກ.

ແຫຼ່ງຂໍ້ມູນ: begriffs

ກວດເບິ່ງ ແລະບໍ່ NULL ສະເຫມີຖືກກວດສອບຢູ່ໃນລະດັບແຖວ; ສໍາລັບຂໍ້ຈໍາກັດອື່ນໆ, ດັ່ງທີ່ເຫັນໄດ້ຈາກຕາຕະລາງ, ມີທາງເລືອກທີ່ແຕກຕ່າງກັນ. ທ່ານສາມາດອ່ານເພີ່ມເຕີມ ທີ່ນີ້.

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

ການປັບປຸງ pg_repack

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

$ ./pg_repack -t tablename -o id
INFO: repacking table "tablename"
ERROR: query failed: 
    ERROR: duplicate key value violates unique constraint "index_16508"
DETAIL:  Key (id, index)=(100500, 42) already exists.

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

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

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

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

ດັ່ງນັ້ນພວກເຮົາມີຄວາມຄິດແນວໃດ?

ສ້າງດັດສະນີທີ່ຄ້າຍຄືກັບ deferred

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

ເພື່ອຮັບປະກັນວ່າການກວດສອບຢູ່ໃນໂໝດບໍ່ຖືກເລື່ອນສະເໝີ, ພວກເຮົາໄດ້ສ້າງດັດສະນີໃໝ່ທີ່ຄ້າຍກັບຂໍ້ຈຳກັດທີ່ເລື່ອນເວລາເດີມ:

CREATE UNIQUE INDEX CONCURRENTLY uk_tablename__immediate ON tablename (id, index);
-- run pg_repack
DROP INDEX CONCURRENTLY uk_tablename__immediate;

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

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

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

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

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

ເພື່ອທົດສອບການປ່ຽນແປງຂອງພວກເຮົາ, ພວກເຮົາຂຽນແບບທົດສອບງ່າຍໆ:

• ຕາຕະລາງທີ່ມີຂໍ້ຈໍາກັດທີ່ເລື່ອນເວລາແລະບັນທຶກຫນຶ່ງ;
• ໃສ່ຂໍ້ມູນໃນ loop ທີ່ຂັດແຍ້ງກັບບັນທຶກທີ່ມີຢູ່ແລ້ວ;
• ປັບປຸງໃຫ້ທັນ – ຂໍ້ມູນບໍ່ຂັດກັນອີກຕໍ່ໄປ;
• ຫມັ້ນສັນຍາການປ່ຽນແປງ.

create table test_table
(
  id serial,
  val int,
  constraint uk_test_table__val unique (val) deferrable initially deferred 
);

INSERT INTO test_table (val) VALUES (0);
FOR i IN 1..10000 LOOP
  BEGIN
    INSERT INTO test_table VALUES (0) RETURNING id INTO v_id;
    UPDATE test_table set val = i where id = v_id;
    COMMIT;
  END;
END LOOP;

ສະບັບຕົ້ນສະບັບຂອງ pg_repack ສະເຫມີ crashed ໃນ insert ທໍາອິດ, ສະບັບດັດແກ້ເຮັດວຽກໂດຍບໍ່ມີຄວາມຜິດພາດ. ຍິ່ງໃຫຍ່.

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

$ ./pg_repack -t tablename -o id
INFO: repacking table "tablename"
ERROR: query failed: 
    ERROR: duplicate key value violates unique constraint "index_16508"
DETAIL:  Key (id, index)=(100500, 42) already exists.

ສະຖານະການຄລາສສິກ: ທຸກສິ່ງທຸກຢ່າງເຮັດວຽກຢູ່ໃນສະພາບແວດລ້ອມການທົດສອບ, ແຕ່ບໍ່ແມ່ນໃນການຜະລິດ?!

APPLY_COUNT ແລະຈຸດເຊື່ອມຕໍ່ຂອງສອງຊຸດ

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

for (;;)
{
num = apply_log(connection, table, APPLY_COUNT);

if (num > MIN_TUPLES_BEFORE_SWITCH)
     continue;  /* there might be still some tuples, repeat. */
...
}

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

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

FOR i IN 1..10000 LOOP
  BEGIN
    INSERT INTO test_table VALUES (1) RETURNING id INTO v_id;
    UPDATE test_table set val = i where id = v_id;
    UPDATE test_table set val = i where id = v_id; -- one more update
    COMMIT;
  END;
END LOOP;

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

ການປະຕິເສດຈາກ batch

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

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

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

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

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

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

ການຄົ້ນພົບ

ສິ່ງທີ່ພວກເຮົາສາມາດແນະນໍາໂດຍອີງໃສ່ປະສົບການຂອງພວກເຮົາເອງ:

1. ຕິດ​ຕາມ​ກວດ​ກາ bloat ຂອງ​ທ່ານ​. ອີງຕາມຂໍ້ມູນການຕິດຕາມ, ທ່ານສາມາດເຂົ້າໃຈວ່າ autovacuum ຖືກຕັ້ງຄ່າໄດ້ດີປານໃດ.
2. ປັບ AUTOVACUUM ເພື່ອຮັກສາການບວມຢູ່ໃນລະດັບທີ່ຍອມຮັບໄດ້.
3. ຖ້າ bloat ຍັງເຕີບໃຫຍ່ແລະທ່ານບໍ່ສາມາດເອົາຊະນະມັນໄດ້ໂດຍໃຊ້ເຄື່ອງມືນອກກ່ອງ, ຢ່າຢ້ານທີ່ຈະໃຊ້ການຂະຫຍາຍພາຍນອກ. ສິ່ງທີ່ ສຳ ຄັນແມ່ນການທົດສອບທຸກຢ່າງທີ່ດີ.
4. ຢ່າຢ້ານທີ່ຈະດັດແປງວິທີແກ້ໄຂພາຍນອກເພື່ອໃຫ້ເຫມາະສົມກັບຄວາມຕ້ອງການຂອງເຈົ້າ - ບາງຄັ້ງນີ້ສາມາດມີປະສິດທິພາບແລະງ່າຍກວ່າການປ່ຽນລະຫັດຂອງທ່ານເອງ.

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