Saluton, Ĥabrovskaj loĝantoj. Kiel kutime, ni daŭre kundividas interesan materialon antaŭ la komenco de novaj kursoj. Hodiaŭ, precipe por vi, ni publikigis artikolon pri Google Cloud Spanner por koincidi kun la lanĉo de la kurso .
Origine eldonita en .
Kiel firmao kiu ofertas diversajn nub-bazitajn POS-solvojn al podetalistoj, restoracioj kaj interretaj vendistoj tra la mondo, Lightspeed uzas plurajn malsamajn specojn de datumbazplatformoj por diversaj transakciaj, analizaj kaj serĉuzaj kazoj. Ĉiu el ĉi tiuj datumbazplatformoj havas siajn proprajn fortojn kaj malfortojn.Tial, kiam Google enkondukis Cloud Spanner al la merkato - promesplenaj trajtoj neviditaj en la mondo de interrilataj datumbazoj, kiel praktike senlima horizontala skaleblo kaj 99,999% serva nivelo interkonsento (SLA), — ni ne povis maltrafi la okazon meti la manon sur ĝin!
Por provizi ampleksan superrigardon pri nia sperto kun Cloud Spanner, kaj ankaŭ pri la taksadkriterioj, kiujn ni uzis, ni kovros la sekvajn temojn:
- Niaj taksaj kriterioj
- Cloud Spanner resume
- Nia takso
- Niaj trovoj
1. Niaj taksaj kriterioj
Antaŭ ol plonĝi en la specifaĵoj de Cloud Spanner, ĝiaj similecoj kaj diferencoj kun aliaj solvoj sur la merkato, ni unue parolu pri la ĉefaj uzkazoj, kiujn ni havis en menso, kiam ni pripensis kie disfaldi Cloud Spanner en nia infrastrukturo:
- Kiel anstataŭaĵo por la (ĉefa) tradicia SQL-datumbaza solvo
- Kiel OLTP-solvo kun OLAP-subteno
Notu: Por simpleco kaj facileco de komparo, ĉi tiu artikolo komparas Cloud Spanner kun la MySQL-variaĵoj de la solvfamilioj de GCP Cloud SQL kaj Amazon AWS RDS.
Uzante Cloud Spanner kiel anstataŭaĵon por tradicia SQL-datumbaza solvo
En la medio tradicia datumbazoj, kiam la datumbaza demanda respondtempo alproksimiĝas aŭ eĉ superas antaŭdifinitajn aplikaĵsojlojn (ĉefe pro pliiĝo en la nombro da uzantoj kaj/aŭ petoj), ekzistas pluraj manieroj redukti la respondtempon al akcepteblaj niveloj. Tamen, la plej multaj el ĉi tiuj solvoj implikas manan intervenon.
Ekzemple, la unua paŝo por fari estas rigardi la diversajn afiksajn datumbazajn parametrojn kaj agordi ilin por plej bone kongrui kun aplikaj uzkazaj ŝablonoj. Se tio ne sufiĉas, vi povas elekti skali la datumbazon vertikale aŭ horizontale.
Vertikale grimpi aplikaĵon implicas ĝisdatigi la servilan petskribon, tipe aldonante pli da procesoroj/kernoj, pli da RAM, pli rapida stokado, ktp. Aldonante pli da aparataro-resursoj rezultigas pliigita datumbaza efikeco, mezurita ĉefe en transakcioj en sekundo, kaj transakcia latenteco por OLTP-sistemoj. Rilataj datumbazaj sistemoj (kiuj uzas multfadenan aliron) kiel MySQL bone skalas vertikale.
Estas pluraj malavantaĝoj al ĉi tiu aliro, sed la plej evidenta estas la maksimuma servila grandeco sur la merkato. Post kiam la limo de la plej granda servila kazo estas atingita, restas nur unu opcio: horizontala skalo.
Horizontala skalo estas aliro kie pli da serviloj estas aldonitaj al areto, ideale pliigante efikecon linie kiam la nombro da serviloj estas aldonita. Plimulto tradicia Datumbazsistemoj ne skalas horizontale bone aŭ tute ne skalas. Ekzemple, MySQL povas skali horizontale por legaj operacioj aldonante sklavajn legantojn, sed ne povas skali horizontale por skriboj.
Aliflanke, pro sia naturo, Cloud Spanner povas facile grimpi horizontale kun minimuma interveno.
Plene prezentita DBMS kiel servo devas esti taksita el malsamaj anguloj. Kiel bazo, ni prenis la plej popularajn DBMS en la nubo - por Google, GCP Cloud SQL kaj por Amazon, AWS RDS. En nia takso ni koncentriĝis pri la sekvaj kategorioj:
- Karakterizaĵmapado: amplekso SQL, DDL, DML; konektaj bibliotekoj/konektiloj, transakcia subteno, ktp.
- Disvolva subteno: facila disvolviĝo kaj testado.
- Administrado-subteno: administrado de instancoj - ekzemple, skalo supren/malsupren kaj ĝisdatigi petskribojn; SLA, sekurkopio kaj reakiro; sekureco/alira kontrolo.
Uzante Cloud Spanner kiel OLTP-ebligitan solvon
Dum Google ne eksplicite asertas, ke Cloud Spanner estas desegnita por analiza prilaborado, ĝi dividas iujn atributojn kun aliaj motoroj kiel Apache Impala & Kudu kaj YugaByte, kiuj estas dizajnitaj por OLAP-laborŝarĝoj.
Eĉ se estis nur malgranda ŝanco, ke Cloud Spanner inkluzivis konsekvencan skaleblan HTAP (hibrida transakcia/analitika pretigo) motoron kun (pli-malpli) uzebla OLAP-trajto, ni pensas, ke ĝi estus inda je nia atento.
Konsiderante ĉi tion, ni rigardis la jenajn kategoriojn:
- Subteno pri ŝarĝo de datumoj, indeksoj kaj dispartigo
- Demandu Agadon kaj DML
2. Cloud Spanner resume
Google Spanner estas amasigita interrilata datumbaza administradsistemo (RDBMS) kiun Guglo uzas por pluraj el siaj propraj servoj. Google igis ĝin ĝenerale havebla al uzantoj de Google Cloud Platform frue en 2017.
Jen kelkaj el la atributoj de Cloud Spanner:
- Tre Konsekvenca Skalebla RDBMS-Areto: Uzas aparatan temposinkronigon por certigi datuman konsistencon.
- Trans-tabla transakcia subteno: Transakcioj povas etendi plurajn tablojn - ne nepre limigitaj al ununura tablo (male al Apache HBase aŭ Apache Kudu).
- Tabeloj bazitaj en ĉefa ŝlosilo: Ĉiuj tabeloj devas havi deklaritan ĉefŝlosilon (PC), kiu povas konsisti el pluraj kolumnoj en la tabelo. Tabelaj datumoj estas konservitaj en komputila ordo, igante ĝin tre efika kaj rapida por komputila serĉado. Kiel aliaj komputil-bazitaj sistemoj, la efektivigo devas esti modeligita kun antaŭdizajnitaj uzkazoj en menso por atingi .
- Striitaj tabloj: Tabloj povas havi fizikajn dependecojn unu de la alia. Vicoj en infana tabelo povas esti egalitaj kun vicoj en gepatra tabelo. Ĉi tiu aliro akcelas la serĉon de rilatoj kiuj povas esti identigitaj dum la datummodeliga fazo, kiel ekzemple kunlokigo de klientoj kaj iliaj fakturoj.
- Indeksoj: Cloud Spanner subtenas sekundarajn indeksojn. La indekso konsistas el la indeksitaj kolumnoj kaj ĉiuj komputilaj kolumnoj. Se vi deziras, la indekso ankaŭ povas enhavi aliajn ne-indeksitajn kolumnojn. La indekso povas esti interplektita kun la gepatra tabelo por akceli demandojn. Pluraj restriktoj validas por indeksoj, kiel ekzemple la maksimuma nombro da kromaj kolumnoj stokitaj en la indekso. Ankaŭ, demandoj per indeksoj eble ne estas tiel simplaj kiel en aliaj RDBMSoj.
"Cloud Spanner elektas aŭtomate indekson nur en maloftaj kazoj. Aparte, Cloud Spanner ne aŭtomate elektas sekundaran indekson se demando petas iujn ajn kolumnojn kiuj ne estas stokitaj en ".
- Service Level Agreement (SLA): Deplojo en unu regiono kun SLA de 99,99%; plurregionaj deplojoj kun 99,999% SLA. Kvankam la SLA mem estas nur interkonsento kaj ne ia ajn garantio, mi kredas, ke la homoj ĉe Google havas iujn malfacilajn datumojn por fari tiel fortan aserton. (Por referenco, 99,999% signifas 26,3 sekundojn da servo nehavebleco monate.)
- Pli:
Notu: La Apache Tephra projekto aldonas plibonigitan transakcian subtenon al Apache HBase (ankaŭ nun efektivigita en Apache Phoenix kiel betao).
3. Nia takso
Do, ni ĉiuj legis la asertojn de Google pri la avantaĝoj de Cloud Spanner - preskaŭ senlima horizontala skalo konservante altan konsistencon kaj tre altan SLA. Kvankam ĉi tiuj postuloj estas, ĉiukaze, ege malfacile atingeblaj, nia celo estis ne refuti ilin. Anstataŭe, ni koncentriĝu pri aliaj aferoj, pri kiuj la plej multaj datumbazuzantoj zorgas: egaleco kaj uzebleco.
Ni taksis Cloud Spanner kiel anstataŭaĵon por Sharded MySQL
Google Cloud SQL kaj Amazon AWS RDS, du el la plej popularaj OLTP-DBMS-oj en la nuba merkato, havas tre grandan aron da funkcioj. Tamen, por grimpi ĉi tiujn datumbazojn preter la grandeco de ununura nodo, vi devas fari aplikaĵdispartigon. Ĉi tiu aliro kreas plian kompleksecon por kaj aplikoj kaj administrado. Ni rigardis kiel Spanner konvenas al la scenaro kombini plurajn fragmentojn en ununuran kazon kaj kiajn funkciojn (se ekzistas) eble devas esti oferitaj.
SQL, DML kaj DDL-subteno, same kiel konektilo kaj bibliotekoj?
Unue, kiam vi komencas kun ajna datumbazo, vi devas krei datummodelon. Se vi pensas, ke vi povas konekti JDBC Spanner al via plej ŝatata SQL-ilo, vi trovos, ke vi povas pridemandi viajn datumojn per ĝi, sed vi ne povas uzi ĝin por krei tabelon aŭ modifi (DDL) aŭ ajnan enmeti/ĝisdatigi/forigi. operacioj (DML). La oficiala JDBC de Google ne subtenas neniun el ĉi tiuj.
"Ŝoforoj nuntempe ne subtenas DML aŭ DDL-deklarojn."
Spanner Dokumentado
La situacio ne estas pli bona kun la GCP-konzolo - vi povas nur sendi SELECT-demandojn. Feliĉe ekzistas JDBC-ŝoforo kun subteno por DML kaj DDL de la komunumo, inkluzive de transakcioj . Dum ĉi tiu ŝoforo estas ekstreme utila, la manko de la propra JDBC-ŝoforo de Guglo estas surpriza. Feliĉe, Google ofertas sufiĉe larĝan subtenon por klientbibliotekoj (bazita sur gRPC): C#, Go, Java, node.js, PHP, Python kaj Ruby.
La preskaŭ deviga uzo de Cloud Spanner kutimaj API-oj (pro la manko de DDL kaj DML en JDBC) rezultigas kelkajn limigojn por rilataj kodaj areoj kiel ekzemple konektaj naĝejoj aŭ datumbazaj ligaj kadroj (ekz. Spring MVC). Kutime, kiam vi uzas JDBC, vi rajtas elekti vian plej ŝatatan konekton (ekz. HikariCP, DBCP, C3PO, ktp.), kiu estas testita kaj bone funkcias. En la kazo de kutimaj Spanner-APIoj, ni devas fidi al kadroj/ligantaj naĝejoj/sesioj, kiujn ni mem kreis.
La centra dezajno de la ĉefa ŝlosilo (komputilo) permesas al Cloud Spanner esti tre rapida kiam aliras datumojn per komputilo, sed ankaŭ enkondukas kelkajn demandojn.
- Vi ne povas ĝisdatigi la ĉefŝlosilvaloron; Vi unue devas forigi la eniron de la originala komputilo kaj reenmeti ĝin kun la nova valoro. (Ĉi tio similas al aliaj komputilaj orientitaj datumbazoj/stokaj motoroj.)
- Ajna UPDATE kaj DELETE deklaroj devas specifi PC en la WHERE, tial ne povas esti malplenaj DELETE ĉiuj deklaroj - ĉiam devas esti subdemando, ekzemple: UPDATE xxx WHERE id IN (SELECT id FROM tabelo1)
- Manko de aŭtomata pliiga opcio aŭ io simila, kiu fiksas la sekvencon por la komputila kampo. Por ke ĉi tio funkciu, la responda valoro devas esti kreita ĉe la aplikaĵo.
Sekundaraj indeksoj?
Google Cloud Spanner havas enkonstruitan subtenon por sekundaraj indeksoj. Ĉi tio estas tre bela trajto, kiu ne ĉiam ĉeestas en aliaj teknologioj. Apache Kudu nuntempe tute ne subtenas sekundarajn indeksojn, kaj Apache HBase ne subtenas rekte indeksojn, sed povas aldoni ilin per Apache Phoenix.
Indeksoj en Kudu kaj HBase povas esti modeligitaj kiel aparta tablo kun malsama kunmetaĵo de primaraj ŝlosiloj, sed la atomeco de la operacioj faritaj sur la gepatra tablo kaj rilataj indekstabloj devas esti farita sur la aplikiĝnivelo kaj ne estas bagatela efektivigi ĝuste.
Kiel menciite en la revizio de Cloud Spanner, ĝiaj indeksoj povas diferenci de MySQL-indeksoj. Tial, speciala zorgo devas esti prenita dum konstruado de demandoj kaj profilado por certigi ke la taŭga indekso estas uzata kie ĝi estas necesa.
Reprezento?
Tre populara kaj utila objekto en datumbazo estas vidoj. Ili povas esti utilaj por granda nombro da uzkazoj; miaj du plej ŝatataj estas la logika abstrakta tavolo kaj la sekureca tavolo. Bedaŭrinde, Cloud Spanner NE subtenas vidojn. Tamen, ĉi tio nur parte limigas nin ĉar ne ekzistas granulareco por alirpermesoj ĉe la kolumna nivelo kie vidoj povus esti realigebla solvo.
Vidu la dokumentaron de Cloud Spanner por sekcio kiu detaligas kvotojn kaj limigojn (), ekzistas unu aparte kiu povas esti problema por iuj aplikoj: Cloud Spanner el la skatolo havas limon de maksimumo de 100 datumbazoj per okazo. Evidente, ĉi tio povas esti grava proplemkolo por datumbazo, kiu estas desegnita por grimpi al pli ol 100 datumbazoj. Feliĉe, parolinte kun nia teknika reprezentanto de Google, ni eksciis, ke ĉi tiu limo povas esti pliigita al preskaŭ ajna valoro per Google Support.
Disvolva subteno?
Cloud Spanner ofertas sufiĉe decan programlingvon subtenon por labori kun sia API. Oficiale subtenataj bibliotekoj estas en la areoj de C#, Go, Java, node.js, PHP, Python kaj Ruby. La dokumentaro estas sufiĉe detala, sed kiel kun aliaj altnivelaj teknologioj, la komunumo estas sufiĉe malgranda kompare kun la plej popularaj datumbazaj teknologioj, kiuj povas konduki al pli da tempo elspezita solvante malpli oftajn uzkazojn aŭ problemojn.
Kio do pri subteni lokan disvolviĝon?
Ni ne trovis manieron krei ekzemplon de Cloud Spanner surloke. La plej proksima afero, kiun ni ricevis, estis bildo de Docker. , kiu principe similas, sed tre malsamas praktike. Ekzemple, CockroachDB povas uzi PostgreSQL JDBC. Ĉar la evolumedio devus esti kiel eble plej proksima al la produktadmedio, Cloud Spanner ne estas ideala ĉar ĝi devas fidi je plena Spanner-instanco. Por ŝpari kostojn, vi povas elekti unuregionan petskribon.
Subteno de administrado?
Krei ekzemplon de Cloud Spanner estas tre simpla. Vi nur bezonas elekti inter kreado de multregiona aŭ unuregiona okazo, specifi la regiono(j)n kaj la nombron da nodoj. Post malpli ol minuto, via kazo estos funkcianta.
Pluraj rudimentaj metrikoj estas rekte alireblaj de la paĝo Spanner en la Google Console. Pli detalaj vidoj haveblas per Stackdriver, kie vi ankaŭ povas agordi metrikajn sojlojn kaj atentajn politikojn.
Aliro al rimedoj?
MySQL ofertas ampleksajn kaj tre grajnecajn agordojn por uzantpermesoj/roloj. Vi povas facile agordi aliron al specifa tabelo, aŭ eĉ nur subaro de ĝiaj kolumnoj. Cloud Spanner uzas la ilon pri Administrado de Identeco kaj Aliro (IAM) de Guglo, kiu nur permesas al vi agordi politikojn kaj permesojn al tre alta nivelo. La plej grajneca opcio estas datumbaznivela rezolucio, kiu ne konvenas al plej multaj produktadaj uzkazoj. Ĉi tiu limigo devigas vin aldoni pliajn sekurecajn mezurojn al via kodo, infrastrukturo aŭ ambaŭ por malhelpi neaŭtorizitan uzon de Spanner-resursoj.
Rezervoj?
Por simple diri, ne ekzistas sekurkopioj en Cloud Spanner. Kvankam la altaj SLA-postuloj de Google povas certigi, ke vi ne perdas ajnajn datumojn pro misfunkciadoj de aparataro aŭ datumbazo, homaj eraroj, aplikaj difektoj, ktp. Ni ĉiuj konas la regulon: alta havebleco ne anstataŭas solidan rezervan strategion. Nuntempe, la nura maniero sekurigi datumojn estas programe flui ĝin de datumbazo al aparta stoka medio.
Ĉu konsulti rendimenton?
Ni uzis Yahoo! por ŝargi datumojn kaj testi demandojn. Nuba Servado Benchmark. La suba tabelo montras YCSB-laborkvanton B kun 95% legi al 5% skribproporcio.
* La ŝarĝa testo estis rulita sur la n1-norma-32 Komputila Motoro (CE) (32 vCPU, 120 GB-memoro), kaj la testa kazo neniam estis proplemkolo en la testoj.
** La maksimuma nombro da fadenoj en ununura YCSB-instanco estas 400. Entute ses paralelaj okazoj de YCSB-testoj devis esti rulitaj por akiri entute 2400-fadenoj.
Rigardante la komparnormajn rezultojn, precipe la kombinaĵon de CPU-ŝarĝo kaj TPS, ni povas klare vidi, ke Cloud Spanner skalas sufiĉe bone. La peza ŝarĝo kreita de la granda nombro da fadenoj estas kompensita de la granda nombro da nodoj en la Cloud Spanner-areto. Dum la latenteco aspektas sufiĉe alta, precipe kiam ĝi funkcias kun 2400 fadenoj, retestado kun 6 pli malgrandaj okazoj de la komputila motoro povas esti necesa por akiri pli precizajn nombrojn. Ĉiu okazo funkcios unu YCSB-teston anstataŭ unu granda CE-instanco kun 6 paralelaj testoj. Tiel, estos pli facile diferenci inter Cloud Spanner-peto-latenteco kaj latenteco aldonita de la reto-konekto inter Cloud Spanner kaj la CE-instanco rulanta la teston.
Kiel Cloud Spanner funkcias kiel OLAP?
Dispartigo?
Dividi datumojn en fizike kaj/aŭ logike sendependajn segmentojn, nomitajn sekciojn, estas tre populara koncepto trovita en la plej multaj OLAP-motoroj. Dispartigoj povas signife plibonigi demandan rendimenton kaj datumbazan konserveblecon. Pli profundiĝi en dispartigo estus aparta(j) artikolo(j), do ni simple menciu la gravecon havi dispartigan kaj subdispartigan skemon. La kapablo rompi datumojn en sekciojn kaj eĉ pli en subsekciojn estas ŝlosilo por analiza demanda rendimento.
Cloud Spanner ne subtenas sekciojn kiel tiajn. Ĝi dividas la datumojn interne en tn disigo-s surbaze de primaraj ŝlosilaj gamoj. Dispartigo estas farita aŭtomate por ekvilibrigi la ŝarĝon en Cloud Spanner-areto. Tre utila trajto de Cloud Spanner estas la disigo de la baza ŝarĝo de la gepatra tablo (tablo kiu ne estas interplektita kun alia). Spanner aŭtomate detektas ĉu ĝi enhavas disigo datumoj kiuj estas legitaj pli ofte ol datumoj en aliaj disigo-ah, kaj povas decidi pri plua disiĝo. Tiel, pli da nodoj povas esti implikitaj en peto, kiu ankaŭ efike pliigas trairon.
Ĉu ŝargi datumojn?
La metodo de Cloud Spanner por amasaj datumoj estas la sama kiel normala alŝuto. Por atingi maksimuman rendimenton, vi devas sekvi kelkajn gvidliniojn, inkluzive de:
- Ordigu viajn datumojn laŭ ĉefa ŝlosilo.
- Dividu ilin per 10*nombro da nodoj apartaj sekcioj.
- Kreu aron da labortaskoj, kiuj ŝarĝas datumojn paralele.
Ĉi tiu datuma ŝarĝo uzas ĉiujn Cloud Spanner-nodojn.
Ni uzis YCSB-laborŝarĝon A por generi datumaron de 10M-vicoj.
* La ŝarĝotesto estis rulita sur la n1-norma-32-komputila motoro (32 vCPU, 120 GB-memoro), kaj la testa kazo neniam estis proplemkolo en la testoj.
**Agordo de ununura nodo ne estas rekomendita por ajna produktada laborkvanto.
Kiel menciite supre, Cloud Spanner aŭtomate prilaboras disiĝojn laŭ ilia ŝarĝo, do rezultoj pliboniĝas post pluraj sinsekvaj testaj ripetoj. La rezultoj prezentitaj ĉi tie estas la plej bonaj rezultoj, kiujn ni akiris. Rigardante la suprajn nombrojn, ni povas vidi kiel Cloud Spanner skalas (bone) kiam la nombro da nodoj en la areto pliiĝas. La nombroj kiuj elstaras estas la ekstreme malaltaj averaĝaj latentecoj, kiuj kontrastas kun la rezultoj por miksitaj laborŝarĝoj (95% legado kaj 5% skriba) kiel priskribite en la supra sekcio.
Skali?
Pliigi kaj malpliigi la nombron da Cloud Spanner-nodoj estas unu-klaka tasko. Se vi volas ŝargi datumojn rapide, vi eble pripensos plifortigi vian ekzemplon al la maksimumo (en nia kazo ĝi estis 25 nodoj en la US-EAST-regiono) kaj tiam redukti la nombron da nodoj elekteblaj por via normala ŝarĝo post kiam ĉiuj datumoj estas enigitaj. la datumbazo, rilatante al la 2TB/noda limo.
Ni rememorigis ĉi tiun limon eĉ kun multe pli malgranda datumbazo. Post pluraj kuroj de ŝarĝaj testoj, nia datumbazo estis proksimume 155 GB en grandeco, kaj kiam malgrandigita al 1 noda kazo, ni ricevis la sekvan eraron:
Ni sukcesis malpligrandigi de 25 al 2 okazoj, sed ni estis blokitaj ĉe du nodoj.
Pliigi kaj malpliigi la nombron da nodoj en Cloud Spanner-areto povas esti aŭtomatigita per la REST API. Ĉi tio povas esti speciale utila por redukti pliigitan sisteman ŝarĝon dum okupataj laborhoroj.
Agado de OLAP-demandoj?
Ni origine planis pasigi gravan tempon en nia taksado de Spanner ĉi-parte. Post pluraj SELECT COUNToj, ni tuj rimarkis, ke testado estos mallonga kaj ke Spanner NE estus taŭga motoro por OLAP. Sendepende de la nombro da nodoj en la areto, simple elekti la nombron da vicoj en 10M-victabelo daŭris inter 55 kaj 60 sekundoj. Aldone, ĉiu demando kiu postulis pli da memoro por stoki mezajn rezultojn malsukcesis kun OOM-eraro.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Kelkaj nombroj por TPC-H-demandoj troveblas en la artikolo de Todd Lipcon , diapozitivoj 42 kaj 43. Ĉi tiuj nombroj kongruas kun niaj propraj rezultoj (bedaŭrinde).
4. Niaj konkludoj
Konsiderante la nunan staton de la funkcioj de Cloud Spanner, estas malfacile imagi, ke ĝi estas simpla anstataŭaĵo por via ekzistanta OLTP-solvo, precipe kiam viaj bezonoj superas ĝin. Grava kvanto da tempo devus esti elspezita por konstrui solvon ĉirkaŭ la mankoj de Cloud Spanner.
Kiam ni komencis taksi Cloud Spanner, ni atendis, ke ĝiaj administraj funkcioj estu egalaj aŭ almenaŭ ne tro malproksime de aliaj Google SQL-solvoj. Sed surprizis nin la kompleta manko de sekurkopioj kaj tre limigita kontrolo pri aliro al rimedoj. Sen mencii neniujn vidojn, neniun lokan evoluan medion, nesubtenatajn sekvencojn, JDBC sen DML kaj DDL-subteno, ktp.
Do kien iras iu, kiu bezonas skali transakcian datumbazon? Ŝajnas ke ne ekzistas ununura solvo sur la merkato, kiu taŭgas por ĉiuj uzkazoj. Estas multaj fermitaj kaj malfermfontaj solvoj (kelkaj el kiuj estas menciitaj en ĉi tiu artikolo), ĉiu kun siaj propraj fortoj kaj malfortoj, sed neniu el ili ofertas SaaS kun 99,999% SLA kaj alta konsistenco. Se alta SLA estas via ĉefa celo kaj vi ne emas konstrui kutiman plurnuban solvon, Cloud Spanner eble estas la solvo, kiun vi serĉas. Sed vi devus esti konscia pri ĉiuj ĝiaj limoj.
Por esti justa, Cloud Spanner estis publikigita nur al la publiko en la printempo de 2017, do estas racie atendi, ke iuj el ĝiaj nunaj mankoj eble foriros (espereble), kaj kiam ili faros, ĝi povus esti ludŝanĝilo. Post ĉio, Cloud Spanner ne estas nur flanka projekto por Guglo. Guglo uzas ĝin kiel bazon por aliaj Google-produktoj. Kaj kiam Google lastatempe anstataŭigis Megastore en Google Cloud Storage per Cloud Spanner, ĝi permesis al Google Cloud Storage iĝi tre konsekvenca por listoj de objektoj tutmonde (kio ankoraŭ ne estas la kazo por ).
Do, ankoraŭ estas espero... ni esperas.
Tio estas ĉio. Same kiel la aŭtoro de la artikolo, ankaŭ ni daŭre esperas, sed kion vi pensas pri tio? Skribu en la komentoj
Ni invitas ĉiujn viziti nian ene de kiu ni rakontos al vi detale pri la kurso de OTUS.
fonto: www.habr.com