ຄ່າໃຊ້ຈ່າຍທີ່ແທ້ຈິງຂອງ I/O ແບບສຸ່ມ

ຊອບ​ແວ​ທຸ​ລະ​ກິດ​ຂອງ​ທ່ານ​ແມ່ນ​ຊ້າ​ກ​່​ວາ​ມັນ​ຄວນ​ຈະ​ເປັນ — ແລະ Random I/O ແມ່ນ​ການ​ກະ​ທໍາ​ຜິດ​ທີ່​ເບິ່ງ​ບໍ່​ເຫັນ

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

I/O Random ຫມາຍຄວາມວ່າແນວໃດ (ແລະເປັນຫຍັງມັນແພງ)

ໃນຫຼັກຂອງມັນ, I/O — input/output — ແມ່ນຂະບວນການອ່ານ ແລະຂຽນຂໍ້ມູນໃສ່ບ່ອນເກັບຂໍ້ມູນ. ເມື່ອແອັບພລິເຄຊັນຂອງທ່ານດຶງເອົາບັນທຶກຈາກຖານຂໍ້ມູນ, ໂຫລດໄຟລ໌ຈາກແຜ່ນ, ຫຼືຂຽນບັນທຶກການເຮັດທຸລະກໍາ, ມັນດໍາເນີນການ I/O. ການປະຕິບັດເຫຼົ່ານີ້ມີສອງລົດຊາດ: ຕາມລໍາດັບ ແລະ ແບບສຸ່ມ. Sequential I/O ອ່ານ ຫຼືຂຽນຂໍ້ມູນໃນບລັອກທີ່ຕິດຕໍ່ກັນ ເຊັ່ນ: ການອ່ານໜັງສືຕັ້ງແຕ່ຕົ້ນຈົນຈົບ. Random I/O ໂດດໄປມາແບບບໍ່ຄາດຄິດ ເຊັ່ນ: ພິກໄປໜ້າ 47, ຈາກນັ້ນໜ້າ 3, ຈາກນັ້ນໜ້າ 812.

ຊ່ອງ​ຫວ່າງ​ການ​ປະ​ຕິ​ບັດ​ລະ​ຫວ່າງ​ສອງ​ຮູບ​ແບບ​ນີ້​ແມ່ນ staggering. ໃນຮາດໄດດ໌ແບບດັ້ງເດີມ, ການອ່ານຕາມລຳດັບສາມາດບັນລຸໄດ້ເຖິງ 150-200 MB/s, ໃນຂະນະທີ່ການອ່ານແບບສຸ່ມມັກຈະລວບລວມຂໍ້ມູນຢູ່ທີ່ 0.5-1.5 MB/s — ຄວາມແຕກຕ່າງຂອງ 100x ຫຼືຫຼາຍກວ່ານັ້ນ. ເຖິງແມ່ນວ່າໃນ NVMe SSDs ທີ່ທັນສະໄຫມ, ເຊິ່ງປັບປຸງປະສິດທິພາບ I/O ແບບສຸ່ມຢ່າງຫຼວງຫຼາຍ, ຊ່ອງຫວ່າງຍັງຄົງຢູ່ລະຫວ່າງ 5x ຫາ 20x ຂຶ້ນກັບວຽກ. ເມື່ອຄໍາຮ້ອງສະຫມັກທຸລະກິດຂອງທ່ານອອກຄໍາຮ້ອງຂໍການອ່ານກະແຈກກະຈາຍຂະຫນາດນ້ອຍຫຼາຍພັນຄໍາຕໍ່ວິນາທີ - ດຶງຊື່ລູກຄ້າມາທີ່ນີ້, ບັນຊີລາຍການໃບເກັບເງິນຢູ່ທີ່ນັ້ນ, ການກວດສອບການອະນຸຍາດຢູ່ບ່ອນອື່ນ - ແຕ່ລະ hop ແນະນໍາ latency ທີ່ວັດແທກເປັນ microseconds ທີ່ປະສົມເຂົ້າໄປໃນວິນາທີຂອງເວລາລໍຖ້າຂອງຜູ້ໃຊ້ທີ່ແທ້ຈິງ.

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

ພາສີທີ່ເຊື່ອງໄວ້ໃນທຸກໆການດຳເນີນທຸລະກິດ

ພິຈາລະນາສິ່ງທີ່ເກີດຂຶ້ນເມື່ອຜູ້ໃຊ້ດຽວເປີດ dashboard CRM. ແອັບພລິເຄຊັນສອບຖາມຕາຕະລາງລູກຄ້າ, ເຂົ້າຮ່ວມກັບບັນທຶກກິດຈະກໍາທີ່ຜ່ານມາ, ດຶງມູນຄ່າການຕົກລົງທີ່ກ່ຽວຂ້ອງ, ກວດສອບການອະນຸຍາດຂອງຜູ້ໃຊ້, ຈໍານວນການແຈ້ງເຕືອນການໂຫຼດ, ແລະການດຶງຂໍ້ມູນຕາມຄວາມຕ້ອງການສະແດງ. ແຕ່ລະຄໍາຖາມເຫຼົ່ານີ້ອາດຈະສໍາຜັດກັບຕາຕະລາງທີ່ແຕກຕ່າງກັນທີ່ເກັບໄວ້ໃນສະຖານທີ່ຕ່າງໆໃນແຜ່ນ. ແຜງໜ້າປັດທີ່ສະແດງບັນທຶກລູກຄ້າ 50 ອັນອາດຈະສ້າງ 300 ຫາ 500 ການດຳເນີນການ I/O ແບບສຸ່ມ ພາຍໃຕ້ຝາອັດປາກມົດລູກ. ຄູນໃຫ້ 200 ຜູ້ໃຊ້ພ້ອມກັນໃນຊ່ວງເວລາເຮັດວຽກສູງສຸດ, ແລະເຊີບເວີຖານຂໍ້ມູນຂອງເຈົ້າກຳລັງປະມວນຜົນການອ່ານແບບສຸ່ມ 100,000 ເທື່ອຕໍ່ວິນາທີ.

ນີ້ບໍ່ແມ່ນສົມມຸດຕິຖານ. ການສຶກສາປີ 2024 ໂດຍ Percona ພົບວ່າການໂຫຼດຂອງຖານຂໍ້ມູນທີ່ເພີ່ມປະສິດທິພາບບໍ່ດີໃຊ້ເວລາເຖິງ 68% ຂອງເວລາປະຕິບັດການທັງໝົດ ລໍຖ້າການດຳເນີນການ I/O, ໂດຍມີຮູບແບບການເຂົ້າເຖິງແບບສຸ່ມເປັນຜູ້ກະທຳຜິດຫຼັກ. ສໍາລັບບໍລິສັດ SaaS ທີ່ໃຫ້ບໍລິການທຸລະກິດຫຼາຍພັນຄົນ, ນີ້ແປໂດຍກົງເປັນຄ່າໃຊ້ຈ່າຍໃນໂຄງສ້າງພື້ນຖານທີ່ສູງຂຶ້ນ. ຜູ້ໃຫ້ບໍລິການຄລາວຄິດຄ່າບໍລິການໂດຍ IOPS (ການດຳເນີນການ I/O ຕໍ່ວິນາທີ), ແລະການໂຫຼດ I/O ໜັກແບບສຸ່ມສາມາດສົ່ງໃບບິນເກັບຂໍ້ມູນປະຈໍາເດືອນຈາກຫຼາຍຮ້ອຍເປັນຫຼາຍສິບພັນໂດລາ — ບໍ່ແມ່ນຍ້ອນປະລິມານຂໍ້ມູນ, ແຕ່ເປັນຍ້ອນຮູບແບບການເຂົ້າເຖິງ.

ຄ່າໃຊ້ຈ່າຍແມ່ນເກີນກວ່າໂຄງສ້າງພື້ນຖານ. ທຸກໆ 100 milliseconds ຂອງເວລາໂຫຼດຫນ້າເພີ່ມເຕີມຫຼຸດລົງອັດຕາການປ່ຽນແປງປະມານ 7%, ອີງຕາມການຄົ້ນຄວ້າຈາກ Akamai. ເມື່ອ I/O ແບບສຸ່ມເພີ່ມວິນາທີເຕັມໃຫ້ກັບການສ້າງໃບແຈ້ງໜີ້ຂອງທ່ານ ຫຼືການໂຫຼດລາຍງານ, ທ່ານບໍ່ພຽງແຕ່ກຳລັງເຜົາຜານຄອມພິວເຕີເທົ່ານັ້ນ — ທ່ານກຳລັງສ້າງລາຍຮັບ.

ບ່ອນທີ່ແອັບພລິເຄຊັນທຸລະກິດເຮັດໃຫ້ປະສິດທິພາບ

ບໍ່​ແມ່ນ​ທຸກ​ຄຸນ​ສົມ​ບັດ​ທີ່​ຖືກ​ສ້າງ​ໃຫ້​ເທົ່າ​ທຽມ​ກັນ​ເມື່ອ​ມັນ​ມາ​ກັບ​ຮູບ​ແບບ I/O. ບາງການດຳເນີນທຸລະກິດທົ່ວໄປທີ່ສຸດກໍ່ແມ່ນຜູ້ກະທຳຜິດທີ່ຮ້າຍແຮງທີ່ສຸດສຳລັບການເຂົ້າເຖິງແບບສຸ່ມ:

• ຄົ້ນຫາ ແລະການກັ່ນຕອງ: ການສອບຖາມທົ່ວຫຼາຍຊ່ອງຂໍ້ມູນ (ຊື່, ວັນທີ, ສະຖານະ, ແທັກ) ບັງຄັບໃຫ້ຖານຂໍ້ມູນສະແກນດັດຊະນີທີ່ກະແຈກກະຈາຍໄປທົ່ວບ່ອນເກັບຂໍ້ມູນ, ເຮັດໃຫ້ເກີດການອ່ານແບບສຸ່ມຫຼາຍ
• ການລວບລວມ Dashboard: ການສັງລວມລາຍຮັບ, ການນັບຜູ້ໃຊ້ທີ່ເຄື່ອນໄຫວຢູ່, ຫຼືການຄິດໄລ່ໃບແຈ້ງໜີ້ທີ່ເກີນກຳນົດຕ້ອງການແຕະຫຼາຍພັນແຖວທີ່ກະຈາຍໄປທົ່ວໜ້າຂໍ້ມູນຕ່າງໆ
• ການກວດສອບການອະນຸຍາດ: ການຄວບຄຸມການເຂົ້າເຖິງໂດຍອີງໃສ່ບົດບາດໃນຫຼາຍແພລດຟອມຜູ້ເຊົ່າມັກຈະຮຽກຮ້ອງໃຫ້ມີການຊອກຫາຫຼາຍຄັ້ງຕໍ່ຄໍາຮ້ອງຂໍ — ຜູ້ໃຊ້ → ບົດບາດ → ການອະນຸຍາດ → ຊັບພະຍາກອນ — ແຕ່ລະການຕີຕາຕະລາງທີ່ແຕກຕ່າງກັນ
• ການ​ສ້າງ​ບົດ​ລາຍ​ງານ: ລາຍ​ງານ​ການ​ຈ່າຍ​ເງິນ​ປະ​ຈໍາ​ເດືອນ, ສັງ​ລວມ​ການ​ບໍາ​ລຸງ​ຮັກ​ສາ​ເຮືອ, ຫຼື​ການ​ວິ​ເຄາະ HR ດຶງ​ຂໍ້​ມູນ​ຈາກ​ຫຼາຍ​ສິບ​ຕາ​ຕະ​ລາງ​ພ້ອມ​ກັນ
• ການແຈ້ງເຕືອນແບບສົດໆ: ການກວດສອບຂໍ້ຄວາມໃໝ່, ການອັບເດດໜ້າວຽກ ແລະ ການແຈ້ງເຕືອນລະບົບໃນທົ່ວທຸກໂມດູນຈະສ້າງກະແສແບບສອບຖາມແບບສຸ່ມແບບຄົງທີ່

ຮູບແບບແມ່ນຈະແຈ້ງ: ຍິ່ງມີໂມດູນຫຼາຍ ແລະຄຸນສົມບັດທີ່ເວທີສະເໜີໃຫ້, ເສັ້ນທາງ I/O ຫຼາຍເທົ່າໃດ. ເຄື່ອງມື link-in-bio ງ່າຍໆອາດຈະສ້າງ 10 ຄໍາຖາມຕໍ່ການໂຫຼດຫນ້າ. ລະ​ບົບ​ປະ​ຕິ​ບັດ​ການ​ທຸ​ລະ​ກິດ​ຢ່າງ​ເຕັມ​ທີ່​ທີ່​ມີ CRM​, invoicing​, HR​, payrolling​, booking​, ແລະ​ໂມ​ດູນ​ການ​ວິ​ເຄາະ — ຄື​ສິ່ງ​ທີ່ Mewayz ໃຫ້​ໃນ​ທົ່ວ 207 ໂມ​ດູນ​ຂອງ​ຕົນ — ທາງ​ທິດ​ສະ​ດີ​ສາ​ມາດ​ສ້າງ​ຫຼາຍ​ຮ້ອຍ​ຄົນ​. ຄວາມແຕກຕ່າງລະຫວ່າງແພລດຟອມທີ່ມີຄວາມຮູ້ສຶກທັນທີ ແລະອັນໜຶ່ງທີ່ຮູ້ສຶກຊ້າລົງມາຢູ່ກັບວິທີການຈັດການຮູບແບບ I/O ເຫຼົ່ານັ້ນຢ່າງສະຫຼາດຢູ່ເບື້ອງຫຼັງ.

ເປັນຫຍັງການຖິ້ມຮາດແວໃສ່ບັນຫາຈຶ່ງບໍ່ເຮັດວຽກ

ສະຕິປັນຍາເມື່ອແອັບພລິເຄຊັນຊ້າລົງແມ່ນການອັບເກຣດ. ເຊີບເວີໃຫຍ່ກວ່າ, SSDs ໄວກວ່າ, RAM ຫຼາຍ. ແລະໃນຂະນະທີ່ການປັບປຸງຮາດແວຊ່ວຍ, ພວກເຂົາປະຕິບັດຕາມເສັ້ນໂຄ້ງຂອງຜົນຕອບແທນທີ່ຫຼຸດລົງທີ່ເຮັດໃຫ້ CFOs ບໍ່ສະບາຍ. ການເພີ່ມ RAM ຂອງເຄື່ອງແມ່ຂ່າຍຖານຂໍ້ມູນຂອງທ່ານເປັນສອງເທົ່າຈາກ 64GB ເປັນ 128GB ອາດຈະປັບປຸງອັດຕາການຕີ cache ຈາກ 92% ເປັນ 96% - ເປັນການເພີ່ມຂຶ້ນທີ່ມີຄວາມຫມາຍ, ແຕ່ 4% ທີ່ຍັງເຫຼືອຂອງ cache misss ຍັງມົນຕີການເກັບຮັກສາດ້ວຍ I/O random. ການເພີ່ມການຈັດສັນ IOPS ຂອງທ່ານໃນ AWS ຈາກ 3,000 ຫາ 10,000 ຄ່າໃຊ້ຈ່າຍປະມານ $450 ຕໍ່ເດືອນ ແຕ່ອາດຈະປັບປຸງເວລາຕອບໂຕ້ p99 ໄດ້ພຽງແຕ່ 30%.

ບັນຫາທີ່ແທ້ຈິງແມ່ນສະຖາປັດຕະຍະກໍາ. Random I/O ມັກຈະເປັນອາການຂອງບັນຫາທີ່ເລິກເຊິ່ງກວ່າ: ດັດສະນີທີ່ຂາດຫາຍໄປ ຫຼືອອກແບບບໍ່ດີ, ຮູບແບບການສອບຖາມ N+1 ທີ່ແອັບພລິເຄຊັນເຮັດການໂທຖານຂໍ້ມູນໜຶ່ງຕໍ່ລາຍການ ແທນທີ່ຈະເປັນຊຸດ, ຮູບແບບທີ່ເກີນປົກກະຕິທີ່ຕ້ອງການ 5 ຕາຕະລາງເຂົ້າຮ່ວມສໍາລັບແຖວສະແດງຜົນດຽວ, ແລະຂາດການອ່ານແບບຈໍາລອງ ຫຼືຊັ້ນຂໍ້ມູນຖານຄວາມຈໍາ. ການຍົກລະດັບຮາດແວປິ່ນປົວອາການ. ການເພີ່ມປະສິດທິພາບທາງສະຖາປັດຕະຍະກຳຮັກສາສາເຫດ.

ການດຳເນີນການ I/O ທີ່ແພງທີ່ສຸດແມ່ນອັນທີ່ບໍ່ຄວນມີຢູ່ໃນບ່ອນທຳອິດ. ສໍາລັບທຸກໆເງິນໂດລາທີ່ໃຊ້ໃນການເກັບຮັກສາໄວ, ສິບເຊັນທີ່ໃຊ້ໃນການເພີ່ມປະສິດທິພາບການສອບຖາມໃຫ້ຜົນໄດ້ຮັບທີ່ດີກວ່າ. ບໍລິສັດທີ່ຊະນະດ້ານປະສິດທິພາບບໍ່ເກີນການແຂ່ງຂັນຂອງເຂົາເຈົ້າ — ເຂົາເຈົ້າຄິດວ່າຮູບແບບການເຂົ້າເຖິງຂໍ້ມູນຂອງເຂົາເຈົ້າ.

💡 DID YOU KNOW?

Mewayz replaces 8+ business tools in one platform

CRM · Invoicing · HR · Projects · Booking · eCommerce · POS · Analytics. Free forever plan available.

Start Free →

ຍຸດທະສາດການປະຕິບັດຕົວຈິງທີ່ຫຼຸດຜ່ອນ I/O ແບບສຸ່ມ

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

1. ປະຕິບັດການສອບຖາມແບບຮຸກຮານ. ແທນທີ່ຮູບແບບການສອບຖາມ N+1 ດ້ວຍການໂຫຼດແບບກະຕືລືລົ້ນ. ຖ້າ dashboard ຂອງທ່ານໂຫຼດ 50 ລູກຄ້າແລະກິດຈະກໍາທີ່ຜ່ານມາຂອງພວກເຂົາ, ເອົາຊຸດກິດຈະກໍາທັງຫມົດ 50 ຢູ່ໃນຄໍາຖາມດຽວໂດຍໃຊ້ WHERE customer_id IN (...) ແທນທີ່ຈະຊອກຫາ 50 ບຸກຄົນ. ອັນດຽວເທົ່ານັ້ນສາມາດຫຼຸດ I/O ແບບສຸ່ມໄດ້ 80% ຈາກການເບິ່ງລາຍການ.
2. ໃຊ້ດັດສະນີປະສົມຢ່າງມີຍຸດທະສາດ. ດັດຊະນີປະສົມໃນ (tenant_id, status, created_at) ຊ່ວຍໃຫ້ຖານຂໍ້ມູນຕອບສະໜອງການສອບຖາມທີ່ຖືກກັ່ນຕອງທົ່ວໄປດ້ວຍການສະແກນດັດສະນີຕາມລໍາດັບອັນດຽວ ແທນທີ່ຈະຊອກຫາແບບສຸ່ມຫຼາຍອັນໃນທົ່ວດັດຊະນີແຍກຕ່າງຫາກ.
3. ແນະນຳຊັ້ນເກັບຂໍ້ມູນດ້ວຍການກວດສອບບໍ່ຖືກຕ້ອງ. Cache ເຂົ້າເຖິງເລື້ອຍໆ ແຕ່ບໍ່ຄ່ອຍມີການປ່ຽນແປງຂໍ້ມູນ — ການອະນຸຍາດຂອງຜູ້ໃຊ້, ການຕັ້ງຄ່າອົງກອນ, ການຕັ້ງຄ່າໂມດູນ — ໃນໜ່ວຍຄວາມຈຳ. Redis ຫຼື Memcached ສາມາດຮັບໃຊ້ສິ່ງເຫຼົ່ານີ້ໃນ microseconds, ກໍາຈັດການອ່ານແບບສຸ່ມຫຼາຍພັນເທື່ອຕໍ່ນາທີ.
4. ການລວບລວມຂໍ້ມູນລ່ວງໜ້າ. ແທນທີ່ຈະຄຳນວນລາຍຮັບລາຍເດືອນ ຫຼື ຈຳນວນຫົວໃນທຸກໆການໂຫຼດຂອງ dashboard, ເຮັດວຽກການຮວບຮວມຕາມກຳນົດເວລາ ແລະຈັດເກັບຜົນໄດ້ຮັບ. ຊື້ຂາຍຄວາມສົດຂອງຂໍ້ມູນຈຳນວນໜ້ອຍເພື່ອຫຼຸດປະລິມານ I/O ແບບສຸ່ມໃນເວລາຈິງ.
5. ແບ່ງຕາຕະລາງຂະໜາດໃຫຍ່ຕາມຮູບແບບການເຂົ້າເຖິງ. ຖ້າ 90% ຂອງການສອບຖາມສໍາຜັດກັບຂໍ້ມູນຈາກ 30 ມື້ທີ່ຜ່ານມາ, ແບ່ງຕາຕະລາງຂອງທ່ານຕາມຊ່ວງວັນທີເພື່ອໃຫ້ພາທິຊັນທີ່ເຮັດວຽກຢູ່ໃນ cache ຮ້ອນ ໃນຂະນະທີ່ຂໍ້ມູນປະຫວັດສາດຍັງເຢັນຢູ່ໃນບ່ອນເກັບຂໍ້ມູນລາຄາຖືກກວ່າ.

ເຫຼົ່ານີ້ບໍ່ແມ່ນເຕັກນິກທີ່ແປກປະຫຼາດ. ພວກມັນເປັນຮູບແບບດຽວກັນທີ່ອະນຸຍາດໃຫ້ແພລະຕະຟອມຮັບໃຊ້ຜູ້ໃຊ້ຫຼາຍຮ້ອຍພັນຄົນເພື່ອຮັກສາເວລາຕອບໂຕ້ຍ່ອຍວິນາທີຜ່ານການໂຕ້ຕອບຫຼາຍໂມດູນທີ່ສັບສົນ. ເມື່ອ Mewayz ກໍ່ສ້າງສະຖາປັດຕະຍະກໍາໃຫມ່ຂອງຕົນສໍາລັບ V2 — ຂະຫຍາຍຈາກເຄື່ອງມືເຊື່ອມຕໍ່ໃນຊີວະພາບດຽວໄປຫາ 207-module OS ທີ່ໃຫ້ບໍລິການຜູ້ໃຊ້ຫຼາຍກວ່າ 138,000 ຄົນ — ການເພີ່ມປະສິດທິພາບຮູບແບບການເຂົ້າເຖິງ I/O ແມ່ນພື້ນຖານເພື່ອເຮັດໃຫ້ການຂະຫຍາຍດັ່ງກ່າວສາມາດນຳໃຊ້ໄດ້ໂດຍບໍ່ມີການຄູນຄ່າໂຄງສ້າງພື້ນຖານຕາມອັດຕາສ່ວນ.

ຜົນ​ກະ​ທົບ​ຕໍ່​ປະ​ສົບ​ການ​ຂອງ​ຜູ້​ໃຊ້ ແລະ​ການ​ເກັບ​ຮັກ​ສາ​ໄວ້

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

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

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

ການວັດແທກສິ່ງທີ່ສຳຄັນ: ເຮັດໃຫ້ I/O ເຫັນໄດ້ແບບສຸ່ມ

ທ່ານບໍ່ສາມາດແກ້ໄຂສິ່ງທີ່ທ່ານເບິ່ງບໍ່ເຫັນ. ຂັ້ນຕອນທໍາອິດໃນການແກ້ໄຂຄ່າໃຊ້ຈ່າຍ I/O ແບບສຸ່ມແມ່ນເຮັດໃຫ້ພວກເຂົາເຫັນໄດ້ໂດຍທີມງານວິສະວະກໍາແລະການດໍາເນີນງານຂອງທ່ານ. ເຄື່ອງມືການສັງເກດການທີ່ທັນສະໄຫມເຊັ່ນ Datadog, New Relic, ຫຼືແມ້ກະທັ້ງການແກ້ໄຂແຫຼ່ງເປີດເຊັ່ນ Prometheus ກັບ Grafana ສາມາດຕິດຕາມຮູບແບບ IOPS, ສອບຖາມການແຈກຢາຍ latency ແລະອັດຕາການຕີ cache ໃນເວລາຈິງ. ຕົວຊີ້ວັດທີ່ສຳຄັນທີ່ສຸດແມ່ນ:

• p95 ແລະ p99 query latency: latency ສະເລ່ຍເຊື່ອງຄວາມເຈັບປວດ. ເປີເຊັນທີ 95 ແລະ 99 ສະແດງໃຫ້ເຫັນສິ່ງທີ່ຊ້າທີ່ສຸດຂອງເຈົ້າ - ແລະອຸກອັ່ງທີ່ສຸດ - ຜູ້ໃຊ້ປະສົບການຕົວຈິງ
• ການແບ່ງ IOPS ດ້ວຍການອ່ານທຽບກັບການຂຽນ, ຕາມລໍາດັບທຽບກັບແບບສຸ່ມ: ນີ້ຈະເປີດເຜີຍວ່າວຽກຂອງເຈົ້າຖືກຜູກມັດ I/O ແລະປະເພດໃດທີ່ I/O ຄອບຄອງ
• ອັດຕາສ່ວນຂອງ Cache hit: ອັດຕາສ່ວນຕໍ່າກວ່າ 95% ໃນລະບົບທີ່ປັບແຕ່ງມາດີ ແນະນຳຮູບແບບການເຂົ້າເຖິງຂໍ້ມູນທີ່ບໍ່ໄດ້ໃຫ້ບໍລິການຈາກໜ່ວຍຄວາມຈຳ
• ຈຳນວນການສອບຖາມຕໍ່ການໂຫຼດໜ້າ: ຖ້າການດຳເນີນການຂອງຜູ້ໃຊ້ດຽວເຮັດໃຫ້ເກີດການສອບຖາມຖານຂໍ້ມູນຫຼາຍກວ່າ 20-30 ເທື່ອ, ເກືອບແນ່ນອນວ່າມີໂອກາດເພີ່ມປະສິດທິພາບ

ປະກອບອາວຸດດ້ວຍຂໍ້ມູນນີ້, ທີມງານສາມາດຈັດລໍາດັບຄວາມສໍາຄັນຂອງການເພີ່ມປະສິດທິພາບທີ່ມີຜົນກະທົບສູງສຸດແທນທີ່ຈະເປັນການຄາດເດົາ. ທຸລະກິດທີ່ປະຕິບັດຕໍ່ການປະຕິບັດ I/O ເປັນການວັດແທກລະດັບທໍາອິດ - ຄຽງຄູ່ກັບການໃຊ້ເວລາຫວ່າງ, ອັດຕາຄວາມຜິດພາດ, ແລະຄວາມພໍໃຈຂອງຜູ້ໃຊ້ - ສະເຫມີໃຫ້ຜະລິດຕະພັນທີ່ໄວຂຶ້ນດ້ວຍຄ່າໃຊ້ຈ່າຍຕ່ໍາ. ໃນຕະຫຼາດທີ່ຜູ້ໃຊ້ຄາດຫວັງວ່າເຄື່ອງມືທາງທຸລະກິດຈະຕອບສະຫນອງຄືກັບແອັບຯຂອງຜູ້ບໍລິໂພກ, ລະບຽບວິໄນນັ້ນບໍ່ແມ່ນທາງເລືອກ. ມັນ​ເປັນ​ຄວາມ​ແຕກ​ຕ່າງ​ລະ​ຫວ່າງ​ເວ​ທີ​ທີ່​ຂະ​ຫນາດ​ຄວາມ​ງາມ​ກັບ 138,000 ຜູ້​ໃຊ້​ແລະ​ຫນຶ່ງ​ທີ່ buckles ພາຍ​ໃຕ້​ຄວາມ​ສັບ​ສົນ​ຂອງ​ຕົນ​ເອງ.

ຄຳຖາມທີ່ຖາມເລື້ອຍໆ

I/O ແບບສຸ່ມແມ່ນຫຍັງ ແລະເປັນຫຍັງມັນຊ້າຫຼາຍ?

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

I/O ແບບສຸ່ມມີຜົນກະທົບໂດຍກົງຕໍ່ການດຳເນີນທຸລະກິດຂອງຂ້ອຍແນວໃດ?

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

ນີ້ບໍ່ແມ່ນພຽງແຕ່ບັນຫາຮາດແວບໍ? ຂ້ອຍບໍ່ສາມາດຊື້ SSD ທີ່ໄວກວ່າໄດ້ບໍ?

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

ຂັ້ນຕອນທຳອິດໃນການລະບຸວ່າ I/O ແບບສຸ່ມແມ່ນຄໍຂວດຂອງຂ້ອຍແມ່ນຫຍັງ?

ເລີ່ມຕົ້ນດ້ວຍເຄື່ອງມືຕິດຕາມປະສິດທິພາບຂອງແອັບພລິເຄຊັນຂອງທ່ານ. ຊອກຫາ metrics ຖານຂໍ້ມູນສະແດງໃຫ້ເຫັນການດໍາເນີນການອ່ານ / ຂຽນສູງຕໍ່ວິນາທີ (IOPS) ບວກໃສ່ກັບເວລາສອບຖາມຊ້າ. ໂປຣໄຟລ໌ແອັບພລິເຄຊັນຂອງທ່ານເພື່ອລະບຸການສອບຖາມນ້ອຍໆເລື້ອຍໆ. ຖ້າການກະ ທຳ ຂອງຜູ້ໃຊ້ດຽວເຮັດໃຫ້ເກີດການໂທໃນຖານຂໍ້ມູນແຕ່ລະອັນແທນທີ່ຈະເປັນບາງອັນທີ່ມີປະສິດຕິພາບ, ເຈົ້າອາດຈະພົບບັນຫາ I/O ແບບສຸ່ມທີ່ຕ້ອງການແກ້ໄຂ.