ຄວາມຜິດພາດທົ່ວໄປໃນຄໍາຮ້ອງສະຫມັກທີ່ນໍາໄປສູ່ການ bloat ໃນ postgresql. Andrey Salnikov

ຂ້າພະເຈົ້າແນະນໍາໃຫ້ທ່ານອ່ານບົດບັນທຶກຂອງບົດລາຍງານໃນຕອນຕົ້ນຂອງ 2016 ໂດຍ Andrey Salnikov "ຄວາມຜິດພາດທົ່ວໄປໃນຄໍາຮ້ອງສະຫມັກທີ່ນໍາໄປສູ່ການ bloat ໃນ postgresql"

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

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

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

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

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

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

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

ແລະໃນສະຖານະການນີ້, ພວກເຮົາເຫັນວ່າພວກເຮົາກໍ່ມີເຄື່ອງຫມາຍນ້ອຍໆ. ດັດຊະນີແມ່ນຂະຫນາດນ້ອຍຢູ່ທີ່ 2 MB. ນີ້ແມ່ນເສັ້ນສະແດງທຳອິດຢູ່ເບື້ອງຊ້າຍ.

ເວລາຕອບສະ ໜອງ ໂດຍສະເລ່ຍໃນເຊີບເວີແມ່ນຍັງຄົງທີ່ແລະສັ້ນ. ນີ້ແມ່ນເສັ້ນສະແດງດ້ານຂວາເທິງ.

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

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

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

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

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

ສິ່ງດັ່ງກ່າວນໍາໄປໃສ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ເກີດຫຍັງຂຶ້ນໃນລະຫວ່າງອຸປະຕິເຫດ? ຂະບວນການນີ້ເກີດຂຶ້ນຢູ່ທີ່ນັ້ນໄດ້ແນວໃດ?

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

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

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

ແລະເມື່ອພວກເຮົາດໍາເນີນການສອບຖາມ, ຖານຂໍ້ມູນຕ້ອງຜ່ານເສັ້ນທັງຫມົດ: ທັງສີແດງແລະສີຂຽວ, ເພື່ອຊອກຫາເສັ້ນທີ່ຕ້ອງການ. ແລະຜົນກະທົບຂອງ bloating ຕາຕະລາງທີ່ມີຂໍ້ມູນທີ່ບໍ່ມີປະໂຫຍດແມ່ນເອີ້ນວ່າ "bloat", ເຊິ່ງກິນເຖິງພື້ນທີ່ດິດຂອງພວກເຮົາ. ຈືຂໍ້ມູນການ, ມັນແມ່ນ 2 MB, ມັນໄດ້ກາຍເປັນ 300 MB? ໃນປັດຈຸບັນປ່ຽນ megabytes ເປັນ gigabyte ແລະທ່ານຈະສູນເສຍຊັບພະຍາກອນແຜ່ນທັງຫມົດຂອງທ່ານຢ່າງໄວວາ.

ຜົນ​ສະ​ທ້ອນ​ອັນ​ໃດ​ທີ່​ອາດ​ຈະ​ມີ​ສໍາ​ລັບ​ພວກ​ເຮົາ?

• ໃນຕົວຢ່າງຂອງຂ້ອຍ, ຕາຕະລາງແລະດັດຊະນີເພີ່ມຂຶ້ນ 150 ເທົ່າ. ລູກຄ້າບາງຄົນຂອງພວກເຮົາມີກໍລະນີທີ່ເສຍຊີວິດຫຼາຍຂຶ້ນເມື່ອພວກເຂົາເລີ່ມໝົດພື້ນທີ່ດິສກ໌.
• ຂະຫນາດຂອງຕາຕະລາງຕົວມັນເອງຈະບໍ່ຫຼຸດລົງ. Autovacuum ໃນບາງກໍລະນີສາມາດຕັດຫາງຂອງຕາຕະລາງໄດ້ຖ້າມີພຽງແຕ່ເສັ້ນຕາຍ. ແຕ່ເນື່ອງຈາກມີການຫມູນວຽນຄົງທີ່, ເສັ້ນສີຂຽວຫນຶ່ງອາດຈະ freeze ໃນທ້າຍແລະບໍ່ໄດ້ຮັບການປັບປຸງ, ໃນຂະນະທີ່ອື່ນໆທັງຫມົດຈະຖືກຂຽນລົງຢູ່ບ່ອນໃດຫນຶ່ງໃນຕອນຕົ້ນຂອງແຜ່ນ. ແຕ່ນີ້ແມ່ນເຫດການທີ່ບໍ່ຫນ້າຈະເປັນໄປໄດ້ທີ່ຕາຕະລາງຂອງເຈົ້າເອງຈະຫຼຸດລົງໃນຂະຫນາດ, ດັ່ງນັ້ນທ່ານບໍ່ຄວນຫວັງກັບມັນ.
• ຖານຂໍ້ມູນຈໍາເປັນຕ້ອງຈັດລຽງຜ່ານຊໍ່ທັງຫມົດຂອງເສັ້ນທີ່ບໍ່ມີປະໂຫຍດ. ແລະພວກເຮົາເສຍຊັບພະຍາກອນແຜ່ນ, ພວກເຮົາເສຍຊັບພະຍາກອນໂຮງງານຜະລິດແລະໄຟຟ້າ.
• ແລະນີ້ມີຜົນກະທົບໂດຍກົງຕໍ່ຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາ, ເພາະວ່າຖ້າໃນຕອນເລີ່ມຕົ້ນພວກເຮົາໃຊ້ເວລາ 10 milliseconds ໃນການຮ້ອງຂໍ, 10 milliseconds ໃນລະຫັດຂອງພວກເຮົາ, ຫຼັງຈາກນັ້ນໃນໄລຍະ crash ພວກເຮົາເລີ່ມໃຊ້ເວລາຫນຶ່ງວິນາທີໃນການຮ້ອງຂໍແລະ 10 milliseconds ກ່ຽວກັບລະຫັດ, i.e. ຄໍາສັ່ງຂອງ. ຂະຫນາດໃນການປະຕິບັດຄໍາຮ້ອງສະຫມັກຫຼຸດລົງ. ແລະໃນເວລາທີ່ອຸປະຕິເຫດໄດ້ຖືກແກ້ໄຂ, ພວກເຮົາເລີ່ມໃຊ້ເວລາ 20 milliseconds ໃນການຮ້ອງຂໍ, 10 milliseconds ກ່ຽວກັບລະຫັດ. ນີ້ຫມາຍຄວາມວ່າພວກເຮົາຍັງຫຼຸດລົງຫນຶ່ງເທົ່າແລະເຄິ່ງຫນຶ່ງຂອງຜົນຜະລິດ. ແລະອັນນີ້ແມ່ນຍ້ອນທຸລະກຳອັນໜຶ່ງທີ່ຢຸດ, ບາງທີອາດຜ່ານຄວາມຜິດຂອງພວກເຮົາ.
• ແລະຄໍາຖາມ: "ພວກເຮົາຈະເອົາທຸກສິ່ງທຸກຢ່າງຄືນມາໄດ້ແນວໃດ?" ເພື່ອໃຫ້ທຸກສິ່ງທຸກຢ່າງດີກັບພວກເຮົາແລະການຮ້ອງຂໍເຂົ້າມາໄວເທົ່າທີ່ເກີດກ່ອນອຸປະຕິເຫດ.

ສໍາລັບຈຸດປະສົງນີ້ມີວົງຈອນທີ່ແນ່ນອນຂອງການເຮັດວຽກທີ່ດໍາເນີນ.

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

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

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

ຫຼັງຈາກທີ່ພວກເຮົາແກ້ໄຂທຸກສິ່ງທຸກຢ່າງແລະໃຫ້ແນ່ໃຈວ່າທຸກຢ່າງດີ, ພວກເຮົາຕ້ອງຮູ້ຈັກວິທີປ້ອງກັນສະຖານະການນີ້ໃນອະນາຄົດ:

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

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

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

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

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

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

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

ແລະສະຖານະການນີ້ມີລັກສະນະແນວໃດ? ໂດຍສະເພາະໃນກາຟເຫຼົ່ານີ້, ຂ້າພະເຈົ້າຍັງໄດ້ເພີ່ມໄລຍະເວລາຂອງການເຮັດທຸລະກໍາຈາກ replica ສໍາລັບໄລຍະເວລາການເຮັດທຸລະກໍາ. ກຣາບອື່ນໆທັງໝົດອ້າງອີງໃສ່ເຊີບເວີແມ່ບົດເທົ່ານັ້ນ.

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

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

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

ພວກເຮົາໄປອອນໄລນ໌ແລະເລີ່ມຕົ້ນອ່ານວ່າເປັນຫຍັງນີ້ເກີດຂຶ້ນ. ແລະພວກເຮົາຊອກຫາວິທີແກ້ໄຂ.

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

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

ແລະສິ່ງທີ່ເກີດຂຶ້ນກັບເຄື່ອງແມ່ຂ່າຍແມ່ບົດໃນເວລານີ້? ແລະພວກເຮົາຢູ່ໃນບັນຫາທັງຫມົດກັບເຄື່ອງແມ່ຂ່າຍແມ່ບົດ. ໃນປັດຈຸບັນພວກເຮົາກໍາລັງເຫັນກາຟໃນເວລາທີ່ຂ້ອຍໄດ້ເປີດໃຊ້ທັງສອງການຕັ້ງຄ່ານີ້. ແລະພວກເຮົາເຫັນວ່າກອງປະຊຸມກ່ຽວກັບການ replica ຂອງພວກເຮົາ somehow ເລີ່ມມີອິດທິພົນສະຖານະການຢູ່ໃນເຄື່ອງແມ່ຂ່າຍແມ່ບົດ. ນາງມີຜົນກະທົບເພາະວ່ານາງໄດ້ຢຸດ autovacuum, ເຊິ່ງເຮັດໃຫ້ເສັ້ນທາງທີ່ຕາຍແລ້ວອອກ. ຂະຫນາດຕາຕະລາງຂອງພວກເຮົາໄດ້ເພີ່ມຂຶ້ນ skyrocketed ອີກເທື່ອຫນຶ່ງ. ເວລາປະຕິບັດການສອບຖາມສະເລ່ຍໃນທົ່ວຖານຂໍ້ມູນທັງຫມົດກໍ່ເພີ່ມຂຶ້ນ skyrocketed. autovacuums ໄດ້ tightened ຂຶ້ນເລັກນ້ອຍ.

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

ຈະ​ເປັນ​ແນວ​ໃດ​ຖ້າ​ພວກ​ເຮົາ​ບໍ່​ຮູ້​ວ່າ​ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ເວົ້າ​ກ່ຽວ​ກັບ​ການ​ກ່ອນ​ຫນ້າ​ນີ້?

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

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

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

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

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

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

• ບໍ່ເປີດໃຊ້ hot_standby_feedback ບໍ? ແມ່ນແລ້ວ, ມັນບໍ່ໄດ້ຖືກແນະນໍາໃຫ້ເປີດມັນໂດຍບໍ່ມີເຫດຜົນທີ່ເຂັ້ມແຂງໂດຍສະເພາະ. ເນື່ອງຈາກວ່າການບິດນີ້ມີຜົນກະທົບໂດຍກົງກັບເຄື່ອງແມ່ຂ່າຍຂອງແມ່ບົດແລະຢຸດການເຮັດວຽກຂອງ autovacuum ຢູ່ທີ່ນັ້ນ. ໂດຍການເປີດໃຊ້ມັນຢູ່ໃນບາງ replica ແລະລືມກ່ຽວກັບມັນ, ທ່ານສາມາດຂ້າ Master ແລະມີບັນຫາໃຫຍ່ກັບຄໍາຮ້ອງສະຫມັກ.
• ເພີ່ມ max_standby_streaming_delay? ແມ່ນແລ້ວ, ສໍາລັບບົດລາຍງານນີ້ແມ່ນຄວາມຈິງ. ຖ້າທ່ານມີບົດລາຍງານສາມຊົ່ວໂມງແລະທ່ານບໍ່ຕ້ອງການໃຫ້ມັນຂັດຂ້ອງຍ້ອນຄວາມຂັດແຍ້ງຂອງການຈໍາລອງ, ຫຼັງຈາກນັ້ນພຽງແຕ່ເພີ່ມຄວາມລ່າຊ້າ. ບົດລາຍງານໄລຍະຍາວບໍ່ເຄີຍຮຽກຮ້ອງໃຫ້ມີຂໍ້ມູນທີ່ເຂົ້າມາໃນຖານຂໍ້ມູນໃນປັດຈຸບັນ. ຖ້າທ່ານມີມັນເປັນເວລາສາມຊົ່ວໂມງ, ຫຼັງຈາກນັ້ນທ່ານກໍາລັງແລ່ນມັນສໍາລັບໄລຍະເວລາຂໍ້ມູນເກົ່າ. ແລະສໍາລັບທ່ານ, ບໍ່ວ່າຈະເປັນການຊັກຊ້າສາມຊົ່ວໂມງຫຼືການຊັກຊ້າຫົກຊົ່ວໂມງຈະບໍ່ເຮັດໃຫ້ມີຄວາມແຕກຕ່າງ, ແຕ່ທ່ານຈະໄດ້ຮັບບົດລາຍງານຢ່າງຕໍ່ເນື່ອງແລະຈະບໍ່ມີບັນຫາໃດໆກັບພວກເຂົາຫຼຸດລົງ.
• ຕາມທໍາມະຊາດ, ທ່ານຈໍາເປັນຕ້ອງຄວບຄຸມກອງປະຊຸມທີ່ຍາວນານກ່ຽວກັບການຈໍາລອງ, ໂດຍສະເພາະຖ້າທ່ານຕັດສິນໃຈເປີດໃຊ້ hot_standby_feedback ຢູ່ໃນ replicas. ເນື່ອງຈາກວ່າສິ່ງໃດສາມາດເກີດຂຶ້ນໄດ້. ພວກເຮົາໄດ້ມອບສິ່ງຈໍາລອງນີ້ໃຫ້ກັບຜູ້ພັດທະນາເພື່ອໃຫ້ລາວສາມາດທົດສອບການສອບຖາມໄດ້. ລາວຂຽນຄໍາຮ້ອງຂໍ Crazy. ລາວ​ເປີດ​ມັນ​ອອກ​ໄປ​ດື່ມ​ຊາ, ແລະ​ພວກ​ເຮົາ​ໄດ້​ຮັບ​ພຣະ​ອາ​ຈານ​ທີ່​ຕັ້ງ​ຂຶ້ນ. ຫຼືບາງທີພວກເຮົາເອົາຄໍາຮ້ອງສະຫມັກທີ່ບໍ່ຖືກຕ້ອງຢູ່ໃນບ່ອນນັ້ນ. ສະຖານະການແມ່ນແຕກຕ່າງກັນ. ກອງປະຊຸມກ່ຽວກັບການຈໍາລອງຕ້ອງໄດ້ຮັບການຕິດຕາມຢ່າງລະມັດລະວັງຄືກັບໃນ Master.
• ແລະຖ້າທ່ານມີການສອບຖາມທີ່ໄວແລະຍາວຢູ່ໃນ replicas, ຫຼັງຈາກນັ້ນໃນກໍລະນີນີ້ມັນກໍ່ດີກວ່າທີ່ຈະແບ່ງປັນພວກມັນເພື່ອແຈກຢາຍການໂຫຼດ. ນີ້ແມ່ນລິ້ງໄປຫາ streaming_delay. ສໍາລັບໄວ, ໃຫ້ມີການຈໍາລອງແບບຫນຶ່ງທີ່ມີການຊັກຊ້າການຈໍາລອງຂະຫນາດນ້ອຍ. ສໍາລັບການຮ້ອງຂໍການລາຍງານໄລຍະຍາວ, ມີ replica ທີ່ສາມາດຊັກຊ້າ 6 ຊົ່ວໂມງຫຼືຕໍ່ມື້. ນີ້ແມ່ນສະຖານະການປົກກະຕິຢ່າງສົມບູນ.

ພວກເຮົາ ກຳ ຈັດຜົນສະທ້ອນໃນລັກສະນະດຽວກັນ:

• ພວກເຮົາຊອກຫາຕາຕະລາງ bloated.
• ແລະພວກເຮົາບີບອັດມັນດ້ວຍເຄື່ອງມືທີ່ສະດວກທີ່ສຸດທີ່ເຫມາະສົມກັບພວກເຮົາ.

ເລື່ອງທີສອງສິ້ນສຸດລົງຢູ່ທີ່ນີ້. ຂໍໃຫ້ກ້າວໄປສູ່ເລື່ອງທີສາມ.

ນອກຈາກນີ້ຍັງຂ້ອນຂ້າງທົ່ວໄປສໍາລັບພວກເຮົາທີ່ພວກເຮົາເຮັດການເຄື່ອນຍ້າຍ.

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

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

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

ພວກ​ເຮົາ​ໄດ້​ດໍາ​ເນີນ​ການ​ເຄື່ອນ​ຍ້າຍ​ແລະ​ມີ​ບັນ​ຫາ​ອີກ​ເທື່ອ​ຫນຶ່ງ.

ການເຄື່ອນຍ້າຍໄດ້ປະສົບຜົນສໍາເລັດ, ແຕ່:

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

ແລະ​ນີ້​ແມ່ນ​ອີກ​ເທື່ອ​ຫນຶ່ງ bloat, ເຊິ່ງ​ອີກ​ເທື່ອ​ຫນຶ່ງ​ທໍາ​ລາຍ​ຊີ​ວິດ​ຂອງ​ພວກ​ເຮົາ.

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

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

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

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

ແລະໃນເວລາດຽວກັນພວກເຮົາຈະບໍ່ໄດ້ຮັບການ bloat ແລະຈະບໍ່ທົນທຸກໃນແງ່ຂອງການປະຕິບັດ.

ນີ້ແມ່ນບ່ອນທີ່ເລື່ອງທີສາມສິ້ນສຸດລົງ.

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat.sql

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat_approx.sql

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

ກ່ອນທີ່ຈະຊອກຫາ bloat, ທ່ານຕ້ອງຕິດຕັ້ງສ່ວນຂະຫຍາຍ pgstattuple.

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

• ອັນທໍາອິດໃຊ້ເວລາຂ້ອນຂ້າງຍາວໃນການເຮັດວຽກ, ແຕ່ມັນຈະສະແດງໃຫ້ທ່ານເຫັນຄ່າ bloat ທີ່ແນ່ນອນຈາກຕາຕະລາງ.
• ອັນທີສອງເຮັດວຽກໄດ້ໄວຂຶ້ນແລະມີປະສິດຕິຜົນຫຼາຍເມື່ອທ່ານຈໍາເປັນຕ້ອງປະເມີນຢ່າງໄວວາວ່າມີອາການບວມຫຼືບໍ່ຕາມຕາຕະລາງ. ແລະທ່ານກໍ່ຄວນເຂົ້າໃຈວ່າ bloat ແມ່ນມີຢູ່ໃນຕາຕະລາງ Postgres ສະເຫມີ. ນີ້ແມ່ນລັກສະນະຂອງຕົວແບບ MVCC ຂອງມັນ.
• ແລະ 20% bloat ແມ່ນປົກກະຕິສໍາລັບຕາຕະລາງໃນກໍລະນີຫຼາຍທີ່ສຸດ. ນັ້ນແມ່ນ, ທ່ານບໍ່ຄວນກັງວົນແລະບີບອັດຕາຕະລາງນີ້.

ພວກເຮົາຊອກຫາວິທີການກໍານົດຕາຕະລາງທີ່ມີອາການບວມດ້ວຍຂໍ້ມູນທີ່ບໍ່ມີປະໂຫຍດ.

ໃນປັດຈຸບັນກ່ຽວກັບວິທີການແກ້ໄຂ bloat:

• ຖ້າພວກເຮົາມີແທັບເລັດຂະຫນາດນ້ອຍແລະແຜ່ນດີ, ນັ້ນແມ່ນ, ໃນແທັບເລັດສູງເຖິງ gigabyte, ມັນກໍ່ເປັນໄປໄດ້ທີ່ຈະໃຊ້ VACUUM FULL. ລາວຈະເອົາ lock ພິເສດຈາກເຈົ້າຢູ່ເທິງໂຕະເປັນເວລາສອງສາມວິນາທີແລະດີ, ແຕ່ລາວຈະເຮັດທຸກຢ່າງຢ່າງໄວວາແລະຮຸນແຮງ. VACUUM FULL ເຮັດຫຍັງ? ມັນໃຊ້ເວລາລັອກສະເພາະຢູ່ໃນຕາຕະລາງແລະ rewrites ແຖວສົດຈາກຕາຕະລາງເກົ່າເຂົ້າໄປໃນຕາຕະລາງໃຫມ່. ແລະ​ໃນ​ທີ່​ສຸດ​ພະອົງ​ປ່ຽນ​ແທນ​ເຂົາ​ເຈົ້າ. ມັນລຶບໄຟລ໌ເກົ່າ ແລະປ່ຽນໄຟລ໌ເກົ່າດ້ວຍອັນໃໝ່. ແຕ່ສໍາລັບໄລຍະເວລາຂອງການເຮັດວຽກຂອງມັນ, ມັນໃຊ້ເວລາລັອກສະເພາະຢູ່ໃນຕາຕະລາງ. ນີ້ຫມາຍຄວາມວ່າທ່ານບໍ່ສາມາດເຮັດຫຍັງກັບຕາຕະລາງນີ້: ທັງຂຽນໃສ່ມັນ, ຫຼືອ່ານມັນ, ຫຼືດັດແປງມັນ. ແລະ VACUUM FULL ຕ້ອງການພື້ນທີ່ດິດເພີ່ມເຕີມເພື່ອຂຽນຂໍ້ມູນ.
• ເຄື່ອງມືຕໍ່ໄປ pg_repack. ໃນຫຼັກການຂອງມັນ, ມັນຄ້າຍຄືກັນກັບ VACUUM FULL, ເພາະວ່າມັນຍັງຂຽນຄືນຂໍ້ມູນຈາກໄຟລ໌ເກົ່າໄປຫາໃຫມ່ແລະປ່ຽນແທນມັນຢູ່ໃນຕາຕະລາງ. ແຕ່ໃນເວລາດຽວກັນ, ມັນບໍ່ໄດ້ໃຊ້ການລັອກສະເພາະຢູ່ໃນຕາຕະລາງໃນຕອນເລີ່ມຕົ້ນຂອງການເຮັດວຽກຂອງມັນ, ແຕ່ໃຊ້ເວລາມັນພຽງແຕ່ໃນເວລາທີ່ມັນມີຂໍ້ມູນພ້ອມແລ້ວເພື່ອທົດແທນໄຟລ໌. ຄວາມຕ້ອງການຊັບພະຍາກອນຂອງແຜ່ນແມ່ນຄ້າຍຄືກັນກັບ VACUUM FULL. ທ່ານຕ້ອງການພື້ນທີ່ດິດເພີ່ມເຕີມ, ແລະບາງຄັ້ງນີ້ແມ່ນສໍາຄັນຖ້າທ່ານມີຕາຕະລາງ terabyte. ແລະມັນຂ້ອນຂ້າງຫິວເພາະມັນເຮັດວຽກກັບ I/O ຢ່າງຫ້າວຫັນ.
• ຜົນປະໂຫຍດທີສາມແມ່ນ pgcompactable. ມັນມີຄວາມລະມັດລະວັງຫຼາຍກັບຊັບພະຍາກອນເພາະວ່າມັນເຮັດວຽກຕາມຫຼັກການທີ່ແຕກຕ່າງກັນເລັກນ້ອຍ. ແນວຄວາມຄິດຕົ້ນຕໍຂອງ pgcompacttable ແມ່ນວ່າມັນຈະຍ້າຍແຖວທີ່ມີຊີວິດທັງຫມົດໄປຫາຈຸດເລີ່ມຕົ້ນຂອງຕາຕະລາງໂດຍໃຊ້ການປັບປຸງໃນຕາຕະລາງ. ແລະຫຼັງຈາກນັ້ນມັນແລ່ນສູນຍາກາດຢູ່ໃນຕາຕະລາງນີ້, ເພາະວ່າພວກເຮົາຮູ້ວ່າພວກເຮົາມີແຖວທີ່ມີຊີວິດໃນຕອນຕົ້ນແລະແຖວຕາຍໃນທ້າຍ. ແລະສູນຍາກາດຕົວມັນເອງຕັດຫາງນີ້, i.e. ມັນບໍ່ຕ້ອງການພື້ນທີ່ດິດເພີ່ມເຕີມ. ແລະໃນເວລາດຽວກັນ, ມັນຍັງສາມາດຖືກບີບດ້ວຍຊັບພະຍາກອນ.

ທຸກສິ່ງທຸກຢ່າງທີ່ມີເຄື່ອງມື.

ຖ້າທ່ານຊອກຫາຫົວຂໍ້ bloat ທີ່ຫນ້າສົນໃຈໃນແງ່ຂອງການ delving ຕື່ມອີກພາຍໃນ, ນີ້ແມ່ນບາງການເຊື່ອມຕໍ່ທີ່ເປັນປະໂຫຍດ:

• https://www.slideshare.net/alexius2Mb/where-is-the-space-postgres - ນີ້ແມ່ນບົດລາຍງານຈາກເພື່ອນຮ່ວມງານຂອງຂ້ອຍ. ມັນເປັນເລື່ອງທົ່ວໄປກ່ຽວກັບບ່ອນທີ່ພື້ນທີ່ຂອງ Postgres ໄປໃນລະຫວ່າງການເຮັດວຽກແລະຊີວິດຂອງມັນ. ແລະມີຊິ້ນສ່ວນດ້ານວິຊາການຂະຫນາດໃຫຍ່ແລະລາຍລະອຽດຫຼາຍສໍາລັບຜູ້ບໍລິຫານຖານຂໍ້ມູນກ່ຽວກັບ bloat.
• https://github.com/dataegret/pg-utils – ນີ້​ແມ່ນ​ການ​ເຊື່ອມ​ຕໍ່​ກັບ repository ຂອງ​ພວກ​ເຮົາ, ບ່ອນ​ທີ່​ພວກ​ເຮົາ​ເກັບ​ຮັກ​ສາ​ຊໍ່​ຂອງ scripts ທີ່​ເປັນ​ປະ​ໂຫຍດ​ສໍາ​ລັບ​ການ​ກວດ​ສອບ​ສະ​ຖາ​ນະ​ຂອງ​ຖານ​ຂໍ້​ມູນ. ຢູ່ທີ່ນັ້ນເຈົ້າສາມາດຊອກຫາສະຄຣິບເພື່ອຄົ້ນຫາ bloat.
• ທີສາມ и ທີສີ່ ການເຊື່ອມຕໍ່ກັບເຄື່ອງມືທີ່ຈະຊ່ວຍໃຫ້ທ່ານຫຼຸດລົງອາການ.
• http://blog.dataegret.com/2Mb018/03/postgresql-bloatbusters.html - ນີ້ແມ່ນຂໍ້ຄວາມຈາກເພື່ອນຮ່ວມງານຂອງຂ້ອຍ. ຢູ່ທີ່ນັ້ນ, ລາວໄດ້ວິເຄາະຢ່າງຈິງຈັງແລະດ້ານວິຊາການຢ່າງເລິກເຊິ່ງໃນລະດັບທີ່ໃກ້ຊິດກັບຜູ້ບໍລິຫານ.

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

ຄໍາຖາມຂອງທ່ານ

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

ໃນກໍລະນີນີ້, ນີ້ແມ່ນວຽກງານສໍາລັບຜູ້ບໍລິຫານຂອງບໍລິສັດຂອງທ່ານ, ບໍ່ຈໍາເປັນສໍາລັບ DBA.

ຂ້ອຍເປັນຜູ້ບໍລິຫານ.

PostgreSQL ມີມຸມເບິ່ງທີ່ເອີ້ນວ່າ pg_stat_activity ທີ່ສະແດງໃຫ້ເຫັນການສອບຖາມ dangling. ແລະເຈົ້າສາມາດເຫັນໄດ້ວ່າມັນຄ້າງຢູ່ທີ່ນັ້ນດົນປານໃດ.

ຂ້ອຍຕ້ອງເຂົ້າມາເບິ່ງທຸກໆ 5 ນາທີບໍ?

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

ມີເຫດຜົນທີ່ຊັດເຈນວ່າເປັນຫຍັງສິ່ງນີ້ເກີດຂຶ້ນ?

ຂ້າພະເຈົ້າໄດ້ລະບຸໄວ້ບາງ. ຕົວຢ່າງອື່ນໆທີ່ສັບສົນຫຼາຍ. ແລະສາມາດມີການສົນທະນາເປັນເວລາດົນນານ.

ຂອບໃຈສໍາລັບບົດລາຍງານ! ຂ້ອຍຕ້ອງການຄວາມກະຈ່າງແຈ້ງກ່ຽວກັບຜົນປະໂຫຍດ pg_repack. ຖ້ານາງບໍ່ເຮັດການລັອກສະເພາະ, ຫຼັງຈາກນັ້ນ ...

ນາງເຮັດການລັອກສະເພາະ.

... ແລ້ວຂ້ອຍອາດຈະສູນເສຍຂໍ້ມູນ. ແອັບພລິເຄຊັນຂອງຂ້ອຍບໍ່ຄວນບັນທຶກຫຍັງໃນລະຫວ່າງນີ້ບໍ?

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

ນັ້ນແມ່ນ, ລາວເຮັດມັນໃນທີ່ສຸດບໍ?

ໃນທີ່ສຸດ, ລາວໃຊ້ການລັອກສະເພາະເພື່ອແລກປ່ຽນໄຟລ໌ເຫຼົ່ານີ້.

ມັນຈະໄວກວ່າ VACUUM FULL ບໍ?

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

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

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

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

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

ຂອບໃຈສໍາລັບບົດລາຍງານ! ມັນຍອມຮັບໄດ້ບໍທີ່ຈະໃຊ້ການສອບຖາມການໝົດເວລາຂອງຖະແຫຼງການເພື່ອຈຳກັດໄລຍະເວລາ?

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

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

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

ນັ້ນແມ່ນ, ມັນປິດທັນທີຫຼັງຈາກການປັບປຸງ?

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

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

ພື້ນທີ່ຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຕ້ອງໄດ້ຮັບການຕິດຕາມກວດກາຢ່າງຖືກຕ້ອງ.

ຕົວຢ່າງ, DBA ໄດ້ໄປຫາຊາ, ຢູ່ຣີສອດ, ແລະອື່ນໆ.

ເມື່ອລະບົບໄຟລ໌ຖືກສ້າງຂື້ນ, ຢ່າງຫນ້ອຍບາງປະເພດຂອງພື້ນທີ່ສໍາຮອງຂໍ້ມູນໄດ້ຖືກສ້າງຂື້ນບ່ອນທີ່ຂໍ້ມູນບໍ່ໄດ້ຖືກຂຽນ.

ຈະເປັນແນວໃດຖ້າມັນຕໍ່າກວ່າສູນທັງຫມົດ?

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

ມີເຄື່ອງມືອື່ນບໍ?

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

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

ພວກເຂົາເຈົ້າຫຸ້ມຫໍ່ໃຫ້ເຂົາເຈົ້າຄືກັນ.

ແຕ່ສູນຍາກາດບໍ່ມີຜົນຕໍ່ດັດຊະນີບໍ?

ບາງຄົນເຮັດວຽກກັບດັດສະນີ. ຕົວຢ່າງ, pg_rapack, pgcompacttable. ສູນຍາກາດ recreates ດັດຊະນີແລະຜົນກະທົບຕໍ່ເຂົາເຈົ້າ. ດ້ວຍ VACUUM FULL ແນວຄວາມຄິດແມ່ນເພື່ອຂຽນທັບທຸກສິ່ງທຸກຢ່າງ, ເຊັ່ນວ່າມັນເຮັດວຽກກັບທຸກຄົນ.

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

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

Andrey, ຂ້ອຍມີຄໍາຖາມ. ເສັ້ນສະແດງທີ່ຍອດຢ້ຽມເຫຼົ່ານີ້ທີ່ທ່ານສະແດງໃຫ້ເຫັນໃນລະຫວ່າງການນໍາສະເຫນີ, ນີ້ແມ່ນຜົນມາຈາກການເຮັດວຽກຂອງຜົນປະໂຫຍດບາງຢ່າງຂອງເຈົ້າບໍ? ກຣາຟຖືກສ້າງຂື້ນແນວໃດ?

ນີ້ແມ່ນການບໍລິການ Okmeter.

ນີ້ແມ່ນຜະລິດຕະພັນການຄ້າບໍ?

ແມ່ນແລ້ວ. ນີ້ແມ່ນຜະລິດຕະພັນການຄ້າ.

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