Amazon Redshift Parallel Scaling Guide ແລະຜົນການທົດສອບ

ທີ່ Skyeng ພວກເຮົາໃຊ້ Amazon Redshift, ລວມທັງການຂະຫຍາຍຂະຫນານ, ດັ່ງນັ້ນພວກເຮົາໄດ້ພົບເຫັນບົດຄວາມນີ້ໂດຍ Stefan Gromoll, ຜູ້ກໍ່ຕັ້ງ dotgo.com, ສໍາລັບ intermix.io ທີ່ຫນ້າສົນໃຈ. ຫຼັງຈາກການແປ, ປະສົບການຂອງພວກເຮົາເລັກນ້ອຍຈາກວິສະວະກອນຂໍ້ມູນ Daniyar Belkhodzhaev.

ຖາປັດຕະຍະ Amazon Redshift ອະນຸຍາດໃຫ້ຂະຫຍາຍໄດ້ໂດຍການເພີ່ມ nodes ໃໝ່ໃສ່ກຸ່ມ. ຄວາມຕ້ອງການທີ່ຈະຮັບມືກັບຈໍານວນການຮ້ອງຂໍສູງສຸດສາມາດນໍາໄປສູ່ການສະຫນອງຂໍ້ສະເຫນີເກີນ. Concurrency Scaling, ກົງກັນຂ້າມກັບການເພີ່ມ nodes ໃຫມ່, ເພີ່ມພະລັງງານຄອມພິວເຕີຕາມຄວາມຕ້ອງການ.

ການຂະຫຍາຍຂະຫນານ Amazon Redshift ໃຫ້ Redshift clusters ຄວາມສາມາດເພີ່ມເຕີມເພື່ອຈັດການກັບປະລິມານການຮ້ອງຂໍສູງສຸດ. ມັນເຮັດວຽກໂດຍການຍ້າຍຄໍາຮ້ອງຂໍໄປຫາກຸ່ມ "ຂະຫນານ" ໃຫມ່ໃນພື້ນຫລັງ. ການຮ້ອງຂໍແມ່ນໄດ້ສົ່ງຕໍ່ໂດຍອີງໃສ່ການຕັ້ງຄ່າ WLM ແລະກົດລະບຽບ.

ການກຳນົດລາຄາຂະໜາດຂະໜານແມ່ນອີງໃສ່ຮູບແບບສິນເຊື່ອທີ່ມີລະດັບຟຣີ. ຂ້າງເທິງສິນເຊື່ອຟຣີ, ການຈ່າຍເງິນແມ່ນອີງໃສ່ເວລາທີ່ຂະຫນານ Scaling Cluster ດໍາເນີນການຮ້ອງຂໍ.

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

ຄວາມຕ້ອງການກຸ່ມ

ເພື່ອໃຊ້ການຂະຫຍາຍຂະຫນານ, ກຸ່ມ Amazon Redshift ຂອງທ່ານຕ້ອງຕອບສະຫນອງຄວາມຕ້ອງການດັ່ງຕໍ່ໄປນີ້:

- ເວ​ທີ​: EC2-VPC;
- ປະ​ເພດ node​: dc2.8xlarge, ds2.8xlarge, dc2.large ຫຼື ds2.xlarge;
- ຈໍາ​ນວນ​ຂອງ nodes​: ຈາກ 2 ຫາ 32 (ກຸ່ມ node ດຽວບໍ່ຮອງຮັບ).

ປະເພດການຮ້ອງຂໍທີ່ຍອມຮັບ

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

— ການ​ສອບ​ຖາມ SELECT ແມ່ນ​ອ່ານ​ເທົ່າ​ນັ້ນ (ເຖິງ​ແມ່ນ​ວ່າ​ຈະ​ມີ​ການ​ວາງ​ແຜນ​ຫຼາຍ​ປະ​ເພດ​)​;
— ການ​ສອບ​ຖາມ​ບໍ່​ໄດ້​ອ້າງ​ອີງ​ຕາ​ຕະ​ລາງ​ທີ່​ມີ​ຮູບ​ແບບ​ການ​ຈັດ​ລຽງ​ແຊກ​ຊ້ອນ​;
- ການສອບຖາມບໍ່ໄດ້ໃຊ້ Amazon Redshift Spectrum ເພື່ອອ້າງອີງຕາຕະລາງພາຍນອກ.

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

ຄິວ ແລະ SQA ຕ້ອງການການຕັ້ງຄ່າທີ່ເຫມາະສົມ ການຈັດການວຽກ Redshift (WLM). ພວກເຮົາແນະນໍາໃຫ້ເພີ່ມປະສິດທິພາບ WLM ຂອງທ່ານກ່ອນ - ນີ້ຈະຫຼຸດຜ່ອນຄວາມຕ້ອງການສໍາລັບການຂະຫນານ. ແລະນີ້ເປັນສິ່ງສໍາຄັນເພາະວ່າການຂະຫຍາຍຂະຫນານແມ່ນບໍ່ເສຍຄ່າພຽງແຕ່ສໍາລັບຈໍານວນທີ່ແນ່ນອນຂອງຊົ່ວໂມງ. AWS ອ້າງວ່າການຂະຫຍາຍຂະຫນານຈະບໍ່ເສຍຄ່າສໍາລັບ 97% ຂອງລູກຄ້າ, ເຊິ່ງນໍາພວກເຮົາໄປສູ່ບັນຫາຂອງລາຄາ.

ຄ່າ​ໃຊ້​ຈ່າຍ​ຂອງ​ຂະ​ຫນານ​ຂະ​ຫນານ​

AWS ສະເຫນີຮູບແບບສິນເຊື່ອສໍາລັບການຂະຫນານຂະຫນານ. ແຕ່ລະກຸ່ມທີ່ເຄື່ອນໄຫວ Amazon RedShift ສະສົມເຄຣດິດທຸກຊົ່ວໂມງ, ສູງສຸດໜຶ່ງຊົ່ວໂມງຂອງເຄຣດິດຂະໜາດຂະໜານຟຣີຕໍ່ມື້.

ທ່ານຈ່າຍພຽງແຕ່ເມື່ອການນຳໃຊ້ Parallel Scaling Clusters ຂອງທ່ານເກີນຈຳນວນເຄຣດິດທີ່ທ່ານໄດ້ຮັບ.

ຄ່າໃຊ້ຈ່າຍແມ່ນຄິດໄລ່ໃນອັດຕາຕໍ່ວິນາທີຕາມຄວາມຕ້ອງການສໍາລັບກຸ່ມຂະຫນານທີ່ຖືກນໍາໃຊ້ຂ້າງເທິງອັດຕາຟຣີ. ທ່ານຈະຖືກຄິດຄ່າບໍລິການພຽງແຕ່ສໍາລັບໄລຍະເວລາຂອງການຮ້ອງຂໍຂອງທ່ານ, ໂດຍມີຄ່າໃຊ້ຈ່າຍຕ່ໍາສຸດຂອງຫນຶ່ງນາທີໃນແຕ່ລະຄັ້ງທີ່ຂະຫນານ Scaling Cluster ຖືກເປີດໃຊ້. ອັດຕາຄວາມຕ້ອງການຕໍ່ວິນາທີແມ່ນຄິດໄລ່ຕາມຫຼັກການລາຄາທົ່ວໄປ Amazon RedShift, ນັ້ນແມ່ນ, ມັນຂຶ້ນກັບປະເພດຂອງ node ແລະຈໍານວນຂອງ nodes ໃນ cluster ຂອງທ່ານ.

ເປີດຕົວຂະໜານຂະໜານ

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

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

ການຕັ້ງຄ່າ

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

ຈໍານວນເລີ່ມຕົ້ນຂອງກຸ່ມທີ່ໃຊ້ສໍາລັບການຂະຫນານຂະຫນານແມ່ນຫນຶ່ງ (1), ມີຄວາມສາມາດທີ່ຈະກໍາຫນົດຄ່າໄດ້ເຖິງສິບ (10) clusters.
ຈຳນວນກຸ່ມທັງໝົດສຳລັບການຂະໜານຂະໜານສາມາດກຳນົດໄດ້ໂດຍພາຣາມິເຕີ max_concurrency_scaling_clusters. ການເພີ່ມມູນຄ່າຂອງພາລາມິເຕີນີ້ສະຫນອງກຸ່ມທີ່ຊ້ໍາຊ້ອນເພີ່ມເຕີມ.

ການຕິດຕາມ

ມີກາຟເພີ່ມເຕີມຈໍານວນຫນຶ່ງທີ່ມີຢູ່ໃນ console AWS Redshift. ຕາຕະລາງການຂະຫຍາຍກຸ່ມສະກຸນເງິນທີ່ກຳນົດຄ່າສູງສຸດທີ່ກຳນົດຈະສະແດງຄ່າຂອງ max_concurrency_scaling_clusters ໃນໄລຍະເວລາ.

ຈໍານວນຂອງກຸ່ມການປັບຂະ ໜາດ ທີ່ຫ້າວຫັນແມ່ນສະແດງຢູ່ໃນສ່ວນຕິດຕໍ່ຜູ້ໃຊ້ໃນສ່ວນ "ກິດຈະ ກຳ ການປັບຂະ ໜາດ ສອດຄ່ອງ":

ໃນແຖບການສອບຖາມ, ມີຖັນທີ່ຊີ້ບອກວ່າການສອບຖາມໄດ້ຖືກປະຕິບັດຢູ່ໃນກຸ່ມຫຼັກ ຫຼືຢູ່ໃນກຸ່ມການຂະຫຍາຍຂະໜານ:

ບໍ່ວ່າຈະເປັນການສອບຖາມສະເພາະໃດນຶ່ງຖືກປະຕິບັດຢູ່ໃນກຸ່ມຫຼັກ ຫຼືຜ່ານກຸ່ມການຂະຫຍາຍຂະໜານ, ມັນຖືກເກັບໄວ້ໃນ stl_query.concurrency_scaling_status.

ຄ່າຂອງ 1 ຊີ້ໃຫ້ເຫັນວ່າການສອບຖາມໄດ້ຖືກປະຕິບັດຢູ່ໃນກຸ່ມຂະຫນານຂະຫນາດ, ໃນຂະນະທີ່ຄ່າອື່ນໆຊີ້ໃຫ້ເຫັນວ່າມັນຖືກປະຕິບັດຢູ່ໃນກຸ່ມຕົ້ນຕໍ.

ຕົວຢ່າງ:

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

Результаты

ຜູ້ຂຽນໄດ້ເລີ່ມການຂະຫຍາຍຂະໜານສຳລັບໜຶ່ງຄິວໃນກຸ່ມພາຍໃນເວລາປະມານ 18:30:00 GMT ຂອງວັນທີ 29.03.2019/3/20. ໄດ້ປ່ຽນພາລາມິເຕີ max_concurrency_scaling_clusters ເປັນ 30 ເວລາປະມານ 00:29.03.2019:XNUMX ໂມງຂອງວັນທີ XNUMX/XNUMX/XNUMX.

ເພື່ອຈຳລອງຄິວຄຳຮ້ອງຂໍ, ພວກເຮົາຫຼຸດຈຳນວນຊ່ອງສຳລັບຄິວນີ້ຈາກ 15 ເປັນ 5.

ຂ້າງລຸ່ມນີ້ແມ່ນຕາຕະລາງ dashboard intermix.io ສະແດງໃຫ້ເຫັນຈໍານວນຂອງການຮ້ອງຂໍທີ່ແລ່ນແລະຄິວຫຼັງຈາກຫຼຸດລົງຈໍານວນຂອງສະລັອດຕິງ.

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

ນີ້ແມ່ນຂໍ້ມູນທີ່ກ່ຽວຂ້ອງຈາກ console AWS ກ່ຽວກັບສິ່ງທີ່ເກີດຂຶ້ນໃນເວລານີ້:

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

ກຣາບການໃຊ້ງານກ່ຽວຂ້ອງກັບກຣາຟກິດຈະກໍາການປັບຂະໜາດ:

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

ການຄົ້ນພົບ

ການຂະຫຍາຍຂະໜານສາມາດຫຼຸດຜ່ອນເວລາການຮ້ອງຂໍທີ່ໃຊ້ໃນຄິວໃນລະຫວ່າງການໂຫຼດສູງສຸດ.

ອີງຕາມຜົນໄດ້ຮັບຂອງການທົດສອບພື້ນຖານ, ມັນໄດ້ຫັນອອກວ່າສະຖານະການທີ່ມີການຮ້ອງຂໍການໂຫຼດໄດ້ປັບປຸງບາງສ່ວນ. ຢ່າງໃດກໍຕາມ, ຂະຫນາດຂະຫນານດຽວບໍ່ໄດ້ແກ້ໄຂບັນຫາ concurrency ທັງຫມົດ.

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

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

ດັ່ງນັ້ນ, ຜູ້ຂຽນແນະນໍາໃຫ້ໃຊ້ມັນສໍາລັບແຖວ WLM ຂອງທ່ານ. ເລີ່ມຕົ້ນດ້ວຍກຸ່ມຂະໜານດຽວ ແລະຕິດຕາມການໂຫຼດສູງສຸດຜ່ານ console ເພື່ອກຳນົດວ່າກຸ່ມກຸ່ມໃໝ່ກຳລັງຖືກນຳໃຊ້ຢ່າງຄົບຖ້ວນຫຼືບໍ່.

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

ຄໍາເຫັນຈາກ Daniyar Belkhodzhaev, ວິສະວະກອນຂໍ້ມູນ Skyeng

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

ມັນເກີດຂຶ້ນດັ່ງນັ້ນໃນກາງເດືອນເມສາພວກເຮົາມີການຮ້ອງຂໍ flurry ຜິດປົກກະຕິກັບກຸ່ມ Redshift. ໃນລະຫວ່າງໄລຍະເວລານີ້, ພວກເຮົາມັກຈະໃຊ້ການປັບຂະໜາດຄວາມສອດຄ່ອງ; ບາງຄັ້ງກຸ່ມເພີ່ມເຕີມເຮັດວຽກ 24 ຊົ່ວໂມງຕໍ່ມື້ໂດຍບໍ່ມີການຢຸດ.

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

ການສັງເກດການຂອງພວກເຮົາສ່ວນໃຫຍ່ແມ່ນກົງກັນກັບຄວາມປະທັບໃຈຂອງຜູ້ຊາຍຈາກ intermix.io.

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

ໂດຍໄດ້ຮັບການກໍາຈັດການໂຫຼດທີ່ຜິດປົກກະຕິໃນເດືອນເມສາ, ພວກເຮົາ, ຕາມທີ່ AWS ຄາດໄວ້, ເຂົ້າໄປໃນໂຫມດການນໍາໃຊ້ບາງຄັ້ງ - ພາຍໃນມາດຕະຖານທີ່ບໍ່ເສຍຄ່າ.
ທ່ານສາມາດຕິດຕາມຄ່າໃຊ້ຈ່າຍໃນການຂະຫຍາຍຂະຫນານຂອງທ່ານໃນ AWS Cost Explorer. ທ່ານຈໍາເປັນຕ້ອງເລືອກບໍລິການ - Redshift, ປະເພດການນໍາໃຊ້ - CS, ຕົວຢ່າງ USW2-CS:dc2.large.

ທ່ານສາມາດອ່ານເພີ່ມເຕີມກ່ຽວກັບລາຄາໃນພາສາລັດເຊຍ ທີ່ນີ້.

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