DELETE ທີ່ຮັກແພງ. Nikolay Samokhvalov (Postgres.ai)

ບາງຄັ້ງໃນອະນາຄົດທີ່ຫ່າງໄກ, ການໂຍກຍ້າຍອັດຕະໂນມັດຂອງຂໍ້ມູນທີ່ບໍ່ຈໍາເປັນຈະເປັນຫນຶ່ງໃນວຽກງານທີ່ສໍາຄັນຂອງ DBMS [1]. ໃນເວລານີ້, ພວກເຮົາເອງຕ້ອງເບິ່ງແຍງການລຶບຫຼືຍ້າຍຂໍ້ມູນທີ່ບໍ່ຈໍາເປັນໄປສູ່ລະບົບການເກັບຮັກສາທີ່ມີລາຄາແພງກວ່າ. ສົມມຸດວ່າເຈົ້າຕັດສິນໃຈລຶບສອງສາມລ້ານແຖວ. ວຽກງານທີ່ງ່າຍດາຍພໍສົມຄວນ, ໂດຍສະເພາະຖ້າຫາກວ່າເງື່ອນໄຂແມ່ນເປັນທີ່ຮູ້ຈັກແລະມີດັດຊະນີທີ່ເຫມາະສົມ. "DELETE FROM table1 WHERE col1 = :value" - ສິ່ງທີ່ອາດຈະງ່າຍກວ່າ, ແມ່ນບໍ?

ວິດີໂອ:

• ຂ້າພະເຈົ້າໄດ້ຢູ່ໃນຄະນະກໍາມະການໂຄງການ Highload ນັບຕັ້ງແຕ່ປີທໍາອິດ, i.e. ນັບຕັ້ງແຕ່ 2007.

• ແລະຂ້ອຍໄດ້ຢູ່ກັບ Postgres ຕັ້ງແຕ່ປີ 2005. ໃຊ້ມັນຢູ່ໃນຫຼາຍໂຄງການ.

• ກຸ່ມກັບ RuPostges ຍັງຕັ້ງແຕ່ປີ 2007.

• ພວກເຮົາໄດ້ເພີ່ມຂຶ້ນເປັນ 2100+ ຜູ້ເຂົ້າຮ່ວມຢູ່ Meetup. ເປັນອັນດັບ XNUMX ຂອງໂລກ ຫຼັງຈາກນິວຢອກ, ເອົາຊະນະ ຊານຟຣານຊິສໂກ ເປັນເວລາດົນນານ.

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

https://postgres.ai/ ແມ່ນບໍລິສັດຂອງຂ້ອຍ. ພວກເຮົາຢູ່ໃນທຸລະກິດຂອງວຽກງານອັດຕະໂນມັດທີ່ລົບລ້າງການຊ້າລົງຂອງການພັດທະນາ.

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

https://www.seagate.com/files/www-content/our-story/trends/files/idc-seagate-dataage-whitepaper.pdf

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

ມີຂໍ້ມູນຫຼາຍກວ່າແລະຫຼາຍໃນໂລກຂອງ zettabytes - ນັ້ນແມ່ນ 1 petabytes. ແລະໃນປັດຈຸບັນມັນໄດ້ຖືກຄາດຄະເນແລ້ວວ່າພວກເຮົາມີຫຼາຍກວ່າ 000 zettabytes ຂອງຂໍ້ມູນທີ່ເກັບໄວ້ໃນໂລກ. ແລະມີຫຼາຍກວ່າແລະຫຼາຍຂອງພວກເຂົາ.

https://vldb2019.github.io/files/VLDB19-keynote-2-slides.pdf

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

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

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

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

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

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

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

ຖານຂໍ້ມູນເຕີບໃຫຍ່ແລະເຕີບໃຫຍ່. DELETE ປະຈໍາວັນເລີ່ມເຮັດວຽກຊ້າກວ່າເລັກນ້ອຍ.

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

ສອງສາມເດືອນຕໍ່ມາເຂົາເຈົ້າຈື່ໄດ້. ແລະຜູ້ພັດທະນາຄົນນັ້ນເຊົາ ຫຼືຫຍຸ້ງກັບອັນອື່ນ, ແນະນຳໃຫ້ຜູ້ອື່ນສົ່ງມັນຄືນ.

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

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

ມີບາງຢ່າງຜິດພາດບໍ? ນີ້ແມ່ນບັນຊີລາຍຊື່ຂອງສິ່ງທີ່ອາດຈະຜິດພາດ. ອັນໃດສຳຄັນທີ່ສຸດ?

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

• ບາງທີພວກເຂົາກວດເບິ່ງບາງຢ່າງຜິດພາດ.

• ບາງທີຮາດແວແມ່ນລ້າສະໄຫມແລະທ່ານຈໍາເປັນຕ້ອງຍົກລະດັບພື້ນຖານນີ້.

• ຫຼືບາງສິ່ງບາງຢ່າງຜິດພາດກັບຖານຂໍ້ມູນຂອງມັນເອງ, ແລະພວກເຮົາຈໍາເປັນຕ້ອງຍ້າຍຈາກ Postgres ໄປ MySQL.

• ຫຼືບາງທີມີບາງສິ່ງບາງຢ່າງຜິດພາດກັບການດໍາເນີນງານ.

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

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

ແລະລາວຈະເວົ້າວ່າທ່ານຈະມີບັນຫາກັບ disk IO ແລະຂະບວນການທັງຫມົດຈະບ້າ, ອາດຈະມີການລັອກ, ແລະທ່ານຈະຕັນ autovacuum ສໍາລັບຊໍ່ຂອງນາທີ, ດັ່ງນັ້ນນີ້ບໍ່ດີ.

http://bit.ly/nancy-hl2018-2

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

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

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

ບາງທີອຸປະກອນຂອງພວກເຮົາບໍ່ດີບໍ? ຖ້າທ່ານເບິ່ງ, ຫຼັງຈາກນັ້ນ, latency jumped. ພວກເຮົາໄດ້ເຫັນວ່າການນໍາໃຊ້ແມ່ນ 100%. ແນ່ນອນ, ຖ້າສິ່ງເຫຼົ່ານີ້ແມ່ນໄດ NVMe ທີ່ທັນສະໄຫມ, ມັນອາດຈະງ່າຍຂຶ້ນຫຼາຍສໍາລັບພວກເຮົາ. ແລະບາງທີພວກເຮົາຈະບໍ່ໄດ້ວາງລົງຈາກມັນ.

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

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

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

ການຕັ້ງຄ່າໃນ Postgres ແມ່ນຊັກຊ້າ. ເຂົາເຈົ້າໄດ້ຖືກອອກແບບສໍາລັບ 10-15 ປີປະລິມານຂໍ້ມູນແລະການເຮັດທຸລະກໍາ. ແລະດ່ານແມ່ນບໍ່ມີຂໍ້ຍົກເວັ້ນ.

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

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

ແລະໂດຍຄ່າເລີ່ມຕົ້ນ max_wal_saze ຖືກກໍານົດເປັນ 1 gigabyte. ໃນຄວາມເປັນຈິງ, ນີ້ກໍ່ເກີດຂື້ນໃນ Postgres ຫຼັງຈາກ 300-400 megabytes. ທ່ານໄດ້ປ່ຽນແປງຂໍ້ມູນຫຼາຍຢ່າງແລະຈຸດກວດກາຂອງທ່ານເກີດຂຶ້ນ.

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

ແລະພວກເຮົາຈໍາເປັນຕ້ອງໃຫ້ແນ່ໃຈວ່າມັນມາຫນ້ອຍລົງເລື້ອຍໆ. ນັ້ນແມ່ນ, ພວກເຮົາສາມາດຍົກສູງ max_wal_size. ແລະມັນຈະມາຫນ້ອຍລົງເລື້ອຍໆ.

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

ດັ່ງນັ້ນ, ພວກເຮົາກໍາລັງດໍາເນີນການທົດລອງສອງຊຸດກ່ຽວກັບຖານຂໍ້ມູນ.

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

ເຈົ້າສາມາດເຫັນໄດ້ວ່າມັນຍາກສໍ່າໃດສຳລັບພວກເຮົາ. ພວກເຮົາເຫັນວ່າ disk IO ແມ່ນບໍ່ດີຫຼາຍ. ພວກເຮົາເບິ່ງວ່າພວກເຮົາສ້າງ WAL ຫຼາຍປານໃດ, ເພາະວ່ານີ້ມີຄວາມສໍາຄັນຫຼາຍ. ຂໍໃຫ້ເບິ່ງວ່າມີຈຸດກວດກາເກີດຂຶ້ນຫຼາຍປານໃດ. ແລະພວກເຮົາເຫັນວ່າມັນບໍ່ດີ.

ຕໍ່ໄປພວກເຮົາເພີ່ມ max_wal_size. ພວກເຮົາເຮັດຊ້ຳ. ພວກເຮົາເພີ່ມຂຶ້ນ, ພວກເຮົາເຮັດເລື້ມຄືນ. ແລະຫຼາຍເທື່ອ. ໃນຫຼັກການ, 10 ຈຸດແມ່ນດີ, ບ່ອນທີ່ 1, 2, 4, 8 gigabyte. ແລະພວກເຮົາເບິ່ງພຶດຕິກໍາຂອງລະບົບສະເພາະໃດຫນຶ່ງ. ມັນເປັນທີ່ຊັດເຈນວ່າໃນທີ່ນີ້ອຸປະກອນຄວນຈະຄືກັບຜະລິດຕະພັນ. ທ່ານຕ້ອງມີແຜ່ນດຽວກັນ, ຈໍານວນຫນ່ວຍຄວາມຈໍາດຽວກັນ, ແລະການຕັ້ງຄ່າ Postgres ດຽວກັນ.

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

ດ່ານກວດໃນພາສາລັດເຊຍແມ່ນດ່ານກວດກາ.

ຕົວຢ່າງ: ລົບຫຼາຍລ້ານແຖວໂດຍດັດສະນີ, ແຖວຖືກ "ກະແຈກກະຈາຍ" ໄປທົ່ວໜ້າ.

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

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

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

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

ເປັນຫຍັງມັນຈຶ່ງ?

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

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

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

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

ພຶດຕິກໍາການຂຽນ WAL ຂອງບັນທຶກການສົ່ງຕໍ່ແມ່ນເຊັ່ນວ່າເມື່ອພວກເຮົາມີຈຸດກວດກາແລະພວກເຮົາປ່ຽນຫນ້າຄັ້ງທໍາອິດ, ຫນ້າທັງຫມົດ, i.e. ທັງຫມົດ 8 ກິໂລໄບ, ເຂົ້າໄປໃນບັນທຶກການສົ່ງຕໍ່, ເຖິງແມ່ນວ່າພວກເຮົາພຽງແຕ່ປ່ຽນຫນ້າ. ເສັ້ນ, ເຊິ່ງມີນ້ໍາຫນັກ 100 bytes . ແລະພວກເຮົາຕ້ອງຂຽນລົງໃນຫນ້າທັງຫມົດ.

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

ແລະ, ຕາມຄວາມເຫມາະສົມ, ຖ້າຈຸດກວດກາເກີດຂຶ້ນອີກເທື່ອຫນຶ່ງ, ພວກເຮົາຕ້ອງເລີ່ມຕົ້ນທຸກສິ່ງທຸກຢ່າງຈາກ scratch ອີກເທື່ອຫນຶ່ງແລະຍູ້ຫນ້າທັງຫມົດ. ດ້ວຍການກວດກາເລື້ອຍໆ, ເມື່ອພວກເຮົາຍ່າງຜ່ານຫນ້າດຽວກັນ, full_page_writes = on ຈະມີຫຼາຍກວ່າທີ່ມັນອາດຈະເປັນ, i.e. ພວກເຮົາສ້າງ WAL ຫຼາຍຂຶ້ນ. ເພີ່ມເຕີມແມ່ນຖືກສົ່ງໄປຫາ replicas, ໄປຮວບຮວມ, to disk.

ແລະ, ຕາມຄວາມເຫມາະສົມ, ພວກເຮົາມີສອງຊ້ໍາຊ້ອນ.

ຖ້າພວກເຮົາເພີ່ມ max_wal_size, ມັນຈະກາຍເປັນວ່າພວກເຮົາເຮັດໃຫ້ມັນງ່າຍຂຶ້ນສໍາລັບທັງ checkpoint ແລະ wal writer. ແລະນັ້ນຍິ່ງໃຫຍ່.

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

ພວກເຮົາດໍາເນີນການປະຕິບັດງານແລະເບິ່ງເວລາທີ່ດ່ານກໍາລັງຈະສໍາເລັດ, ພວກເຮົາຂ້າ -9 Postgres ຈຸດປະສົງ.

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

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

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

ແລະນີ້ແມ່ນຈຸດທີ່ຫນ້າສົນໃຈ. ພວກເຮົາມີບົດລາຍງານສອງສາມຢ່າງກ່ຽວກັບ Patroni ໃນກອງປະຊຸມ. ແລະບາງທີທ່ານກໍາລັງໃຊ້ມັນ. ນີ້ແມ່ນ autofailover ສໍາລັບ Postgres. GitLab ແລະ Data Egret ເວົ້າກ່ຽວກັບເລື່ອງນີ້.

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

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

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

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

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

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

DELETE ກັບ ROLLBACK ນີ້ແມ່ນເຫມາະສົມສໍາລັບການປັບຈຸດກວດກາ, ເຖິງແມ່ນວ່າທ່ານບໍ່ມີຫ້ອງທົດລອງຖານຂໍ້ມູນທີ່ຖືກປະຕິບັດຢ່າງຖືກຕ້ອງ.

ພວກເຮົາເຮັດແຜ່ນທີ່ມີຖັນຫນຶ່ງ "i". Postgres ມີຖັນຜົນປະໂຫຍດ. ພວກມັນເບິ່ງບໍ່ເຫັນເວັ້ນເສຍແຕ່ຈະຖາມໂດຍສະເພາະ. ເຫຼົ່ານີ້ແມ່ນ: ctid, xmid, xmax.

Ctid ແມ່ນທີ່ຢູ່ທາງດ້ານຮ່າງກາຍ. ຫນ້າສູນ, tuple ທໍາອິດໃນຫນ້າ.

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

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

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

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

ເປັນຫຍັງມັນຈຶ່ງສໍາຄັນທີ່ຈະທໍາລາຍ?

• ຖ້າພວກເຮົາເຫັນວ່າແຜ່ນແຂງ, ຫຼັງຈາກນັ້ນໃຫ້ມັນຊ້າລົງ. ແລະຖ້າພວກເຮົາຖືກແຍກ, ຫຼັງຈາກນັ້ນພວກເຮົາສາມາດເພີ່ມການຢຸດຊົ່ວຄາວ, ພວກເຮົາສາມາດຊ້າລົງ throttling.

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

https://postgres.ai/products/joe/

ນີ້ແມ່ນຫນ້າສົນໃຈ. ຂ້ອຍມັກຈະເຫັນວ່ານັກພັດທະນາຖາມວ່າ: "ຂ້ອຍຄວນເລືອກຂະຫນາດຊຸດໃດ?".

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

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

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

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

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

ໂດຍວິທີທາງການ, ທຸກສິ່ງທຸກຢ່າງທີ່ຂ້າພະເຈົ້າເວົ້າກ່ຽວກັບບໍ່ພຽງແຕ່ກ່ຽວກັບການ DELETE ເທົ່ານັ້ນ. ຕາມທີ່ທ່ານເດົາ, ເຫຼົ່ານີ້ແມ່ນການດໍາເນີນການຈໍານວນຫຼາຍກ່ຽວກັບຂໍ້ມູນ.

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

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

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

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

https://docs.gitlab.com/ee/development/background_migrations.html

ຍຸດທະສາດການແບ່ງສ່ວນແມ່ນຫຍັງ? ຂ້ອຍເຫັນ 3 ຍຸດທະສາດການແບ່ງປັນທີ່ແຕກຕ່າງກັນທີ່ນັກພັດທະນາຢູ່ໃນຊຸດກໍາລັງໃຊ້.

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

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

ໃນຍຸດທະສາດທໍາອິດ, ເຊັ່ນດຽວກັນ, ໂດຍວິທີທາງການ, ທ່ານສາມາດເຮັດໄດ້ໃນຫຼາຍຫົວຂໍ້. ມັນບໍ່ຍາກ.

https://medium.com/@samokhvalov/how-partial-indexes-affect-update-performance-in-postgres-d05e0052abc

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

ໂດຍທົ່ວໄປແລ້ວ, index only scan ແມ່ນໄວກ່ວາ index scan.

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

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

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

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

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

ທຸລະກໍາຍາວ https://gitlab.com/snippets/1890447

ສະກັດອັດຕະໂນມັດ - https://gitlab.com/snippets/1889668

ບັນ​ຫາ​ການ​ສະ​ກັດ - https://gitlab.com/snippets/1890428

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

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

ຖ້າມີ IO ຂະຫນາດໃຫຍ່, ມັນຈະແຈ້ງວ່ານີ້ແມ່ນບໍ່ດີ.

ການເຮັດທຸລະກໍາຍາວເກີນໄປ. ການເຮັດທຸລະກໍາຍາວບໍ່ຄວນຖືກອະນຸຍາດໃຫ້ຢູ່ໃນ OLTP. ແລະນີ້ແມ່ນການເຊື່ອມຕໍ່ກັບ snippet ທີ່ອະນຸຍາດໃຫ້ທ່ານເອົາ snippet ນີ້ແລະແລ້ວຕິດຕາມບາງທຸລະກໍາຍາວ.

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

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

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

ບາງຄັ້ງຄວາມຜິດພາດທັງຫມົດເຫຼົ່ານີ້ເກີດຂຶ້ນໃນຈໍານວນລວມ.

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

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

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

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

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

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

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

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

ຕົວຢ່າງ: ຖານຂໍ້ມູນ 5 terabyte, ໄດ້ຮັບສໍາເນົາໃນເວລາຫນ້ອຍກວ່າ 30 ວິນາທີ. ແລະມັນບໍ່ຂຶ້ນກັບຂະຫນາດ, ນັ້ນແມ່ນ, ມັນບໍ່ສໍາຄັນຫຼາຍປານໃດ terabytes.

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

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

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

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

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

ຖ້າທ່ານເບິ່ງ pg_repack ໃນ GitHub, ຢູ່ທີ່ນັ້ນ, ເມື່ອມີວຽກງານທີ່ຈະປ່ຽນ ID ຈາກ int 4 ເປັນ int 8, ຫຼັງຈາກນັ້ນມີຄວາມຄິດທີ່ຈະໃຊ້ pg_repack ຕົວຂອງມັນເອງ. ນີ້ກໍ່ເປັນໄປໄດ້, ແຕ່ວ່າມັນເປັນການ hack ເລັກນ້ອຍ, ແຕ່ມັນຈະເຮັດວຽກສໍາລັບການນີ້ເຊັ່ນດຽວກັນ. ທ່ານສາມາດແຊກແຊງໃນ ​​trigger ທີ່ pg_repack ໃຊ້ແລະເວົ້າວ່າ: "ພວກເຮົາບໍ່ຕ້ອງການຂໍ້ມູນນີ້", i.e. ພວກເຮົາພຽງແຕ່ໂອນສິ່ງທີ່ພວກເຮົາຕ້ອງການ. ແລະຫຼັງຈາກນັ້ນລາວພຽງແຕ່ປ່ຽນແລະນັ້ນແມ່ນມັນ.

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

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

ຂ້ອຍມາຈາກໂລກຂອງ MySQL ເລັກນ້ອຍ, ສະນັ້ນຂ້ອຍມາຟັງ. ແລະພວກເຮົາໃຊ້ວິທີການນີ້.

ແຕ່ວ່າມັນເປັນພຽງແຕ່ຖ້າພວກເຮົາມີ 90%. ຖ້າພວກເຮົາມີ 5%, ມັນກໍ່ບໍ່ດີທີ່ຈະໃຊ້ມັນ.

ຂອບໃຈສໍາລັບບົດລາຍງານ! ຖ້າບໍ່ມີຊັບພະຍາກອນທີ່ຈະເຮັດສໍາເນົາທີ່ສົມບູນຂອງ prod, ມີ algorithm ຫຼືສູດການຄິດໄລ່ການໂຫຼດຫຼືຂະຫນາດບໍ?

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

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

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

ເຮັດດ້ວຍດັດຊະນີ.

ຂ້າ​ພະ​ເຈົ້າ​ສາ​ມາດ​ສົມ​ມຸດ​ວ່າ​ການ​ປັບ​ຈຸດ​ກວດ​ສອບ​ດຽວ​ກັນ​ສາ​ມາດ​ອັດ​ຕະ​ໂນ​ມັດ​. ມື້ຫນຶ່ງມັນອາດຈະເປັນ. ແຕ່ຫຼັງຈາກນັ້ນຂ້ອຍກໍ່ບໍ່ເຂົ້າໃຈຄໍາຖາມ.

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

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

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

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

Autovacuum ອາດຈະບໍ່ແມ່ນບັນຫາໃຫຍ່ທີ່ສຸດຢູ່ທີ່ນີ້. ແລະຄວາມຈິງທີ່ວ່າການເຮັດທຸລະກໍາທີ່ຍາວນານສາມາດລັອກການເຮັດທຸລະກໍາອື່ນໆ, ຄວາມເປັນໄປໄດ້ນີ້ແມ່ນອັນຕະລາຍຫຼາຍ. ນາງອາດຈະຫຼືອາດຈະບໍ່ພົບ. ຖ້ານາງໄດ້ພົບ, ມັນອາດຈະເປັນສິ່ງທີ່ບໍ່ດີຫຼາຍ. ແລະດ້ວຍ autovacuum - ນີ້ແມ່ນບັນຫາເຊັ່ນກັນ. ມີສອງບັນຫາກ່ຽວກັບການເຮັດທຸລະກໍາຍາວໃນ OLTP: locks ແລະ autovacuum. ແລະຖ້າທ່ານມີຄໍາຕິຊົມສະແຕນບາຍທີ່ເປີດຢູ່ໃນການຈໍາລອງແບບຮ້ອນ, ຫຼັງຈາກນັ້ນທ່ານຍັງຈະໄດ້ຮັບການ lock autovacuum ໃນແມ່ບົດ, ມັນຈະມາຮອດຈາກ replica. ແຕ່ຢ່າງຫນ້ອຍຈະບໍ່ມີການລັອກ. ແລະຈະມີ loks. ພວກເຮົາກໍາລັງເວົ້າກ່ຽວກັບການປ່ຽນແປງຂໍ້ມູນ, ດັ່ງນັ້ນການລັອກແມ່ນຈຸດສໍາຄັນຢູ່ທີ່ນີ້. ແລະຖ້າຫາກວ່າທັງຫມົດນີ້ແມ່ນເປັນເວລາດົນນານ, ເວລາດົນນານ, ຫຼັງຈາກນັ້ນ, ການເຮັດທຸລະກໍາຫຼາຍຂື້ນຖືກລັອກ. ພວກເຂົາສາມາດລັກເອົາຄົນອື່ນ. ແລະ​ຕົ້ນ​ໄມ້​ລົກ​ປະກົດ​ຂຶ້ນ. ຂ້າພະເຈົ້າໄດ້ສະຫນອງການເຊື່ອມຕໍ່ກັບ snippet ໄດ້. ແລະບັນຫານີ້ຈະກາຍເປັນທີ່ສັງເກດເຫັນໄວກວ່າບັນຫາທີ່ມີ autovacuum, ເຊິ່ງພຽງແຕ່ສາມາດສະສົມໄດ້.

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

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

ໃນເວລາທີ່ພວກເຮົາກໍາລັງເຮັດຂີ້ເຫຍື້ອແລ້ວເລືອກແລະພວກເຮົາມີ, ຕົວຢ່າງ, ທຸງທີ່ຖືກລົບ

ນີ້ແມ່ນສິ່ງທີ່ autovacuum ເຮັດໂດຍອັດຕະໂນມັດໃນ Postgres.

ໂອ້, ລາວເຮັດບໍ?

Autovacuum ແມ່ນຜູ້ເກັບຂີ້ເຫຍື້ອ.

!

ຂອບໃຈສໍາລັບບົດລາຍງານ! ມີທາງເລືອກທີ່ຈະອອກແບບຖານຂໍ້ມູນທັນທີດ້ວຍການແບ່ງສ່ວນໃນລັກສະນະທີ່ຂີ້ເຫຍື້ອທັງຫມົດເປື້ອນຈາກຕາຕະລາງຕົ້ນຕໍຢູ່ບ່ອນໃດບ່ອນຫນຶ່ງ?

ແນ່ນອນວ່າມີ.

ມັນເປັນໄປໄດ້ທີ່ຈະປ້ອງກັນຕົວເຮົາເອງຖ້າພວກເຮົາລັອກຕາຕະລາງທີ່ບໍ່ຄວນໃຊ້?

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

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