Amazon Redshift: madalam hind, suurem jõudlus | Amazoni veebiteenused

Amazon Redshift: madalam hind, suurem jõudlus | Amazoni veebiteenused

Ajatempel: 26. oktoober 2023 6:10
Allikasõlm: 2959258

Nagu peaaegu kõik kliendid, soovite ka teie kulutada võimalikult vähe, saavutades samal ajal parima võimaliku toimivuse. See tähendab, et peate pöörama tähelepanu hinna ja kvaliteedi suhtele. Koos Amazoni punane nihe, võid oma koogi süüa ja ka seda süüa! Amazon Redshift pakub kuni 4.9 korda madalamaid kulusid kasutaja kohta ja kuni 7.9 korda paremat hinna-jõudlust kui teised pilveandmeladud reaalse töökoormuse korral, kasutades täiustatud tehnikaid, nagu samaaegsuse skaleerimine sadade samaaegsete kasutajate toetamiseks, täiustatud stringkodeering kiiremaks päringu jõudluseks ja Amazon Redshift serverita jõudluse täiustused. Lugege edasi, et mõista, miks hinna-toimivus on oluline ja kuidas Amazon Redshifti hinna-toimivus mõõdab, kui palju kulub teatud töökoormuse taseme saavutamine, nimelt jõudluse ROI (investeeringutasuvus).

Kuna hinna ja toimivuse arvutamisel võetakse arvesse nii hind kui ka jõudlus, on hinna ja toimivuse osas kaks võimalust mõelda. Esimene võimalus on hoida hind konstantsena: kui teil on kulutada 1 dollar, kui palju toimivust saate oma andmelaost? Parema hinna ja kvaliteedi suhtega andmebaas tagab parema jõudluse iga kulutatud 1 dollari kohta. Seega, kui hoida hind konstantsena, kui võrrelda kahte sama maksvat andmelao, siis parema hinna ja kvaliteedi suhtega andmebaas käivitab teie päringud kiiremini. Teine võimalus hinna ja toimivuse vaatamiseks on hoida jõudlust konstantsena: kui teil on vaja, et teie töökoormus lõppeks 10 minutiga, siis mis see maksab? Parema hinna ja kvaliteedi suhtega andmebaas täidab teie töökoormuse 10 minutiga madalamate kuludega. Seega, kui hoida jõudlust konstantsena, kui võrrelda kahte sama jõudlust pakkuvat andmeladu, maksab parema hinna ja kvaliteedi suhtega andmebaas vähem ja säästab teie raha.

Lõpuks on hinna ja kvaliteedi suhte teine ​​oluline aspekt prognoositavus. Planeerimisel on ülioluline teada, kui palju teie andmeladu läheb maksma, kuna andmelao kasutajate arv kasvab. See ei peaks mitte ainult pakkuma parimat hinna ja kvaliteedi suhet täna, vaid ka prognoositavalt skaleerima ja pakkuma parimat hinna-jõudlust, kuna kasutajaid ja töökoormust lisandub. Ideaalne andmeladu peaks olema lineaarne skaala— Andmelao skaleerimine kahekordse päringu läbilaskevõime saavutamiseks peaks ideaaljuhul maksma kaks korda rohkem (või vähem).

Selles postituses jagame toimivustulemusi, et illustreerida, kuidas Amazon Redshift pakub märkimisväärselt paremat hinna ja kvaliteedi suhet võrreldes juhtivate alternatiivsete pilvandmeladudega. See tähendab, et kui kulutate Amazon Redshiftile sama palju kui mõnele muule andmelaole, saavutate Amazon Redshiftiga parema jõudluse. Teise võimalusena, kui muudate oma Redshifti klastri suurust sama jõudluse tagamiseks, näete nende alternatiividega võrreldes madalamaid kulusid.

Hinna ja kvaliteedi suhe reaalse töökoormuse jaoks

Amazon Redshifti saate kasutada väga erinevate töökoormuste toiteks, alates keerukate ekstrakti-, teisendus- ja laadimispõhiste (ETL) aruannete pakktöötlusest ja reaalajas voogesituse analüüsist kuni madala latentsusajaga äriteabe (BI) armatuurlaudadeni, mis peavad teenindama sadu või isegi tuhandeid kasutajaid samaaegselt alamsekundiliste reageerimisaegadega ja kõike, mis sinna vahele jääb. Üks viise, kuidas me oma klientide jaoks pidevalt hinna-jõudlust parandame, on Redshifti laevastiku tarkvara ja riistvara jõudluse telemeetria pidev ülevaatamine, otsides võimalusi ja klientide kasutusjuhtumeid, kus saaksime Amazon Redshifti jõudlust veelgi parandada.

Mõned hiljutised näited sõidukipargi telemeetria abil juhitud jõudluse optimeerimisest on järgmised:

  • Stringipäringu optimeerimine – Analüüsides, kuidas Amazon Redshift töötles erinevaid andmetüüpe Redshifti lennukipargis, leidsime, et stringirohkete päringute optimeerimine tooks meie klientide töökoormusele märkimisväärset kasu. (Arutame seda üksikasjalikumalt hiljem selles postituses.)
  • Automatiseeritud materialiseeritud vaated – Leidsime, et Amazon Redshifti kliendid esitavad sageli palju päringuid, millel on ühised alampäringumustrid. Näiteks võib mitu erinevat päringut ühendada samad kolm tabelit, kasutades sama liitumistingimust. Amazon Redshift suudab nüüd automaatselt luua ja säilitada materialiseeritud vaateid ning seejärel päringuid läbipaistvalt ümber kirjutada, et kasutada masinõpitud vaateid automatiseeritud materialiseeritud vaade autonoomia funktsioon Amazon Redshiftis. Kui see on lubatud, võivad automatiseeritud materialiseeritud vaated läbipaistvalt suurendada päringu jõudlust korduvate päringute korral ilma kasutaja sekkumiseta. (Pange tähele, et automaatseid materialiseeritud vaateid ei kasutatud üheski selles postituses käsitletud võrdlustulemustes).
  • Suure samaaegsuse töökoormused – Kasvav kasutusjuht on Amazon Redshifti kasutamine armatuurlaualaadsete töökoormuste teenindamiseks. Neid töökoormusi iseloomustavad soovitud ühekohalised sekundid või lühemad päringu vastuseajad, kusjuures kümned või sajad samaaegsed kasutajad esitavad päringuid samaaegselt terava ja sageli ettearvamatu kasutusmustriga. Selle prototüüpne näide on Amazon Redshiftiga toetatud BI armatuurlaud, mille liiklus suureneb esmaspäeva hommikuti, kui suur hulk kasutajaid alustab oma nädalat.

Eriti suure samaaegsusega töökoormused on väga laiaulatuslikud: enamik andmelao töökoormusi töötab samaaegselt ja pole haruldane, et sajad või isegi tuhanded kasutajad esitavad Amazon Redshiftis päringuid samal ajal. Amazon Redshift loodi selleks, et hoida päringu reageerimisajad prognoositavad ja kiired. Redshift Serverless teeb seda teie eest automaatselt, lisades ja eemaldades vajaduse korral arvutusi, et hoida päringu reageerimisajad kiired ja prognoositavad. See tähendab, et Redshifti serverita toega armatuurlaud, mis laaditakse kiiresti, kui sellele juurde pääseb üks või kaks kasutajat, jätkab kiiret laadimist isegi siis, kui seda laadivad korraga paljud kasutajad.

Seda tüüpi töökoormuse simuleerimiseks kasutasime TPC-DS-ist tuletatud võrdlusalust 100 GB andmestikuga. TPC-DS on tööstusharu standardne etalon, mis sisaldab mitmesuguseid tüüpilisi andmelao päringuid. Sellel suhteliselt väikesel 100 GB mahul käitatakse selle võrdlusaluse päringuid Redshift Serverlessis keskmiselt mõne sekundiga, mis iseloomustab seda, mida interaktiivset BI armatuurlauda laadivad kasutajad ootavad. Tegime selle võrdlusaluse 1–200 samaaegset testimist, simuleerides 1–200 kasutajat, kes üritasid armatuurlauda korraga laadida. Kordasime testi ka mitme populaarse alternatiivse pilvandmelaoga, mis toetavad samuti automaatset skaleerimist (kui olete postitusega tuttav Amazon Redshift jätkab oma juhtpositsiooni hinna ja kvaliteedi osas, me ei kaasanud konkurenti A, kuna see ei toeta automaatset suurendamist). Mõõtsime päringu keskmist reageerimisaega, mis tähendab, kui kaua kasutaja ootab päringu lõpetamist (või armatuurlaua laadimist). Tulemused on näidatud järgmises diagrammis.

Konkurent B mastaabib hästi kuni umbes 64 samaaegse päringuni, misjärel ta ei suuda pakkuda täiendavat arvutust ja päringud hakkavad järjekorda, mis põhjustab päringutele vastamise pikenemise. Kuigi konkurent C suudab skaleerida automaatselt, skaleerub see madalama päringu läbilaskevõimega kui nii Amazon Redshift kui ka konkurent B ning ei suuda päringu käitusaegu madalal hoida. Lisaks ei toeta see päringute järjekorda seadmist, kui arvutus saab otsa, mis takistab selle skaleerimist üle umbes 128 samaaegse kasutaja. Süsteem lükkab tagasi täiendavate päringute esitamise.

Siin suudab Redshift Serverless hoida päringu reageerimisaja suhteliselt ühtlasena, umbes 5 sekundis, isegi kui sajad kasutajad esitavad päringuid samal ajal. Konkurentide B ja C keskmised päringule vastamise ajad pikenevad pidevalt ladude koormuse kasvades, mille tulemusel peavad kasutajad ootama kauem (kuni 16 sekundit) päringute naasmist, kui andmelao on hõivatud. See tähendab, et kui kasutaja üritab armatuurlauda värskendada (mis võib uuesti laadimisel esitada isegi mitu samaaegset päringut), suudab Amazon Redshift hoida armatuurlaua laadimisajad palju ühtlasemalt isegi siis, kui armatuurlauda laadivad kümned või sajad muud kasutajad samal ajal.

Kuna Amazon Redshift suudab lühikeste päringute jaoks pakkuda väga suurt päringu läbilaskevõimet (nagu me sellest kirjutasime Amazon Redshift jätkab oma juhtpositsiooni hinna ja kvaliteedi osas), suudab see tõhusamalt ja seega oluliselt väiksemate kuludega toime tulla ka nende suuremate samaaegsustega. Selle kvantifitseerimiseks vaatleme avaldatud hinna-toimivust tellitav hinnakujundus iga eelmise testi lao jaoks, mis on näidatud järgmises tabelis. Väärib märkimist, et kasutades Reserveeritud eksemplarid (RI-d), eriti 3-aastastel RI-del, mis on ostetud koos ettemaksevõimalusega, on Amazon Redshifti käitamiseks ette nähtud klastrites madalaim hind, mille tulemuseks on parim suhteline hinna ja kvaliteedi suhe võrreldes tellitavate või muude RI-valikutega.

Seega ei suuda Amazon Redshift mitte ainult pakkuda paremat jõudlust kõrgemate samaaegsuste korral, vaid suudab seda teha ka oluliselt väiksemate kuludega. Iga andmepunkt hinna-toimivuse diagrammil on võrdne võrdlusaluse käitamise kuluga määratud samaaegsel ajal. Kuna hinna-toimivus on lineaarne, saame jagada võrdlusaluse mis tahes samaaegsel käitamise kulud samaaegsusega (selles diagrammis samaaegsete kasutajate arv), et öelda meile, kui palju iga uue kasutaja lisamine selle konkreetse võrdlusaluse jaoks maksab.

Eelnevaid tulemusi on lihtne korrata. Kõik võrdlusaluses kasutatud päringud on saadaval meie lehel GitHubi hoidla ja jõudlust mõõdetakse andmelao käivitamisega, samaaegse skaleerimise lubamisega Amazon Redshiftis (või vastava automaatse skaleerimise funktsiooniga teistes ladudes), laadides andmed karbist välja (ilma käsitsi häälestamise või andmebaasipõhise häälestamiseta) ja seejärel käivitades päringute samaaegne voog samaaegsustel 1–200 sammuga 32 igas andmelaos. Sama GitHubi repo viitab eelgenereeritud (ja muutmata) TPC-DS-i andmetele Amazoni lihtne salvestusteenus (Amazon S3) erinevates mastaapides, kasutades ametlikku TPC-DS andmete genereerimise komplekti.

Stringirikka töökoormuse optimeerimine

Nagu varem mainitud, otsib Amazon Redshifti meeskond pidevalt uusi võimalusi, et pakkuda klientidele veelgi paremat hinna ja kvaliteedi suhet. Hiljuti käivitatud täiustus, mis oluliselt parandas jõudlust, on optimeerimine, mis kiirendab päringute toimivust stringiandmetega võrreldes. Näiteks võite soovida leida New Yorgis asuvate jaemüügikaupluste kogutulu päringuga nagu SELECT sum(price) FROM sales WHERE city = ‘New York’. See päring rakendab stringiandmetele predikaati (city = ‘New York’). Nagu võite ette kujutada, on stringiandmete töötlemine andmelao rakendustes üldlevinud.

Et mõõta, kui sageli klientide töökoormus stringidele juurde pääseb, viisime läbi üksikasjaliku stringiandmete tüübi kasutamise analüüsi, kasutades kümnete tuhandete kliendiklastrite telemeetriat, mida haldab Amazon Redshift. Meie analüüs näitab, et 90% klastritest moodustavad stringiveerud vähemalt 30% kõigist veergudest ja 50% klastritest moodustavad stringiveerud vähemalt 50% kõigist veergudest. Pealegi pääseb enamik päringuid Amazon Redshift pilvandmelao platvormil juurde vähemalt ühele stringiveerule. Teine oluline tegur on see, et stringiandmetel on väga sageli madal kardinaalsus, mis tähendab, et veerud sisaldavad suhteliselt väikest unikaalsete väärtuste komplekti. Näiteks kuigi an orders müügiandmeid esitav tabel võib sisaldada miljardeid ridu, an order_status selle tabeli veerg võib sisaldada vaid mõnda ainulaadset väärtust nende miljardite ridade lõikes, nt pending, in processja completed.

Selle kirjutamise seisuga on enamik Amazon Redshifti stringiveerudest tihendatud LZO or ZSTD algoritmid. Need on head üldotstarbelised tihendusalgoritmid, kuid need ei ole mõeldud madala kardinaalsusega stringiandmete ärakasutamiseks. Eelkõige nõuavad nad andmete lahtipakkimist enne nende kasutamist ja on riistvaramälu ribalaiuse kasutamisel vähem tõhusad. Madala kardinaalsusega andmete jaoks on teist tüüpi kodeering, mis võib olla optimaalsem: BYTEDICT. See kodeering kasutab sõnastik-kodeerimisskeemi, mis võimaldab andmebaasimootoril töötada otse tihendatud andmete kohal, ilma et oleks vaja neid esmalt lahti pakkida.

Suure töökoormuse hinna ja kvaliteedi suhte edasiseks parandamiseks tutvustab Amazon Redshift nüüd täiendavaid jõudluse täiustusi, mis kiirendavad skaneerimist ja predikaatide hindamist, võrreldes madala kardinaalsusega stringiveergudega, mis on kodeeritud kui BYTEDICT, 5–63 korda kiiremini (vt tulemusi järgmine jaotis) võrreldes alternatiivsete tihenduskodeeringutega, nagu LZO või ZSTD. Amazon Redshift saavutab selle jõudluse paranemise, vektoriseerides skaneeringud kergete, protsessoritõhusate, BYTEDICT-kodeeringuga ja madala kardinaalsusega stringiveergude kaudu. Need stringitöötluse optimeerimised kasutavad tõhusalt ära kaasaegse riistvara pakutavat mälu ribalaiust, võimaldades stringiandmete reaalajas analüüsi. Need äsja kasutusele võetud jõudlusvõimalused on optimaalsed madala kardinaalsusega stringiveergude jaoks (kuni paarsada unikaalset stringiväärtust).

Lubades saate sellest uuest suure jõudlusega stringi täiustusest automaatselt kasu saada automaatne tabeli optimeerimine teie Amazon Redshifti andmelaos. Kui teie tabelites pole automaatset tabeli optimeerimist lubatud, saate soovitusi aadressilt Amazon Redshift Advisor Amazon Redshift konsoolis stringi veeru sobivuse kohta BYTEDICT-kodeeringu jaoks. Samuti saate määratleda uusi tabeleid, millel on madala kardinaalsusega stringiveerud BYTEDICT-kodeeringuga. Amazon Redshifti stringide täiustused on nüüd saadaval kõigis AWS-i piirkondades, kus Amazon Redshift on saadaval.

Tulemuslikkuse tulemused

Meie stringi täiustuste mõju mõõtmiseks lõime 10 TB (terabaidi) andmestiku, mis koosnes madala kardinaalsusega stringiandmetest. Lõime andmetest kolm versiooni, kasutades lühikesi, keskmisi ja pikki stringe, mis vastavad Amazon Redshifti laevastiku telemeetria stringide pikkuste 25., 50. ja 75. protsentiilile. Laadisime need andmed Amazon Redshifti kaks korda, kodeerisime need ühel juhul LZO-tihendust ja teisel BYTEDICT-tihendust kasutades. Lõpuks mõõtsime nende madalate tulemustega võrreldes raskete päringute toimivust, mis tagastavad palju ridu (90% tabelist), keskmise arvu ridu (50% tabelist) ja mõne rea (1% tabelist). -kardinaalsuse stringide andmestikud. Tulemused on kokku võetud järgmises tabelis.

Predikaatidega päringute puhul, mis vastavad suurele protsendile ridadest, paranes uus vektoriseeritud BYTEDICT-kodeering võrreldes LZO-ga 5–30 korda, samas kui predikaatidega päringute puhul, mis vastavad väikesele protsendile ridadest, paranes see sisemine võrdlusalus 10–63 korda.

Redshift serverita hinna ja kvaliteedi suhtega

Lisaks selles postituses esitatud suure samaaegsuse jõudluse tulemustele kasutasime ka TPC-DS-st tuletatud Cloud Data Warehouse'i etalonit, et võrrelda Redshift Serverlessi hinna ja teiste andmeladudega, kasutades suuremat 3TB andmestikku. Valisime andmelaod, mille hind oli sarnane, antud juhul 10% piires 32 dollarist tunnis, kasutades avalikult kättesaadavat tellitavat hinnakujundust. Need tulemused näitavad, et sarnaselt Amazon Redshift RA3 eksemplaridele pakub Redshift Serverless teiste juhtivate pilvandmeladudega võrreldes paremat hinna ja kvaliteedi suhet. Nagu alati, saab neid tulemusi kopeerida, kasutades meie SQL-i skripte GitHubi hoidla.

Soovitame teil proovida Amazon Redshiftit omaenda abil tõendi mõiste töökoormused on parim viis näha, kuidas Amazon Redshift suudab teie andmeanalüütikavajadusi rahuldada.

Leidke oma töökoormuse jaoks parim hinna ja kvaliteedi suhe

Selles postituses kasutatud võrdlusalused on tuletatud tööstusstandardi TPC-DS võrdlusalusest ja neil on järgmised omadused:

  • Skeemi ja andmeid kasutatakse TPC-DS-is muutmata kujul.
  • Päringud genereeritakse ametliku TPC-DS komplekti abil koos päringuparameetritega, mis on loodud TPC-DS komplekti vaikimisi juhusliku seemne abil. TPC heakskiidetud päringu variante kasutatakse lao jaoks, kui ladu ei toeta TPC-DS vaikepäringu SQL-i dialekti.
  • Test sisaldab 99 TPC-DS SELECT päringut. See ei sisalda hoolduse ja läbilaskevõime etappe.
  • Ühe 3 TB samaaegsuse testi jaoks viidi läbi kolm võimsusega käitamist ja iga andmelao jaoks võetakse parim katse.
  • TPC-DS-päringute hinna-toimivus arvutatakse tunnikuluna (USD) korrutatuna võrdlusaluse käitusajaga tundides, mis on võrdne võrdlusuuringu käitamise kuluga. Kõikide andmeladude jaoks kasutatakse viimast avaldatud tellitavat hinnakujundust, mitte reserveeritud eksemplari hinnakujundust, nagu varem märgitud.

Nimetame seda Cloud Data Warehouse'i võrdlusaluseks ja saate hõlpsasti reprodutseerida eelnevaid võrdlusuuringu tulemusi, kasutades meie lehel saadaolevaid skripte, päringuid ja andmeid. GitHubi hoidla. See on tuletatud selles postituses kirjeldatud TPC-DS-i võrdlusalustest ja sellisena ei ole see võrreldav avaldatud TPC-DS-i tulemustega, kuna meie testide tulemused ei vasta ametlikule spetsifikatsioonile.

Järeldus

Amazon Redshift on pühendunud valdkonna parima hinna ja kvaliteedi suhte pakkumisele kõige erinevamate töökoormuste puhul. Redshift Serverless skaleerib lineaarselt parima (madalaima) hinna ja kvaliteedi suhtega, toetades sadu samaaegseid kasutajaid, säilitades samal ajal järjepidevad päringu vastuseajad. Selles postituses käsitletud testitulemuste põhjal on Amazon Redshiftil lähima konkurendiga (konkurent B) samaaegselt samal tasemel kuni 2.6 korda parem hinna ja kvaliteedi suhe. Nagu varem mainitud, annab reserveeritud eksemplaride kasutamine koos 3-aastase kõik ettemaksuvalikuga teile Amazon Redshifti käitamiseks kõige madalamad kulud, mille tulemuseks on veelgi parem suhteline hinna-toimivus võrreldes tellitavate eksemplaride hinnakujundusega, mida selles postituses kasutasime. Meie lähenemine pidevale jõudluse parandamisele hõlmab ainulaadset kombinatsiooni klientide kinnisideest, et mõista klientide kasutusjuhtumeid ja nendega seotud mastaapsuse kitsaskohti koos pideva sõidukipargi andmete analüüsiga, et teha kindlaks võimalused märkimisväärseks jõudluse optimeerimiseks.

Igal töökoormusel on ainulaadsed omadused, nii et kui te alles alustate, a tõendi mõiste on parim viis mõista, kuidas Amazon Redshift saab teie kulusid alandada, pakkudes samal ajal paremat jõudlust. Oma kontseptsiooni tõestust käitades on oluline keskenduda õigetele mõõdikutele – päringu läbilaskevõimele (päringute arv tunnis), reageerimisajale ja hinna-toimivusele. Saate teha andmepõhise otsuse, käivitades kontseptsiooni tõendi ise või abiga AWS-ist või a süsteemiintegratsiooni ja konsultatsioonipartner.

Amazon Redshifti viimaste arengutega kursis püsimiseks järgige Mida uut Amazon Redshiftis? toita.

Autoritest

Stefan Gromoll on vaneminsener Amazon Redshifti meeskonnas, kus ta vastutab Redshift jõudluse mõõtmise ja parandamise eest. Vabal ajal meeldib talle süüa teha, oma kolme poisiga mängida ja küttepuid raiuda.

Ravi Animi on Amazon Redshifti meeskonna vanem tootehalduse juht ja haldab Amazon Redshifti pilvandmelaoteenuse mitmeid funktsionaalseid valdkondi, sealhulgas jõudlust, ruumianalüüsi, voogesituse allaneelamist ja migratsioonistrateegiaid. Tal on kogemusi relatsiooniandmebaaside, mitmemõõtmeliste andmebaaside, asjade Interneti-tehnoloogiate, salvestus- ja arvutustaristu teenustega ning viimasel ajal idufirma asutajana, kasutades tehisintellekti/süvaõpet, arvutinägemust ja robootikat.

Aamer Shah on Amazon Redshift Service meeskonna vaneminsener.

Sanket Hase on Amazon Redshift Service meeskonna tarkvaraarenduse juht.

Orestis Polychroniou on Amazon Redshift Service meeskonna peainsener.

Ajatempel:

Veel alates AWSi suured andmed