ການເພີ່ມປະສິດທິພາບຫຼາຍຂອງການສອບຖາມ PostgreSQL. Kirill Borovikov (ເທນເຊີ)

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

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

ໃຜສົນໃຈ? ການວິເຄາະບັນຫາສະເພາະ ແລະເຕັກນິກການເພີ່ມປະສິດທິພາບຕ່າງໆ ການສອບຖາມ SQL ແລະການແກ້ໄຂບັນຫາ DBA ປົກກະຕິໃນ PostgreSQL - ເຈົ້າຍັງສາມາດເຮັດໄດ້ ອ່ານຊຸດຂອງບົດຄວາມ ກ່ຽວກັບຫົວຂໍ້ນີ້.


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

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

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

ເພື່ອ​ໃຫ້​ພວກ​ເຂົາ​ເຈົ້າ​ທັງ​ຫມົດ​ເຮັດ​ວຽກ​ແລະ​ພັດ​ທະ​ນາ​ເປັນ​ປົກ​ກະ​ຕິ​, ພວກ​ເຮົາ​ມີ 10 ສູນ​ພັດ​ທະ​ນາ​ໃນ​ທົ່ວ​ປະ​ເທດ​, ມີ​ຫຼາຍ​ໃນ​ພວກ​ເຂົາ​ ນັກພັດທະນາ 1000 ຄົນ.

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

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

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

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

ໂດຍທົ່ວໄປແລ້ວ, ບັນຫາຄລາສສິກທີ່ນັກພັດທະນາ [ເຖິງ DBA] ມັກຈະມາພ້ອມກັບ? “ນີ້​ພວກ​ເຮົາ​ໄດ້​ປະ​ຕິ​ບັດ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​, ແລະ​ ທຸກສິ່ງທຸກຢ່າງແມ່ນຊ້າກັບພວກເຮົາ, ທຸກສິ່ງທຸກຢ່າງແມ່ນຫ້ອຍ, ບາງສິ່ງບາງຢ່າງເກີດຂຶ້ນ ... ປະເພດຂອງບັນຫາບາງຢ່າງ!”

ເຫດຜົນແມ່ນເກືອບສະເຫມີຄືກັນ:

• ສູດການສອບຖາມທີ່ບໍ່ມີປະສິດທິພາບ
  ນັກພັດທະນາ: "ຕອນນີ້ຂ້ອຍໃຫ້ລາວ 10 ຕາຕະລາງໃນ SQL ໂດຍຜ່ານ JOIN ... " - ແລະຄາດຫວັງວ່າເງື່ອນໄຂຂອງລາວຈະມະຫັດສະຈັນຢ່າງມີປະສິດທິພາບ "untied" ແລະລາວຈະໄດ້ຮັບທຸກສິ່ງທຸກຢ່າງຢ່າງໄວວາ. ແຕ່ສິ່ງມະຫັດສະຈັນບໍ່ໄດ້ເກີດຂຶ້ນ, ແລະລະບົບໃດກໍ່ຕາມທີ່ມີການປ່ຽນແປງດັ່ງກ່າວ (10 ຕາຕະລາງໃນຫນຶ່ງ FROM) ສະເຫມີເຮັດໃຫ້ບາງປະເພດຂອງຄວາມຜິດພາດ. [ບົດຄວາມ]
• ສະຖິຕິລ້າສະໄຫມ
  ຈຸດນີ້ແມ່ນມີຄວາມກ່ຽວຂ້ອງຫຼາຍໂດຍສະເພາະສໍາລັບ PostgreSQL, ເມື່ອທ່ານ "ເທ" ຊຸດຂໍ້ມູນຂະຫນາດໃຫຍ່ໃສ່ເຄື່ອງແມ່ຂ່າຍ, ຮ້ອງຂໍ, ແລະມັນ "sexcanits" ແທັບເລັດຂອງທ່ານ. ເນື່ອງຈາກວ່າມື້ວານນີ້ມີ 10 ບັນທຶກໃນນັ້ນ, ແລະໃນມື້ນີ້ມີ 10 ລ້ານຄົນ, ແຕ່ PostgreSQL ຍັງບໍ່ທັນຮູ້ເລື່ອງນີ້, ແລະພວກເຮົາຈໍາເປັນຕ້ອງບອກມັນກ່ຽວກັບມັນ. [ບົດຄວາມ]
• "ສຽບ" ກ່ຽວກັບຊັບພະຍາກອນ
  ທ່ານໄດ້ຕິດຕັ້ງຖານຂໍ້ມູນຂະຫນາດໃຫຍ່ແລະໂຫຼດຫຼາຍຢູ່ໃນເຄື່ອງແມ່ຂ່າຍທີ່ອ່ອນແອທີ່ບໍ່ມີແຜ່ນ, ຫນ່ວຍຄວາມຈໍາ, ຫຼືໂປເຊດເຊີປະສິດທິພາບພຽງພໍ. ແລະນັ້ນແມ່ນທັງໝົດ... ບາງບ່ອນມີເພດານປະສິດທິພາບຂ້າງເທິງທີ່ທ່ານບໍ່ສາມາດໂດດໄດ້.
• ການຂັດຂວາງ
  ນີ້ແມ່ນຈຸດທີ່ມີຄວາມຫຍຸ້ງຍາກ, ແຕ່ພວກມັນມີຄວາມກ່ຽວຂ້ອງຫຼາຍທີ່ສຸດສໍາລັບການສອບຖາມດັດແກ້ຕ່າງໆ (INSERT, UPDATE, DELETE) - ນີ້ແມ່ນຫົວຂໍ້ໃຫຍ່ແຍກຕ່າງຫາກ.

ໄດ້ຮັບແຜນການ

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

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

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

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

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

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

ຖ້າມັນຮູ້ວ່າບາງຄໍາຮ້ອງຂໍແລ່ນດົນກວ່າຂອບເຂດຈໍາກັດທີ່ທ່ານບອກມັນ, ມັນກໍ່ເຮັດໄດ້ "ພາບລວມ" ຂອງແຜນການຂອງຄໍາຮ້ອງຂໍນີ້ແລະຂຽນພວກມັນຮ່ວມກັນໃນບັນທຶກ.

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

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

ແຕ່ເຖິງແມ່ນວ່າມັນບໍ່ຊັດເຈນ, ເຖິງແມ່ນວ່າມັນບໍ່ສະດວກ, ມີບັນຫາພື້ນຖານຫຼາຍ:

• node ຊີ້ໃຫ້ເຫັນ ຜົນລວມຂອງຊັບພະຍາກອນຂອງຕົ້ນໄມ້ຍ່ອຍທັງໝົດ ພາຍໃຕ້ພຣະອົງ. ນັ້ນແມ່ນ, ທ່ານບໍ່ສາມາດຊອກຫາເວລາຫຼາຍປານໃດໃນ Index Scan ນີ້ຖ້າມີບາງເງື່ອນໄຂທີ່ຖືກວາງໄວ້ພາຍໃຕ້ມັນ. ພວກເຮົາຕ້ອງເບິ່ງແບບເຄື່ອນໄຫວເພື່ອເບິ່ງວ່າມີ "ເດັກນ້ອຍ" ແລະຕົວແປທີ່ມີເງື່ອນໄຂ, CTEs ພາຍໃນ - ແລະລົບທັງຫມົດນີ້ "ຢູ່ໃນໃຈຂອງພວກເຮົາ".
• ຈຸດທີສອງ: ເວລາທີ່ຊີ້ໃຫ້ເຫັນຢູ່ໃນ node ແມ່ນ ເວລາປະຕິບັດ node ດຽວ. ຖ້າ node ນີ້ຖືກປະຕິບັດເປັນຜົນມາຈາກ, ສໍາລັບການຍົກຕົວຢ່າງ, loops ຜ່ານຕາຕະລາງບັນທຶກຫຼາຍຄັ້ງ, ຫຼັງຈາກນັ້ນຈໍານວນຂອງ loops-cycles ຂອງ node ນີ້-ເພີ່ມຂຶ້ນໃນແຜນການ. ​ແຕ່​ເວລາ​ປະຕິບັດ​ໜ້າ​ທີ່​ຂອງ​ປະ​ມະ​ນູນ​ເອງ​ຍັງ​ຄື​ເກົ່າ​ໃນ​ແຜນການ. ນັ້ນແມ່ນ, ເພື່ອເຂົ້າໃຈວ່າຂໍ້ນີ້ປະຕິບັດໄດ້ດົນປານໃດ, ທ່ານ ຈຳ ເປັນຕ້ອງຄູນສິ່ງ ໜຶ່ງ ແລະອີກຢ່າງ ໜຶ່ງ - ອີກເທື່ອ ໜຶ່ງ, "ຢູ່ໃນຫົວຂອງເຈົ້າ."

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

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

ການວາງແຜນການເບິ່ງເຫັນ

ດັ່ງນັ້ນ, ພວກເຮົາຮັບຮູ້ວ່າເພື່ອແກ້ໄຂບັນຫາເຫຼົ່ານີ້, ພວກເຮົາຕ້ອງການ ການເບິ່ງເຫັນທີ່ດີຂອງແຜນການ. [ບົດຄວາມ]

ພວກເຮົາທໍາອິດ "ຜ່ານຕະຫຼາດ" - ໃຫ້ພວກເຮົາເບິ່ງໃນອິນເຕີເນັດເພື່ອເບິ່ງວ່າມີຢູ່.

ແຕ່ມັນໄດ້ຫັນອອກວ່າມີການແກ້ໄຂ "ດໍາລົງຊີວິດ" ຂ້ອນຂ້າງຫນ້ອຍທີ່ມີການພັດທະນາຫຼາຍຫຼືຫນ້ອຍ - ແທ້ໆ, ມີພຽງແຕ່ຫນຶ່ງ: ອະທິບາຍ.depesz.com ໂດຍ Hubert Lubaczewski. ເມື່ອທ່ານເຂົ້າໄປໃນຊ່ອງ "ອາຫານ" ຂໍ້ຄວາມທີ່ເປັນຕົວແທນຂອງແຜນການ, ມັນສະແດງໃຫ້ທ່ານເຫັນຕາຕະລາງທີ່ມີຂໍ້ມູນທີ່ວິເຄາະ:

• ເວລາປະມວນຜົນຂອງ node
• ເວລາທັງໝົດສຳລັບຕົ້ນໄມ້ຍ່ອຍທັງໝົດ
• ຈໍາ​ນວນ​ຂອງ​ການ​ບັນ​ທຶກ​ທີ່​ໄດ້​ຮັບ​ທີ່​ໄດ້​ຮັບ​ການ​ຄາດ​ຄະ​ເນ​ທາງ​ສະ​ຖິ​ຕິ​
• ຮ່າງກາຍຂອງ node ຕົວຂອງມັນເອງ

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

ແຕ່ຍັງມີບັນຫານ້ອຍໆ.

ປະການທໍາອິດ, ຈໍານວນຫຼວງຫຼາຍຂອງ "copy-paste". ເຈົ້າ​ເອົາ​ໄມ້​ທ່ອນ​ອັນ​ໜຶ່ງ​ຕິດ​ໃສ່​ໃນ​ນັ້ນ, ແລະ​ອີກ​ເທື່ອ​ໜຶ່ງ.

ອັນ​ທີ​ສອງ​, ບໍ່ມີການວິເຄາະປະລິມານການອ່ານຂໍ້ມູນ — buffers ດຽວກັນກັບຜົນຜະລິດ EXPLAIN (ANALYZE, BUFFERS), ພວກເຮົາບໍ່ເຫັນມັນຢູ່ທີ່ນີ້. ລາວພຽງແຕ່ບໍ່ຮູ້ວິທີການຖອດພວກມັນ, ເຂົ້າໃຈພວກເຂົາແລະເຮັດວຽກກັບພວກເຂົາ. ໃນເວລາທີ່ທ່ານກໍາລັງອ່ານຂໍ້ມູນຈໍານວນຫລາຍແລະຮູ້ວ່າທ່ານອາດຈະຖືກຈັດແບ່ງແຜ່ນດິດແລະຫນ່ວຍຄວາມຈໍາທີ່ບໍ່ຖືກຕ້ອງ, ຂໍ້ມູນນີ້ແມ່ນມີຄວາມສໍາຄັນຫຼາຍ.

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

ແຕ່ນີ້ແມ່ນ "ເນື້ອເພງ", ພວກເຮົາສາມາດອາໄສຢູ່ກັບສິ່ງນີ້, ແຕ່ມີສິ່ງຫນຶ່ງທີ່ເຮັດໃຫ້ພວກເຮົາຫັນຫນີຈາກການບໍລິການນີ້ຢ່າງຫຼວງຫຼາຍ. ເຫຼົ່ານີ້ແມ່ນຄວາມຜິດພາດໃນການວິເຄາະຂອງ Common Table Expression (CTE) ແລະ nodes dynamic ຕ່າງໆເຊັ່ນ InitPlan/SubPlan.

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

ຫຼັງຈາກນັ້ນ, ພວກເຮົາຮູ້ວ່າມັນແມ່ນເວລາທີ່ຈະຂຽນຂອງພວກເຮົາເອງ - hurray! ນັກພັດທະນາທຸກຄົນເວົ້າວ່າ: "ຕອນນີ້ພວກເຮົາຈະຂຽນຂອງພວກເຮົາເອງ, ມັນຈະງ່າຍທີ່ສຸດ!"

ພວກເຮົາໄດ້ເອົາ stack ປົກກະຕິສໍາລັບການບໍລິການເວັບ: ຫຼັກໂດຍອີງໃສ່ Node.js + Express, ໃຊ້ Bootstrap ແລະ D3.js ສໍາລັບແຜນວາດທີ່ສວຍງາມ. ແລະຄວາມຄາດຫວັງຂອງພວກເຮົາແມ່ນຖືກຕ້ອງຢ່າງເຕັມສ່ວນ - ພວກເຮົາໄດ້ຮັບຕົວແບບທໍາອິດໃນ 2 ອາທິດ:

• ຕົວວິເຄາະແຜນກຳນົດເອງ
  ນັ້ນແມ່ນ, ຕອນນີ້ພວກເຮົາສາມາດວິເຄາະແຜນການໃດໆຈາກທີ່ສ້າງຂຶ້ນໂດຍ PostgreSQL.
• ການວິເຄາະທີ່ຖືກຕ້ອງຂອງ dynamic nodes - CTE Scan, InitPlan, SubPlan
• ການວິເຄາະການແຈກຢາຍ buffers - ບ່ອນທີ່ຫນ້າຂໍ້ມູນຖືກອ່ານຈາກຫນ່ວຍຄວາມຈໍາ, ບ່ອນທີ່ຈາກແຄດທ້ອງຖິ່ນ, ບ່ອນທີ່ຈາກແຜ່ນ
• ໄດ້ຮັບຄວາມຊັດເຈນ
  ເພື່ອບໍ່ໃຫ້ "ຂຸດ" ທັງຫມົດນີ້ຢູ່ໃນບັນທຶກ, ແຕ່ເພື່ອເບິ່ງ "ການເຊື່ອມຕໍ່ທີ່ອ່ອນແອທີ່ສຸດ" ທັນທີໃນຮູບ.

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

ນີ້​ແມ່ນ​ຕົວ​ແທນ​ຫຍໍ້​ທີ່​ພວກ​ເຮົາ​ເອີ້ນ​ວ່າ​ ແບບແຜນ.

ແມ່ນຫຍັງອີກແດ່ທີ່ຈະສະດວກ? ມັນຈະເປັນການສະດວກທີ່ຈະເຫັນວ່າສ່ວນແບ່ງຂອງເວລາທັງໝົດຂອງພວກເຮົາຖືກຈັດສັນໃຫ້ກັບຂໍ້ໃດ - ແລະພຽງແຕ່ “ຕິດມັນ” ໄປຂ້າງໆ. pie chart.

ພວກເຮົາຊີ້ໃສ່ node ແລະເບິ່ງ - ມັນ turns ໃຫ້ເຫັນວ່າ Seq Scan ໄດ້ໃຊ້ເວລາຫນ້ອຍກວ່າຫນຶ່ງສ່ວນສີ່ຂອງເວລາທັງຫມົດ, ແລະສ່ວນທີ່ເຫຼືອ 3/4 ໄດ້ຖືກປະຕິບັດໂດຍ CTE Scan. ຕົກໃຈ! ນີ້ແມ່ນບັນທຶກນ້ອຍໆກ່ຽວກັບ "ອັດຕາການໄຟ" ຂອງ CTE Scan ຖ້າທ່ານໃຊ້ພວກມັນຢ່າງຈິງຈັງໃນການສອບຖາມຂອງທ່ານ. ພວກມັນບໍ່ໄວຫຼາຍ - ພວກມັນຕໍ່າກວ່າການສະແກນຕາຕະລາງປົກກະຕິ. [ບົດຄວາມ] [ບົດຄວາມ]

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

ຕາມທໍາມະຊາດ, ມີບາງ "rakes" ມີສ່ວນຮ່ວມ.

ສິ່ງທໍາອິດທີ່ພວກເຮົາພົບແມ່ນບັນຫາຮອບ. ເວລາຂອງແຕ່ລະ node ບຸກຄົນໃນແຜນການແມ່ນຊີ້ໃຫ້ເຫັນເຖິງຄວາມຖືກຕ້ອງຂອງ 1 μs. ແລະເມື່ອຈໍານວນຮອບວຽນຂອງ node ເກີນ, ສໍາລັບຕົວຢ່າງ, 1000 - ຫຼັງຈາກການປະຕິບັດ PostgreSQL ແບ່ງອອກ "ພາຍໃນຄວາມຖືກຕ້ອງ", ຫຼັງຈາກນັ້ນ, ເມື່ອຄິດໄລ່ຄືນ, ພວກເຮົາໄດ້ຮັບເວລາທັງຫມົດ "ບາງບ່ອນລະຫວ່າງ 0.95ms ແລະ 1.05ms". ເມື່ອການນັບເປັນ microseconds, ນັ້ນກໍ່ບໍ່ເປັນຫຍັງ, ແຕ່ເມື່ອມັນຮອດ [milli] ວິນາທີແລ້ວ, ທ່ານຕ້ອງເອົາຂໍ້ມູນນີ້ເຂົ້າໃນບັນຊີໃນເວລາທີ່ "untying" ຊັບພະຍາກອນໄປຫາ nodes ຂອງ "ຜູ້ທີ່ບໍລິໂພກຫຼາຍປານໃດ".

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

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

ພວກເຮົາເບິ່ງແຜນການແລະເຂົ້າໃຈ - ມັນແປກ, ພວກເຮົາມີ 3 buffers (ຫນ້າຂໍ້ມູນ) "ບໍລິໂພກ" ໃນ Seq Scan, 1 ເພີ່ມເຕີມໃນ CTE Scan, ແລະອີກ 2 ອັນໃນ CTE Scan ທີສອງ. ນັ້ນແມ່ນ, ຖ້າພວກເຮົາສະຫຼຸບທຸກຢ່າງ, ພວກເຮົາຈະໄດ້ 6, ແຕ່ຈາກເມັດທີ່ພວກເຮົາອ່ານພຽງແຕ່ 3! CTE Scan ບໍ່ໄດ້ອ່ານຫຍັງຈາກທຸກບ່ອນ, ແຕ່ເຮັດວຽກໂດຍກົງກັບຫນ່ວຍຄວາມຈໍາຂະບວນການ. ນັ້ນແມ່ນ, ບາງສິ່ງບາງຢ່າງແມ່ນຜິດພາດຢ່າງຊັດເຈນຢູ່ທີ່ນີ້!

ໃນ​ຄວາມ​ເປັນ​ຈິງ, ມັນ turns ໃຫ້​ເຫັນ​ວ່າ​ນີ້​ແມ່ນ​ທັງ​ຫມົດ 3 ຫນ້າ​ຂອງ​ຂໍ້​ມູນ​ທີ່​ໄດ້​ຮັບ​ການ​ຮ້ອງ​ຂໍ​ຈາກ Seq Scan, ຄັ້ງ​ທໍາ​ອິດ 1 ຂໍ​ໃຫ້​ສໍາ​ລັບ​ການ​ສະ​ແກນ CTE ຄັ້ງ​ທີ 1, ແລະ​ຫຼັງ​ຈາກ​ນັ້ນ​ຄັ້ງ​ທີ 2, ແລະ 2 ຫຼາຍ​ໄດ້​ຮັບ​ການ​ອ່ານ​ໃຫ້​ເຂົາ. 3 ໜ້າຖືກອ່ານຂໍ້ມູນ, ບໍ່ແມ່ນ 6.

ແລະຮູບພາບນີ້ໄດ້ນໍາພາພວກເຮົາໄປສູ່ຄວາມເຂົ້າໃຈວ່າການປະຕິບັດແຜນການບໍ່ແມ່ນຕົ້ນໄມ້ອີກຕໍ່ໄປ, ແຕ່ພຽງແຕ່ບາງປະເພດຂອງກາຟ acyclic. ແລະພວກເຮົາໄດ້ຮັບແຜນວາດແບບນີ້, ດັ່ງນັ້ນພວກເຮົາເຂົ້າໃຈ "ສິ່ງທີ່ມາຈາກບ່ອນທໍາອິດ." ນັ້ນແມ່ນ, ທີ່ນີ້ພວກເຮົາໄດ້ສ້າງ CTE ຈາກ pg_class, ແລະໄດ້ຮ້ອງຂໍເອົາມັນສອງຄັ້ງ, ແລະເກືອບທັງຫມົດທີ່ໃຊ້ເວລາຂອງພວກເຮົາແມ່ນໃຊ້ເວລາໃນສາຂາໃນເວລາທີ່ພວກເຮົາຮ້ອງຂໍເອົາມັນຄັ້ງທີ 2. ມັນເປັນທີ່ຊັດເຈນວ່າການອ່ານລາຍການທີ 101 ແມ່ນລາຄາແພງຫຼາຍກ່ວາພຽງແຕ່ອ່ານລາຍການທີ 1 ຈາກແທັບເລັດ.

ພວກເຮົາ exhaled ສໍາລັບໃນຂະນະທີ່. ພວກ​ເຂົາ​ເຈົ້າ​ເວົ້າ​ວ່າ: “ບັດ​ນີ້, Neo, ເຈົ້າ​ຮູ້ kung Fu! ໃນປັດຈຸບັນປະສົບການຂອງພວກເຮົາແມ່ນຖືກຕ້ອງໃນຫນ້າຈໍຂອງທ່ານ. ດຽວນີ້ເຈົ້າສາມາດໃຊ້ມັນໄດ້." [ບົດຄວາມ]

ບັນທຶກລວມ

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

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

ກ່ອນອື່ນ ໝົດ, ມັນມອບ ໝາຍ ໃຫ້ກັບການສອບຖາມດຽວກັນໂດຍໃຊ້ໂຄງການທີ່ແຕກຕ່າງກັນພາຍໃນຖານຂໍ້ມູນດຽວກັນ QueryIds ທີ່ແຕກຕ່າງກັນ. ນັ້ນແມ່ນ, ຖ້າທ່ານທໍາອິດເຮັດ SET search_path = '01'; SELECT * FROM user LIMIT 1;ແລະຫຼັງຈາກນັ້ນ SET search_path = '02'; ແລະການຮ້ອງຂໍດຽວກັນ, ຫຼັງຈາກນັ້ນ, ສະຖິຕິຂອງໂມດູນນີ້ຈະມີບັນທຶກທີ່ແຕກຕ່າງກັນ, ແລະຂ້າພະເຈົ້າຈະບໍ່ສາມາດເກັບກໍາສະຖິຕິທົ່ວໄປໂດຍສະເພາະໃນສະພາບການຂອງ profile ການຮ້ອງຂໍນີ້, ໂດຍບໍ່ມີການຄໍານຶງເຖິງໂຄງການ.

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

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

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

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

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

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

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

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

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

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

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

ຈຸດທີສາມ - ຂ້ອຍຕ້ອງ ປະຖິ້ມ triggers, ຕາມລໍາດັບ, ແລະກະແຈຕ່າງປະເທດ. ນັ້ນແມ່ນ, ພວກເຮົາບໍ່ມີຄວາມຊື່ສັດໃນການອ້າງອີງໃດໆ. ເພາະວ່າຖ້າທ່ານມີຕາຕະລາງທີ່ມີຄູ່ຂອງ FKs, ແລະທ່ານເວົ້າໃນໂຄງສ້າງຖານຂໍ້ມູນວ່າ "ນີ້ແມ່ນບັນທຶກບັນທຶກທີ່ອ້າງອີງໂດຍ FK, ສໍາລັບຕົວຢ່າງ, ກັບກຸ່ມບັນທຶກ," ຫຼັງຈາກນັ້ນເມື່ອທ່ານໃສ່ມັນ, PostgreSQL ບໍ່​ມີ​ຫຍັງ​ເຫຼືອ​ແຕ່​ວິ​ທີ​ທີ່​ຈະ​ເອົາ​ມັນ​ແລະ​ເຮັດ​ໃຫ້​ມັນ​ຊື່​ສັດ​ SELECT 1 FROM master_fk1_table WHERE ... ກັບຕົວລະບຸທີ່ທ່ານກໍາລັງພະຍາຍາມໃສ່ - ພຽງແຕ່ເພື່ອກວດເບິ່ງວ່າບັນທຶກນີ້ຢູ່ທີ່ນັ້ນ, ວ່າທ່ານບໍ່ໄດ້ "ທໍາລາຍ" ລະຫັດຕ່າງປະເທດດ້ວຍການໃສ່ຂອງທ່ານ.

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

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

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

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

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

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

ແຕ່ເພື່ອບັນທຶກທັງຫມົດນີ້ຢ່າງໄວວາ, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ດັດແປງຂັ້ນຕອນການບັນທຶກຕົວມັນເອງ.

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

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

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

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

ເພື່ອກໍາຈັດຄວາມຜິດປົກກະຕິດັ່ງກ່າວ, ພຽງແຕ່ບໍ່ລວບລວມສິ່ງໃດ, ບໍ່ buffer ເລີຍ. ແລະຖ້າ buffering ກັບ disk ເກີດຂຶ້ນ (ໂຊກດີ, Stream API ໃນ Node.js ອະນຸຍາດໃຫ້ທ່ານຊອກຫາ) - ເລື່ອນການເຊື່ອມຕໍ່ນີ້. ເມື່ອທ່ານໄດ້ຮັບເຫດການທີ່ມັນບໍ່ເສຍຄ່າອີກເທື່ອຫນຶ່ງ, ຂຽນມັນຈາກຄິວທີ່ສະສົມ. ແລະໃນຂະນະທີ່ມັນບໍ່ຫວ່າງ, ເອົາອັນຕໍ່ໄປທີ່ບໍ່ເສຍຄ່າຈາກສະລອຍນ້ໍາແລະຂຽນໃສ່ມັນ.

ກ່ອນທີ່ຈະແນະນໍາວິທີການບັນທຶກຂໍ້ມູນນີ້, ພວກເຮົາມີປະມານ 4K write ops, ແລະດ້ວຍວິທີນີ້ພວກເຮົາຫຼຸດລົງການໂຫຼດ 4 ເທົ່າ. ໃນປັດຈຸບັນພວກເຂົາເຈົ້າໄດ້ເພີ່ມຂຶ້ນອີກ 6 ເທົ່າເນື່ອງຈາກຖານຂໍ້ມູນທີ່ຖືກຕິດຕາມໃຫມ່ - ເຖິງ 100MB/s. ແລະໃນປັດຈຸບັນພວກເຮົາເກັບຮັກສາບັນທຶກສໍາລັບ 3 ເດືອນທີ່ຜ່ານມາໃນປະລິມານປະມານ 10-15TB, ຫວັງວ່າໃນສາມເດືອນນັກພັດທະນາຈະສາມາດແກ້ໄຂບັນຫາໃດໆ.

ພວກເຮົາເຂົ້າໃຈບັນຫາ

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

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

ພວກເຮົາໄດ້ກໍານົດສາມຈຸດສໍາຄັນ:

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

ເພື່ອເຂົ້າໃຈ "ໃຜ" ສົ່ງຄໍາຮ້ອງຂໍໃຫ້ພວກເຮົາ, ພວກເຮົາໃຊ້ເຄື່ອງມືມາດຕະຖານ - ກໍານົດຕົວແປຂອງກອງປະຊຸມ: SET application_name = '{bl-host}:{bl-method}'; — ພວກ​ເຮົາ​ສົ່ງ​ຊື່​ຂອງ​ເຈົ້າ​ພາບ​ຕາມ​ເຫດ​ຜົນ​ທຸ​ລະ​ກິດ​ຈາກ​ການ​ຮ້ອງ​ຂໍ​ແມ່ນ​ມາ​, ແລະ​ຊື່​ຂອງ​ວິ​ທີ​ການ​ຫຼື​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ທີ່​ລິ​ເລີ່ມ​ມັນ​.

ຫຼັງຈາກທີ່ພວກເຮົາໄດ້ຜ່ານ "ເຈົ້າຂອງ" ຂອງການຮ້ອງຂໍ, ມັນຕ້ອງຖືກສົ່ງອອກໄປຫາບັນທຶກ - ສໍາລັບນີ້ພວກເຮົາກໍານົດຕົວແປ. log_line_prefix = ' %m [%p:%v] [%d] %r %a'. ສໍາລັບຜູ້ທີ່ສົນໃຈ, ບາງທີ ເບິ່ງໃນຄູ່ມືມັນທັງຫມົດຫມາຍຄວາມວ່າແນວໃດ. ມັນປະກົດວ່າພວກເຮົາເຫັນຢູ່ໃນບັນທຶກ:

• время
• ຕົວລະບຸຂະບວນການ ແລະທຸລະກຳ
• ຊື່ຖານຂໍ້ມູນ
• IP ຂອງບຸກຄົນທີ່ສົ່ງຄໍາຮ້ອງຂໍນີ້
• ແລະຊື່ວິທີການ

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

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

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

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

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

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

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

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

ແລະທັນທີທ່ານສາມາດເບິ່ງຄໍາຮ້ອງສະຫມັກທີ່ແຕກຕ່າງກັນທີ່ມາພ້ອມກັບແມ່ແບບດຽວກັນຈາກການຮ້ອງຂໍເຊັ່ນ: SELECT * FROM users WHERE login = 'Vasya'. Frontend, backend, processing... ແລະທ່ານສົງໄສວ່າເປັນຫຍັງການປະມວນຜົນຈະອ່ານຜູ້ໃຊ້ຖ້າລາວບໍ່ພົວພັນກັບລາວ.

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

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

ທ່ານບໍ່ມີດັດຊະນີທີ່ເຫມາະສົມໃນແຜ່ນ, ທ່ານຮ້ອງຂໍໃຫ້ມັນ, ມັນບິນຜ່ານດັດຊະນີ, ຕົກຢູ່ໃນ Seq Scan ... ທ່ານໄດ້ກັ່ນຕອງອອກທັງຫມົດບັນທຶກຍົກເວັ້ນຫນຶ່ງ. ເປັນຫຍັງທ່ານຕ້ອງການ 100M ບັນທຶກການກັ່ນຕອງຕໍ່ມື້? ມັນດີກວ່າທີ່ຈະມ້ວນດັດສະນີບໍ?

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

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

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

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

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