DBA bot Joe. Anatoly Stansler (Postgres.ai)

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

ວິດີໂອ:

ສະບາຍດີທຸກຄົນ! ຂ້ອຍຊື່ Anatoly Stansler. ຂ້ອຍເຮັດວຽກໃຫ້ບໍລິສັດ postgres.ai. ພວກເຮົາມຸ່ງຫມັ້ນທີ່ຈະເລັ່ງຂະບວນການພັດທະນາໂດຍການກໍາຈັດຄວາມລ່າຊ້າທີ່ກ່ຽວຂ້ອງກັບການເຮັດວຽກຂອງ Postgres ຈາກນັກພັດທະນາ, DBAs ແລະ QAs.

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

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

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

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

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

ມັນເຈັບປວດ, ມັນແພງ. ມັນອາດຈະດີທີ່ສຸດທີ່ຈະບໍ່.

ແລະວິທີທີ່ດີທີ່ສຸດທີ່ຈະເຮັດມັນແມ່ນຫຍັງ?

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

ນີ້ຈະຊ່ວຍໃຫ້ພວກເຮົາເອົາບາງຂໍ້ຜິດພາດອອກ, i.e. ປ້ອງກັນບໍ່ໃຫ້ພວກເຂົາຢູ່ໃນຜະລິດຕະພັນ.

ມີບັນຫາຫຍັງແດ່?

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

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

ນີ້ແມ່ນດີກ່ວາວິທີການທີ່ຜ່ານມາ, ແຕ່ຍັງມີຄວາມເປັນໄປໄດ້ສູງທີ່ບາງປະເພດຂອງຄວາມຜິດພາດຈະໄປສູ່ການຜະລິດ.

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

ໃຜມີຖານຂໍ້ມູນໃຫຍ່ກວ່າ terabyte? ຫຼາຍກວ່າເຄິ່ງຫນຶ່ງຂອງຫ້ອງ.

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

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

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

ແຕ່ພວກເຂົາໃຊ້ວິທີການນີ້ເພາະວ່າມັນອະນຸຍາດໃຫ້ພວກເຂົາຮັກສາຜະລິດຕະພັນທີ່ເຊື່ອຖືໄດ້.

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

ແລະນີ້ເປັນໄປໄດ້.

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

ຕົວຢ່າງທີ່ແທ້ຈິງ:

• DB - 4,5 terabytes.

• ພວກເຮົາສາມາດໄດ້ຮັບສໍາເນົາເອກະລາດໃນ 30 ວິນາທີ.

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

ນີ້ແມ່ນຍິ່ງໃຫຍ່. ໃນທີ່ນີ້ພວກເຮົາເວົ້າກ່ຽວກັບ magic ແລະຈັກກະວານຂະຫນານ.

ໃນກໍລະນີຂອງພວກເຮົາ, ນີ້ເຮັດວຽກໂດຍໃຊ້ລະບົບ OpenZFS.

OpenZFS ເປັນລະບົບໄຟລ໌ copy-on-write ທີ່ຮອງຮັບ snapshots ແລະ clones ອອກຈາກກ່ອງ. ມັນເປັນທີ່ເຊື່ອຖືໄດ້ແລະສາມາດຂະຫຍາຍໄດ້. ນາງແມ່ນງ່າຍຫຼາຍໃນການຄຸ້ມຄອງ. ມັນສາມາດຖືກ ນຳ ໃຊ້ເປັນສອງທີມ.

ມີທາງເລືອກອື່ນ:

• lvm,

• ການເກັບຮັກສາ (ຕົວຢ່າງ, ການເກັບຮັກສາບໍລິສຸດ).

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

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

ແລະໃນອະນາຄົດ, ໃນເວລາທີ່ພວກເຮົາຕ້ອງການທີ່ຈະ rollback ຫຼືພວກເຮົາຕ້ອງການທີ່ຈະເຮັດໃຫ້ເປັນ clone ໃຫມ່ຈາກບາງສະບັບເກົ່າ, ພວກເຮົາພຽງແຕ່ເວົ້າວ່າ: "OK, ໃຫ້ພວກເຮົາ blocks ຂອງຂໍ້ມູນທີ່ມີເຄື່ອງຫມາຍເຊັ່ນນີ້."

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

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

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

• ທໍາອິດແມ່ນແຫຼ່ງຂໍ້ມູນ, ບ່ອນທີ່ທ່ານຈະເອົາມັນມາຈາກ. ທ່ານສາມາດຕັ້ງຄ່າການຈໍາລອງກັບການຜະລິດ. ທ່ານສາມາດນໍາໃຊ້ການສໍາຮອງຂໍ້ມູນທີ່ທ່ານໄດ້ configured ແລ້ວ, ຂ້າພະເຈົ້າຫວັງວ່າ. WAL-E, WAL-G ຫຼື Barman. ແລະເຖິງແມ່ນວ່າທ່ານກໍາລັງໃຊ້ບາງປະເພດຂອງການແກ້ໄຂ Cloud ເຊັ່ນ RDS ຫຼື Cloud SQL, ຫຼັງຈາກນັ້ນທ່ານສາມາດນໍາໃຊ້ການ dumps ຢ່າງມີເຫດຜົນ. ແຕ່ພວກເຮົາຍັງແນະນໍາໃຫ້ທ່ານໃຊ້ການສໍາຮອງຂໍ້ມູນ, ເພາະວ່າດ້ວຍວິທີການນີ້ທ່ານຍັງຈະຮັກສາໂຄງສ້າງທາງກາຍະພາບຂອງໄຟລ໌, ເຊິ່ງຈະຊ່ວຍໃຫ້ທ່ານໃກ້ຊິດກັບ metrics ທີ່ທ່ານຈະເຫັນໃນການຜະລິດເພື່ອຈັບບັນຫາເຫຼົ່ານັ້ນທີ່ມີຢູ່.

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

ຈິນຕະນາການວ່າສໍາລັບແຕ່ລະ clone ດັ່ງກ່າວ, ອີງຕາມການດໍາເນີນງານທີ່ພວກເຮົາເຮັດກັບພື້ນຖານ, ປະເພດຂອງ dev ບາງຢ່າງຈະເຕີບໂຕ. ສໍາລັບການນີ້, dev ຍັງຕ້ອງການພື້ນທີ່. ແຕ່ເນື່ອງຈາກຄວາມຈິງທີ່ວ່າພວກເຮົາໄດ້ເອົາພື້ນຖານຂອງ 4,5 terabytes, ZFS ຈະບີບອັດມັນເປັນ 3,5 terabytes. ນີ້ສາມາດແຕກຕ່າງກັນໄປຕາມການຕັ້ງຄ່າ. ແລະພວກເຮົາຍັງມີຫ້ອງສໍາລັບ dev.

ລະບົບດັ່ງກ່າວສາມາດຖືກນໍາໃຊ້ສໍາລັບກໍລະນີທີ່ແຕກຕ່າງກັນ.

• ເຫຼົ່ານີ້ແມ່ນນັກພັດທະນາ, DBAs ສໍາລັບການກວດສອບການສອບຖາມ, ສໍາລັບການເພີ່ມປະສິດທິພາບ.

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

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

ດ້ວຍວິທີການນີ້:

1. ຄວາມເປັນໄປໄດ້ຕໍ່າຂອງຄວາມຜິດພາດໃນ "prod", ເພາະວ່າພວກເຮົາໄດ້ທົດສອບການປ່ຽນແປງທັງຫມົດກ່ຽວກັບຂໍ້ມູນຂະຫນາດເຕັມ.

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

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

• ຈະມີ refactoring ຫນ້ອຍ. ແມງໄມ້ຫນ້ອຍລົງຈະສິ້ນສຸດໃນການຜະລິດ. ພວກ​ເຮົາ​ຈະ​ຕອບ​ສະ​ຫນອງ​ໃຫ້​ເຂົາ​ເຈົ້າ​ຫນ້ອຍ​ຕໍ່​ມາ​.

• ພວກເຮົາສາມາດປີ້ນກັບການປ່ຽນແປງ irreversible. ນີ້ບໍ່ແມ່ນວິທີການມາດຕະຖານ.

1. ນີ້ແມ່ນຜົນປະໂຫຍດເພາະວ່າພວກເຮົາແບ່ງປັນຊັບພະຍາກອນຂອງ benches ທົດສອບ.

ດີແລ້ວ, ແຕ່ສິ່ງທີ່ສາມາດເລັ່ງໄດ້?

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

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

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

ວິທີການອອກຈາກວົງການນີ້? ໃນຖານະເປັນການໂຕ້ຕອບທໍາອິດ, ສະດວກສໍາລັບນັກພັດທະນາໃນລະດັບໃດກໍ່ຕາມ, ພວກເຮົາເລືອກ Slack bot. ແຕ່ມັນສາມາດເປັນການໂຕ້ຕອບອື່ນໆ.

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

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

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

ແຕ່ເພື່ອໃຫ້ການທົດສອບເຫຼົ່ານີ້ສາມາດເຊື່ອຖືໄດ້, ທ່ານຈໍາເປັນຕ້ອງແກ້ໄຂບັນຫານີ້ຢ່າງໃດກໍ່ຕາມ.

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

ມັນຈະເປັນການດີທີ່ຈະມີຮາດແວດຽວກັນກັບການຜະລິດ, ແຕ່ມັນອາດຈະແຕກຕ່າງກັນ.

ຂໍໃຫ້ຈື່ວິທີການ Postgres ເຮັດວຽກກັບຄວາມຊົງຈໍາ. ພວກເຮົາມີສອງ cache. ຫນຶ່ງຈາກລະບົບໄຟລ໌ແລະຫນຶ່ງ Postgres ພື້ນເມືອງ, i.e. Shared Buffer Cache.

ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະສັງເກດວ່າ Shared Buffer Cache ຖືກຈັດສັນເມື່ອ Postgres ເລີ່ມຕົ້ນ, ຂຶ້ນກັບຂະຫນາດໃດທີ່ທ່ານລະບຸໃນການຕັ້ງຄ່າ.

ແລະແຄດທີສອງໃຊ້ພື້ນທີ່ທີ່ມີຢູ່ທັງຫມົດ.

ແລະໃນເວລາທີ່ພວກເຮົາເຮັດ clones ຫຼາຍຢູ່ໃນຫນຶ່ງເຄື່ອງ, ມັນ turns ໃຫ້ເຫັນວ່າພວກເຮົາຄ່ອຍໆຕື່ມຂໍ້ມູນໃສ່ຫນ່ວຍຄວາມຈໍາ. ແລະໃນທາງທີ່ດີ, Shared Buffer Cache ແມ່ນ 25% ຂອງຈໍານວນຫນ່ວຍຄວາມຈໍາທັງຫມົດທີ່ມີຢູ່ໃນເຄື່ອງ.

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

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

ຕົວຢ່າງ, ຖ້າພວກເຮົາມີ cache ຂະຫນາດໃຫຍ່ໃນ prod, ຫຼັງຈາກນັ້ນ Postgres ຈະມັກໃຊ້ດັດສະນີ. ແລະຖ້າບໍ່, ຫຼັງຈາກນັ້ນຈະມີ SeqScan. ແລະ​ຈະ​ເປັນ​ແນວ​ໃດ​ຖ້າ​ແຜນ​ການ​ຂອງ​ພວກ​ເຮົາ​ບໍ່​ກົງ​ກັນ?

ແຕ່ໃນທີ່ນີ້ພວກເຮົາມາສະຫລຸບວ່າໃນຄວາມເປັນຈິງແຜນການໃນ Postgres ບໍ່ໄດ້ຂຶ້ນກັບຂະຫນາດສະເພາະທີ່ລະບຸໄວ້ໃນ Shared Buffer ໃນແຜນການ, ມັນຂຶ້ນກັບ effect_cache_size.

Effective_cache_size ແມ່ນຈຳນວນທີ່ຄາດໄວ້ຂອງ cache ທີ່ມີໃຫ້ພວກເຮົາ, ເຊັ່ນ: ຜົນລວມຂອງ Buffer Cache ແລະ cache ຂອງລະບົບໄຟລ໌. ນີ້ຖືກກໍານົດໂດຍ config. ແລະຄວາມຊົງຈໍານີ້ບໍ່ໄດ້ຖືກຈັດສັນ.

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

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

• ມັນຂຶ້ນກັບການໂຫຼດທີ່ປະຈຸບັນຢູ່ໃນຜະລິດຕະພັນ.

• ມັນຂຶ້ນກັບຄຸນລັກສະນະຂອງເຄື່ອງຈັກຂອງມັນເອງ.

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

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

ລອງພິຈາລະນາເບິ່ງວ່າ Joe ຖືກປັບແຕ່ງໂດຍສະເພາະແນວໃດ.

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

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

B Joe ຈະສະແດງໃຫ້ທ່ານແນະນໍາອັດຕະໂນມັດໂດຍອີງໃສ່ແຜນການແລະການວັດແທກ.

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

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

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

ແລະນີ້ເກີດຂຶ້ນໃນແຜນການເນື່ອງຈາກຄວາມຈິງທີ່ວ່າເງື່ອນໄຂໃນການສອບຖາມແລະເງື່ອນໄຂໃນດັດຊະນີບາງສ່ວນບໍ່ກົງກັນ.

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

ການສ້າງດັດສະນີໃຊ້ເວລາຂ້ອນຂ້າງຍາວ, ແຕ່ຕອນນີ້ພວກເຮົາກວດເບິ່ງແບບສອບຖາມແລະເຫັນວ່າເວລາແທນທີ່ຈະເປັນ 2,5 ນາທີແມ່ນພຽງແຕ່ 156 ມິນລິວິນາທີ, ເຊິ່ງດີພໍ. ແລະພວກເຮົາອ່ານຂໍ້ມູນພຽງແຕ່ 6 megabytes.

ແລະໃນປັດຈຸບັນພວກເຮົາໃຊ້ດັດສະນີພຽງແຕ່ສະແກນ.

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

ນີ້ແມ່ນຄໍາຮ້ອງຂໍທີ່ແຕກຕ່າງກັນ, ຮຸນແຮງກວ່າ. ແລະພວກເຮົາສ້າງ Flame Graphs ຕາມສອງຕົວກໍານົດການ: ນີ້ແມ່ນຈໍານວນຂໍ້ມູນທີ່ node ໂດຍສະເພາະນັບຢູ່ໃນແຜນການແລະເວລາ, i.e. ເວລາປະຕິບັດຂອງ node.

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

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

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

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

ການຮ່ວມມື

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

ມັນເບິ່ງຄືວ່າພວກເຮົາມີຄວາມສໍາຄັນທີ່ຈະທົດສອບຂໍ້ມູນຂະຫນາດເຕັມ. ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາໄດ້ສ້າງເຄື່ອງມື Update Database Lab, ເຊິ່ງມີຢູ່ໃນແຫຼ່ງເປີດ. ທ່ານສາມາດນໍາໃຊ້ Joe bot ຄືກັນ. ທ່ານ​ສາ​ມາດ​ເອົາ​ມັນ​ໃນ​ປັດ​ຈຸ​ບັນ​ແລະ​ປະ​ຕິ​ບັດ​ມັນ​ຢູ່​ທີ່​ຂອງ​ທ່ານ​. ຜູ້ແນະນຳທັງໝົດແມ່ນມີຢູ່ບ່ອນນັ້ນ.

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

ນີ້ແມ່ນບ່ອນທີ່ຂ້ອຍສິ້ນສຸດ. ຂອບ​ໃຈ!

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

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

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

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

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

ມີບາງ ttl ສໍາລັບແຕ່ລະ clone. ໂດຍພື້ນຖານແລ້ວ, ພວກເຮົາມີ ttl ຄົງທີ່.

ຈະເປັນແນວໃດ, ຖ້າບໍ່ແມ່ນຄວາມລັບ?

1 ຊົ່ວໂມງ, i.e. idle - 1 ຊົ່ວໂມງ. ຖ້າມັນບໍ່ຖືກນໍາໃຊ້, ຫຼັງຈາກນັ້ນພວກເຮົາ bang ມັນ. ແຕ່​ບໍ່​ມີ​ຄວາມ​ແປກ​ໃຈ​ທີ່​ນີ້​, ນັບ​ຕັ້ງ​ແຕ່​ພວກ​ເຮົາ​ສາ​ມາດ​ຍົກ​ສູງ​ບົດ​ບາດ clone ໃນ​ວິ​ນາ​ທີ​. ແລະຖ້າທ່ານຕ້ອງການມັນອີກເທື່ອຫນຶ່ງ, ກະລຸນາ.

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

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

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

Nikolai Samokhvalov: ຂ້ອຍຂໍຄໍາເຫັນຕື່ມອີກບໍ? ຂ້ອຍຊື່ Nikolay, ພວກເຮົາເຮັດວຽກຮ່ວມກັນກັບ Anatoly. ຂ້ອຍເຫັນດີວ່າການເກັບຮັກສາແມ່ນດີຫຼາຍ. ແລະບາງລູກຄ້າຂອງພວກເຮົາມີ Pure Storage ແລະອື່ນໆ.

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

ແຕ່ ZFS ມີໃຫ້ທຸກຄົນ. DelPhix ແມ່ນພຽງພໍແລ້ວ, ພວກເຂົາມີລູກຄ້າ 300 ຄົນ. ໃນນັ້ນ, fortune 100 ມີລູກຄ້າ 50 ຄົນ, i.e. ເຂົາເຈົ້າມີຈຸດປະສົງຢູ່ອົງການ NASA, ແລະອື່ນໆ. ມັນເປັນເວລາສໍາລັບທຸກຄົນທີ່ຈະໄດ້ຮັບເຕັກໂນໂລຢີນີ້. ແລະນັ້ນແມ່ນເຫດຜົນທີ່ພວກເຮົາມີ Open Source Core. ພວກເຮົາມີສ່ວນການໂຕ້ຕອບທີ່ບໍ່ແມ່ນແຫຼ່ງເປີດ. ນີ້ແມ່ນເວທີທີ່ພວກເຮົາຈະສະແດງ. ແຕ່ພວກເຮົາຕ້ອງການໃຫ້ມັນເຂົ້າເຖິງໄດ້ກັບທຸກຄົນ. ພວກເຮົາຕ້ອງການທີ່ຈະເຮັດການປະຕິວັດເພື່ອໃຫ້ຜູ້ທົດສອບທັງຫມົດຢຸດເຊົາການຄາດເດົາກ່ຽວກັບຄອມພິວເຕີໂນດບຸກ. ພວກເຮົາຕ້ອງຂຽນ SELECT ແລະທັນທີເຫັນວ່າມັນຊ້າ. ຢຸດລໍຖ້າໃຫ້ DBA ບອກທ່ານກ່ຽວກັບມັນ. ນີ້ແມ່ນເປົ້າຫມາຍຕົ້ນຕໍ. ແລະຂ້າພະເຈົ້າຄິດວ່າພວກເຮົາທຸກຄົນຈະມາຮອດນີ້. ແລະພວກເຮົາເຮັດໃຫ້ສິ່ງນີ້ສໍາລັບທຸກຄົນທີ່ຈະມີ. ເພາະສະນັ້ນ ZFS, ເນື່ອງຈາກວ່າມັນຈະມີຢູ່ທົ່ວທຸກແຫ່ງ. ຂອບໃຈຊຸມຊົນສຳລັບການແກ້ໄຂບັນຫາ ແລະສຳລັບການມີໃບອະນຸຍາດແຫຼ່ງເປີດ, ແລະອື່ນໆ.*

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

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

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

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

ຂ້ອຍມີສອງຄໍາຖາມ. ນີ້ແມ່ນສິ່ງທີ່ເຢັນຫຼາຍ. ມີກໍລະນີທີ່ຂໍ້ມູນການຜະລິດມີຄວາມສໍາຄັນເຊັ່ນ: ເລກບັດເຄຣດິດບໍ? ມີສິ່ງທີ່ກຽມພ້ອມແລ້ວຫຼືເປັນວຽກທີ່ແຍກຕ່າງຫາກບໍ? ແລະຄໍາຖາມທີສອງ - ມີບາງສິ່ງບາງຢ່າງເຊັ່ນນີ້ສໍາລັບ MySQL?

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

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

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

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

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

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

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

ດັດສະນີຈະຖືກສ້າງຂື້ນໃນແຕ່ລະຄັ້ງບໍ?

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

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

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

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

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

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

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

ຈາກຊັ້ນກ່ອນໜ້າ ທີ່ມາຈາກການຈຳລອງກ່ອນໜ້າ.

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

ໂດຍທົ່ວໄປ, ແມ່ນແລ້ວ.

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

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

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

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

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

ໃນປັດຈຸບັນມີການເຊື່ອມຕໍ່ກັບ Slack, i.e. ບໍ່ມີຜູ້ສົ່ງຂ່າວອື່ນ, ແຕ່ຂ້ອຍກໍ່ຕ້ອງການສະຫນັບສະຫນູນຜູ້ສົ່ງຂ່າວອື່ນໆເຊັ່ນກັນ. ເຈົ້າສາມາດເຮັດຫຍັງໄດ້ແດ່? ທ່ານສາມາດຕິດຕັ້ງ DB Lab ໂດຍບໍ່ມີ Joe, ໄປດ້ວຍການຊ່ວຍເຫຼືອຂອງ REST API ຫຼືດ້ວຍການຊ່ວຍເຫຼືອຂອງເວທີຂອງພວກເຮົາແລະສ້າງ clones ແລະເຊື່ອມຕໍ່ກັບ PSQL. ແຕ່ນີ້ສາມາດເຮັດໄດ້ຖ້າຫາກວ່າທ່ານພ້ອມທີ່ຈະໃຫ້ນັກພັດທະນາຂອງທ່ານເຂົ້າເຖິງຂໍ້ມູນ, ເພາະວ່າຈະບໍ່ມີຫນ້າຈໍໃດໆ.

ຂ້ອຍບໍ່ຕ້ອງການຊັ້ນນີ້, ແຕ່ຂ້ອຍຕ້ອງການໂອກາດດັ່ງກ່າວ.

ແລ້ວ, ມັນສາມາດເຮັດໄດ້.

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