By Skyeng brûke wy Amazon Redshift, ynklusyf parallelle skaalfergrutting, dus wy fûnen dit artikel fan Stefan Gromoll, oprjochter fan dotgo.com, foar intermix.io ynteressant. Nei de oersetting, in bytsje fan ús ûnderfining fan data-yngenieur Daniyar Belkhodzhaev.
lit skaalfergrutting troch tafoegjen fan nije knopen oan it kluster. De needsaak om te gean mei in pykoantal oanfragen kin liede ta tefolle foarsjenningen fan knopen. Tagelyk skaalfergrutting, yn tsjinstelling ta it tafoegjen fan nije knopen, fergruttet de berekkeningskrêft as nedich.
Amazon Redshift parallelle skaalfergrutting jout Redshift-klusters ekstra kapasiteit om pykfersykvoluminten te behanneljen. It wurket troch fersiken te ferpleatsen nei nije "parallelle" klusters op 'e eftergrûn. Fersiken wurde trochstjoerd op basis fan WLM-konfiguraasje en regels.
Parallelle skaalfergrutting is basearre op in kredytmodel mei in fergese tier. Boppe fergese credits is betelling basearre op 'e tiid dat it Parallel Scaling Cluster fersiken ferwurket.
De auteur testte parallelle skaalfergrutting op ien fan 'e ynterne klusters. Yn dizze post sil hy prate oer de testresultaten en tips jaan oer hoe't jo kinne begjinne.
Cluster easken
Om parallelle skaalfergrutting te brûken, moat jo Amazon Redshift-kluster oan de folgjende easken foldwaan:
- platfoarm: EC2-VPC;
- node type: dc2.8xlarge, ds2.8xlarge, dc2.large of ds2.xlarge;
- oantal knooppunten: fan 2 oan 32 (single node klusters wurde net stipe).
Akseptabel fersyk typen
Parallel skaalfergrutting is net geskikt foar alle soarten fragen. Yn 'e earste ferzje ferwurket it allinich lêsoanfragen dy't oan trije betingsten foldwaan:
- SELECT-fragen binne allinich lêzen (hoewol mear typen binne pland);
- de fraach ferwiist net nei in tabel mei de INTERLEAVED sortearstyl;
- De query brûkt Amazon Redshift Spectrum net om eksterne tabellen te ferwizen.
Om troch te gean nei it Parallel Scaling Cluster, moat it fersyk yn 'e wachtrige stean. Derneist, queries yn oanmerking komme foar de wachtrige , sil net rinne op parallelle skaalklusters.
Wachtrijen en SQA fereaskje goede konfiguraasje . Wy riede oan om jo WLM earst te optimalisearjen - dit sil de needsaak foar parallelle skaalfergrutting ferminderje. En dit is wichtich om't parallelle skaalfergrutting allinich fergees is foar in bepaald oantal oeren. AWS beweart dat parallelle skaalfergrutting fergees sil wêze foar 97% fan klanten, wat ús bringt by it probleem fan prizen.
Kosten fan parallelle skaalfergrutting
AWS biedt in kredytmodel foar parallelle skaalfergrutting. Elke aktive kluster Accumulearret credits per oere, oant ien oere fergees parallelle skaalfergruttings per dei.
Jo betelje allinich as jo gebrûk fan Parallel Scaling Clusters grutter is as it bedrach fan credits dat jo hawwe ûntfongen.
De kosten wurde berekkene op in per-sekonde on-demand taryf foar in parallel kluster dat wurdt brûkt boppe de frije taryf. Jo wurde allinich yn rekken brocht foar de doer fan jo oanfragen, mei in minimale lading fan ien minút elke kear as in Parallel Scaling Cluster is aktivearre. It taryf per sekonde op oanfraach wurdt berekkene op basis fan algemiene priisprinsipes , dat is, it hinget ôf fan it type knooppunt en it oantal knooppunten yn jo kluster.
Launching Parallel Scaling
Parallelle skaalfergrutting wurdt útrikt foar elke WLM-wachtrige. Gean nei de AWS Redshift-konsole en selektearje Workload Management út it linker navigaasjemenu. Selektearje de WLM-parametergroep fan jo kluster út it folgjende útklapmenu.
Jo sille neist elke wachtrige in nije kolom sjen mei de namme "Concurrency Scaling Mode". De standert is "Utskeakele". Klikje op "Bewurkje" en jo kinne de ynstellings foar elke wachtrige feroarje.
Konfiguraasje
Parallel skaalfergrutting wurket troch passende oanfragen troch te stjoeren nei nije tawijde klusters. Nije klusters hawwe deselde grutte (type en oantal knopen) as de haadkluster.
It standert oantal klusters brûkt foar parallelle skaalfergrutting is ien (1), mei de mooglikheid om te konfigurearjen oant in totaal fan tsien (10) klusters.
It totale oantal klusters foar parallelle skaalfergrutting kin ynsteld wurde troch de parameter max_concurrency_scaling_clusters. It fergrutsjen fan de wearde fan dizze parameter jout ekstra oerstallige klusters.
Monitoring
D'r binne ferskate ekstra grafiken beskikber yn 'e AWS Redshift-konsole. De grafyk fan Max Configured Concurrency Scaling Clusters toant de wearde fan max_concurrency_scaling_clusters oer de tiid.
It oantal aktive skaalklusters wurdt werjûn yn 'e brûkersynterface yn' e seksje "Concurrency Scaling Activity":
Yn it ljepblêd Queries is d'r in kolom dy't oanjout oft de query útfierd is yn it haadkluster of yn it parallelle skaalkluster:
Nettsjinsteande oft in bepaalde query waard útfierd yn de wichtichste kluster of fia in parallel skaalfergrutting kluster, it wurdt opslein yn stl_query.concurrency_scaling_status.
In wearde fan 1 jout oan dat de query waard útfierd yn it parallelle skaalkluster, wylst oare wearden oanjaan dat it waard útfierd yn it primêre kluster.
Foarbyld:
Ynformaasje oer de skaalfergrutting fan gearfal wurdt ek opslein yn guon oare tabellen en werjeften, lykas SVCS_CONCURRENCY_SCALING_USAGE. Dêrneist binne der in oantal katalogus tabellen dy't bewarje ynformaasje oer parallel skaalfergrutting.
Resultaten
De auteurs begûnen parallele skaalfergrutting foar ien wachtrige yn it ynterne kluster om sawat 18:30:00 GMT op 29.03.2019/3/20.
Om in fersykwachtrige te simulearjen, hawwe wy it oantal slots foar dizze wachtrige fermindere fan 15 nei 5.
Hjirûnder is in intermix.io-dashboard-diagram mei it oantal oanfragen dy't rinne en yn 'e wachtrige steane nei't it oantal slots fermindere is.
Wy sjogge dat de wachttiid foar oanfragen yn 'e wachtrige is ferhege, mei de maksimale tiid mear as 5 minuten.
Hjir is de relevante ynformaasje fan 'e AWS-konsole oer wat der yn dizze tiid barde:
Redshift lansearre trije (3) parallelle skaalklusters lykas konfigurearre. It docht bliken dat dizze klusters ûnderbenut waarden, ek al stiene in protte oanfragen yn ús kluster yn 'e wachtrige.
De gebrûksgrafyk korrelearret mei de grafyske skaalaktiviteit:
Nei in pear oeren kontrolearren de auteurs de wachtrige en it like derop dat 6 oanfragen op parallelle skaal rinne. Wy hawwe ek willekeurich testen twa oanfragen fia de brûkersynterface. Wy hawwe net kontrolearre hoe't jo dizze wearden brûke as ferskate parallelle klusters tagelyk aktyf binne.
befinings
Parallelle skaalfergrutting kin de tiidfersiken ferminderje dy't yn 'e wachtrige besteegje by pykladen.
Op grûn fan de útkomsten fan de basistest die bliken dat de situaasje mei laden oanfragen foar in part ferbettere is. Lykwols, parallelle skaalfergrutting allinnich net oplosse alle concurrency problemen.
Dit komt troch beheiningen op 'e soarten fragen dy't parallelle skaalfergrutting kinne brûke. Bygelyks, de auteurs hawwe in protte tabellen mei ynterleaved sortearring kaaien, en de measte fan ús wurkdruk is skriuwen.
Hoewol parallele skaalfergrutting gjin universele oplossing is foar it ynstellen fan WLM, is it brûken fan dizze funksje ienfâldich en rjochtlinich.
Dêrom advisearret de auteur it te brûken foar jo WLM-wachtrijen. Begjin mei ien parallelle kluster en kontrolearje pyklast troch de konsole om te bepalen as de nije klusters folslein brûkt wurde.
As AWS stipet foar ekstra querytypen en tabellen, soe parallele skaalfergrutting stadichoan mear en effisjinter wurde moatte.
Kommentaar fan Daniyar Belkhodzhaev, Skyeng Data Engineer
Wy by Skyeng hawwe ek fuortendaliks de opkommende mooglikheid fan parallelle skaalfergrutting opmurken.
De funksjonaliteit is heul oantreklik, foaral sjoen it feit dat AWS skat dat de measte brûkers der net iens ekstra foar hoege te beteljen.It barde sa dat wy heal april in ûngewoane floed fan fersiken hienen oan it Redshift-kluster. Yn dizze perioade hawwe wy faaks taflecht ta Concurrency Scaling; soms wurke in ekstra kluster 24 oeren deis sûnder ophâlden.
Dit makke it mooglik, as net om it probleem folslein op te lossen mei wachtrijen, dan op syn minst om de situaasje akseptabel te meitsjen.
Us waarnimmings komme foar in grut part oerien mei de yndrukken fan 'e jonges fan intermix.io.
Wy hawwe ek fernaam dat hoewol't der fersiken wachte yn 'e wachtrige, net alle fersiken waarden fuortendaliks trochstjoerd nei it parallelle kluster. Blykber bart dit om't it parallelkluster noch tiid duorret om te begjinnen. As gefolch hawwe wy by koarte termyn pyklasten noch lytse wachtrijen, en de oerienkommende alaarms hawwe tiid om te triggerjen.
Nei't wy yn april abnormale loads kwytrekke, gongen wy, lykas AWS ferwachte, de gelegenheidsgebrûksmodus yn - binnen de frije noarm.
Jo kinne jo parallelle skaalkosten folgje yn AWS Cost Explorer. Jo moatte selektearje Service - Redshift, Usage Type - CS, bygelyks USW2-CS: dc2.large.Jo kinne mear lêze oer prizen yn it Russysk
Boarne: www.habr.com