ພວກເຮົາຂຽນໃນ PostgreSQL ໃນ sublight: 1 host, 1 ມື້, 1TB

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

#1. ການແບ່ງສ່ວນ

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

"ວັນເວລາຜ່ານໄປ..."

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

ເວລາແມ່ນເກືອບຄ້າຍຄືເວລາ epic, ສະບັບທີ່ແຕກຕ່າງກັນຂອງ PostgreSQL 9.x ແມ່ນມີຄວາມກ່ຽວຂ້ອງ, ດັ່ງນັ້ນການແບ່ງສ່ວນທັງຫມົດຕ້ອງເຮັດ "ຄູ່ມື" - ຜ່ານ. ການສືບທອດຕາຕະລາງແລະຜົນກະທົບຕໍ່ ກຳນົດເສັ້ນທາງແບບເຄື່ອນໄຫວ EXECUTE.

ການ​ແກ້​ໄຂ​ຜົນ​ໄດ້​ກາຍ​ເປັນ​ທົ່ວ​ໄປ​ພຽງ​ພໍ​ທີ່​ມັນ​ສາ​ມາດ​ໄດ້​ຮັບ​ການ​ແປ​ເປັນ​ຕາ​ຕະ​ລາງ​ທັງ​ຫມົດ​:

• ຕາຕະລາງພໍ່ແມ່ "header" ຫວ່າງເປົ່າໄດ້ຖືກປະກາດ, ເຊິ່ງອະທິບາຍທັງຫມົດ ດັດຊະນີ ແລະຕົວກະຕຸ້ນທີ່ຈຳເປັນ.
• ບັນທຶກຈາກທັດສະນະຂອງລູກຄ້າໄດ້ຖືກເຮັດຢູ່ໃນຕາຕະລາງ "ຮາກ", ແລະການນໍາໃຊ້ພາຍໃນ ຕົວກະຕຸ້ນເສັ້ນທາງ BEFORE INSERT ບັນທຶກໄດ້ຖືກໃສ່ "ທາງດ້ານຮ່າງກາຍ" ເຂົ້າໄປໃນພາກສ່ວນທີ່ຕ້ອງການ. ຖ້າ​ຫາກ​ວ່າ​ບໍ່​ມີ​ສິ່ງ​ດັ່ງ​ກ່າວ​ຍັງ​, ພວກ​ເຮົາ​ໄດ້​ຮັບ​ການ​ຍົກ​ເວັ້ນ​ແລະ ...
• … ໂດຍ​ການ​ນໍາ​ໃຊ້ CREATE TABLE ... (LIKE ... INCLUDING ...) ຖືກສ້າງຂື້ນໂດຍອີງໃສ່ແມ່ແບບຂອງຕາຕະລາງພໍ່ແມ່ ພາກສ່ວນທີ່ມີຂໍ້ຈໍາກັດໃນວັນທີທີ່ຕ້ອງການດັ່ງນັ້ນເມື່ອຂໍ້ມູນຖືກດຶງ, ການອ່ານແມ່ນດໍາເນີນການພຽງແຕ່ໃນມັນ.

PG10: ຄວາມພະຍາຍາມທໍາອິດ

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

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

ດັ່ງທີ່ມັນໄດ້ຫັນອອກຫຼັງຈາກຂຸດຜ່ານຄູ່ມື, ຕາຕະລາງການແບ່ງປັນພື້ນເມືອງໃນສະບັບນີ້ແມ່ນ:

• ບໍ່ຮອງຮັບຄໍາອະທິບາຍດັດສະນີ
• ບໍ່ສະຫນັບສະຫນູນຜົນກະທົບຕໍ່ມັນ
• ບໍ່ສາມາດເປັນ "ເຊື້ອສາຍ" ຂອງໃຜໄດ້
• ບໍ່ສະຫນັບສະຫນູນ INSERT ... ON CONFLICT
• ບໍ່ສາມາດສ້າງພາກສ່ວນອັດຕະໂນມັດໄດ້

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

PG10: ໂອກາດທີສອງ

ດັ່ງນັ້ນ, ພວກເຮົາເລີ່ມຕົ້ນແກ້ໄຂບັນຫາທີ່ເກີດຂື້ນໂດຍຫນຶ່ງ:

1. ເນື່ອງຈາກວ່າຜົນກະທົບຕໍ່ແລະ ON CONFLICT ພວກເຮົາພົບວ່າພວກເຮົາຍັງຕ້ອງການພວກມັນຢູ່ບ່ອນນີ້ ແລະບ່ອນນັ້ນ, ດັ່ງນັ້ນພວກເຮົາຈຶ່ງເຮັດຂັ້ນຕອນປານກາງເພື່ອແກ້ໄຂພວກມັນ ຕາຕະລາງຕົວແທນ.
2. ໄດ້ກໍາຈັດ "ເສັ້ນທາງ" ໃນຜົນກະທົບຕໍ່ - ນັ້ນແມ່ນ, ຈາກ EXECUTE.
3. ພວກເຂົາເອົາມັນອອກແຍກຕ່າງຫາກ ຕາຕະລາງແມ່ແບບທີ່ມີດັດສະນີທັງຫມົດເພື່ອບໍ່ໃຫ້ພວກມັນຢູ່ໃນຕາຕະລາງຕົວແທນ.

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

ວັດຈະນານຸກົມ "Sawing".

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

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

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

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

• ຂຽນ/ອ່ານໄວຂຶ້ນ ເນື່ອງ​ຈາກ​ຂະ​ຫນາດ​ຂະ​ຫນາດ​ນ້ອຍ​ກວ່າ​
• ບໍລິໂພກຄວາມຊົງຈໍາຫນ້ອຍ ໂດຍການເຮັດວຽກກັບດັດຊະນີທີ່ຫນາແຫນ້ນກວ່າ
• ເກັບຂໍ້ມູນໜ້ອຍລົງ ເນື່ອງຈາກຄວາມສາມາດທີ່ຈະເອົາອອກລ້າສະໄຫມຢ່າງໄວວາ

ເປັນຜົນມາຈາກການຊັບຊ້ອນທັງຫມົດຂອງມາດຕະການ ການໂຫຼດຂອງ CPU ຫຼຸດລົງ ~30%, ການໂຫຼດ disk 50%:

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

#2. ການ​ພັດ​ທະ​ນາ​ຖານ​ຂໍ້​ມູນ​ແລະ refactoring​

ດັ່ງນັ້ນພວກເຮົາໄດ້ຕົກລົງກັບສິ່ງທີ່ພວກເຮົາມີ ແຕ່ລະມື້ມີພາກສ່ວນຂອງຕົນເອງ ກັບຂໍ້ມູນ. ຕົວຈິງແລ້ວ, CHECK (dt = '2018-10-12'::date) — ແລະ​ມີ​ການ​ແບ່ງ​ປັນ​ທີ່​ສໍາ​ຄັນ​ແລະ​ເງື່ອນ​ໄຂ​ສໍາ​ລັບ​ການ​ບັນ​ທຶກ​ການ​ຕົກ​ເຂົ້າ​ໄປ​ໃນ​ພາກ​ສະ​ເພາະ​ໃດ​ຫນຶ່ງ​.

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

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

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

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

#3. "ການແຜ່ກະຈາຍ" ການໂຫຼດສູງສຸດ

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

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

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

setInterval(sendToDB, interval)

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

ໂຊກດີ, ນີ້ແມ່ນຂ້ອນຂ້າງງ່າຍທີ່ຈະແກ້ໄຂ, ເພີ່ມ "random" run-up ຕາມເວລາ:

setInterval(sendToDB, interval * (1 + 0.1 * (Math.random() - 0.5)))

#4. ພວກເຮົາ cache ສິ່ງທີ່ພວກເຮົາຕ້ອງການ

ບັນຫາການໂຫຼດສູງແບບດັ້ງເດີມທີສາມແມ່ນ ບໍ່ມີແຄດ ລາວຢູ່ໃສ ສາມາດ ເປັນ.

ຕົວຢ່າງ, ພວກເຮົາເຮັດໃຫ້ມັນເປັນໄປໄດ້ໃນການວິເຄາະໃນຂໍ້ກໍານົດຂອງ nodes ແຜນ (ທັງຫມົດເຫຼົ່ານີ້ Seq Scan on users), ແຕ່ທັນທີຄິດວ່າພວກເຂົາເຈົ້າແມ່ນ, ສໍາລັບສ່ວນໃຫຍ່, ຄືກັນ - ພວກເຂົາເຈົ້າລືມ.

ບໍ່, ແນ່ນອນ, ບໍ່ມີຫຍັງຖືກຂຽນໃສ່ຖານຂໍ້ມູນອີກເທື່ອຫນຶ່ງ, ນີ້ຕັດຜົນກະທົບຕໍ່ກັບ INSERT ... ON CONFLICT DO NOTHING. ແຕ່ຂໍ້ມູນນີ້ຍັງມາຮອດຖານຂໍ້ມູນ, ແລະມັນບໍ່ຈໍາເປັນ ອ່ານເພື່ອກວດກາເບິ່ງຂໍ້ຂັດແຍ່ງ ຕ້ອງ​ເຮັດ. ອຸຍ #3...

ຄວາມແຕກຕ່າງຂອງຈໍານວນບັນທຶກທີ່ຖືກສົ່ງໄປຫາຖານຂໍ້ມູນກ່ອນ / ຫຼັງຈາກການເປີດໃຊ້ cache ແມ່ນເຫັນໄດ້ຊັດເຈນ:

ແລະນີ້ແມ່ນການຫຼຸດລົງຂອງການໂຫຼດທີ່ມາພ້ອມກັບການເກັບຮັກສາ:

ລວມ

"Terabyte-ຕໍ່ມື້" ພຽງແຕ່ຟັງຫນ້າຢ້ານ. ຖ້າທ່ານເຮັດທຸກຢ່າງທີ່ຖືກຕ້ອງ, ນີ້ແມ່ນພຽງແຕ່ 2^40 bytes / 86400 ວິນາທີ = ~12.5MB/sວ່າແມ້ແຕ່ສະກູ IDE desktop ຖື. 🙂

ແຕ່ຢ່າງຈິງຈັງ, ເຖິງແມ່ນວ່າມີ "skew" ສິບເທົ່າຂອງການໂຫຼດໃນລະຫວ່າງມື້, ທ່ານສາມາດຕອບສະຫນອງຄວາມສາມາດຂອງ SSDs ທີ່ທັນສະໄຫມໄດ້ຢ່າງງ່າຍດາຍ.

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