Google mākoņu uzgriežņu atslēga: labs, slikts, neglīts

Sveiki, Habrovskas iedzÄ«votāji. Kā ierasts, mēs turpinām dalÄ«ties ar interesantu materiālu pirms jaunu kursu sākuma. Å odien Ä«paÅ”i jums esam publicējuÅ”i rakstu par Google Cloud Spanner, lai tas sakristu ar kursa sākÅ”anu "AWS izstrādātājiem".

Google mākoņu uzgriežņu atslēga: labs, slikts, neglīts

Sākotnēji publicēts Lightspeed HQ emuārs.

Kā uzņēmums, kas piedāvā dažādus mākoņdatoÅ”anas POS risinājumus mazumtirgotājiem, restorāniem un tieÅ”saistes pārdevējiem visā pasaulē, Lightspeed izmanto dažādu veidu datu bāzu platformas dažādiem darÄ«jumu, analÄ«tiskajiem un meklÄ“Å”anas gadÄ«jumiem. Katrai no Ŕīm datu bāzu platformām ir savas stiprās un vājās puses. LÄ«dz ar to, kad Google tirgÅ« ieviesa Cloud Spanner ā€” relāciju datu bāzu pasaulē neredzētas daudzsoloÅ”as funkcijas, piemēram, praktiski neierobežota horizontālā mērogojamÄ«ba un 99,999% pakalpojumu lÄ«meņa lÄ«gums (SLA), ā€” nevarējām laist garām iespēju tikt pie rokas!

Lai sniegtu visaptveroÅ”u pārskatu par mÅ«su pieredzi ar Cloud Spanner, kā arÄ« izmantotajiem vērtÄ“Å”anas kritērijiem, mēs apskatÄ«sim Ŕādas tēmas:

  1. MÅ«su vērtÄ“Å”anas kritēriji
  2. Mākoņu atslēga īsumā
  3. Mūsu vērtējums
  4. Mūsu atklājumi

Google mākoņu uzgriežņu atslēga: labs, slikts, neglīts

1. MÅ«su vērtÄ“Å”anas kritēriji

Pirms iedziļināties Cloud Spanner specifikā, tā līdzībās un atŔķirībās ar citiem tirgū esoŔajiem risinājumiem, vispirms parunāsim par galvenajiem lietoŔanas gadījumiem, kas mums bija prātā, apsverot, kur mūsu infrastruktūrā izvietot Cloud Spanner:

  • Kā (pārsvarā) tradicionālā SQL datu bāzes risinājuma aizstājējs
  • Kā OLTP risinājumu ar OLAP atbalstu

Piezīme: VienkārŔības un salīdzināŔanas labad Ŕajā rakstā Cloud Spanner ir salīdzināts ar GCP Cloud SQL un Amazon AWS RDS risinājumu saimes MySQL variantiem.

Cloud Spanner izmantoÅ”ana kā tradicionālā SQL datu bāzes risinājuma aizstājējs

Vidē tradicionālā datubāzēm, kad datu bāzes vaicājuma reakcijas laiks tuvojas vai pat pārsniedz iepriekÅ” definētos lietojumprogrammu sliekŔņus (galvenokārt lietotāju un/vai pieprasÄ«jumu skaita pieauguma dēļ), ir vairāki veidi, kā samazināt atbildes laiku lÄ«dz pieņemamam lÄ«menim. Tomēr lielākā daļa Å”o risinājumu ietver manuālu iejaukÅ”anos.

Piemēram, pirmais solis, kas jāveic, ir aplÅ«kot dažādus ar veiktspēju saistÄ«tos datu bāzes parametrus un pielāgot tos, lai tie vislabāk atbilstu lietojumprogrammu lietoÅ”anas gadÄ«jumu modeļiem. Ja ar to nepietiek, varat izvēlēties mērogot datubāzi vertikāli vai horizontāli.

Lietojumprogrammas vertikālā mērogoÅ”ana ir saistÄ«ta ar servera instances jaunināŔanu, parasti pievienojot vairāk procesoru/kodolu, vairāk RAM, ātrāku krātuvi utt. Pievienojot vairāk aparatÅ«ras resursu, palielinās datu bāzes veiktspēja, galvenokārt transakcijās sekundē, un darÄ«jumu latentums OLTP sistēmām. Relāciju datu bāzu sistēmas (kas izmanto daudzpavedienu pieeju), piemēram, MySQL mērogojas labi vertikāli.

Å ai pieejai ir vairāki trÅ«kumi, taču visredzamākais ir tirgÅ« pieejamais maksimālais servera izmērs. Kad ir sasniegts lielākās servera instances ierobežojums, atliek tikai viena iespēja: horizontālā mērogoÅ”ana.

Horizontālā mērogoÅ”ana ir pieeja, kurā klasterim tiek pievienots vairāk serveru, ideālā gadÄ«jumā lineāri palielinot veiktspēju, pievienojot serveru skaitu. Vairums tradicionālā Datu bāzu sistēmas mērogojas horizontāli slikti vai vispār netiek mērogotas. Piemēram, MySQL var mērogot horizontāli lasÄ«Å”anas darbÄ«bām, pievienojot vergu lasÄ«tājus, bet nevar mērogot horizontāli rakstÄ«Å”anai.

No otras puses, tā bÅ«tÄ«bas dēļ Cloud Spanner var viegli mērogot horizontāli ar minimālu iejaukÅ”anos.

PilnÄ«bā aprÄ«kots DBVS kā pakalpojums jāvērtē no dažādiem leņķiem. Par pamatu mēs ņēmām populārākās DBVS mākonÄ« - Google, GCP Cloud SQL un Amazon, AWS RDS. Savā novērtējumā mēs koncentrējāmies uz Ŕādām kategorijām:

  • IezÄ«mju kartÄ“Å”ana: apjoms SQL, DDL, DML; savienojumu bibliotēkas/savienotāji, transakciju atbalsts un tā tālāk.
  • Izstrādes atbalsts: vienkārÅ”a izstrāde un testÄ“Å”ana.
  • AdministrÄ“Å”anas atbalsts: instanču pārvaldÄ«ba ā€“ piemēram, gadÄ«jumu palielināŔana/samazināŔanās un jaunināŔana; SLA, dublÄ“Å”ana un atkopÅ”ana; droŔības/piekļuves kontrole.

Cloud Spanner izmantoÅ”ana kā OLAP iespējots OLTP risinājums

Lai gan Google skaidri nenorāda, ka Cloud Spanner ir paredzēts analītiskai apstrādei, tā koplieto dažus atribūtus ar citiem dzinējiem, piemēram, Apache Impala & Kudu un YugaByte, kas ir paredzēti OLAP darba slodzēm.

Pat ja būtu tikai neliela iespēja, ka Cloud Spanner iekļāva konsekventu mērogojamu HTAP (hibrīda darījumu/analītikas apstrādes) dzinēju ar (vairāk vai mazāk) lietojamu OLAP funkciju kopu, mēs uzskatām, ka tas būtu mūsu uzmanības vērts.

Paturot to prātā, mēs apskatÄ«jām Ŕādas kategorijas:

  • Datu ielāde, indeksi un sadalÄ«Å”anas atbalsts
  • Vaicājuma veiktspēja un DML

2. Mākoņu atslēga īsumā

Google Spanner ir kopu relāciju datu bāzes pārvaldÄ«bas sistēma (RDBMS), ko Google izmanto vairākiem saviem pakalpojumiem. Google padarÄ«ja to vispārēji pieejamu Google Cloud Platform lietotājiem 2017. gada sākumā.

Šeit ir daži no Cloud Spanner atribūtiem:

  • Ä»oti konsekvents mērogojams RDBMS klasteris: izmanto aparatÅ«ras laika sinhronizāciju, lai nodroÅ”inātu datu konsekvenci.
  • Vairāku tabulu transakciju atbalsts: darÄ«jumi var aptvert vairākas tabulas ā€” ne vienmēr ir tikai viena tabula (atŔķirÄ«bā no Apache HBase vai Apache Kudu).
  • Tabulas, kuru pamatā ir primārā atslēga: Visām tabulām ir jābÅ«t deklarētai primārajai atslēgai (PC), kas var sastāvēt no vairākām tabulas kolonnām. Tabulu dati tiek glabāti datora secÄ«bā, padarot tos ļoti efektÄ«vus un ātrus meklÄ“Å”anai datorā. Tāpat kā citas uz datoru balstÄ«tas sistēmas, ievieÅ”ana ir jāmodelē, ņemot vērā iepriekÅ” izstrādātus lietoÅ”anas gadÄ«jumus, lai to panāktu labākais sniegums.
  • SvÄ«trainas tabulas: tabulām var bÅ«t fiziska atkarÄ«ba viena no otras. Pakārtotās tabulas rindas var saskaņot ar vecāktabulas rindām. Å Ä« pieeja paātrina tādu attiecÄ«bu meklÄ“Å”anu, kuras var identificēt datu modelÄ“Å”anas fāzē, piemēram, klientu un viņu rēķinu lÄ«dzāsatraÅ”anos.
  • Indeksi: Cloud Spanner atbalsta sekundāros indeksus. Indekss sastāv no indeksētajām kolonnām un visām PC kolonnām. Ja vēlaties, rādÄ«tājā var bÅ«t arÄ« citas neindeksētas kolonnas. Lai paātrinātu vaicājumu izpildi, indeksu var apvienot ar vecāktabulu. Uz indeksiem attiecas vairāki ierobežojumi, piemēram, maksimālais indeksā saglabāto papildu kolonnu skaits. Turklāt vaicājumi, izmantojot indeksus, var nebÅ«t tik vienkārÅ”i kā citās RDBVS.

ā€œCloud Spanner automātiski atlasa indeksu tikai retos gadÄ«jumos. Jo Ä«paÅ”i, Cloud Spanner automātiski neatlasa sekundāro indeksu, ja vaicājumā tiek pieprasÄ«tas kolonnas, kas nav saglabātas rādÄ«tājs '.

  • Pakalpojuma lÄ«meņa lÄ«gums (SLA): izvietoÅ”ana vienā reÄ£ionā ar SLA 99,99%; vairāku reÄ£ionu izvietoÅ”ana ar 99,999% SLA. Lai gan pats SLA ir tikai vienoÅ”anās, nevis nekāda veida garantija, es uzskatu, ka Google darbiniekiem ir daži grÅ«ti dati, lai izteiktu tik spēcÄ«gu apgalvojumu. (Uzziņai ā€” 99,999% nozÄ«mē, ka pakalpojums nav pieejams 26,3 sekundes mēnesÄ«.)
  • Vairāk: https://cloud.google.com/spanner/

Piezīme: Apache Tephra projekts pievieno uzlabotu darījumu atbalstu Apache HBase (tagad arī tiek ieviests Apache Phoenix kā beta versija).

3. Mūsu vērtējums

Tātad, mēs visi esam lasÄ«juÅ”i Google apgalvojumus par Cloud Spanner priekÅ”rocÄ«bām ā€” praktiski neierobežotu horizontālo mērogoÅ”anu, vienlaikus saglabājot augstu konsekvenci un ļoti augstu SLA. Lai gan Ŕīs prasÄ«bas jebkurā gadÄ«jumā ir ārkārtÄ«gi grÅ«ti izpildāmas, mÅ«su mērÄ·is nebija tās atspēkot. Tā vietā pievērsÄ«simies citām lietām, kas rÅ«p lielākajai daļai datu bāzes lietotāju: paritātei un lietojamÄ«bai.

Mēs novērtējām Cloud Spanner kā Sharded MySQL aizstājēju

Google Cloud SQL un Amazon AWS RDS, divām no populārākajām OLTP DBVS mākoņu tirgÅ«, ir ļoti plaÅ”s funkciju kopums. Tomēr, lai Ŕīs datu bāzes bÅ«tu lielākas par viena mezgla lielumu, ir jāveic lietojumprogrammu sadalÄ«Å”ana. Å Ä« pieeja rada papildu sarežģītÄ«bu gan lietojumprogrammām, gan administrÄ“Å”anai. Mēs apskatÄ«jām, kā Spanner iekļaujas scenārijā, kurā vienā instancē tiek apvienotas vairākas Ŕķembas, un kādas funkcijas (ja tādas ir) varētu bÅ«t jāupurē.

SQL, DML un DDL atbalsts, kā arī savienotājs un bibliotēkas?

Pirmkārt, sākot ar jebkuru datu bāzi, ir jāizveido datu modelis. Ja domājat, ka varat savienot JDBC Spanner ar savu iecienītāko SQL rīku, jūs atklāsit, ka varat ar to vaicāt savus datus, taču nevarat to izmantot, lai izveidotu tabulu vai modificētu (DDL) vai ievietotu/atjauninātu/dzēstu. operācijas (DML). Google oficiālais JDBC neatbalsta nevienu no tiem.

"Draiveri paÅ”laik neatbalsta DML vai DDL paziņojumus."
Uzgriežņu atslēgas dokumentācija

Situācija nav labāka ar GCP konsoli ā€” jÅ«s varat nosÅ«tÄ«t tikai SELECT vaicājumus. Par laimi, kopienai ir JDBC draiveris ar DML un DDL atbalstu, tostarp darÄ«jumiem github.com/olavloite/spanner-jdbc. Lai gan Å”is draiveris ir ārkārtÄ«gi noderÄ«gs, Google paÅ”a JDBC draivera trÅ«kums ir pārsteidzoÅ”s. Par laimi, Google piedāvā diezgan plaÅ”u atbalstu klientu bibliotēkām (pamatojoties uz gRPC): C#, Go, Java, node.js, PHP, Python un Ruby.

GandrÄ«z obligāta Cloud Spanner pielāgoto API izmantoÅ”ana (jo JDBC nav DDL un DML) rada zināmus ierobežojumus saistÄ«tajām koda jomām, piemēram, savienojumu pÅ«liem vai datu bāzes saistÄ«Å”anas ietvariem (piemēram, Spring MVC). Parasti, izmantojot JDBC, jÅ«s varat brÄ«vi izvēlēties savu iecienÄ«tāko savienojumu kopu (piemēram, HikariCP, DBCP, C3PO utt.), kas ir pārbaudÄ«ts un darbojas labi. Pielāgotu Spanner API gadÄ«jumā mums ir jāpaļaujas uz ietvariem/saistoÅ”iem pÅ«liem/sesijām, ko esam izveidojuÅ”i paÅ”i.

Uz primāro atslēgu (PC) orientētais dizains ļauj Cloud Spanner darboties ļoti ātri, piekļūstot datiem, izmantojot datoru, kā arī rada dažas vaicājumu problēmas.

  • JÅ«s nevarat atjaunināt primārās atslēgas vērtÄ«bu; Vispirms ir jāizdzÄ“Å” ieraksts no sākotnējā datora un atkārtoti jāievieto ar jauno vērtÄ«bu. (Tas ir lÄ«dzÄ«gs citiem uz datoru orientētiem datu bāzu/atmiņas dzinējiem.)
  • Jebkuriem priekÅ”rakstiem UPDATE un DELETE ir jānorāda PC laukā WHERE, tāpēc visi priekÅ”raksti DELETE nedrÄ«kst bÅ«t tukÅ”i - vienmēr ir jābÅ«t apakÅ”vaicājumam, piemēram: UPDATE xxx WHERE id IN (SELECT id FROM table1)
  • TrÅ«kst automātiskās palielināŔanas opcijas vai kaut kas lÄ«dzÄ«gs, kas nosaka datora lauka secÄ«bu. Lai tas darbotos, lietojumprogrammas pusē ir jāizveido atbilstoŔā vērtÄ«ba.

Sekundārie indeksi?

Google Cloud Spanner ir iebÅ«vēts atbalsts sekundārajiem indeksiem. Å Ä« ir ļoti jauka funkcija, kas ne vienmēr ir pieejama citās tehnoloÄ£ijās. Apache Kudu paÅ”laik vispār neatbalsta sekundāros indeksus, un Apache HBase neatbalsta indeksus tieÅ”i, bet var tos pievienot, izmantojot Apache Phoenix.

Indeksus programmās Kudu un HBase var modelēt kā atseviŔķu tabulu ar atŔķirÄ«gu primāro atslēgu sastāvu, taču vecāku tabulā un ar to saistÄ«tajās indeksu tabulās veikto darbÄ«bu atomitāte ir jāveic lietojumprogrammas lÄ«menÄ«, un tā nav triviāla, lai to pareizi ieviestu.

Kā minēts Cloud Spanner pārskatā, tā indeksi var atŔķirties no MySQL indeksiem. Tāpēc, veidojot vaicājumus un profilÄ“Å”anu, ir jāievēro Ä«paÅ”a piesardzÄ«ba, lai nodroÅ”inātu, ka tur, kur tas ir nepiecieÅ”ams, tiek izmantots pareizs indekss.

Pārstāvība?

Ä»oti populārs un noderÄ«gs objekts datu bāzē ir skati. Tie var bÅ«t noderÄ«gi daudziem lietoÅ”anas gadÄ«jumiem; mani divi favorÄ«ti ir loÄ£iskās abstrakcijas slānis un droŔības slānis. Diemžēl Cloud Spanner NEatbalsta skatus. Tomēr tas mÅ«s ierobežo tikai daļēji, jo piekļuves atļaujām kolonnu lÄ«menÄ« nav precizitātes, kur skati varētu bÅ«t dzÄ«votspējÄ«gs risinājums.

Skatiet Cloud Spanner dokumentācijā sadaļu, kurā ir detalizēti aprakstÄ«tas kvotas un ierobežojumi (uzgriežņu atslēga/kvotas), ir viena, kas var bÅ«t problemātiska dažām lietojumprogrammām: Cloud Spanner jau sākotnēji ir ierobežots lÄ«dz 100 datu bāzēm vienā instancē. AcÄ«mredzot tas var bÅ«t galvenais Ŕķērslis datu bāzei, kas paredzēta vairāk nekā 100 datu bāzēm. Par laimi, pēc sarunas ar mÅ«su Google tehnisko pārstāvi mēs noskaidrojām, ka, izmantojot Google atbalstu, Å”o ierobežojumu var palielināt lÄ«dz gandrÄ«z jebkurai vērtÄ«bai.

Atbalsts attīstībai?

Cloud Spanner piedāvā diezgan pienācÄ«gu programmÄ“Å”anas valodas atbalstu darbam ar tā API. Oficiāli atbalstÄ«tās bibliotēkas ir C#, Go, Java, node.js, PHP, Python un Ruby jomās. Dokumentācija ir diezgan detalizēta, taču, tāpat kā ar citām progresÄ«vām tehnoloÄ£ijām, kopiena ir diezgan maza, salÄ«dzinot ar populārākajām datu bāzu tehnoloÄ£ijām, kas var novest pie vairāk laika, kas pavadÄ«ts retāk sastopamu lietoÅ”anas gadÄ«jumu vai problēmu risināŔanai.

Kā tad ar vietējās attÄ«stÄ«bas atbalstÄ«Å”anu?

Mēs neesam atraduÅ”i veidu, kā lokāli izveidot Cloud Spanner instanci. Tuvākais, ko mēs saņēmām, bija Docker attēls. TarakānsDB, kas principā ir lÄ«dzÄ«gs, bet praksē ļoti atŔķirÄ«gs. Piemēram, CockroachDB var izmantot PostgreSQL JDBC. Tā kā izstrādes videi ir jābÅ«t pēc iespējas tuvākai ražoÅ”anas videi, Cloud Spanner nav ideāls, jo tam ir jāpaļaujas uz pilnu uzgriežņu atslēgu gadÄ«jumu. Lai ietaupÄ«tu izmaksas, varat atlasÄ«t viena reÄ£iona gadÄ«jumu.

Administrācijas atbalsts?

Cloud Spanner instances izveide ir ļoti vienkārÅ”a. Jums vienkārÅ”i jāizvēlas starp vairāku reÄ£ionu vai viena reÄ£iona instances izveidi, jānorāda reÄ£ions(-i) un mezglu skaits. Mazāk nekā minÅ«tes laikā jÅ«su instance tiks izveidota un darbosies.

Vairāki elementāri rādÄ«tāji ir tieÅ”i pieejami Google konsoles uzgriežņu atslēgas lapā. Detalizētāki skati ir pieejami, izmantojot Stackdriver, kur varat arÄ« iestatÄ«t metrikas sliekŔņus un brÄ«dinājumu politikas.

Piekļuve resursiem?

MySQL piedāvā plaÅ”us un ļoti detalizētus iestatÄ«jumus lietotāja atļaujām/lomām. Varat viegli konfigurēt piekļuvi noteiktai tabulai vai pat tikai tās kolonnu apakÅ”kopai. Cloud Spanner izmanto Google identitātes un piekļuves pārvaldÄ«bas (IAM) rÄ«ku, kas ļauj iestatÄ«t politikas un atļaujas tikai ļoti augstā lÄ«menÄ«. VisprecÄ«zākā iespēja ir datu bāzes lÄ«meņa izŔķirtspēja, kas neietilpst lielākajā daļā ražoÅ”anas gadÄ«jumu. Å is ierobežojums liek jums pievienot papildu droŔības pasākumus savam kodam, infrastruktÅ«rai vai abiem, lai novērstu neatļautu Spanner resursu izmantoÅ”anu.

Dublējumkopijas?

VienkārÅ”i sakot, pakalpojumā Cloud Spanner nav dublējumu. Lai gan Google augstās SLA prasÄ«bas var nodroÅ”ināt, ka jÅ«s nezaudējat datus aparatÅ«ras vai datu bāzes kļūmju, cilvēku kļūdu, lietojumprogrammu defektu u.c. dēļ. Mēs visi zinām noteikumu: augsta pieejamÄ«ba neaizstāj droÅ”u dublÄ“Å”anas stratēģiju. PaÅ”laik vienÄ«gais veids, kā dublēt datus, ir programmatiski straumēt tos no datu bāzes uz atseviŔķu krātuves vidi.

Vai vaicāt veiktspēju?

Mēs izmantojām Yahoo!, lai ielādētu datus un pārbaudÄ«tu vaicājumus. Mākoņa apkalpoÅ”anas etalons. Tālāk esoÅ”ajā tabulā parādÄ«ta YCSB darba slodze B ar 95% lasÄ«Å”anas un 5% rakstÄ«Å”anas attiecÄ«bu.

Google mākoņu uzgriežņu atslēga: labs, slikts, neglīts

* Slodzes tests tika veikts ar n1-standard-32 Compute Engine (CE) (32 vCPU, 120 GB atmiņa), un testa eksemplārs testos nekad nav bijis Ŕķērslis.
** Maksimālais pavedienu skaits vienā YCSB instancē ir 400. Kopā bija jāpalaiž seÅ”i paralēli YCSB testu gadÄ«jumi, lai kopā iegÅ«tu 2400 pavedienus.

AplÅ«kojot etalonu rezultātus, jo Ä«paÅ”i CPU slodzes un TPS kombināciju, mēs varam skaidri redzēt, ka Cloud Spanner mērogojas diezgan labi. Lielo slodzi, ko rada liels pavedienu skaits, kompensē lielais mezglu skaits Cloud Spanner klasterÄ«. Lai gan latentums izskatās diezgan augsts, it Ä«paÅ”i, ja darbojas ar 2400 pavedieniem, var bÅ«t nepiecieÅ”ama atkārtota pārbaude ar 6 mazākiem skaitļoÅ”anas programmas gadÄ«jumiem, lai iegÅ«tu precÄ«zākus skaitļus. Katrs gadÄ«jums veiks vienu YCSB testu, nevis vienu lielu CE gadÄ«jumu ar 6 paralēliem testiem. Tādā veidā bÅ«s vieglāk atŔķirt Cloud Spanner pieprasÄ«juma latentumu un latentumu, ko pievieno tÄ«kla savienojums starp Cloud Spanner un CE instanci, kas veic testu.

Kā Cloud Spanner darbojas kā OLAP?

SadalīŔana?

Datu sadalÄ«Å”ana fiziski un/vai loÄ£iski neatkarÄ«gos segmentos, ko sauc par nodalÄ«jumiem, ir ļoti populārs jēdziens, kas atrodams lielākajā daļā OLAP dzinēju. Starpsienas var ievērojami uzlabot vaicājumu veiktspēju un datu bāzes apkopi. Padziļināta sadalÄ«Å”ana bÅ«tu atseviŔķs(-i) raksts(-i), tāpēc pieminēsim tikai sadalÄ«Å”anas un apakÅ”nodalÄ«Å”anas shēmas nozÄ«mi. AnalÄ«tiskā vaicājuma veiktspējas atslēga ir spēja sadalÄ«t datus nodalÄ«jumos un vēl vairāk apakÅ”sadaļās.

Cloud Spanner neatbalsta nodalÄ«jumus kā tādus. Tas datus iekŔēji sadala tā sauktajos sadalÄ«t-s, pamatojoties uz primāro atslēgu diapazoniem. SadalÄ«Å”ana tiek veikta automātiski, lai lÄ«dzsvarotu slodzi Cloud Spanner klasterÄ«. Ä»oti noderÄ«ga Cloud Spanner funkcija ir vecāktabulas bāzes slodzes sadalÄ«Å”ana (tabula, kas nav savstarpēji savienota ar citu). Atslēgas atslēga automātiski nosaka, vai tajā ir sadalÄ«t dati, kas tiek lasÄ«ti biežāk nekā dati citās sadalÄ«t-ah, un var lemt par turpmāku ŔķirÅ”anos. Tādā veidā pieprasÄ«jumā var iesaistÄ«t vairāk mezglu, kas arÄ« efektÄ«vi palielina caurlaidspēju.

Vai ielādēt datus?

Cloud Spanner metode lielapjoma datiem ir tāda pati kā parastai ielādei. Lai sasniegtu maksimālu veiktspēju, jums jāievēro daži noteikumi, tostarp:

  • Kārtojiet datus pēc primārās atslēgas.
  • Sadaliet tos ar 10*mezglu skaits atseviŔķas sadaļas.
  • Izveidojiet darba uzdevumu kopu, kas paralēli ielādē datus.

Šī datu ielāde izmanto visus Cloud Spanner mezglus.

Mēs izmantojām YCSB darba slodzi A, lai Ä£enerētu datu kopu ar 10 miljoniem rindu.

Google mākoņu uzgriežņu atslēga: labs, slikts, neglīts

* Slodzes tests tika veikts ar n1-standard-32 skaitļoÅ”anas dzinēju (32 vCPU, 120 GB atmiņa), un testa eksemplārs testos nekad nav bijis Ŕķērslis.
** Viena mezgla iestatīŔana nav ieteicama nevienai ražoŔanas darba slodzei.

Kā minēts iepriekÅ”, Cloud Spanner automātiski apstrādā sadalÄ«jumus, pamatojoties uz to slodzi, tāpēc rezultāti uzlabojas pēc vairākiem secÄ«giem testa atkārtojumiem. Å eit sniegtie rezultāti ir labākie rezultāti, ko esam sasnieguÅ”i. AplÅ«kojot iepriekÅ” minētos skaitļus, mēs varam redzēt, kā Cloud Spanner mērogojas (labi), palielinoties klastera mezglu skaitam. Skaitļi, kas izceļas, ir ārkārtÄ«gi zemais vidējais latentums, kas ir pretrunā ar rezultātiem jauktām darba slodzēm (95% lasÄ«Å”anas un 5% rakstÄ«Å”anas), kā aprakstÄ«ts iepriekÅ” sadaļā.

MērogoÅ”ana?

Cloud Spanner mezglu skaita palielināŔana un samazināŔana ir uzdevums ar vienu klikŔķi. Ja vēlaties ātri ielādēt datus, varat apsvērt iespēju maksimāli palielināt instanci (mÅ«su gadÄ«jumā tas bija 25 mezgli ASV un Austrumu reÄ£ionā) un pēc tam samazināt to mezglu skaitu, kas ir piemēroti jÅ«su parastajai ielādei, tiklÄ«dz visi dati ir ievadÄ«ti. datu bāzē, atsaucoties uz 2TB/mezgla ierobežojumu.

Mums tika atgādināts par Å”o ierobežojumu pat ar daudz mazāku datu bāzi. Pēc vairākām slodzes pārbaudēm mÅ«su datubāze bija aptuveni 155 GB liela, un, samazinot lÄ«dz 1 mezgla instancei, mēs saņēmām Ŕādu kļūdu:

Google mākoņu uzgriežņu atslēga: labs, slikts, neglīts

Mums izdevās samazināt apjomu no 25 lÄ«dz 2 gadÄ«jumiem, taču mēs bijām iestrēguÅ”i divos mezglos.

Mezglu skaita palielināŔanu un samazināŔanu Cloud Spanner klasterÄ« var automatizēt, izmantojot REST API. Tas var bÅ«t Ä«paÅ”i noderÄ«gi, lai samazinātu palielinātu sistēmas slodzi aizņemtajā darba laikā.

OLAP vaicājumu veiktspēja?

Sākotnēji mēs plānojām veltÄ«t ievērojamu laiku, lai novērtētu Spannera Å”o daļu. Pēc vairākiem SELECT COUNT mēs uzreiz sapratām, ka testÄ“Å”ana bÅ«s Ä«sa un ka Spanner NEBÅŖS piemērots OLAP dzinējs. NeatkarÄ«gi no mezglu skaita klasterÄ«, vienkārÅ”i atlasot rindu skaitu 10 miljonu rindu tabulā, bija nepiecieÅ”amas 55ā€“60 sekundes. Turklāt jebkurÅ” vaicājums, kuram bija nepiecieÅ”ams vairāk atmiņas, lai saglabātu starprezultātus, neizdevās ar OOM kļūdu.

SELECT COUNT(DISTINCT(field0)) FROM usertable; ā€” (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.

Daži skaitļi TPC-H vaicājumiem ir atrodami Toda Lipkona rakstā Nosql-kudu-spanner-slides.html, 42. un 43. slaidi. Å ie skaitļi atbilst mÅ«su paÅ”u rezultātiem (diemžēl).

Google mākoņu uzgriežņu atslēga: labs, slikts, neglīts

4. Mūsu secinājumi

Ņemot vērā paÅ”reizējo Cloud Spanner funkciju stāvokli, ir grÅ«ti iedomāties, ka tas varētu vienkārÅ”i aizstāt jÅ«su esoÅ”o OLTP risinājumu, it Ä«paÅ”i, ja jÅ«su vajadzÄ«bas to pārspēj. BÅ«tu jāpavada ievērojams laiks, lai izstrādātu risinājumu Cloud Spanner trÅ«kumiem.

Kad sākām novērtēt Cloud Spanner, mēs gaidījām, ka tā pārvaldības funkcijas būs līdzvērtīgas citiem Google SQL risinājumiem vai vismaz ne pārāk tālu no tiem. Bet mūs pārsteidza pilnīgs rezerves kopiju trūkums un ļoti ierobežota kontrole pār piekļuvi resursiem. Nemaz nerunājot par bezskatiem, bez vietējās izstrādes vides, neatbalstītām sekvencēm, JDBC bez DML un DDL atbalsta un tā tālāk.

Tātad, kur iet kāds, kuram ir jāmēro darÄ«jumu datu bāze? Å Ä·iet, ka tirgÅ« nav neviena risinājuma, kas atbilstu visiem lietoÅ”anas gadÄ«jumiem. Ir daudz slēgtā un atvērtā koda risinājumu (daži no tiem ir minēti Å”ajā rakstā), katram ir savas stiprās un vājās puses, taču neviens no tiem nepiedāvā SaaS ar 99,999% SLA un augstu konsekvenci. Ja jÅ«su galvenais mērÄ·is ir augsts SLA un jÅ«s nevēlaties izveidot pielāgotu vairāku mākoņu risinājumu, Cloud Spanner var bÅ«t jÅ«su meklētais risinājums. Bet jums jāapzinās visi tā ierobežojumi.

TaisnÄ«bas labad jāsaka, ka Cloud Spanner sabiedrÄ«bai tika izlaists tikai 2017. gada pavasarÄ«, tāpēc ir pamatoti sagaidÄ«t, ka daži no tā paÅ”reizējiem trÅ«kumiem galu galā var izzust (cerams), un, kad tie notiks, tas varētu mainÄ«t spēli. Galu galā Cloud Spanner nav tikai Google blakusprojekts. Google to izmanto kā pamatu citiem Google produktiem. Un, kad Google nesen Google mākoņkrātuvē Megastore nomainÄ«ja ar Cloud Spanner, tas ļāva Google Cloud Storage kļūt ļoti konsekventi globālā mēroga objektu sarakstiem (kas joprojām tā nav Amazones S3).

Tātad, vēl ir cerība... mēs ceram.

Tas ir viss. Tāpat kā raksta autors, arī mēs turpinām cerēt, bet ko jūs par to domājat? Raksti komentāros

Aicinām ikvienu apmeklēt mūsu bezmaksas vebinārs kura ietvaros detalizēti pastāstīsim par kursu "AWS izstrādātājiem" no OTUS.

Avots: www.habr.com

Pievieno komentāru