ເລື່ອງຂອງການລຶບ 300 ລ້ານບັນທຶກທາງຮ່າງກາຍໃນ MySQL

ການນໍາສະເຫນີ

ສະບາຍດີ. ຂ້ອຍແມ່ນ ningenMe, ຜູ້ພັດທະນາເວັບ.

ໃນຖານະເປັນຫົວຂໍ້ເວົ້າວ່າ, ເລື່ອງຂອງຂ້ອຍແມ່ນເລື່ອງຂອງການລຶບ 300 ລ້ານບັນທຶກໃນ MySQL.

ຂ້ອຍສົນໃຈເລື່ອງນີ້, ດັ່ງນັ້ນຂ້ອຍຈຶ່ງຕັດສິນໃຈເຮັດການເຕືອນ (ຄໍາແນະນໍາ).

ຫນ້າທໍາອິດ - ແຈ້ງເຕືອນ

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

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

ກຳ ລັງຊອກຫາເຫດຜົນ

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

hoge_table | 350'000'000 |

350 ລ້ານບັນທຶກ. ດັດສະນີເບິ່ງຄືວ່າຈະເຮັດວຽກຢ່າງຖືກຕ້ອງ, ພຽງແຕ່ຊ້າຫຼາຍ.

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

DB

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

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

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

ແລະຫຼັງຈາກນັ້ນຂ້າພະເຈົ້າໄດ້ເຂົ້າໄປໃນການປະຕິບັດ.

ການແກ້ໄຂ

ມັນເປັນການສົມເຫດສົມຜົນຫຼາຍທີ່ຈະຫຼຸດລົງຂະຫນາດຂອງຖານຂໍ້ມູນຕົວມັນເອງແລະຫຼຸດຜ່ອນເວລາສໍາລັບການປຸງແຕ່ງມັນກ່ວາການປ່ຽນແປງເຫດຜົນຂອງມັນເອງ.

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

ການປະຕິບັດ 1

ມີການກະກຽມສໍາຮອງຂໍ້ມູນທີ່ເຊື່ອຖືໄດ້, ສຸດທ້າຍຂ້າພະເຈົ້າໄດ້ເລີ່ມຕົ້ນສົ່ງຄໍາຮ້ອງຂໍ.

"ສົ່ງຄໍາຮ້ອງຂໍ"

DELETE FROM hoge_table WHERE create_time <= 'YYYY-MM-DD HH:MM:SS';

"…"

"…"

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

ການປະຕິບັດ 2

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

ຂ້າພະເຈົ້າໄດ້ຕັດສິນໃຈຂຽນສະຄິບທີ່ສາມາດລຶບປະມານ 1 ບັນທຶກແລະເປີດຕົວມັນ.

"ຂ້ອຍປະຕິບັດຕົວຫນັງສື"

"ຕອນນີ້ມັນຈະເຮັດວຽກແນ່ນອນ," ຂ້ອຍຄິດ.

ການປະຕິບັດ 3

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

ດັ່ງນັ້ນ, ນີ້ແມ່ນສິ່ງທີ່ຂ້ອຍຕັດສິນໃຈເຮັດ:

ຄັດລອກຕາຕະລາງແລະປ່ຽນຊື່ມັນ

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

| hoge_table     | 350'000'000|
| tmp_hoge_table |  50'000'000|

ຖ້າທ່ານເຮັດໃຫ້ຕາຕະລາງໃຫມ່ມີຂະຫນາດດຽວກັນກັບຂ້າງເທິງ, ຄວາມໄວການປຸງແຕ່ງຂໍ້ມູນຄວນຈະເປັນ 1/7 ໄວຂຶ້ນ.

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

ການປະຕິບັດ

"ສົ່ງຄໍາຮ້ອງຂໍ"

INSERT INTO tmp_hoge_table SELECT FROM hoge_table create_time > 'YYYY-MM-DD HH:MM:SS';

"…"
"…"
"ເອີ…?"

ການປະຕິບັດ 4

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

ຂ້ອຍເມື່ອຍຫຼາຍຈົນເລີ່ມຄິດວ່າຂ້ອຍບໍ່ຢາກເຮັດແບບນີ້ອີກ.

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

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

ການປ່ຽນຊື່ຕາຕະລາງ

ນີ້ໂຊກຢູ່ຂ້າງຂ້ອຍ: ທຸກສິ່ງທຸກຢ່າງໄດ້ດໍາເນີນໄປຢ່າງສະບາຍ.

ການ​ແຈ້ງ​ເຕືອນ​ຫາຍ​ໄປ​

ຄວາມໄວການປຸງແຕ່ງ batch ໄດ້ເພີ່ມຂຶ້ນ.

ກ່ອນຫນ້ານີ້ຂະບວນການນີ້ໃຊ້ເວລາປະມານຫນຶ່ງຊົ່ວໂມງ, ໃນປັດຈຸບັນມັນໃຊ້ເວລາປະມານ 2 ນາທີ.

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

ສະຫຼຸບ

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

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

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

ຂອບໃຈສໍາລັບການອ່ານ!

ພວກ​ເຮົາ​ຈະ​ດີ​ໃຈ​ຫຼາຍ​ຖ້າ​ຫາກ​ທ່ານ​ບອກ​ພວກ​ເຮົາ​ວ່າ​ທ່ານ​ມັກ​ບົດ​ຄວາມ​ນີ້, ບໍ່​ວ່າ​ຈະ​ເປັນ​ການ​ແປ​ພາ​ສາ​ທີ່​ຈະ​ແຈ້ງ, ບໍ່​ວ່າ​ຈະ​ເປັນ​ປະ​ໂຫຍດ​ກັບ​ທ່ານ?

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