Sa Skyeng ginagamit namin ang Amazon Redshift, kabilang ang parallel scaling, kaya nakita namin ang artikulong ito ni Stefan Gromoll, tagapagtatag ng dotgo.com, para sa intermix.io na interesante. Pagkatapos ng pagsasalin, kaunti sa aming karanasan mula sa data engineer na si Daniyar Belkhodzhaev.
nagbibigay-daan sa pag-scale sa pamamagitan ng pagdaragdag ng mga bagong node sa cluster. Ang pangangailangang makayanan ang pinakamataas na bilang ng mga kahilingan ay maaaring humantong sa sobrang pagbibigay ng mga node. Ang Concurrency Scaling, bilang kabaligtaran sa pagdaragdag ng mga bagong node, ay nagpapataas ng kapangyarihan sa pag-compute kung kinakailangan.
Ang Amazon Redshift parallel scaling ay nagbibigay sa mga Redshift cluster ng karagdagang kapasidad upang mahawakan ang mga volume ng peak request. Gumagana ito sa pamamagitan ng paglipat ng mga kahilingan sa mga bagong "parallel" na cluster sa background. Ang mga kahilingan ay niruruta batay sa WLM configuration at mga panuntunan.
Ang parallel scaling na pagpepresyo ay batay sa isang modelo ng kredito na may libreng antas. Sa itaas ng mga libreng kredito, ang pagbabayad ay nakabatay sa oras na iproseso ng Parallel Scaling Cluster ang mga kahilingan.
Sinubukan ng may-akda ang parallel scaling sa isa sa mga panloob na kumpol. Sa post na ito, magsasalita siya tungkol sa mga resulta ng pagsusulit at magbibigay ng mga tip kung paano magsimula.
Mga kinakailangan sa cluster
Upang gumamit ng parallel scaling, dapat matugunan ng iyong Amazon Redshift cluster ang mga sumusunod na kinakailangan:
- platform: EC2-VPC;
β uri ng node: dc2.8xlarge, ds2.8xlarge, dc2.large o ds2.xlarge;
β bilang ng mga node: mula 2 hanggang 32 (iisang node cluster ay hindi suportado).
Mga katanggap-tanggap na uri ng kahilingan
Ang parallel scaling ay hindi angkop para sa lahat ng uri ng mga query. Sa unang bersyon, pinoproseso lamang nito ang mga kahilingan sa pagbasa na nakakatugon sa tatlong kundisyon:
β Ang mga SELECT query ay read-only (bagaman mas maraming uri ang nakaplano);
β ang query ay hindi tumutukoy sa isang table na may INTERLEAVED sorting style;
- Ang query ay hindi gumagamit ng Amazon Redshift Spectrum upang sumangguni sa mga panlabas na talahanayan.
Upang mairuta sa Parallel Scaling Cluster, ang kahilingan ay dapat na naka-queue. Bukod pa rito, kwalipikado ang mga queue para sa queue , ay hindi tatakbo sa parallel scale clusters.
Ang mga pila at SQA ay nangangailangan ng wastong pagsasaayos . Inirerekomenda namin na i-optimize muna ang iyong WLM - babawasan nito ang pangangailangan para sa parallel scaling. At ito ay mahalaga dahil ang parallel scaling ay libre lamang para sa isang tiyak na bilang ng mga oras. Sinasabi ng AWS na ang parallel scaling ay magiging libre para sa 97% ng mga customer, na nagdadala sa amin sa isyu ng pagpepresyo.
Halaga ng parallel scaling
Nag-aalok ang AWS ng modelo ng kredito para sa parallel scaling. Ang bawat aktibong kumpol Nag-iipon ng mga credit kada oras, hanggang isang oras ng libreng parallel scaling credits bawat araw.
Magbabayad ka lang kapag ang iyong paggamit ng Parallel Scaling Clusters ay lumampas sa halaga ng mga credit na iyong natanggap.
Kinakalkula ang gastos sa per-segundo on-demand rate para sa parallel cluster na ginagamit sa itaas ng libreng rate. Sisingilin ka lamang para sa tagal ng iyong mga kahilingan, na may minimum na singil na isang minuto sa bawat oras na ang isang Parallel Scaling Cluster ay isinaaktibo. Ang per-second on-demand rate ay kinakalkula batay sa pangkalahatang mga prinsipyo ng pagpepresyo , ibig sabihin, depende ito sa uri ng node at sa bilang ng mga node sa iyong cluster.
Paglulunsad ng Parallel Scaling
Ang parallel scaling ay na-trigger para sa bawat WLM queue. Pumunta sa AWS Redshift console at piliin ang Workload Management mula sa kaliwang navigation menu. Piliin ang pangkat ng parameter ng WLM ng iyong cluster mula sa sumusunod na drop-down na menu.
Makakakita ka ng bagong column na tinatawag na "Concurrency Scaling Mode" sa tabi ng bawat queue. Ang default ay "Disabled". I-click ang "I-edit" at maaari mong baguhin ang mga setting para sa bawat pila.
Configuration
Gumagana ang parallel scaling sa pamamagitan ng pagpapasa ng mga naaangkop na kahilingan sa mga bagong nakalaang cluster. Ang mga bagong cluster ay may parehong laki (uri at bilang ng mga node) bilang pangunahing cluster.
Ang default na bilang ng mga cluster na ginagamit para sa parallel scaling ay isa (1), na may kakayahang mag-configure ng hanggang sa kabuuang sampung (10) cluster.
Ang kabuuang bilang ng mga cluster para sa parallel scaling ay maaaring itakda ng max_concurrency_scaling_clusters parameter. Ang pagtaas ng halaga ng parameter na ito ay nagbibigay ng mga karagdagang redundant na cluster.
Pagsubaybay
Mayroong ilang karagdagang mga graph na available sa AWS Redshift console. Ang Max Configured Concurrency Scaling Clusters chart ay nagpapakita ng halaga ng max_concurrency_scaling_clusters sa paglipas ng panahon.
Ang bilang ng mga aktibong scaling cluster ay ipinapakita sa user interface sa seksyong "Concurrency Scaling Activity":
Sa tab na Mga Query, mayroong column na nagsasaad kung ang query ay naisakatuparan sa pangunahing cluster o sa parallel scaling cluster:
Hindi alintana kung ang isang partikular na query ay naisakatuparan sa pangunahing cluster o sa pamamagitan ng parallel scaling cluster, ito ay nakaimbak sa stl_query.concurrency_scaling_status.
Ang isang halaga ng 1 ay nagpapahiwatig na ang query ay naisakatuparan sa parallel scale cluster, habang ang iba pang mga halaga ay nagpapahiwatig na ito ay naisakatuparan sa pangunahing cluster.
Halimbawa:
Nakaimbak din ang impormasyon ng concurrency scaling sa ilang iba pang mga talahanayan at view, gaya ng SVCS_CONCURRENCY_SCALING_USAGE. Bilang karagdagan, mayroong isang bilang ng mga talahanayan ng katalogo na nag-iimbak ng impormasyon tungkol sa parallel scaling.
Natuklasan
Sinimulan ng mga may-akda ang parallel scaling para sa isang queue sa internal cluster sa humigit-kumulang 18:30:00 GMT noong 29.03.2019/3/20. Binago ang max_concurrency_scaling_clusters na parameter sa 30 sa humigit-kumulang 00:29.03.2019:XNUMX noong XNUMX/XNUMX/XNUMX.
Upang gayahin ang isang queue ng kahilingan, binawasan namin ang bilang ng mga slot para sa queue na ito mula 15 hanggang 5.
Nasa ibaba ang isang intermix.io dashboard chart na nagpapakita ng bilang ng mga kahilingang tumatakbo at nakapila pagkatapos bawasan ang bilang ng mga slot.
Nakikita namin na ang oras ng paghihintay para sa mga kahilingan sa pila ay tumaas, na ang maximum na oras ay higit sa 5 minuto.
Narito ang nauugnay na impormasyon mula sa AWS console tungkol sa nangyari sa panahong ito:
Inilunsad ng Redshift ang tatlong (3) parallel scaling cluster gaya ng na-configure. Mukhang hindi gaanong nagamit ang mga cluster na ito, kahit na maraming mga kahilingan sa aming cluster ang nakapila.
Ang graph ng paggamit ay nauugnay sa graph ng aktibidad ng pag-scale:
Pagkalipas ng ilang oras, sinuri ng mga may-akda ang pila at mukhang 6 na kahilingan ang tumatakbo sa parallel scaling. Random din naming sinubukan ang dalawang kahilingan sa pamamagitan ng user interface. Hindi namin nasuri kung paano gamitin ang mga halagang ito kapag ang ilang magkakatulad na kumpol ay aktibo nang sabay-sabay.
Natuklasan
Maaaring bawasan ng parallel scaling ang oras na ginugugol ng mga kahilingan sa pila sa mga peak load.
Batay sa mga resulta ng pangunahing pagsubok, lumabas na ang sitwasyon sa mga kahilingan sa pag-load ay bahagyang bumuti. Gayunpaman, ang parallel scaling lamang ay hindi nalutas ang lahat ng mga problema sa concurrency.
Ito ay dahil sa mga paghihigpit sa mga uri ng mga query na maaaring gumamit ng parallel scaling. Halimbawa, ang mga may-akda ay may maraming mga talahanayan na may interleaved sort key, at karamihan sa aming workload ay pagsusulat.
Kahit na ang parallel scaling ay hindi isang unibersal na solusyon para sa pag-set up ng WLM, ang paggamit ng feature na ito ay simple at diretso.
Samakatuwid, inirerekomenda ng may-akda ang paggamit nito para sa iyong mga pila sa WLM. Magsimula sa isang parallel cluster at subaybayan ang peak load sa pamamagitan ng console upang matukoy kung ang mga bagong cluster ay ganap na ginagamit.
Habang ang AWS ay nagdaragdag ng suporta para sa karagdagang mga uri ng query at mga talahanayan, ang parallel scaling ay dapat na unti-unting maging mas at mas mahusay.
Komento mula kay Daniyar Belkhodzhaev, Skyeng Data Engineer
Napansin din namin sa Skyeng agad ang lumalabas na posibilidad ng parallel scaling.
Ang pag-andar ay talagang kaakit-akit, lalo na kung isasaalang-alang na ang AWS ay tinatantya na ang karamihan sa mga gumagamit ay hindi na kailangang magbayad ng labis para dito.Nagkataon na noong kalagitnaan ng Abril nagkaroon kami ng hindi pangkaraniwang pagkagulo ng mga kahilingan sa Redshift cluster. Sa panahong ito, madalas kaming gumamit ng Concurrency Scaling; minsan may karagdagang cluster na gumagana nang 24 na oras sa isang araw nang walang tigil.
Ginawa nitong posible, kung hindi man lubusang malutas ang problema sa mga pila, kung gayon ay maging katanggap-tanggap ang sitwasyon.
Ang aming mga obserbasyon ay higit na tumutugma sa mga impression ng mga lalaki mula sa intermix.io.
Napansin din namin na bagama't may mga kahilingang naghihintay sa pila, hindi lahat ng kahilingan ay agad na ipinasa sa parallel cluster. Tila nangyayari ito dahil ang parallel cluster ay tumatagal pa rin ng oras upang magsimula. Bilang resulta, sa mga panandaliang peak load, mayroon pa rin tayong maliliit na pila, at ang mga kaukulang alarma ay may oras na mag-trigger.
Nang maalis ang mga abnormal na pag-load noong Abril, kami, tulad ng inaasahan ng AWS, ay pumasok sa paminsan-minsang mode ng paggamit - sa loob ng libreng pamantayan.
Maaari mong subaybayan ang iyong parallel scaling na mga gastos sa AWS Cost Explorer. Kailangan mong piliin ang Serbisyo - Redshift, Uri ng Paggamit - CS, halimbawa USW2-CS:dc2.large.Maaari kang magbasa nang higit pa tungkol sa mga presyo sa Russian
Pinagmulan: www.habr.com