Përshëndetje, Khabrovites. Tradicionalisht, ne vazhdojmë të ndajmë materiale interesante në prag të fillimit të kurseve të reja. Sot, posaçërisht për ju, ne kemi përkthyer një artikull rreth Google Cloud Spanner, në kohën e duhur që të përkojë me fillimin e kursit .
Botuar fillimisht në .
Si një kompani që ofron një sërë zgjidhjesh POS të bazuara në cloud për shitësit me pakicë, restorantet dhe tregtarët online në mbarë botën, Lightspeed përdor disa lloje të ndryshme të platformave të bazës së të dhënave për një sërë rastesh përdorimi transaksionesh, analitike dhe kërkimi. Secila prej këtyre platformave të bazës së të dhënave ka pikat e veta të forta dhe të dobëta. Prandaj, kur Google prezantoi Cloud Spanner në treg - veçori premtuese që nuk shihen në botën e bazave të të dhënave relacionale, të tilla si shkallëzueshmëria horizontale praktikisht e pakufizuar dhe një marrëveshje e nivelit të shërbimit 99,999% (SLA) , Nuk mund ta humbnim rastin ta kishim në dorë!
Për të dhënë një përmbledhje gjithëpërfshirëse të përvojës sonë me Cloud Spanner, si dhe kriteret e vlerësimit që kemi përdorur, ne do të mbulojmë temat e mëposhtme:
- Kriteret tona të vlerësimit
- Cloud Spanner me pak fjalë
- Vlerësimi ynë
- Gjetjet tona
1. Kriteret tona të vlerësimit
Përpara se të zhytemi në specifikat e Cloud Spanner, ngjashmëritë dhe ndryshimet e tij me zgjidhjet e tjera në treg, le të flasim fillimisht për rastet kryesore të përdorimit që kishim parasysh kur shqyrtonim se ku të vendosim Cloud Spanner në infrastrukturën tonë:
- Si një zëvendësim për zgjidhjen (mbizotëruese) tradicionale të bazës së të dhënave SQL
- Si një zgjidhje OLTP e aktivizuar me OLAP
Shenim: Për lehtësi krahasimi, ky artikull krahason Cloud Spanner me variantet MySQL të familjeve të zgjidhjeve GCP Cloud SQL dhe Amazon AWS RDS.
Duke përdorur Cloud Spanner si një zëvendësim për një zgjidhje tradicionale të bazës së të dhënave SQL
Në mjedis tradicionale bazat e të dhënave, kur koha e përgjigjes për një pyetje të bazës së të dhënave afrohet apo edhe tejkalon pragjet e paracaktuara të aplikacionit (kryesisht për shkak të rritjes së numrit të përdoruesve dhe/ose kërkesave), ka disa mënyra për të reduktuar kohën e përgjigjes në nivele të pranueshme. Megjithatë, shumica e këtyre zgjidhjeve përfshijnë ndërhyrje manuale.
Për shembull, hapi i parë që duhet ndërmarrë është të shikoni cilësimet e ndryshme të bazës së të dhënave të lidhura me performancën dhe t'i rregulloni ato që të përputhen më mirë me modelet e skenarit të përdorimit të aplikacionit. Nëse kjo nuk mjafton, mund të zgjidhni të shkallëzoni bazën e të dhënave vertikalisht ose horizontalisht.
Rritja e një aplikacioni përfshin përditësimin e shembullit të serverit, zakonisht duke shtuar më shumë procesorë/bërthama, më shumë RAM, ruajtje më të shpejtë, etj. Shtimi i më shumë burimeve harduerike rezulton në rritjen e performancës së bazës së të dhënave, e matur kryesisht në transaksione për sekondë, dhe vonesën e transaksionit për sistemet OLTP. Sistemet e bazës së të dhënave relacionale (që përdorin një qasje me shumë fije) të tilla si MySQL shkallëzohen mirë vertikalisht.
Ka disa të meta për këtë qasje, por më e dukshme është madhësia maksimale e serverit në treg. Pasi të arrihet kufiri më i madh i Instancës së Serverit, mbetet vetëm një shteg: zvogëloni.
Scale-out është një qasje që shton më shumë serverë në një grup për të rritur në mënyrë ideale performancën në mënyrë lineare ndërsa shtohen më shumë serverë. Shumica tradicionale sistemet e bazës së të dhënave nuk shkallëzohen mirë ose nuk shkallëzohen fare. Për shembull, MySQL mund të zvogëlohet për operacionet e leximit duke shtuar lexues skllav, por nuk mund të zvogëlohet 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.
I paraqitur plotësisht DBMS si shërbim duhet vlerësuar nga këndvështrime të ndryshme. Si bazë, ne morëm DBMS-të më të njohura në cloud - për Google, GCP Cloud SQL dhe për Amazon, AWS RDS. Në vlerësimin tonë, ne u fokusuam në kategoritë e mëposhtme:
- Hartimi i veçorive: shtrirja SQL, DDL, DML; bibliotekat/lidhëset e lidhjeve, mbështetja e transaksioneve, e kështu me radhë.
- Mbështetja e zhvillimit: Lehtësia e zhvillimit dhe testimit.
- Mbështetje Administrative: Menaxhimi i instancës, si p.sh. shkallëzimi/ulja dhe përmirësimi i rasteve; SLA, rezervë dhe rikuperim; siguria/kontrolli i aksesit.
Përdorimi i "Cloud Spanner" si një zgjidhje OLTP e aktivizuar me OLAP
Ndërsa Google nuk deklaron në mënyrë eksplicite se Cloud Spanner është për analitikë, ai ndan disa atribute me motorë të tjerë si Apache Impala & Kudu dhe YugaByte që janë krijuar për ngarkesat e punës OLAP.
Edhe nëse do të kishte vetëm një shans të vogël që Cloud Spanner të përfshinte një motor HTAP (Përpunim Hibrid Transaksional/Analitik) me shkallë të qëndrueshme me një grup (pak a shumë) veçorish të përdorshëm OLAP, ne mendojmë se do të meritonte vëmendjen tonë.
Me këtë në mendje, ne shikuam kategoritë e mëposhtme:
- Mbështetja e ngarkimit të të dhënave, indekseve dhe ndarjes
- Performanca e pyetjeve dhe DML
2. Kthesë e reve me pak fjalë
Google Spanner është një sistem i menaxhimit të bazës së të dhënave relacionale të grupuar (RDBMS) që Google përdor për disa nga shërbimet e veta. Google e bëri atë të disponueshme publikisht për përdoruesit e Platformës së resë kompjuterike të Google në fillim të vitit 2017.
Këtu janë disa nga atributet e Cloud Spanner:
- Grup RDBMS shumë konsistent dhe i shkallëzueshëm: Përdor sinkronizimin e kohës së harduerit për të siguruar qëndrueshmërinë e të dhënave.
- Mbështetja e transaksioneve ndërmjet tabelave: Transaksionet mund të përfshijnë shumë tabela - jo domosdoshmërisht të kufizuara në një tabelë të vetme (ndryshe nga Apache HBase ose Apache Kudu).
- Tabelat e bazuara në çelësin primar: Të gjitha tabelat duhet të kenë një çelës primar (PC) të deklaruar, i cili mund të përbëhet nga kolona të shumta tabele. Të dhënat tabelare ruhen sipas rendit të kompjuterit, gjë që e bën atë shumë efikas dhe të shpejtë për kërkimet në PC. Ashtu si me sistemet e tjera të bazuara në PC, zbatimi duhet të modelohet kundër rasteve të përdorimit të paracaktuar në mënyrë që të arrihet .
- Tabelat me vija: Tabelat mund të kenë varësi fizike nga njëra-tjetra. Rreshtat e tabelës fëmijë mund të përputhen me rreshtat e tabelës mëmë. Kjo qasje përshpejton kërkimin e marrëdhënieve që mund të përcaktohen në fazën e modelimit të të dhënave, për shembull, kur vendosni klientët dhe faturat e tyre së bashku.
- Indekset: Cloud Spanner mbështet indekset dytësore. Një indeks përbëhet nga kolona të indeksuara dhe të gjitha kolonat e PC. Opsionale, indeksi mund të përmbajë edhe kolona të tjera jo të indeksuara. Indeksi mund të ndërlidhet me tabelën mëmë për të shpejtuar pyetjet. Për indekset zbatohen disa kufizime, të tilla si numri maksimal i kolonave shtesë që mund të ruhen në një indeks. Gjithashtu, pyetjet përmes indekseve mund të mos jenë aq të drejtpërdrejta sa në RDBMS të tjera.
"Cloud Spanner zgjedh një indeks automatikisht vetëm në raste të rralla. Në veçanti, Cloud Spanner nuk zgjedh automatikisht një indeks dytësor nëse pyetja kërkon ndonjë kolonë që nuk është ruajtur në '.
- Marrëveshja e Nivelit të Shërbimit (SLA): Vendosja e një rajoni të vetëm me 99,99% SLA; vendosje në shumë rajone me 99,999% SLA. Ndërsa SLA në vetvete është vetëm një marrëveshje dhe jo një garanci e asnjë lloji, unë besoj se njerëzit e Google kanë disa të dhëna të vështira për të bërë një pretendim kaq të fortë. (Për referencë, 99,999% do të thotë 26,3 sekonda pushim shërbimi në muaj.)
- Më shumë:
Shenim: Projekti Apache Tephra shton mbështetje të avancuar të transaksioneve në Apache HBase (gjithashtu i zbatuar tani në Apache Phoenix si beta).
3. Vlerësimi ynë
Pra, të gjithë i kemi lexuar deklaratat e Google për përfitimet e Cloud Spanner - shkallëzim horizontal praktikisht i pakufizuar duke ruajtur qëndrueshmëri të lartë dhe një SLA shumë të lartë. Edhe pse këto pretendime janë, në çdo rast, jashtëzakonisht të vështira për t'u arritur, qëllimi ynë nuk ishte që t'i hedhim poshtë. Në vend të kësaj, le të përqendrohemi në gjëra të tjera për të cilat kujdesen shumica e përdoruesve të bazës së të dhënave: barazia dhe përdorshmëria.
Ne e vlerësuam Cloud Spanner si një zëvendësim për Sharded MySQL
Google Cloud SQL dhe Amazon AWS RDS, dy nga bazat e të dhënave më të njohura OLTP në tregun e cloud, kanë një grup shumë të madh funksionesh. Megjithatë, për të shkallëzuar këto baza të dhënash përtej madhësisë së një nyje të vetme, duhet të kryeni ndarjen e aplikacionit. Kjo qasje krijon kompleksitet shtesë si për aplikimet ashtu edhe për administrimin. Ne shikuam se si Spanner përshtatet në skenarin e kombinimit të disa copëzave në një shembull dhe cilat veçori (nëse ka) mund të duhet të sakrifikohen.
Mbështetje për SQL, DML dhe DDL, si dhe lidhësin dhe bibliotekat?
Së pari, kur filloni me ndonjë bazë të dhënash, duhet të krijoni një model të dhënash. Nëse mendoni se mund ta lidhni 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 një tabelë ose përditësim (DDL) ose ndonjë insert/përditësim/fshirje operacionet (DML). JDBC zyrtare e Google nuk e mbështet as.
"Driferët nuk mbështesin aktualisht deklaratat DML ose DDL."
Dokumentacioni i çelësit
Situata nuk është më e mirë me tastierën GCP - mund të dërgoni vetëm pyetje SELECT. Për fat të mirë, ekziston një drejtues JDBC me mbështetje DML dhe DDL nga komuniteti, duke përfshirë transaksionet . Ndërsa ky drejtues është jashtëzakonisht i dobishëm, mungesa e drejtuesit JDBC të Google është befasuese. Për fat të mirë, Google ofron mbështetje mjaft të gjerë të bibliotekës së klientit (bazuar 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) rezulton në disa kufizime për fushat përkatëse të kodit, si p.sh. bashkimi i lidhjeve ose kornizat e lidhjes së bazës së të dhënave (si Spring MVC). Në përgjithësi, kur përdorni JDBC, jeni i lirë të zgjidhni grupin tuaj të preferuar të lidhjes (p.sh. HikariCP, DBCP, C3PO, etj.) që është i testuar dhe funksionon mirë. Në rastin e API-ve të personalizuara të Spanner, ne duhet të mbështetemi në kornizat / grupet e lidhjeve / sesioneve që kemi krijuar vetë.
Dizajni i orientuar nga çelësi primar (PC) lejon që Cloud Spanner të jetë shumë i shpejtë kur akseson të dhënat përmes kompjuterit, por gjithashtu prezanton disa çështje pyetjesh.
- Ju nuk mund të përditësoni vlerën e një çelësi primar; Së pari duhet të fshini hyrjen origjinale të kompjuterit dhe ta rifusni atë me vlerën e re. (Kjo është e ngjashme me motorët e tjerë të bazës së të dhënave/ruajtjes së orientuar nga PC.)
- Çdo deklaratë UPDATE dhe DELETE duhet të specifikojë PC-në në WHERE, prandaj, nuk mund të ketë bosh DELETE të gjitha deklaratat - duhet të ketë gjithmonë një nënpyetje, për shembull: UPDATE xxx WHERE IN (ZGJEDH id-në NGA tabela1)
- Mungesa e një opsioni të rritjes automatike ose diçka e ngjashme që përcakton sekuencën për fushën e PC. Që kjo të funksionojë, vlera përkatëse duhet të krijohet në anën e aplikacionit.
Indekset dytësore?
Google Cloud Spanner ka mbështetje të integruar për indekset dytësore. Kjo është një veçori shumë e bukur që nuk është gjithmonë e pranishme në teknologjitë e tjera. Apache Kudu aktualisht nuk i mbështet fare indekset dytësore dhe Apache HBase nuk i mbështet indekset drejtpërdrejt, por mund t'i shtojë ato përmes Apache Phoenix.
Indekset në Kudu dhe HBase mund të modelohen si një tabelë e veçantë me përbërje të ndryshme të çelësave kryesorë, por atomiciteti i operacioneve të kryera në tabelën mëmë dhe në tabelat e indeksit përkatës duhet të kryhet në nivelin e aplikacionit dhe nuk është e parëndësishme për t'u zbatuar në mënyrë korrekte.
Siç u përmend në rishikimin e Cloud Spanner, indekset e tij mund të ndryshojnë nga indekset e MySQL. Kështu, duhet pasur kujdes i veçantë në ndërtimin dhe profilizimin e pyetjeve për të siguruar që indeksi i saktë të përdoret aty ku nevojitet.
Përfaqësimi?
Një objekt shumë popullor dhe i dobishëm në një bazë të dhënash janë pamjet. Ato mund të jenë të dobishme për një numër të madh rastesh përdorimi; dy të preferuarat e mia janë shtresa e abstraksionit logjik dhe shtresa e sigurisë. Fatkeqësisht, Cloud Spanner NUK i mbështet pamjet. Megjithatë, kjo na kufizon vetëm pjesërisht, pasi nuk ka asnjë shkallëzim të nivelit të kolonës për lejet e aksesit ku pamjet mund të jenë një zgjidhje e pranueshme.
Shihni dokumentacionin e Cloud Spanner për një seksion që përshkruan kuotat dhe kufijtë (), ka një në veçanti që mund të jetë problematik për disa aplikacione: Cloud Spanner out of box ka një maksimum prej 100 bazash të dhënash për shembull. Natyrisht, kjo mund të jetë një pengesë e madhe për një bazë të dhënash që është krijuar për t'u shkallëzuar në mbi 100 baza të të dhënave. Për fat të mirë, pasi folëm me përfaqësuesin tonë teknik të Google, zbuluam se ky kufi mund të rritet pothuajse në çdo vlerë përmes Mbështetjes së Google.
Mbështetje për zhvillim?
Cloud Spanner ofron mbështetje mjaft të mirë të gjuhës programuese për të punuar me API-në e saj. Bibliotekat e mbështetura zyrtarisht janë në fushën e C#, Go, Java, node.js, PHP, Python dhe Ruby. Dokumentacioni është mjaft i detajuar, por si me teknologjitë e tjera më të avancuara, komuniteti është mjaft i vogël në krahasim me teknologjitë më të njohura të bazës së të dhënave, gjë që mund të rezultojë në më shumë kohë të shpenzuar për raste të përdorimit ose probleme më pak të zakonshme.
Po në lidhje me mbështetjen e zhvillimit lokal?
Nuk kemi gjetur një mënyrë për të krijuar një shembull të "Cloud Spanner" brenda ambienteve. Më e afërta që kemi është një imazh Docker e cila është e ngjashme në parim, por shumë e ndryshme në praktikë. Për shembull CockroachDB mund të përdorë PostgreSQL JDBC. Meqenëse mjedisi i zhvillimit duhet të jetë sa më afër mjedisit të prodhimit, Cloud Spanner nuk është ideal sepse duhet të mbështeteni në një shembull të plotë Spanner. Për të kursyer kostot, mund të zgjidhni një shembull të vetëm rajonal.
Mbështetja e administratës?
Krijimi i një shembulli Cloud Spanner është shumë i thjeshtë. Ju vetëm duhet të zgjidhni midis krijimit të një shembulli shumë-rajonal ose të një rajoni të vetëm, të specifikoni rajonin(et) dhe numrin e nyjeve. Në më pak se një minutë, shembulli do të funksionojë.
Disa metrika elementare janë të disponueshme drejtpërdrejt në faqen e "Kthesës" në "Panelin e Google". Pamje më të detajuara ofrohen nëpërmjet Stackdriver, ku mund të vendosni gjithashtu pragjet metrike dhe politikat e alarmit.
Akses në burime?
MySQL ofron parametra të gjerë dhe shumë të grimcuar të lejeve/rolit të përdoruesit. Mund të personalizoni lehtësisht aksesin në një tabelë specifike, apo edhe vetëm një nëngrup të kolonave të saj. Cloud Spanner përdor mjetin e Google Identity & Access Management (IAM), i cili ju lejon vetëm të vendosni politikat dhe lejet në një nivel shumë të lartë. Opsioni më i grimcuar është leja e nivelit të bazës së të dhënave, e cila nuk përshtatet në shumicën e rasteve të prodhimit. Ky kufizim ju detyron të shtoni masa shtesë sigurie në kodin tuaj, infrastrukturën ose të dyja për të parandaluar përdorimin e paautorizuar të burimeve të Spanner.
Rezervimet?
Për ta thënë thjesht, nuk ka kopje rezervë në Cloud Spanner. Ndërsa kërkesat e larta SLA të Google mund të garantojnë që të mos humbni asnjë të dhënë për shkak të dështimeve të harduerit ose bazës së të dhënave, gabimeve njerëzore, defekteve të aplikacionit, etj. Të gjithë e dimë rregullin: disponueshmëria e lartë nuk është zëvendësim për një strategji rezervë inteligjente. Aktualisht, mënyra e vetme për të rezervuar të dhënat është transmetimi i tyre në mënyrë programore nga baza e të dhënave në një mjedis të veçantë ruajtjeje.
Kërkoni performancën?
Ne përdorëm Yahoo! për të ngarkuar të dhëna dhe për të testuar kërkesat. Standardi i shërbimit në renë kompjuterike. Tabela e mëposhtme tregon ngarkesën e punës B YCSB me një raport leximi 95% ndaj 5% të shkrimit.
* Testi i ngarkesës u krye në n1-standard-32 Compute Engine (CE) (32 vCPU, 120 GB memorie) dhe shembulli i testit nuk ishte kurrë pengesa në teste.
** Numri maksimal i thread-eve në një shembull YCSB është 400. Në total, gjashtë shembuj paralelë të testeve YCSB duhej të ekzekutoheshin për të marrë gjithsej 2400 thread.
Duke parë rezultatet e standardeve, në veçanti kombinimin e ngarkesës së CPU dhe TPS, mund të shohim qartë se Cloud Spanner shkallëzohet mjaft mirë. Ngarkesa e madhe e krijuar nga një numër i madh thread-sh kompensohet nga një numër i madh nyjesh në grupin Cloud Spanner. Megjithëse vonesa duket mjaft e lartë, veçanërisht kur funksionon në 2400 fije, mund të jetë e nevojshme të ritestohet me 6 instanca më të vogla të motorit llogaritës për të marrë numra më të saktë. Çdo shembull do të ekzekutojë një test YCSB në vend të një shembulli të madh CE me 6 teste paralele. Kjo do ta bëjë më të lehtë dallimin midis vonesave të kërkesave të "Cloud Spanner" dhe vonesave të shtuara nga lidhja e rrjetit midis "Cloud Spanner" dhe shembullit CE që kryen testin.
Si funksionon Cloud Spanner si OLAP?
Ndarje?
Ndarja e të dhënave në segmente të pavarura fizikisht dhe/ose logjikisht, të quajtura ndarje, është një koncept shumë popullor që gjendet në shumicën e motorëve OLAP. Ndarjet mund të përmirësojnë shumë performancën e pyetjeve dhe mirëmbajtjen e bazës së të dhënave. Hulumtimi i mëtejshëm në ndarje do të ishte një artikull(a) më vete, kështu që le të përmendim vetëm rëndësinë e të pasurit një skemë ndarjeje dhe nënndarjeje. Aftësia për të ndarë të dhënat në ndarje dhe edhe më tej në nënndarje është çelësi për performancën e pyetjeve analitike.
Cloud Spanner nuk i mbështet ndarjet në vetvete. Ai i ndan të dhënat nga brenda në të ashtuquajturat i ndarë-s bazuar në diapazonin e çelësit primar. Ndarja bëhet automatikisht për të balancuar ngarkesën në grupin Cloud Spanner. Një veçori shumë e dobishme e Cloud Spanner është ndarja e ngarkesës bazë të një tabele mëmë (një tabelë që nuk është e ndërthurur me një tjetër). Çelësi zbulon automatikisht nëse përmban i ndarë të dhëna që lexohen më shpesh se të dhënat në të tjera i ndarë-ah, dhe mund të vendosë për një ndarje të mëtejshme. Kështu, më shumë nyje mund të përfshihen në një kërkesë, e cila gjithashtu rrit efektivisht xhiron.
Po ngarkoni të dhënat?
Metoda Cloud Spanner për të dhënat me shumicë është e njëjtë si për një ngarkim të rregullt. Për performancë maksimale, duhet të ndiqni disa udhëzime, duke përfshirë:
- Renditni të dhënat tuaja sipas çelësit kryesor.
- Ndajini ato me 10*numri i nyjeve seksione individuale.
- Krijoni një grup detyrash të punonjësve që ngarkojnë të dhënat paralelisht.
Kjo ngarkesë e të dhënave përdor të gjitha nyjet e "Cloud Spanner".
Ne përdorëm ngarkesën e punës A YCSB për të gjeneruar një grup të dhënash rreshti 10 milion.
* Testi i ngarkesës u krye në motorin kompjuterik n1-standard-32 (32 vCPU, 120 GB memorie) dhe shembulli i testit nuk ishte kurrë pengesa në teste.
** Një konfigurim me 1 nyje nuk rekomandohet për asnjë ngarkesë prodhimi.
Siç u përmend 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ëritjesh të njëpasnjëshme të testit. Rezultatet e paraqitura këtu janë rezultatet më të mira që kemi marrë. Duke parë numrat e mësipërm, ne mund të shohim se si Cloud Spanner shkallëzohet (mirë) ndërsa numri i nyjeve në grup rritet. Numrat që bien në sy janë vonesa mesatare jashtëzakonisht e ulët, e cila është në kontrast me rezultatet nga ngarkesat e përziera të punës (95% lexim dhe 5% shkrim) siç përshkruhet në seksionin e mësipërm.
Shkallëzimi?
Rritja dhe zvogëlimi i numrit të nyjeve të Cloud Spanner është një detyrë me një klikim. Nëse dëshironi të ngarkoni të dhënat shpejt, mund të mendoni të rritni instancën në maksimum (në rastin tonë ishin 25 nyje në rajonin SHBA-LINDJE) dhe më pas të zvogëloni numrin e nyjeve të përshtatshme për ngarkesën tuaj normale pas të gjitha të dhënave në bazën e të dhënave, duke mbajtur parasysh kufirin 2 TB/nyje.
Na u kujtua ky kufi edhe me një bazë të dhënash shumë më të vogël. Pas disa testeve të ngarkimit, databaza jonë ishte me madhësi rreth 155 GB dhe kur u zvogëlua në një shembull me 1 nyje, morëm gabimin e mëposhtëm:
Ne ishim në gjendje të zvogëlojmë nga 25 në 2 raste, por kemi ngecur në dy nyje.
Rritja dhe zvogëlimi i numrit të nyjeve në një grup Cloud Spanner mund të automatizohet duke përdorur API-në REST. Kjo mund të jetë veçanërisht e dobishme për reduktimin e ngarkesës së shtuar në sistem gjatë orëve të ngarkuara.
Performanca e pyetjes OLAP?
Fillimisht kemi planifikuar t'i kushtojmë kohë të konsiderueshme vlerësimit tonë të Spanner në këtë pjesë. Pas disa NUMËRIVE SELECT, menjëherë kuptuam se testi do të ishte i shkurtër dhe se Spanner NUK do të ishte një motor i përshtatshëm për OLAP. Pavarësisht nga numri i nyjeve në grup, thjesht zgjedhja e numrit të rreshtave në një tabelë rreshtash 10M mori 55 deri në 60 sekonda. Gjithashtu, çdo pyetje që kërkonte më shumë memorie për të ruajtur rezultatet e ndërmjetme dështoi me një gabim OOM.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Disa numra për pyetjet TPC-H mund të gjenden në artikullin e Todd Lipcon , rrëshqitjet 42 dhe 43. Këta numra janë në përputhje me rezultatet tona (për fat të keq).
4. Gjetjet tona
Duke pasur parasysh gjendjen aktuale të veçorive të Cloud Spanner, është e vështirë ta shohësh atë si një zëvendësim të thjeshtë për një zgjidhje ekzistuese OLTP, veçanërisht kur nevojat tuaja e tejkalojnë atë. Një kohë e konsiderueshme do të duhet të shpenzohet për të krijuar një zgjidhje rreth mangësive të Cloud Spanner.
Kur filluam të vlerësonim Cloud Spanner, prisnim që veçoritë e tij të menaxhimit të ishin të barabarta, ose të paktën jo larg zgjidhjeve të tjera të Google SQL. Por ne u befasuam nga mungesa e plotë e kopjeve rezervë dhe kontrolli shumë i kufizuar i aksesit në burime. Për të mos përmendur asnjë pamje, asnjë mjedis zhvillimi lokal, sekuenca të pambështetura, JDBC pa mbështetje DML dhe DDL, e kështu me radhë.
Pra, ku të shkoni për dikë që ka nevojë të shkallëzojë një bazë të dhënash transaksionale? Nuk duket të ketë ende një zgjidhje të vetme në treg që i përshtatet të gjitha rasteve të përdorimit. Ka shumë zgjidhje me burim të mbyllur dhe të hapur (disa prej të cilave janë përmendur në këtë artikull), secila me pikat e forta dhe të dobëta të veta, por asnjëra prej tyre nuk ofron SaaS me një SLA 99,999% dhe një shkallë të lartë konsistence. Nëse një SLA e lartë është qëllimi juaj kryesor dhe nuk jeni të prirur të ndërtoni zgjidhjen tuaj për retë e shumta, Cloud Spanner mund të jetë zgjidhja që po kërkoni. Por ju duhet të jeni të vetëdijshëm për të gjitha kufizimet e tij.
Për të qenë të drejtë, Cloud Spanner u lëshua për publikun vetëm në pranverën e vitit 2017, kështu që është e arsyeshme të pritet që disa nga të metat e tij aktuale mund të zhduken përfundimisht (shpresojmë), dhe kur të ndodhë, mund të jetë një ndryshim i lojës. 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 të Google. Dhe kur Google së fundi zëvendësoi Megastore në Google Cloud Storage me Cloud Spanner, ai lejoi që Google Cloud Storage të bëhej shumë i qëndrueshëm për listat e objekteve në shkallë globale (gjë që ende nuk është rasti për ).
Pra, ka ende shpresë... shpresojmë.
Kjo eshte e gjitha. Ashtu si autori i artikullit, edhe ne vazhdojmë të shpresojmë, por çfarë mendoni për këtë? Shkruani në komente
Ftojmë të gjithë të vizitojnë tonën në të cilën do t'ju tregojmë në detaje rreth kursit nga OTUS.
Burimi: www.habr.com