ProHoster >> Blog >> Administrimi >> Google Cloud Spanner: i mirë, i keq, i shëmtuar

Google Cloud Spanner: i mirë, i keq, i shëmtuar

Përshëndetje, anëtarë të Habr. Tradicionalisht, vazhdojmë të ndajmë materiale interesante para fillimit të kurseve të reja. Sot, veçanërisht për ju, kemi përkthyer një artikull mbi Google Cloud Spanner, duke e lidhur atë me lansimin e kursit. «AWS për zhvilluesit».

Google Cloud Spanner: i mirë, i keq, i shëmtuar

Fillimisht e publikuar në blogun e Lightspeed HQ.

Si njĂ« kompani qĂ« ofron njĂ« gamĂ« tĂ« gjerĂ« zgjidhjesh POS nĂ« re pĂ«r tregtarĂ«t me pakicĂ«, restorantet dhe shitĂ«sit online nga e gjithĂ« bota, Lightspeed pĂ«rdor disa lloje tĂ« ndryshme platformash bazash tĂ« dhĂ«nash pĂ«r shumĂ« raste transaksionesh, analitikĂ« dhe kĂ«rkime. Çdo njĂ«ra nga kĂ«to platforma tĂ« bazave tĂ« dhĂ«nash ka forcat dhe dobĂ«sitĂ« e saj. Prandaj, kur Google prezantoi nĂ« treg Cloud Spanner — funksione premtuese, tĂ« paindikative nĂ« botĂ«n e bazave tĂ« tĂ« dhĂ«nave relacionale, si shkallĂ«zimi horizontal praktikisht tĂ« pa kufizuar dhe njĂ« marrĂ«veshje pĂ«r nivelin e shĂ«rbimit (SLA) prej 99.999% — ne nuk mundĂ«m tĂ« humbnim mundĂ«sinĂ« ta kishim atĂ« nĂ« duar!

Për t'i dhënë një pasqyrë të plotë të përvojës sonë me Cloud Spanner, si dhe kriteret e vlerësimit që ne përdorëm, do të shqyrtojmë temat në vazhdim:

  1. Kriteret tona të vlerësimit
  2. Cloud Spanner me dy fjalë
  3. Vlerësimi ynë
  4. Konkluzionet tona

Google Cloud Spanner: i mirë, i keq, i shëmtuar

1. Kritet tona për vlerësimin

Para se të thellohemi në tiparet e Cloud Spanner, ngjashmëritë dhe dallimet e saj me zgjidhjet e tjera në treg, le të flasim fillimisht për rastet kryesore të përdorimit që keqpërdorëm kur shqyrtuam ku ta vendosnim Cloud Spanner në infrastrukturën tonë:

  • Si njĂ« zĂ«vendĂ«sim (dominues) pĂ«r zgjidhjet tradicionale tĂ« bazĂ«s sĂ« tĂ« dhĂ«nave SQL
  • Si njĂ« zgjidhje OLTP me mbĂ«shtetje pĂ«r OLAP

Shënim: Për thjeshtësi dhe lehtësi krahasimi, ky artikull e krahason Cloud Spanner me variantet MySQL të familjeve të zgjidhjeve GCP Cloud SQL dhe Amazon AWS RDS.

Përdorimi i Cloud Spanner si një zëvendësim për zgjidhjet tradicionale të bazës së të dhënave SQL

Në mjedisin tradicional të bazave të të dhënave, kur koha e përgjigjes për kërkesat ndaj bazës së të dhënave afrohet ose madje tejkalon vlerat e njohura të pragut të aplikacionit (kryesisht për shkak të rritjes së numrit të përdoruesve dhe/ose kërkesave), ekzistojnë disa mënyra për të ulur kohën e përgjigjes në nivele të pranueshme. Megjithatë, shumica e këtyre zgjidhjeve kërkojnë ndërhyrje manuale.

Për shembull, hapin e parë që duhet të ndërmerrni është të shikoni parametrat e ndryshëm të bazës së të dhënave që lidhen me performancën dhe t'i konfiguroni ato në mënyrë që të përputhen më mirë me modelet e skenarëve të përdorimit të aplikacioneve. Nëse kjo dështon, mund të zgjidhni të shkalloni bazën e të dhënave verticalisht ose horizontalisht.

Shkallëzimi vertical i aplikacionit përfshin përmirësimin e instancës së serverit, zakonisht duke shtuar më shumë procesorë/bërthama, më shumë memorie të përhershme, ruajtje më të shpejtë etj. Shtimi i burimeve të tjera harduerike çon në rritjen e performancës së bazës së të dhënave, e cila matet kryesisht në transaksione për sekondë dhe vonesë transaksionesh për sistemet OLTP. Sistemet e bazave të të dhënave relacionale (të cilat përdorin një qasje me shumë prova), si MySQL, shkallëzohen mirë verticalisht.

Ky qasje ka disa disavantazhe, por ajo më e dukshme është madhësia maksimale e serverit në treg. Pasi të arrihet kufiri i instancës më të madhe të serverit, ka vetëm një rrugë: shkallëzim horizontal.

Shkallëzimi horizontal është një qasje ku më shumë serverë shtohen në klaster, për të rritur idealisht performancën linearisht me shtimin e numrit të serverëve. Shumica e sistemeve të bazave të të dhënave tradicional kanë probleme me shkallëzimin horizontal ose nuk mund të shkallëzohen fare. Për shembull, MySQL mund të shkallëzohet horizontalisht për operacionet e leximit, duke shtuar slave-lexues, por nuk mund të shkallëzohet horizontalisht për operacionet e shkrimit.

Nga ana tjetër, për shkak të natyrës së tij, Cloud Spanner mund të shkallëzohet lehtësisht horizontalisht me ndërhyrje minimale.

NjĂ« Baze tĂ« dhĂ«nash si shĂ«rbim duhet tĂ« vlerĂ«sohet nga kĂ«ndvĂ«shtrime tĂ« ndryshme. Si bazĂ«, morĂ«m bazĂ«n mĂ« tĂ« njohur tĂ« tĂ« dhĂ«nave nĂ« re — pĂ«r Google, GCP Cloud SQL dhe pĂ«r Amazon, AWS RDS. NĂ« vlerĂ«simin tonĂ«, u fokusuam nĂ« kategoritĂ« e mĂ«poshtme:

  • PĂ«rputhja e karakteristikave: shkalla SQL, DDL, DML; bibliotekat e lidhjeve/konektorĂ«t, mbĂ«shtetje pĂ«r transaksionet dhe tĂ« tjera.
  • MbĂ«shtetje pĂ«r zhvillimin: thjeshtĂ«sia e zhvillimit dhe testimit.
  • MbĂ«shtetje pĂ«r administrimin: menaxhimi i instanceve — pĂ«r shembull, shkallĂ«zimi lart/poshtĂ« dhe pĂ«rmirĂ«simi i instanceve; SLA, kopje rezervĂ« dhe rikuperim; siguria/kontrolli i aksesit.

Përdorimi i Cloud Spanner si zgjidhje OLTP me mbështetje OLAP

Megjithëse Google nuk deklaron qartë se Cloud Spanner është i destinuar për përpunimin analitik, ai ndan disa atributet me mekanizma të tjerë si Apache Impala & Kudu dhe YugaByte, të cilat janë të destinuara për ngarkesa pune OLAP.

Edhe nëse do të kishte vetëm një mundësi të vogël që Cloud Spanner përfshinte një motor të përputhshëm horizontalisht të shkallëzuar HTAP (përpunimi hibrid të transaksioneve/analitikës) me një grup funksionesh OLAP (më shumë ose më pak) të përdorshëm, ne mendojmë se kjo do të meritonte vëmendjen tonë.

Duke e mbajtur këtë në mend, ne shqyrtuam kategoritë e mëposhtme:

  • Ngarkimi i tĂ« dhĂ«nave, indekset dhe mbĂ«shtetje pĂ«r ndarjen pĂ«rveç
  • Performanca e kĂ«rkimeve dhe DML

2. Cloud Spanner në dy fjalë

Google Spanner është një sistem i menaxhimit të bazave të dhënash relacional (RDBMS) në klaster, që Google e përdor për disa nga shërbimet e saj. Google e bëri atë të disponueshme për përdoruesit e Google Cloud Platform në fillim të vitit 2017.

Ja disa nga atributet e Cloud Spanner:

  • Klaster RDBMS i shkallĂ«zuar me saktĂ«si tĂ« lartĂ«: pĂ«rdor sinkronizimin e hardware-it pĂ«r tĂ« siguruar koherencĂ«n e tĂ« dhĂ«nave.
  • MbĂ«shtetje pĂ«r transaksionet ndĂ«rmjet tabelave: transaksionet mund tĂ« pĂ«rfshijnĂ« disa tabela — nuk kufizohen domosdoshmĂ«risht nĂ« njĂ« tabelĂ« (ndryshe nga Apache HBase ose Apache Kudu).
  • Tabelat bazuar nĂ« çelĂ«sin primar: tĂ« gjitha tabelat duhet tĂ« kenĂ« njĂ« çelĂ«s primar tĂ« shpallur (PK), i cili mund tĂ« pĂ«rbĂ«het nga disa kolona tĂ« tabelĂ«s. TĂ« dhĂ«nat e tabelĂ«s ruhen nĂ« rendin e PK, duke e bĂ«rĂ« atĂ« shumĂ« tĂ« efektshme dhe tĂ« shpejtĂ« pĂ«r kĂ«rkimin sipas PK. Siç ndodh me sistemet e tjera tĂ« bazuara nĂ« PK, realizimi duhet tĂ« modelojĂ« me kujdes rastet e pĂ«rdorimit pĂ«r tĂ« arritur performancĂ«n mĂ« tĂ« mirĂ«.
  • TĂ« dhĂ«nat e ndĂ«rlikuara: tabelat mund tĂ« kenĂ« lidhje fizike me njĂ«ra-tjetrĂ«n. Rreshtat e tabelave tĂ« fĂ«mijĂ«ve mund tĂ« lidhen me rreshtat e tabelĂ«s prind. Ky qasje e bĂ«n mĂ« tĂ« shpejtĂ« kĂ«rkimin pĂ«r marrĂ«dhĂ«nie qĂ« mund tĂ« pĂ«rcaktohen gjatĂ« fazĂ«s sĂ« modelimit tĂ« tĂ« dhĂ«nave, pĂ«r shembull, kur lihen bashkĂ« klientĂ«t dhe faturat e tyre.
  • Indeksi: Cloud Spanner mbĂ«shtet indekse sekondarĂ«. Indeksi pĂ«rbĂ«het nga kolonat e indeksuara dhe tĂ« gjitha kolonat e PK. NĂ«se dĂ«shirohet, indeksi gjithashtu mund tĂ« pĂ«rmbajĂ« kolona tĂ« tjera qĂ« nuk janĂ« indeksuar. Indeksi mund tĂ« ndĂ«rthuret me tabelĂ«n prind pĂ«r tĂ« pĂ«rshpejtuar kĂ«rkesat. Ka disa kufizime qĂ« i zbatohen indekseve, pĂ«r shembull, numri maksimal i kolonave shtesĂ« qĂ« ruhet nĂ« indeks. Gjithashtu, kĂ«rkesat pĂ«rmes indekseve mund tĂ« mos jenĂ« aq tĂ« drejtpĂ«rdrejta si nĂ« DBMS-tĂ« e tjera.

«Cloud Spanner zgjedh indeksin automatikisht vetëm në raste të rralla. Veçanërisht, Cloud Spanner nuk zgjedh indeksin sekondar automatikisht nëse kërkesa kërkon ndonjë kolonë që nuk është ruajtur në indeks ».

  • MarrĂ«veshja e Nivelit tĂ« ShĂ«rbimit (SLA): implementim nĂ« njĂ« rajon me SLA prej 99.99%; implementime multiregjionale me SLA prej 99.999%. MegjithĂ«se vetĂ« marrĂ«veshja e nivelit tĂ« shĂ«rbimit Ă«shtĂ« vetĂ«m njĂ« marrĂ«veshje dhe jo njĂ« garanci, besoj se punonjĂ«sit e Google kanĂ« disa tĂ« dhĂ«na tĂ« sakta pĂ«r tĂ« bĂ«rĂ« njĂ« deklaratĂ« tĂ« tillĂ« serioze. (PĂ«r referencĂ«, 99.999% do tĂ« thotĂ« 26.3 sekonda mosfunksionimi nĂ« muaj.)
  • MĂ« shumĂ«: https://cloud.google.com/spanner/

Shënim: Projekti Apache Tephra shton mbështetje të zgjeruar për transaksionet në Apache HBase (tani gjithashtu i implementuar në Apache Phoenix si një version beta).

3. Vlerësimi ynë

Pra, tĂ« gjithĂ« kemi lexuar deklaratat e Google rreth avantazheve tĂ« Cloud Spanner — pothuajse shkallĂ«zim horizontal tĂ« pakufizuar me ruajtjen e njĂ« konsistencĂ« tĂ« lartĂ« dhe njĂ« SLA shumĂ« tĂ« lartĂ«. MegjithĂ«se kĂ«to kĂ«rkesa, nĂ« çdo rast, janĂ« jashtĂ«zakonisht tĂ« vĂ«shtira pĂ«r t'u arritur, qĂ«llimi ynĂ« nuk ishte t'i mohonim ato. NĂ« vend tĂ« kĂ«saj, le tĂ« pĂ«rqendrohemi nĂ« gjĂ«ra tĂ« tjera qĂ« shqetĂ«sojnĂ« shumicĂ«n e pĂ«rdoruesve tĂ« databazĂ«s: saktĂ«sia dhe lehtĂ«sia e pĂ«rdorimit.

Ne e vlerësuam Cloud Spanner si një zëvendësim për Sharded MySQL

Google Cloud SQL dhe Amazon AWS RDS, dy nga sistemet më të njohura OLTP në tregun e cloud, ofrojnë një gamë të gjerë funksionesh. Megjithatë, për të shkallëzuar këto databaza përtej madhësisë së një njësi, do t'ju nevojitet të realizoni ndarjen e aplikacioneve. Ky qasje krijon kompleksitet shtesë si për aplikacionet ashtu edhe për administrimin. Ne shqyrtuam se si Spanner përshtatet në skenarin e kombinuar të disa segmenteve në një instancë dhe cilat funksione (nëse ka) mund të duhet të sakrifikoni.

Përkrahja për SQL, DML dhe DDL, si dhe konektorët dhe bibliotekat?

Së pari, kur filloni me ndonjë databazë, duhet të krijoni një model të të dhënave. Nëse mendoni se mund të lidheni me JDBC Spanner me mjetin tuaj të preferuar SQL, do të zbuloni se mund të kërkoni të dhënat tuaja me të, por nuk mund ta përdorni për të krijuar tabela ose për të bërë ndryshime (DDL) apo operacione të çdo lloji për futje/ri-aktualizim/zhbllokim (DML). JDBC zyrtar nga Google nuk mbështet asnjërin prej tyre.

«Aktualisht, drejtuesit nuk mbështesin operatorët DML ose DDL».
Dokumentacioni i Spanner

Me konsolĂ«n GCP, situata nuk Ă«shtĂ« mĂ« e mirĂ« — mund tĂ« dĂ«rgoni vetĂ«m kĂ«rkesa SELECT. FatmirĂ«sisht, ekziston njĂ« drejtues JDBC me mbĂ«shtetje pĂ«r DML dhe DDL nga komuniteti, duke pĂ«rfshirĂ« transaksionet. github.com/olavloite/spanner-jdbc. NdĂ«rsa ky drejtues Ă«shtĂ« jashtĂ«zakonisht i dobishĂ«m, mungesa e njĂ« drejtuesi JDBC tĂ« vetin nga Google Ă«shtĂ« e çuditshme. FatmirĂ«sisht, Google ofron njĂ« mbĂ«shtetje tĂ« gjerĂ« pĂ«r bibliotekat klienti (tĂ« bazuara nĂ« gRPC): C#, Go, Java, node.js, PHP, Python dhe Ruby.

Përdorimi pothuajse i detyrueshëm i API-ve të personalizuara të Cloud Spanner (për shkak të mungesës së DDL dhe DML në JDBC) çon në disa kufizime për zonat e lidhura të kodit, siç janë grupet e lidhjes ose kornizat e lidhjes së bazës së të dhënave (p.sh., Spring MVC). Si zakonisht, kur përdoret JDBC, mund të zgjidhni lirisht grupin e preferuar të lidhjes (p.sh., HikariCP, DBCP, C3PO etj.) që është testuar dhe funksionon mirë. Në rastin e API-ve të personalizuara të Spanner, ne duhet të mbështetemi në kornizat/grupet e lidhjes/sesionet që kemi krijuar vetë.

Struktura e orientuar mbi çelësin primar (PK) i lejon Cloud Spanner të ketë një akses shumë të shpejtë në të dhëna përmes PK-së, por gjithashtu shkakton disa probleme me kërkesat.

  • Nuk mund ta pĂ«rditĂ«soni vlerĂ«n e çelĂ«sit primar; sĂ« pari duhet tĂ« fshini regjistrimin me PK-nĂ« origjinale dhe ta ri-insertoni atĂ« me vlerĂ«n e re. (Kjo Ă«shtĂ« e ngjashme me databazat e tjera tĂ« orientuara mbi PK/ mekanizmat e ruajtjes.)
  • Cdo operator UPDATE dhe DELETE duhet tĂ« specifikojĂ« PK-nĂ« nĂ« WHERE, pĂ«r rrjedhojĂ«, nuk mund tĂ« ketĂ« operatorĂ« DELETE tĂ« zbrazĂ«t — gjithmonĂ« duhet tĂ« ketĂ« njĂ« nĂ«nkĂ«rkesĂ«, pĂ«r shembull: UPDATE xxx WHERE id IN (SELECT id FROM table1)
  • Mungon opsioni pĂ«r auto-increment ose diçka tĂ« ngjashme qĂ« vendos njĂ« sekuencĂ« pĂ«r fushĂ«n PK. PĂ«r ta bĂ«rĂ« kĂ«tĂ« tĂ« funksionojĂ«, vlera pĂ«rkatĂ«se duhet tĂ« krijohet nĂ« anĂ«n e aplikacionit.

Indekset sekondare?

Google Cloud Spanner ka mbështetje të integruar për indekset sekondare. Kjo është një veçori shumë e këndshme, e cila nuk është gjithmonë e pranishme në teknologjitë e tjera. Apache Kudu aktualisht nuk mbështet fare indekset sekondare, ndërsa Apache HBase nuk i mbështet indekset drejtpërdrejt, por mund të shtojë ato përmes Apache Phoenix.

Indeksit në Kudu dhe HBase mund të modelohen si një tabelë të veçantë me përbërje të ndryshme të çelësave primarë, por atomizmi i operacioneve që kryhen me tabelën prind dhe tabelat indeks lidhura, duhet të zbatohet në nivel aplikacioni dhe nuk është triviale në një implementim të saktë.

Siç u përmend në shqyrtimin e Cloud Spanner, indeksat e tij mund të ndryshojnë nga ata të MySQL. Prandaj, duhet të tregohet kujdes i veçantë gjatë ndërtimit të pyetjeve dhe profilizimit për të siguruar që përdoret indeksi i duhur atje ku nevojitet.

Pamjet?

Një objekt shumë i njohur dhe i dobishëm në bazën e të dhënave janë pamjet. Ato mund të jenë të dobishme për një sërë rastesh përdorimi; dy të preferuarat e mia janë niveli i abstraksionit logjik dhe niveli i sigurisë. Fatkeqësisht, Cloud Spanner nuk mbështet pamjet. Megjithatë, kjo vetëm pjesërisht na kufizon, pasi për lejet e aksesit nuk ka detaje në nivelin e kolonave, ku pamjet mund të jenë një zgjidhje e pranueshme.

Në dokumentacionin e Cloud Spanner në seksionin që përshkruan detallisht kuotat dhe kufizimet (spanner/quotas), ka, në veçanti, ka një, që mund të jetë problematike për disa aplikacione: Cloud Spanner nga kutia ka një kufizim maksimal prej 100 bazash të dhënash për instancë. Duke qenë se kjo mund të bëhet një pengesë serioze për një bazë të dhënash që është menduar të shkallëzohet mbi 100 baza të dhënash. Fatmirësisht, pas bisedës me përfaqësuesin tonë teknik në Google, zbuluam se ky limit mund të rritet praktikisht në çdo vlerë përmes shërbimit të mbështetjes së Google.

Mbështetje për zhvillimin?

Cloud Spanner ofron një mbështetje relativisht të mirë për gjuhët e programimit për të punuar me API-në e tij. Bibliotekat zyrtare të mbështetura janë në fushën e C#, Go, Java, node.js, PHP, Python dhe Ruby. Dokumentacioni është mjaft i detajuar, por, si në rastin e teknologjive të tjera të përparuara, komuniteti është mjaft i vogël në krahasim me teknologjitë më të njohura të bazave të dhënash, gjë që mund të çojë në rritjen e kohës së kaluar për zgjidhjen e rasteve më pak të zakonshme të përdorimit ose problemeve.

Pra, çfarë thoni për mbështetjen për zhvillimin lokal?

Nuk gjetëm një mënyrë për të krijuar një instancë Cloud Spanner në ambientin lokal. Ajo që kemi arritur më afër është imazhi Docker CockroachDB, i cili në parim ngjason, por në praktikë ndikon ndjeshëm. Për shembull, CockroachDB mund të përdorë PostgreSQL JDBC. Duke qenë se ambienti i zhvillimit duhet të jetë sa më afër ambientit të prodhimit, Cloud Spanner nuk është ideal, pasi duhet të mbështeteni në një instancë të plotë Spanner. Për të kursyer kosto, mund të zgjidhni një instancë për një rajon.

Përkrahja e administratës?

Krijimi i një instancë Cloud Spanner është shumë i thjeshtë. Thjesht duhet të zgjidhni midis krijimit të një instancë multirajonale ose për një rajon të vetëm, të specifikoni rajonin(e) dhe numrin e nyjeve. Më pak se brenda një minute, instanca do të nisë dhe do të jetë gati për funksionim.

Disa metrika elementare janë direkt të disponueshme në faqen Spanner në konsolën Google. Pamje më të detajuara janë të disponueshme përmes Stackdriver, ku gjithashtu mund të vendosni kufij metrikash dhe politika njoftimi.

Qasje në burime?

MySQL ofron konfigurime shumë të gjera dhe shumë të detajuara për lejet/rolet e përdoruesve. Mund të konfigurohet lehtësisht qasja në një tabelë të caktuar ose madje edhe në një nëngrup të thjeshtë të kolonave të saj. Cloud Spanner përdor mjetin Google Identity & Access Management (IAM), i cili lejon vendosjen e politikave dhe lejeve vetëm në një nivel shumë të lartë. Opcioni më i detajuar është leja në nivelin e bazës së të dhënave, e cila nuk përshtatet në shumicën e rasteve prodhuese. Kjo kufizim ju detyron të shtoni masa të mëtejshme sigurie në kodin tuaj, infrastrukturën ose të dyja për të parandaluar përdorimin e paautorizuar të burimeve Spanner.

Kopje rezervë?

Thjesht duke folur, nuk ka kopje rezervë në Cloud Spanner. Ndërsa kërkesat e larta të SLA të Google mund të garantojnë që nuk do të humbasë asnjë të dhënë për shkak të dështimeve të pajisjeve apo bazës së të dhënave, gabimeve njerëzore, defekteve të aplikacioneve, etj., të gjithë e dimë rregullin: disponueshmëria e lartë nuk zëvendëson një strategji të arsyeshme për kopjimin e të dhënave. Aktualisht, mënyra e vetme për të bërë backup të të dhënave është transmetimi i tyre programatik nga baza e të dhënave në një ambient të veçantë ruajtjeje.

Cila është performanca e kërkesave?

Për ngarkimin e të dhënave dhe testimin e kërkesave, kemi përdorur Yahoo! Cloud Serving Benchmark. Në tabelën më poshtë është paraqitur ngarkesa e punës B YCSB me një raport leximi 95% dhe shkruani 5%.

Google Cloud Spanner: i mirë, i keq, i shëmtuar

* Testi i ngarkesës u zhvillua në motorin e llogaritjes (CE) n1-standard-32 (32 vCPU, 120 GB RAM), dhe instanca testuese kurrë nuk ishte ngushtesa në testime.
** Numri maksimal i fijeve në një instancë YCSB është 400. Kishte nevojë për të ekzekutuar gjashtë instanca paralele të testeve YCSB, për të arritur një total prej 2400 fijeve.

Duke rezultatet e testeve, veçanĂ«risht kombinimi i ngarkesĂ«s sĂ« procesorit dhe TPS, e shohim qartĂ« se Cloud Spanner shkallĂ«zohet mjaft mirĂ«. Ngarkesa e madhe, e krijuar nga numri i madh i thread-eve, kompensohet nga numri i madh i nyjeve nĂ« klasterin Cloud Spanner. NdĂ«rsa vonesa duket mjaft e lartĂ«, veçanĂ«risht kur punojmĂ« me 2400 thread-e, mund tĂ« kĂ«rkohet ripĂ«rsĂ«ritje e testeve me 6 instanca mĂ« tĂ« vogla tĂ« motorit kompjuterik pĂ«r tĂ« marrĂ« numra mĂ« tĂ« saktĂ«. Çdo instancĂ« do tĂ« ekzekutojĂ« njĂ« test YCSB nĂ« vend tĂ« njĂ« instance tĂ« madhe CE me 6 teste paralele. KĂ«shtu, do tĂ« jetĂ« mĂ« e lehtĂ« tĂ« dallosh vonesat e kĂ«rkesave tĂ« Cloud Spanner nga vonesat e shtuara nga lidhja rrjetore midis Cloud Spanner dhe instancĂ«s CE, ku ekzekutohet testi.

Si performon Cloud Spanner si OLAP?

Particionimi?

Ndarja e të dhënave në segmente fizikisht dhe/ose logjikisht të pavarura, të quajtura particione, është një koncept shumë i popullarizuar që i përket shumicës së mekanizmave OLAP. Particionet mund të përmirësojnë ndjeshëm performancën e pyetjeve dhe mbështetje të bazës së të dhënave. Një shqyrtim më i thellë i particioneve do të merrej në një artikull të veçantë, prandaj le të përmendim thjesht rëndësinë e një skeme ndarjeje dhe nënndarjeje. Mundësia për të ndarë të dhënat në particione dhe madje më tej në nënparticione është çelësi për performancën e pyetjeve analitike.

Cloud Spanner nuk mbështet particionet si të tilla. Ai ndan të dhënat brenda në atë që quhet ndarje-e bazuar në intervalet e çelësit primar. Ndarja kryhet automatikisht për të balancuar ngarkesën në klasterin e Cloud Spanner. Një funksion shumë i dobishëm i Cloud Spanner është ndarja e ngarkesës bazë të tabelës prind (tabelës që nuk alternohet me një tjetër). Spanner përcakton automatikisht nëse ndarje të dhënat që lexohen më shpesh janë më shumë se të dhënat në të tjera ndarje-at, dhe mund të marrë vendimin për ndarjen e mëtejshme. Kështu, mund të angazhohen më shumë nyje në kërkesë, duke rritur gjithashtu efektivitetin e kapacitetit të transmetimit.

Duke ngarkuar të dhënat?

Mënyra Cloud Spanner për ngarkimin e të dhënave është e njëjtë si me ngarkimin normal. Për të arritur performancën maksimale, ju nevojitet të ndiqni disa rekomandime, duke përfshirë:

  • Shkruani tĂ« dhĂ«nat tuaja sipas çelĂ«sit kryesor.
  • Ndarini ato nĂ« 10*numri i nyjeve seksione tĂ« veçanta.
  • Krijoni njĂ« grup detyrash pune qĂ« ngarkojnĂ« tĂ« dhĂ«nat paralelisht.

Me një ngarkesë të tillë të dhënash, të gjitha nyjet e Cloud Spanner përdoren.

Ne përdorëm ngarkesën A YCSB për të gjeneruar një grup të dhënash prej 10M rreshtash.

Google Cloud Spanner: i mirë, i keq, i shëmtuar

* Testi i ngarkesës u krye në motorin llogaritor n1-standard-32 (32 vCPU, 120 GB memorie), dhe instanca testuese nuk ishte asnjëherë ngushticë në testime.
** Konfigurimi me 1 nyjë nuk rekomandohet për ngarkesa prodhimi të çdo lloji.

Si përmendëm më lart, Cloud Spanner përpunon automatikisht ndarjet në varësi të ngarkesës së tyre, kështu që rezultatet përmirësohen pas disa përsëritjeve të njëpasnjëshme të testit. Rezultatet e paraqitura këtu janë rezultatet më të mira që kemi marrë. Duke shikuar numrat më sipër, ne mund të shohim se si Cloud Spanner (mirë) shkallëzohet me rritjen e numrit të nyjeve në klaster. Numrat që janë theksuar paraqesin vonesa mesatare jashtëzakonisht të ulëta, të cilat kontrastojnë me rezultatet e ngarkesave të përziera (95% për lexim dhe 5% për shkrim), siç përshkruhet në seksionin më lart.

Shkallëzim?

Rritja dhe ulja e numrit të nyjeve në Cloud Spanner është një detyrë që realizohet me një klik. Nëse dëshironi të ngarkoni shpejt të dhënat, mund të merrni parasysh rritjen e instancës deri në maksimum (në rastin tonë, kjo ishte 25 nyje në rajonin SHBA-LINDJE), dhe pastaj të ulni numrin e nyjeve që përshtaten me ngarkesën tuaj të zakonshme, pas që të gjitha të dhënat janë në bazën e të dhënave, duke pasur parasysh kufizimin 2 TB/një nyje.

Na u kujdesëm për këtë kufi edhe me një bazë të dhënash shumë më të vogël. Pas disa testimeve të ngarkesës, baza jonë e të dhënave kishte një madhësi prej rreth 155 GB, dhe kur e reduktuam në një instancë me 1 nyje, morëm gabimin e mëposhtëm:

Google Cloud Spanner: i mirë, i keq, i shëmtuar

Na arriti të zvogëlojmë shkallën nga 25 në 2 instanca, por u bllokuam në dy nyje.

Rritja dhe zvogëlimi i numrit të nyjeve në klasterin Cloud Spanner mund të automatizohet përmes REST API. Kjo mund të jetë veçanërisht e dobishme për të reduktuar ngarkesat e rritura mbi sistem në orët e ngarkesës.

Cila është performanca e pyetjeve OLAP?

Fillimisht planifikonim të dedikonim një kohë të konsiderueshme për të vlerësuar këtë pjesë të Spanner. Pas disa SELECT COUNT, menjëherë kuptuam se testimi do të ishte i shkurtër dhe se Spanner NUK do të ishte i përshtatshëm si një motor OLAP. Pavarësisht nga numri i nyjeve në klaster, një thjeshtësi për të numëruar radhët në një tabelë prej 10M radhësh zgjati nga 55 në 60 sekonda. Për më tepër, çdo pyetje që kërkonte një volum më të madh memorie për ruajtjen e rezultateve ndërmjetësore përfundoi me gabimin OOM.

SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M vlera tĂ« veçanta) -> SpoolingHashAggregateIterator shkoi jashtĂ« memories gjatĂ« rreshtit tĂ« ri.

Disa numra për kërkesat TPC-H mund të gjenden në artikullin e Todd Lipkonit Nosql-kudu-spanner-slides.html, prezantimet 42 dhe 43. Këto numra përputhen me rezultatet tona të veta (për fat të keq).

Google Cloud Spanner: i mirë, i keq, i shëmtuar

4. Konkluzionet tona

Duke marrë parasysh gjendjen aktuale të karakteristikave të Cloud Spanner, është e vështirë të imagjinohet si një zëvendësim i thjeshtë për një zgjidhje ekzistuese OLTP, veçanërisht kur nevojat tuaja do të tejkalojnë atë. Do të duhej të investohej një kohë e konsiderueshme për të ndërtuar një zgjidhje që merr parasysh disavantazhet e Cloud Spanner.

Kur filluam vlerësimin e Cloud Spanner, prisnim që funksionalitetet e tij të menaxhimit të ishin në nivelin e njëjtë ose, të paktën, jo shumë larg zgjidhjeve të tjera të Google SQL. Por u befasuam nga mungesa e plotë e kopjeve rezervë dhe kontrolli shumë i kufizuar i qasjes në burime. Pa përmendur mungesën e pamjeve, mungesën e një ambienti lokal zhvillimi, sekuenca të pambështetura, JDBC pa mbështetje për DML dhe DDL dhe aq më tepër.

Pra, ku dhe të shkojë ai që ka nevojë të shkallëzojë një bazë të dhënash transaksionesh? Duket se në treg ende nuk ka një zgjidhje të vetme që të përshtatet për të gjitha rastet e përdorimit. Ekzistojnë shumë zgjidhje me kod të mbyllur dhe të hapur (disa prej të cilave përmenden në këtë artikull), çdo njëra prej të cilave ka pikat e saj të forta dhe të dobëta, por asnjëra nuk ofron SaaS me SLA 99,999% dhe një nivel të lartë koherencash. Nëse një nivel i lartë SLA është qëllimi juaj kryesor, dhe nuk keni prirje të krijoni një zgjidhje tuajën për disa mjedise të reve, Cloud Spanner mund të jetë zgjidhja që po kërkoni. Por duhet të jeni në dijeni për të gjitha kufizimet e tij.

PĂ«r tĂ« qenĂ« tĂ« drejtĂ«, duhet theksuar se Cloud Spanner u lĂ«shua pĂ«r pĂ«rdorim tĂ« pĂ«rgjithshĂ«m vetĂ«m nĂ« pranverĂ«n e vitit 2017, prandaj Ă«shtĂ« e arsyeshme tĂ« pritet qĂ« disa nga disavantazhet e tij aktuale mund tĂ« zhduken nĂ« tĂ« ardhmen (shpresoj), dhe kur tĂ« ndodhĂ« kjo, mund tĂ« sjellĂ« ndryshime tĂ« mĂ«dha. NĂ« fund tĂ« fundit, Cloud Spanner nuk Ă«shtĂ« thjesht njĂ« projekt anĂ«sor pĂ«r Google. Google e pĂ«rdor atĂ« si bazĂ« pĂ«r produkte tĂ« tjera. Dhe kur Google sĂ« fundmi zĂ«vendĂ«soi Megastore nĂ« Google Cloud Storage me Cloud Spanner, kjo e dha mundĂ«sinĂ« qĂ« Google Cloud Storage tĂ« bĂ«het plotĂ«sisht i sinkronizuar pĂ«r listat e objekteve nĂ« shkallĂ« globale (e cila ende nuk i referohet) Amazon’s S3).

Pra, shpresë ende ka
 ne shpresojmë.

Këtu përfundojmë. Siç tha autori i artikullit, ne gjithashtu vazhdojmë të shpresojmë, çfarë mendoni ju për këtë? Shkruani në komentet

Të gjithë është të mirëpritur të vizitojnë webinarin falas ku do të flasim në detaje për kursin «AWS për zhvilluesit» nga OTUS.

Burimi: habr.com

Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« đŸ”„ Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« | ProHoster