Kaixo, Khabrovskeko bizilagunak. Ohi bezala, ikastaro berriak hasi aurretik material interesgarria partekatzen jarraitzen dugu. Gaur, bereziki zuretzat, Google Cloud Spanner-i buruzko artikulu bat argitaratu dugu ikastaroaren hasierarekin batera .
Jatorriz urtean argitaratua .
Mundu osoko merkatariei, jatetxeei eta lineako saltzaileei hodeian oinarritutako POS irtenbide ugari eskaintzen dizkien enpresa gisa, Lightspeed-ek hainbat datu-base plataforma mota erabiltzen ditu transakzio, analitiko eta bilaketa-kasu ezberdinetarako. Datu-base-plataforma horietako bakoitzak bere indarguneak eta ahuleziak ditu. Horregatik, Google-k Cloud Spanner merkatuan aurkeztu zuenean - datu-base erlazionalen munduan ikusten ez diren ezaugarri itxaropentsuak, hala nola eskalagarritasun horizontal ia mugagabea eta % 99,999ko zerbitzu-maila-hitzarmena (SLA), β ezin genuen eskua sartzeko aukera galdu!
Cloud Spanner-ekin dugun esperientziaren ikuspegi orokorra emateko, baita erabili ditugun ebaluazio-irizpideei ere, gai hauek landuko ditugu:
- Gure ebaluazio irizpideak
- Cloud Spanner laburbilduz
- Gure balorazioa
- Gure aurkikuntzak
1. Gure ebaluazio irizpideak
Cloud Spanner-en zehaztasunetan murgildu aurretik, merkatuko beste soluzio batzuekiko dituen antzekotasun eta desberdintasunak, lehenik eta behin, hitz egin dezagun kontuan izan ditugun erabilera kasu nagusiei buruz gure azpiegituran Cloud Spanner non zabaldu aztertzerakoan:
- SQL datu-baseen irtenbide tradizionalaren (nagusiena) ordezko gisa
- Nola OLTP irtenbidea OLAP laguntzarekin
Oharra: Sinpletasuna eta konparaketa errazteko, artikulu honek Cloud Spanner GCP Cloud SQL eta Amazon AWS RDS soluzio familien MySQL aldaerekin alderatzen du.
Cloud Spanner erabiltzea SQL datu-baseen irtenbide tradizional baten ordezko gisa
Ingurunean tradizionala datu-baseetan, datu-basearen kontsultaren erantzun-denbora aurrez zehaztutako aplikazio-atalaseetara hurbiltzen denean edo are gainditzen duenean (batez ere erabiltzaile eta/edo eskaera-kopurua handitzearen ondorioz), erantzun-denbora maila onargarrietara murrizteko hainbat modu daude. Hala ere, irtenbide horietako gehienek eskuzko esku-hartzea dakar.
Adibidez, eman beharreko lehen urratsa errendimenduarekin erlazionatutako datu-basearen parametro desberdinak aztertzea eta aplikazioaren erabilera-ereduak hoberen bat etor daitezen doitzea da. Hori gutxi balitz, datu-basea bertikalki edo horizontalki eskala dezakezu.
Aplikazio bat bertikalean eskalatzeak zerbitzariaren instantzia berritzea dakar, normalean prozesadore/nukleo gehiago, RAM gehiago, biltegiratze azkarragoa eta abar gehituz. Hardware-baliabide gehiago gehitzeak datu-basearen errendimendua areagotzen du, batez ere segundoko transakzioetan neurtuta, eta transakzio-latentzia OLTP sistemetan. Erlazio datu-base sistemak (hari anitzeko ikuspegia erabiltzen dutenak), hala nola, MySQL modu bertikalean ondo eskalatzen dira.
Planteamendu honek hainbat desabantaila ditu, baina agerikoena merkatuan dagoen zerbitzariaren gehienezko tamaina da. Zerbitzariaren instantzia handienaren mugara iritsitakoan, aukera bakarra geratzen da: eskalatze horizontala.
Eskalatze horizontala kluster bati zerbitzari gehiago gehitzen zaizkion ikuspegi bat da, hobe da errendimendua linealki handituz zerbitzari kopurua gehitzen den heinean. Gehiengoa tradizionala Datu-base sistemak ez dira horizontalki ondo eskalatzen edo ez dira batere eskalatzen. Adibidez, MySQL-k horizontalki eskalatu dezake irakurketa eragiketetarako irakurgailu esklaboak gehituz, baina ezin du horizontalki eskalatu idazketetarako.
Bestalde, bere izaera dela eta, Cloud Spanner-ek erraz eskala dezake horizontalki esku-hartze minimoarekin.
Erabat aurkeztuta DBMS zerbitzu gisa ertz ezberdinetatik baloratu behar da. Oinarri gisa, hodeiko DBMS ezagunenak hartu genituen: Google-rentzat, GCP Cloud SQLrentzat eta Amazonentzat, AWS RDS-entzat. Gure ebaluazioan honako kategoria hauetan zentratu gara:
- Ezaugarrien mapaketa: hedadura SQL, DDL, DML; konexio liburutegiak/konektoreak, transakzio-laguntza, etab.
- Garapenerako laguntza: garapen eta proba errazak.
- Administrazioaren laguntza: instantzien kudeaketa - adibidez, eskalatzea/behera eta instantzien berritzea; SLA, babeskopia eta berreskurapena; segurtasun/sarbide kontrola.
Cloud Spanner erabiltzea OLAP gaitutako OLTP irtenbide gisa
Google-k esplizituki Cloud Spanner prozesatzeko analitikorako diseinatuta dagoenik esaten ez duen arren, atributu batzuk partekatzen ditu beste motor batzuekin, hala nola Apache Impala & Kudu eta YugaByte, OLAP lan-kargaretarako diseinatuta daudenak.
Cloud Spanner-ek HTAP (transakzio/analitikoen prozesamendu hibridoa) motor koherente bat sartzeko aukera txikia bazen ere OLAP ezaugarri multzo erabilgarri batekin (gutxiago edo gutxiago), gure arreta merezi lukeela uste dugu.
Hori kontuan hartuta, honako kategoria hauek aztertu ditugu:
- Datuak kargatzeko, indizeak eta partizioak egiteko laguntza
- Kontsulten errendimendua eta DML
2. Cloud Spanner laburbilduz
Google Spanner datu-base erlazionalak kudeatzeko sistema multzokatua da (RDBMS), Google-k bere zerbitzuetarako erabiltzen duena. Google-k orokorrean eskuragarri jarri zuen Google Cloud Platform erabiltzaileentzat 2017 hasieran.
Hona hemen Cloud Spanner-en atributu batzuk:
- Oso koherentea den RDBMS Cluster eskalagarria: hardwarearen denbora-sinkronizazioa erabiltzen du datuen koherentzia bermatzeko.
- Taulen arteko transakzioen euskarria: transakzioek hainbat taula izan ditzakete, ez da zertan mahai bakar batera mugatu (Apache HBase edo Apache Kudu ez bezala).
- Gako nagusietan oinarritutako taulak: taula guztiek deklaratutako gako nagusi bat (PC) izan behar dute, eta taulako hainbat zutabez osatuta egon daiteke. Datu taularrak ordenagailuaren ordenan gordetzen dira, eta oso eraginkorra eta azkarra da ordenagailua bilatzeko. PCan oinarritutako beste sistema batzuek bezala, inplementazioa aurrez diseinatutako erabilera kasuak kontuan hartuta modelatu behar da lortzeko .
- Marradun taulak: Taulek elkarren arteko menpekotasun fisikoak izan ditzakete. Haur-taula bateko errenkadak taula nagusi bateko errenkadekin pareka daitezke. Planteamendu honek datuen modelizazio fasean identifikatu daitezkeen harremanen bilaketa azkartzen du, hala nola bezeroak eta haien fakturak elkarlokatzea.
- Indizeak: Cloud Spanner-ek bigarren mailako indizeak onartzen ditu. Indizea indexatutako zutabeek eta PCko zutabe guztiek osatzen dute. Nahi izanez gero, indizeak indexatutako beste zutabe batzuk ere izan ditzake. Indizea taula nagusiarekin gurutzatu daiteke kontsultak bizkortzeko. Indizeei hainbat murrizketa aplikatzen zaizkie, esate baterako, indizean gordetako zutabe gehigarrien gehienezko kopurua. Gainera, baliteke indizeen bidezko kontsultak ez izatea beste RDBMS batzuetan bezain erraza.
"Cloud Spanner-ek indize bat automatikoki hautatzen du kasu bakanetan soilik. Hain zuzen ere, Cloud Spanner-ek ez du automatikoki bigarren indizerik hautatzen, kontsulta batek gordeta ez dauden zutabeak eskatzen baditu. '.
- Zerbitzu-maila-hitzarmena (SLA): % 99,99ko SLA-a duen eskualde batean hedatzea; eskualde anitzeko inplementazioak % 99,999 SLArekin. SLA bera akordio bat besterik ez den eta inolako berme bat ez den arren, uste dut Google-ko pertsonek datu gogorrak dituztela hain erreklamazio sendoa egiteko. (Erreferentzia gisa, % 99,999ak hilean 26,3 segundoko zerbitzua erabilgarri ez izatea esan nahi du.)
- gehiago:
Oharra: Apache Tephra proiektuak transakzio-laguntza hobetua gehitzen dio Apache HBase-ri (orain Apache Phoenix-en ere inplementatuta dago beta gisa).
3. Gure balorazioa
Beraz, denok irakurri ditugu Google-ren aldarrikapenak Cloud Spanner-en abantailei buruz: eskala horizontal ia mugagabea koherentzia handia eta SLA oso altua mantenduz. Baldintza hauek, nolanahi ere, lortzea oso zaila den arren, gure helburua ez zen horiek gezurtatzea. Horren ordez, datu-baseen erabiltzaile gehienei axola zaizkien beste gauza batzuetan zentratu gaitezen: parekotasuna eta erabilgarritasuna.
Cloud Spanner Sharded MySQL-ren ordezko gisa ebaluatu dugu
Google Cloud SQL eta Amazon AWS RDS, hodeiko merkatuko OLTP DBMS ezagunenetako bi, ezaugarri multzo oso handia dute. Hala ere, datu-base hauek nodo bakar baten tamainaz gainditzeko, aplikazioen partizioa egin behar duzu. Ikuspegi honek konplexutasun gehigarria sortzen du bai aplikazioetarako bai administraziorako. Spanner zati bat instantzia bakarrean konbinatzeko eszenatokian nola sartzen den aztertu genuen eta zer ezaugarri (halakorik badago) sakrifikatu beharko liratekeen aztertu genuen.
SQL, DML eta DDL euskarria, baita konektorea eta liburutegiak ere?
Lehenik eta behin, edozein datu-baserekin hastean, datu-eredu bat sortu behar duzu. JDBC Spanner zure gogoko SQL tresnara konekta dezakezula uste baduzu, zure datuak kontsulta ditzakezula ikusiko duzu, baina ezin dituzu erabili taula bat sortzeko edo aldatzeko (DDL) edo txertatzeko/eguneratu/ezabatzeko. eragiketak (DML). Google-ren JDBC ofizialak ez du hauetako bat ere onartzen.
"Gaur egun gidariek ez dituzte DML edo DDL adierazpenak onartzen".
Giltzarako Dokumentazioa
Egoera ez da hobea GCP kontsolarekin - SELECT kontsultak bakarrik bidali ditzakezu. Zorionez, JDBC kontrolatzaile bat dago komunitatearen DML eta DDL laguntzarekin, transakzioak barne . Gidari hau oso erabilgarria den arren, Google-ren JDBC kontrolatzailerik ez izatea harrigarria da. Zorionez, Google-k bezeroen liburutegietarako laguntza nahiko zabala eskaintzen du (gRPC-n oinarrituta): C#, Go, Java, node.js, PHP, Python eta Ruby.
Cloud Spanner API pertsonalizatuen ia derrigorrezko erabilerak (JDBC-n DDL eta DML falta dela eta) muga batzuk eragiten ditu erlazionatutako kode-eremuetarako, hala nola konexio-biltegiak edo datu-baseen lotura-esparruak (adibidez, Spring MVC). Normalean, JDBC erabiltzean, probatutako eta ondo funtzionatzen duen zure gogoko konexio-biltegia aukeratzeko (adibidez, HikariCP, DBCP, C3PO, etab.). Spanner API pertsonalizatuen kasuan, guk geuk sortu ditugun esparru/lotura-talde/saioetan oinarritu behar dugu.
Lehen gakoaren (PC) zentratutako diseinuari esker, Cloud Spanner-i oso azkarra da ordenagailu bidez datuak atzitzen dituenean, baina kontsulta-arazo batzuk ere sartzen ditu.
- Ezin duzu gako nagusiaren balioa eguneratu; Lehenik eta behin, sarrera ezabatu behar duzu jatorrizko ordenagailutik eta berriro sartu balio berriarekin. (Hau ordenagailura zuzendutako beste datu-base/biltegiratze-motor batzuen antzekoa da.)
- UPDATE eta DELETE instrukzioak PC zehaztu behar du WHERE atalean, beraz, ezin dira hutsik egon DELETE sententzia guztiak - beti egon behar da azpikontsulta bat, adibidez: UPDATE xxx WHERE id IN (HAUSTU id FROM taula1)
- Automatikoki gehitzeko aukerarik eza edo PCaren eremuaren sekuentzia ezartzen duen antzeko ezer. Honek funtziona dezan, dagokion balioa sortu behar da aplikazio aldean.
Bigarren mailako indizeak?
Google Cloud Spanner-ek bigarren mailako indizeetarako laguntza integratua du. Ezaugarri oso polita da, beste teknologietan beti ez dagoena. Apache Kudu-k gaur egun ez ditu bigarren mailako indizeak onartzen, eta Apache HBase-k ez ditu zuzenean indizeak onartzen, baina Apache Phoenix bidez gehi ditzake.
Kudu eta HBase-ko indizeak gako nagusien osaera desberdina duen taula bereizi gisa modelatu daitezke, baina taula gurasoan eta erlazionatutako indize-tauletan egindako eragiketen atomotasuna aplikazio mailan egin behar da eta ez da hutsala behar bezala inplementatzea.
Cloud Spanner-en berrikuspenean esan bezala, bere indizeak MySQL-en indizeetatik desberdinak izan daitezke. Horregatik, arreta berezia jarri behar da kontsultak eta profilak egitean, indize egokia behar den lekuan erabiltzen dela ziurtatzeko.
Irudikapena?
Datu-base batean oso ezaguna eta erabilgarria den objektu bat bistak dira. Erabilera-kasu askotarako erabilgarriak izan daitezke; Nire bi gogokoenak abstrakzio-geruza logikoa eta segurtasun-geruza dira. Zoritxarrez, Cloud Spanner-ek EZ ditu ikustaldiak onartzen. Hala ere, horrek partzialki soilik mugatzen gaitu, zutabe mailan sarbide-baimenetarako zehaztasunik ez dagoelako, non ikuspegiak irtenbide bideragarriak izan daitezkeen.
Ikusi Cloud Spanner dokumentazioa kuotak eta murrizketak zehazten dituen atal baterako (), bada bat bereziki aplikazio batzuentzat problematikoa izan daitekeena: Cloud Spanner-ek 100 datu-base gehienez instantzia bakoitzeko muga du. Jakina, hau 100 datu-base baino gehiagora eskalatzeko diseinatuta dagoen datu-base baterako oztopo handia izan daiteke. Zorionez, gure Google-ren ordezkari teknikoarekin hitz egin ondoren, muga hori ia edozein baliotara igo daitekeela jakin genuen Google-ren laguntzaren bidez.
Garapenerako laguntza?
Cloud Spanner-ek programazio-lengoaia nahiko duina eskaintzen du bere APIarekin lan egiteko. Ofizialki onartzen diren liburutegiak C#, Go, Java, node.js, PHP, Python eta Ruby arloetan daude. Dokumentazioa nahiko zehatza da, baina beste teknologia aurreratuekin gertatzen den bezala, komunitatea nahiko txikia da datu-baseen teknologi ezagunenekin alderatuta, eta horrek denbora gehiago eman dezake ez hain ohikoak diren erabilera kasuak edo arazoak konpontzen.
Beraz, zer gertatzen da tokiko garapena laguntzea?
Ez dugu aurkitu Cloud Spanner instantzia lokalean sortzeko modurik. Lortu genuen gauzarik hurbilena Docker irudi bat izan zen. , printzipioz antzekoa dena, baina praktikan oso ezberdina. Adibidez, CockroachDB-k PostgreSQL JDBC erabil dezake. Garapen-inguruneak ekoizpen-ingurunetik ahalik eta hurbilen egon behar duenez, Cloud Spanner ez da aproposa, Spanner instantzia oso batean oinarritu behar baitu. Kostuak aurrezteko, eskualde bakarreko instantzia bat hauta dezakezu.
Administrazioaren laguntza?
Cloud Spanner instantzia bat sortzea oso erraza da. Eskualde anitzeko edo eskualde bakarreko instantzia bat sortzea besterik ez duzu aukeratu, eskualdea(k) eta nodo kopurua zehaztu. Minutu bat baino gutxiago barru, zure instantzia martxan egongo da.
Zenbait metrika rudimentario zuzenean eskura daitezke Google Consoleko Spanner orrialdetik. Ikuspegi zehatzagoak Stackdriver-en bidez eskuragarri daude, non atalase metrikoak eta alerta-politikak ere ezar ditzakezu.
Baliabideetarako sarbidea?
MySQL-k ezarpen zabalak eta oso zehatzak eskaintzen ditu erabiltzailearen baimen/roletarako. Taula zehatz baterako sarbidea erraz konfigura dezakezu, edo baita bere zutabeen azpimultzo bat ere. Cloud Spanner-ek Google-ren Identity & Access Management (IAM) tresna erabiltzen du, politikak eta baimenak oso maila altuan ezartzeko aukera ematen duena. Aukerarik zehatzena datu-base-mailako bereizmena da, produkzioko erabilera kasu gehienetan sartzen ez dena. Muga honek segurtasun neurri gehigarriak gehitzera behartzen zaitu kodean, azpiegituran edo bietan Spanner baliabideak baimenik gabe erabiltzea ekiditeko.
Babeskopiak?
Besterik esateko, ez dago babeskopiarik Cloud Spanner-en. Google-ren SLA eskakizun handiek hardware edo datu-baseen hutsegiteen, giza akatsen, aplikazioen akatsen eta abarrengatik daturik ez galtzea bermatu dezaketen arren. Denok ezagutzen dugu araua: erabilgarritasun handia ez da soinuaren babeskopia estrategiaren ordezkoa. Gaur egun, datuen babeskopia egiteko modu bakarra datu-base batetik biltegiratze-ingurune batera programatikoki transmititzea da.
Errendimendua kontsultatu nahi duzu?
Yahoo! erabili dugu datuak kargatzeko eta kontsultak probatzeko. Hodei-zerbitzariaren erreferentzia. Beheko taulak YCSB B lan-karga erakusten du, % 95eko irakurketa eta % 5eko idazketa ratioarekin.
* Karga-proba n1-standard-32 Compute Engine (CE) (32 vCPU, 120 GB memoria) exekutatu zen, eta proba-instantzia ez zen inoiz botika-lepoa izan probetan.
** YCSB instantzia bakarreko gehienezko hari kopurua 400 da. Guztira YCSB proben sei instantzia paralelo exekutatu behar izan dira guztira 2400 hari lortzeko.
Erreferentziako emaitzei, batez ere CPU kargaren eta TPSaren konbinazioari erreparatuta, argi ikusten dugu Cloud Spanner nahiko ondo eskalatzen dela. Hari kopuru handiak sortzen duen karga astuna Cloud Spanner klusterreko nodo kopuru handiarekin konpentsatzen da. Latentzia nahiko altua dirudien arren, batez ere 2400 harirekin exekutatzen denean, baliteke konputazio-motorreko 6 instantzia txikiagoekin berriro probatzea beharrezkoa izatea zenbaki zehatzagoak lortzeko. Instantzia bakoitzak YCSB proba bat egingo du CE instantzia handi baten ordez 6 proba paralelo dituena. Horrela, errazagoa izango da Cloud Spanner eskaeraren latentzia eta Cloud Spanner-en eta proba egiten ari den CE instantziaren arteko sare-konexioak gehitutako latentzia bereiztea.
Nola funtzionatzen du Cloud Spanner-ek OLAP gisa?
Banaketa?
Datuak fisikoki eta/edo logikoki independenteak diren segmentuetan banatzea, partizioak izenekoak, oso kontzeptu ezaguna da OLAP motor gehienetan. Partizioek kontsulten errendimendua eta datu-baseen mantentzea nabarmen hobetu ditzakete. Partizioan sakontzea aparteko artikulua(k) izango litzateke, beraz, aipa dezagun zatiketa eta azpi-partizio eskema bat izatearen garrantzia. Datuak partizioetan eta are gehiago azpipartizioetan banatzeko gaitasuna funtsezkoa da kontsulta analitikoen errendimendurako.
Cloud Spanner-ek ez ditu partizioak onartzen. Datuak barnean deitzen direnetan banatzen ditu zatitu-s gako nagusien barrutietan oinarrituta. Partizioa automatikoki egiten da Cloud Spanner kluster batean karga orekatzeko. Cloud Spanner-en ezaugarri oso erabilgarria da taula nagusiaren oinarrizko karga zatitzea (beste batekin tartekatuta ez dagoen taula). Spanner-ek automatikoki detektatzen du duen ala ez zatitu besteetan datuak baino maizago irakurtzen diren datuak zatitu-ah, eta bereizketa gehiago erabaki dezake. Horrela, eskaera batean nodo gehiagok parte hartu ahal izango dute, eta horrek ere eraginkortasunez handitzen du errendimendua.
Datuak kargatzen?
Datu masiboetarako Cloud Spanner metodoa karga arrunterako berdina da. Errendimendu handiena lortzeko, jarraibide batzuk jarraitu behar dituzu, besteak beste:
- Ordenatu zure datuak gako nagusiaren arabera.
- Zatitu 10*nodo kopurua atal bereiziak.
- Sortu datuak paraleloan kargatzen dituen lan-zeregin multzo bat.
Datuen karga honek Cloud Spanner nodo guztiak erabiltzen ditu.
YCSB lan-karga A erabili dugu 10M errenkadako datu-multzo bat sortzeko.
* Karga-proba n1-standard-32 konputazio-motorrean exekutatu zen (32 vCPU, 120 GB memoria), eta proba-instantzia ez zen inoiz botika-lepoa izan probetan.
**Nodo bakarreko konfigurazioa ez da gomendatzen ekoizpen-lan kargarako.
Goian esan bezala, Cloud Spanner-ek automatikoki prozesatzen ditu zatiketak beren kargaren arabera, beraz emaitzak hobetzen dira hainbat proba errepikatu ondoren. Hemen aurkezten ditugun emaitzak lortu ditugun emaitzarik onenak dira. Goiko zenbakiei erreparatuz, Cloud Spanner nola eskalatzen den (ondo) ikus dezakegu klusterreko nodo kopurua handitzen den heinean. Nabarmentzen diren zenbakiak batez besteko latentzia oso baxuak dira, lan-karga mistoen emaitzekin kontrajartzen dutenak (% 95 irakurtzen eta % 5 idazten) goiko atalean deskribatzen den moduan.
Eskalatzea?
Cloud Spanner nodo kopurua handitzea eta murriztea klik bakarreko zeregina da. Datuak azkar kargatu nahi badituzu, baliteke zure instantzia ahalik eta gehien handitzea (gure kasuan 25 nodo ziren AEB-EAST eskualdean) eta, ondoren, zure karga arrunterako egokiak diren nodo kopurua murriztea datu guztiak sartzen direnean. datu-basea, 2TB/nodo mugari erreferentzia eginez.
Muga hori gogorarazi ziguten datu-base askoz txikiagoa izanda ere. Karga-probak egin ondoren, gure datu-baseak 155 GB inguruko tamaina zuen, eta 1 nodo instantzia batera eskalatu genuenean, errore hau jaso genuen:
25 instantziatik 2ra eskalatzea lortu genuen, baina bi nodotan geratu ginen.
Cloud Spanner kluster bateko nodo kopurua handitzea eta gutxitzea automatizatu daiteke REST APIa erabiliz. Hau bereziki erabilgarria izan daiteke laneko orduetan sistemaren karga handitzea murrizteko.
OLAP kontsulten errendimendua?
Hasiera batean Spanner-en ebaluazioan denbora kopuru handia ematea aurreikusi genuen zati honetan. Hainbat SELECT COUNT egin ondoren, berehala konturatu ginen probak laburrak izango zirela eta Spanner EZ zela OLAPrako motor egokia izango. Klusterreko nodo kopurua edozein dela ere, 10M errenkada-taulan errenkada-kopurua hautatzeak 55 eta 60 segundo bitartean behar izan zituen. Gainera, tarteko emaitzak gordetzeko memoria gehiago behar zuen edozein kontsultak huts egin du OOM errore batekin.
SELECT COUNT(DISTINCT(field0)) FROM usertable; β (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
TPC-H kontsultetarako zenbaki batzuk Todd Lipcon-en artikuluan aurki daitezke , 42 eta 43 diapositibak. Zenbaki hauek gure emaitzekin bat datoz (zoritxarrez).
4. Gure ondorioak
Cloud Spanner-en funtzioen egungo egoera ikusita, zaila da lehendik dagoen OLTP soluzioaren ordezko soila dela imajinatzea, batez ere zure beharrak gainditzen dituenean. Denbora kopuru handia eman beharko litzateke Cloud Spanner-en gabezien inguruan irtenbide bat eraikitzen.
Cloud Spanner ebaluatzen hasi ginenean, bere kudeaketa-eginbideak Google SQL soluzioen parekoak izatea espero genuen, edo, gutxienez, ez oso urrun egotea. Baina harritu gintuen babeskopien gabeziak eta baliabideetarako sarbidearen kontrol oso mugatua. Zer esanik ez ikuspegirik, garapen lokaleko ingurunerik, onartzen ez diren sekuentziak, DML eta DDL euskarririk gabeko JDBC, etab.
Beraz, nora doa datu-base transakzional bat eskalatu behar duen norbait? Ez dirudi merkatuan erabilera kasu guztietara egokitzen den irtenbide bakarra dagoenik. Itxitako eta kode irekiko irtenbide asko daude (horietako batzuk artikulu honetan aipatzen dira), bakoitzak bere indargune eta ahulguneekin, baina horietako inork ez du eskaintzen %99,999ko SLA eta koherentzia handiko SaaS batekin. SLA altua zure helburu nagusia bada eta ez bazara hodei anitzeko irtenbide pertsonalizatu bat eraikitzeko gogorik, Cloud Spanner izan daiteke bilatzen ari zaren irtenbidea. Baina bere muga guztien berri izan behar duzu.
Zintzoa izateko, Cloud Spanner 2017ko udaberrian bakarrik kaleratu zen jendaurrean, beraz, zentzuzkoa da gaur egungo gabezia batzuk azkenean desagertuko direla (espero dugu), eta hori egiten dutenean, joko-aldaketa bat izan liteke. Azken finean, Cloud Spanner ez da Google-ren alboko proiektu bat. Google-k Google-ren beste produktu batzuen oinarri gisa erabiltzen du. Eta Google-k duela gutxi Megastore Google Cloud Storage-n Cloud Spanner-ekin ordezkatu zuenean, Google Cloud Storage eskala globaleko objektuen zerrendetarako oso koherentea izatea ahalbidetu zuen (oraindik ez da horrela gertatzen). ).
Beraz, oraindik itxaropena dago... espero dugu.
Hori da dena. Artikuluaren egileak bezala, guk ere itxaropenarekin jarraitzen dugu, baina zer deritzozu honi buruz? Idatzi iruzkinetan
Guztiak gure bisitatzera gonbidatzen ditugu horren barruan, ikastaroaren berri zehatz-mehatz emango dizuegu OTUSetik.
Iturria: www.habr.com