Pozdravljeni, prebivalci Khabrovsk. Kot običajno še naprej delimo zanimivo gradivo pred začetkom novih tečajev. Danes smo posebej za vas objavili članek o Google Cloud Spannerju, ki sovpada z začetkom tečaja .
Prvotno objavljeno v .
Kot podjetje, ki ponuja različne POS rešitve v oblaku za trgovce na drobno, restavratorje in spletne prodajalce po vsem svetu, Lightspeed uporablja več različnih vrst platform za baze podatkov za različne transakcijske, analitične in iskalne primere uporabe. Vsaka od teh platform baz podatkov ima svoje prednosti in slabosti. Ko je Google na trg predstavil Cloud Spanner – obetavne funkcije, ki jih v svetu relacijskih baz podatkov še ni bilo, kot sta praktično neomejena vodoravna razširljivost in 99,999-odstotni sporazum o ravni storitev (SLA), — nismo mogli zamuditi priložnosti, da bi ga dobili v roke!
Da bi zagotovili izčrpen pregled naših izkušenj s storitvijo Cloud Spanner, kot tudi merila ocenjevanja, ki smo jih uporabili, bomo obravnavali naslednje teme:
- Naša merila ocenjevanja
- Cloud Spanner na kratko
- Naša ocena
- Naše ugotovitve
1. Naša merila ocenjevanja
Preden se poglobimo v posebnosti Cloud Spannerja, njegovih podobnosti in razlik z drugimi rešitvami na trgu, se najprej pogovorimo o glavnih primerih uporabe, ki smo jih imeli v mislih, ko smo razmišljali, kje v naši infrastrukturi namestiti Cloud Spanner:
- Kot zamenjava za (prevladujočo) tradicionalno rešitev baze podatkov SQL
- Kako do rešitve OLTP s podporo OLAP
Opomba: Zaradi preprostosti in lažje primerjave ta članek primerja Cloud Spanner z različicami MySQL družin rešitev GCP Cloud SQL in Amazon AWS RDS.
Uporaba Cloud Spannerja kot zamenjave za tradicionalno rešitev baze podatkov SQL
V okolju tradicionalno podatkovnih baz, ko se odzivni čas na poizvedbo baze približa ali celo preseže vnaprej določene pragove aplikacije (predvsem zaradi povečanja števila uporabnikov in/ali zahtev), obstaja več načinov za zmanjšanje odzivnega časa na sprejemljive ravni. Vendar večina teh rešitev vključuje ročno posredovanje.
Na primer, prvi korak, ki ga morate storiti, je, da pogledate različne parametre baze podatkov, povezane z zmogljivostjo, in jih prilagodite tako, da se najbolje ujemajo z vzorci primerov uporabe aplikacije. Če to ni dovolj, lahko izberete navpično ali vodoravno skaliranje baze podatkov.
Vertikalno skaliranje aplikacije vključuje nadgradnjo primerka strežnika, običajno z dodajanjem več procesorjev/jeder, več RAM-a, hitrejšim pomnilnikom itd. Dodajanje več virov strojne opreme ima za posledico večjo zmogljivost baze podatkov, merjeno predvsem v transakcijah v sekundi, in zakasnitvijo transakcij za sisteme OLTP. Sistemi relacijskih baz podatkov (ki uporabljajo večnitni pristop), kot je MySQL, se dobro prilagajajo navpični ravni.
Ta pristop ima več pomanjkljivosti, najbolj očitna pa je največja velikost strežnika na trgu. Ko je dosežena omejitev največjega primerka strežnika, ostane le še ena možnost: vodoravno skaliranje.
Horizontalno skaliranje je pristop, pri katerem se v gručo doda več strežnikov, pri čemer se v idealnem primeru zmogljivost linearno povečuje z dodajanjem števila strežnikov. Večina tradicionalno Sistemi baz podatkov se vodoravno ne prilagajajo dobro ali pa se sploh ne prilagajajo. Na primer, MySQL lahko vodoravno spreminja velikosti za operacije branja z dodajanjem podrejenih bralnikov, ne more pa vodoravno spreminjati velikosti za pisanje.
Po drugi strani pa lahko Cloud Spanner zaradi svoje narave enostavno vodoravno prilagaja z minimalnim posegom.
Popolnoma predstavljen DBMS kot storitev je treba oceniti z različnih zornih kotov. Za osnovo smo vzeli najbolj priljubljen DBMS v oblaku - za Google GCP Cloud SQL in za Amazon AWS RDS. Pri naši oceni smo se osredotočili na naslednje kategorije:
- Preslikava funkcij: obseg SQL, DDL, DML; povezovalne knjižnice/konektorji, podpora za transakcije itd.
- Razvojna podpora: enostaven razvoj in testiranje.
- Administrativna podpora: upravljanje instanc – na primer povečanje/zmanjšanje in nadgradnja instanc; SLA, varnostno kopiranje in obnovitev; varnost/kontrola dostopa.
Uporaba Cloud Spannerja kot rešitve OLTP, ki podpira OLAP
Čeprav Google izrecno ne trdi, da je Cloud Spanner zasnovan za analitično obdelavo, si deli nekatere atribute z drugimi motorji, kot sta Apache Impala & Kudu in YugaByte, ki sta zasnovana za delovne obremenitve OLAP.
Tudi če bi obstajala le majhna verjetnost, da bi Cloud Spanner vključeval dosleden mehanizem HTAP (hibridna transakcijska/analitična obdelava) z (bolj ali manj) uporabnim naborom funkcij OLAP, menimo, da bi bil vreden naše pozornosti.
S tem v mislih smo si ogledali naslednje kategorije:
- Podpora za nalaganje podatkov, indekse in particioniranje
- Učinkovitost poizvedb in DML
2. Cloud Spanner na kratko
Google Spanner je sistem za upravljanje relacijskih baz podatkov v gručah (RDBMS), ki ga Google uporablja za več svojih storitev. Google ga je v začetku leta 2017 dal na splošno na voljo uporabnikom Google Cloud Platform.
Tukaj je nekaj atributov Cloud Spannerja:
- Visoko dosledna razširljiva gruča RDBMS: uporablja časovno sinhronizacijo strojne opreme za zagotavljanje doslednosti podatkov.
- Podpora za transakcije med tabelami: Transakcije lahko obsegajo več tabel – niso nujno omejene na eno samo tabelo (za razliko od Apache HBase ali Apache Kudu).
- Tabele, ki temeljijo na primarnem ključu: Vse tabele morajo imeti deklariran primarni ključ (PC), ki je lahko sestavljen iz več stolpcev v tabeli. Tabelarni podatki so shranjeni v vrstnem redu osebnega računalnika, zaradi česar je iskanje zelo učinkovito in hitro. Tako kot drugi sistemi, ki temeljijo na osebnem računalniku, je treba izvedbo modelirati z vnaprej načrtovanimi primeri uporabe v mislih .
- Črtaste tabele: tabele so lahko fizično odvisne druga od druge. Vrstice v podrejeni tabeli je mogoče primerjati z vrsticami v nadrejeni tabeli. Ta pristop pospeši iskanje odnosov, ki jih je mogoče prepoznati med fazo modeliranja podatkov, kot je na primer skupno lociranje strank in njihovih računov.
- Indeksi: Cloud Spanner podpira sekundarne indekse. Indeks je sestavljen iz indeksiranih stolpcev in vseh stolpcev PC. Po želji lahko indeks vsebuje tudi druge neindeksirane stolpce. Indeks je mogoče prepletati z nadrejeno tabelo, da pospešite poizvedbe. Za indekse velja več omejitev, na primer največje število dodatnih stolpcev, shranjenih v indeksu. Poleg tega poizvedbe prek indeksov morda niso tako enostavne kot v drugih RDBMS.
»Cloud Spanner samo v redkih primerih samodejno izbere indeks. Zlasti Cloud Spanner ne izbere samodejno sekundarnega indeksa, če poizvedba zahteva stolpce, ki niso shranjeni v ".
- Sporazum o ravni storitev (SLA): uvedba v eni regiji s SLA 99,99 %; večregionalne uvedbe z 99,999 % SLA. Medtem ko je sama pogodba o ravni storitev le sporazum in ne kakršno koli jamstvo, verjamem, da imajo ljudje pri Googlu nekaj trdnih podatkov, da lahko podajo tako trdno trditev. (Za referenco 99,999 % pomeni 26,3 sekunde nedosegljivosti storitve na mesec.)
- Več:
Opomba: Projekt Apache Tephra doda izboljšano podporo za transakcije v Apache HBase (ki je zdaj implementiran tudi v Apache Phoenix kot beta).
3. Naša ocena
Torej, vsi smo prebrali Googlove trditve o prednostih Cloud Spannerja – skoraj neomejeno vodoravno skaliranje ob ohranjanju visoke konsistentnosti in zelo visokega SLA. Čeprav so te zahteve v vsakem primeru izjemno težko dosegljive, naš cilj ni bil, da bi jih ovrgli. Namesto tega se osredotočimo na druge stvari, ki zanimajo večino uporabnikov baze podatkov: pariteto in uporabnost.
Cloud Spanner smo ocenili kot zamenjavo za Sharded MySQL
Google Cloud SQL in Amazon AWS RDS, dva izmed najbolj priljubljenih OLTP DBMS na trgu v oblaku, imata zelo velik nabor funkcij. Če želite povečati te baze podatkov nad velikostjo enega samega vozlišča, morate izvesti particijo aplikacije. Ta pristop ustvarja dodatno kompleksnost za aplikacije in administracijo. Ogledali smo si, kako se Spanner prilega scenariju združevanja več drobcev v en primerek in katere funkcije (če sploh) je treba žrtvovati.
Podpora za SQL, DML in DDL ter priključek in knjižnice?
Najprej, ko začnete s katero koli bazo podatkov, morate ustvariti podatkovni model. Če menite, da lahko JDBC Spanner povežete s svojim najljubšim orodjem SQL, boste ugotovili, da lahko z njim poizvedujete po svojih podatkih, vendar ga ne morete uporabiti za ustvarjanje tabele ali spreminjanje (DDL) ali kakršno koli vstavljanje/posodabljanje/brisanje operacije (DML). Googlov uradni JDBC ne podpira nobenega od teh.
"Gonilniki trenutno ne podpirajo stavkov DML ali DDL."
Spanner dokumentacija
Situacija ni nič boljša s konzolo GCP - pošiljate lahko le poizvedbe SELECT. Na srečo obstaja gonilnik JDBC s podporo za DML in DDL iz skupnosti, vključno s transakcijami . Čeprav je ta gonilnik izjemno uporaben, je pomanjkanje Googlovega gonilnika JDBC presenetljivo. Na srečo Google ponuja precej široko podporo za odjemalske knjižnice (na podlagi gRPC): C#, Go, Java, node.js, PHP, Python in Ruby.
Skoraj obvezna uporaba API-jev po meri Cloud Spanner (zaradi pomanjkanja DDL in DML v JDBC) ima za posledico nekatere omejitve za povezana področja kode, kot so področja povezav ali okviri za povezovanje baz podatkov (npr. Spring MVC). Običajno lahko pri uporabi JDBC izberete svoje najljubše povezovalno polje (npr. HikariCP, DBCP, C3PO itd.), ki je preizkušeno in dobro deluje. V primeru API-jev Spanner po meri se moramo zanašati na ogrodja/povezave/seje, ki smo jih ustvarili sami.
Zasnova, osredotočena na primarni ključ (PC), omogoča, da je Cloud Spanner zelo hiter pri dostopu do podatkov prek osebnega računalnika, vendar predstavlja tudi nekaj težav pri poizvedbah.
- Vrednosti primarnega ključa ne morete posodobiti; Najprej morate izbrisati vnos iz izvirnega računalnika in ga znova vstaviti z novo vrednostjo. (To je podobno drugim motorjem za podatkovne baze/shranjevanje, usmerjenim v računalnik.)
- Katera koli stavka UPDATE in DELETE morata podati PC v WHERE, zato ne more biti praznih stavkov DELETE all – vedno mora obstajati podpoizvedba, na primer: UPDATE xxx WHERE id IN (SELECT id FROM table1)
- Pomanjkanje možnosti samodejnega povečanja ali česa podobnega, kar bi nastavilo zaporedje za polje PC. Da bi to delovalo, je treba ustvariti ustrezno vrednost na strani aplikacije.
Sekundarni indeksi?
Google Cloud Spanner ima vgrajeno podporo za sekundarne indekse. To je zelo dobra funkcija, ki ni vedno prisotna v drugih tehnologijah. Apache Kudu trenutno sploh ne podpira sekundarnih indeksov, Apache HBase pa indeksov ne podpira neposredno, lahko pa jih doda prek Apache Phoenix.
Indekse v Kudu in HBase je mogoče modelirati kot ločeno tabelo z drugačno sestavo primarnih ključev, vendar je treba atomičnost operacij, ki se izvajajo na nadrejeni tabeli in povezanih indeksnih tabelah, izvesti na ravni aplikacije in ni trivialna za pravilno implementacijo.
Kot je omenjeno v pregledu Cloud Spannerja, se lahko njegovi indeksi razlikujejo od indeksov MySQL. Zato je treba pri izdelavi poizvedb in profiliranju nameniti posebno pozornost, da se zagotovi uporaba ustreznega indeksa, kjer je to potrebno.
Reprezentanca?
Pogledi so zelo priljubljen in uporaben objekt v bazi podatkov. Uporabni so lahko za veliko število primerov uporabe; moja dva najljubša sta sloj logične abstrakcije in varnostni sloj. Na žalost Cloud Spanner NE podpira pogledov. Vendar nas to le delno omejuje, ker ni razdrobljenosti za dovoljenja za dostop na ravni stolpcev, kjer bi lahko bili pogledi izvedljiva rešitev.
Oglejte si dokumentacijo Cloud Spanner za razdelek s podrobnostmi o kvotah in omejitvah (), še posebej obstaja ena, ki je lahko problematična za nekatere aplikacije: Cloud Spanner, ki je takoj po namestitvi, ima omejitev največ 100 baz podatkov na primerek. Očitno je to lahko veliko ozko grlo za zbirko podatkov, ki je zasnovana za več kot 100 zbirk podatkov. Na srečo smo po pogovoru z našim Googlovim tehničnim predstavnikom ugotovili, da je to omejitev mogoče povečati na skoraj vsako vrednost prek Googlove podpore.
Razvojna podpora?
Cloud Spanner ponuja precej spodobno podporo za programski jezik za delo s svojim API-jem. Uradno podprte knjižnice so na področjih C#, Go, Java, node.js, PHP, Python in Ruby. Dokumentacija je precej podrobna, a tako kot pri drugih naprednih tehnologijah je skupnost precej majhna v primerjavi z najbolj priljubljenimi tehnologijami podatkovnih baz, kar lahko povzroči več časa, porabljenega za reševanje manj običajnih primerov ali težav.
Kaj pa podpora lokalnemu razvoju?
Nismo našli načina za ustvarjanje primerka Cloud Spanner na mestu uporabe. Najbližje, kar smo dobili, je bila Dockerjeva slika. , ki je načeloma podoben, v praksi pa zelo drugačen. Na primer, CockroachDB lahko uporablja PostgreSQL JDBC. Ker mora biti razvojno okolje čim bližje produkcijskemu okolju, Cloud Spanner ni idealen, saj se mora zanašati na popolno instanco Spanner. Če želite prihraniti stroške, lahko izberete primerek z eno regijo.
Administrativna podpora?
Ustvarjanje primerka Cloud Spanner je zelo preprosto. Samo izbrati morate med ustvarjanjem primerka z več regijami ali eno regijo, določiti regijo(-e) in število vozlišč. V manj kot minuti bo vaš primerek začel delovati.
Več osnovnih meritev je neposredno dostopnih na strani Spanner v Googlovi konzoli. Podrobnejši pogledi so na voljo prek Stackdriverja, kjer lahko nastavite tudi mejne vrednosti meritev in pravilnike o opozorilih.
Dostop do virov?
MySQL ponuja obsežne in zelo natančne nastavitve za uporabniška dovoljenja/vloge. Z lahkoto lahko konfigurirate dostop do določene tabele ali celo do podnabora njenih stolpcev. Cloud Spanner uporablja Googlovo orodje za upravljanje identitete in dostopa (IAM), ki vam omogoča samo nastavitev pravilnikov in dovoljenj na zelo visoki ravni. Najbolj razdrobljena možnost je ločljivost na ravni baze podatkov, ki ne ustreza večini primerov produkcijske uporabe. Ta omejitev vas prisili, da dodate dodatne varnostne ukrepe svoji kodi, infrastrukturi ali obojemu, da preprečite nepooblaščeno uporabo virov Spanner.
Varnostne kopije?
Preprosto povedano, v Cloud Spannerju ni varnostnih kopij. Čeprav lahko Googlove visoke zahteve SLA zagotovijo, da ne izgubite nobenih podatkov zaradi napak strojne opreme ali baze podatkov, človeških napak, okvar aplikacij itd. Vsi poznamo pravilo: visoka razpoložljivost ni nadomestilo za dobro strategijo varnostnega kopiranja. Trenutno je edini način za varnostno kopiranje podatkov programsko pretakanje iz baze podatkov v ločeno okolje za shranjevanje.
Učinkovitost poizvedbe?
Za nalaganje podatkov in testiranje poizvedb smo uporabili Yahoo! Primerjalno merilo storitve v oblaku. Spodnja tabela prikazuje delovno obremenitev YCSB B s 95-odstotnim razmerjem med branjem in 5-odstotnim pisanjem.
* Obremenitveni preizkus je bil izveden na n1-standard-32 Compute Engine (CE) (32 vCPU, 120 GB pomnilnika) in testna instanca ni bila nikoli ozko grlo pri preizkusih.
** Največje število niti v posameznem primerku YCSB je 400. Za skupno 2400 niti je bilo treba izvesti skupno šest vzporednih primerkov testov YCSB.
Če pogledamo rezultate primerjalnih testov, zlasti kombinacijo obremenitve procesorja in TPS, lahko jasno vidimo, da se Cloud Spanner precej dobro prilagaja. Velika obremenitev, ki jo povzroči veliko število niti, se izravna z velikim številom vozlišč v gruči Cloud Spanner. Medtem ko je zakasnitev videti precej visoka, zlasti pri izvajanju z 2400 niti, bo morda potrebno ponovno testiranje s 6 manjšimi primerki računalniškega mehanizma, da dobite natančnejše številke. Vsaka instanca bo izvajala en test YCSB namesto enega velikega primerka CE s 6 vzporednimi testi. Na ta način bo lažje razlikovati med zakasnitvijo zahteve Cloud Spanner in zakasnitvijo, ki jo doda omrežna povezava med Cloud Spannerjem in primerkom CE, ki izvaja preizkus.
Kako Cloud Spanner deluje kot OLAP?
Particioniranje?
Delitev podatkov na fizično in/ali logično neodvisne segmente, imenovane particije, je zelo priljubljen koncept, ki ga najdemo v večini motorjev OLAP. Particije lahko bistveno izboljšajo zmogljivost poizvedb in vzdržljivost baze podatkov. Poglabljanje v particioniranje bi bil ločen člen(-i), zato omenimo samo pomen particioniranja in sheme podparticioniranja. Zmožnost razčlenjevanja podatkov na particije in še dlje na podparticije je ključna za učinkovitost analitične poizvedbe.
Cloud Spanner ne podpira particij kot takih. Podatke interno deli na t.i po delih-s na podlagi obsegov primarnih ključev. Particioniranje se izvede samodejno za uravnoteženje obremenitve v gruči Cloud Spanner. Zelo uporabna funkcija Cloud Spannerja je razdelitev osnovne obremenitve nadrejene tabele (tabela, ki ni prepletena z drugo). Spanner samodejno zazna, ali vsebuje po delih podatki, ki se berejo pogosteje kot podatki v drugih po delih-ah, in se lahko odloči za nadaljnjo ločitev. Na ta način je lahko v zahtevo vključenih več vozlišč, kar tudi učinkovito poveča prepustnost.
Nalaganje podatkov?
Metoda Cloud Spanner za množične podatke je enaka kot pri običajnem nalaganju. Če želite doseči največjo učinkovitost, morate upoštevati nekaj smernic, vključno z:
- Podatke razvrstite po primarnem ključu.
- Razdeli jih z 10*število vozlišč ločeni odseki.
- Ustvarite niz delovnih nalog, ki podatke nalagajo vzporedno.
To nalaganje podatkov uporablja vsa vozlišča Cloud Spanner.
Za ustvarjanje nabora podatkov z 10 milijoni vrstic smo uporabili delovno obremenitev YCSB A.
* Preizkus obremenitve je bil izveden na računalniškem motorju n1-standard-32 (32 vCPE, 120 GB pomnilnika) in testna instanca ni bila nikoli ozko grlo pri preizkusih.
**Nastavitev enega vozlišča ni priporočljiva za nobeno produkcijsko delovno obremenitev.
Kot je navedeno zgoraj, Cloud Spanner samodejno obdela razdelitve glede na njihovo obremenitev, tako da se rezultati izboljšajo po več zaporednih ponovitvah testa. Tukaj predstavljeni rezultati so najboljši rezultati, ki smo jih dosegli. Če pogledamo zgornje številke, lahko vidimo, kako se Cloud Spanner (dobro) spreminja, ko se število vozlišč v gruči povečuje. Številke, ki izstopajo, so izjemno nizke povprečne zakasnitve, ki so v nasprotju z rezultati za mešane delovne obremenitve (95 % branja in 5 % pisanja), kot je opisano v zgornjem razdelku.
Skaliranje?
Povečanje in zmanjševanje števila vozlišč Cloud Spanner je opravilo z enim klikom. Če želite podatke naložiti hitro, razmislite o tem, da povečate svoj primerek do maksimuma (v našem primeru je bilo to 25 vozlišč v regiji US-EAST) in nato zmanjšate število vozlišč, primernih za vaše običajno nalaganje, ko so vsi podatki v bazo podatkov, ki se nanaša na omejitev 2TB/vozlišče.
Na to omejitev smo bili opozorjeni že z veliko manjšo bazo podatkov. Po več zagonih obremenitvenih testov je bila naša zbirka podatkov velika približno 155 GB in ko smo jo zmanjšali na primerek 1 vozlišča, smo prejeli to napako:
Uspelo nam je zmanjšati število primerkov s 25 na 2, vendar smo obstali pri dveh vozliščih.
Povečevanje in zmanjševanje števila vozlišč v gruči Cloud Spanner je mogoče avtomatizirati z uporabo API-ja REST. To je lahko še posebej koristno za zmanjšanje povečane obremenitve sistema med napornim delovnim časom.
Izvedba poizvedb OLAP?
Prvotno smo načrtovali, da bomo za našo oceno Spannerja porabili precej časa za ta del. Po več SELECT COUNTS smo takoj ugotovili, da bo testiranje kratko in da Spanner NE bo primeren motor za OLAP. Ne glede na število vozlišč v gruči je enostavno izbiranje števila vrstic v 10M vrstični tabeli trajalo med 55 in 60 sekundami. Poleg tega vsaka poizvedba, ki je zahtevala več pomnilnika za shranjevanje vmesnih rezultatov, ni uspela z napako OOM.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Nekaj številk za poizvedbe TPC-H najdete v članku Todda Lipcona , diapozitiva 42 in 43. Te številke so skladne z našimi rezultati (na žalost).
4. Naši sklepi
Glede na trenutno stanje funkcij Cloud Spannerja si je težko predstavljati, da je to preprosta zamenjava za vašo obstoječo rešitev OLTP, zlasti ko jo vaše potrebe prerastejo. Za rešitev pomanjkljivosti Cloud Spannerja bi bilo treba porabiti veliko časa.
Ko smo začeli ocenjevati Cloud Spanner, smo pričakovali, da bodo njegove funkcije upravljanja enake ali vsaj ne preveč oddaljene od drugih rešitev Google SQL. Presenetilo pa nas je popolno pomanjkanje varnostnih kopij in zelo omejen nadzor nad dostopom do virov. Da ne omenjam brez pogledov, brez lokalnega razvojnega okolja, nepodprtih sekvenc, JDBC brez podpore za DML in DDL itd.
Torej, kam gre nekdo, ki mora razširiti transakcijsko bazo podatkov? Zdi se, da na trgu ni ene same rešitve, ki bi ustrezala vsem primerom uporabe. Obstaja veliko zaprtokodnih in odprtokodnih rešitev (nekatere so omenjene v tem članku), vsaka s svojimi prednostmi in slabostmi, vendar nobena od njih ne ponuja SaaS z 99,999 % SLA in visoko doslednostjo. Če je vaš glavni cilj visok SLA in niste nagnjeni k izdelavi rešitve v več oblakih po meri, je Cloud Spanner morda rešitev, ki jo iščete. Vendar se morate zavedati vseh njegovih omejitev.
Če smo pošteni, je bil Cloud Spanner izdan javnosti šele spomladi 2017, zato je razumno pričakovati, da bodo nekatere njegove trenutne pomanjkljivosti sčasoma izginile (upajmo), in ko bodo, bi to lahko spremenilo igro. Navsezadnje Cloud Spanner ni le stranski projekt za Google. Google ga uporablja kot osnovo za druge Googlove izdelke. In ko je Google pred kratkim zamenjal Megastore v storitvi Google Cloud Storage z Cloud Spannerjem, je Google Cloud Storage omogočil, da postane zelo konsistenten za sezname predmetov na globalni ravni (kar še vedno ne velja za ).
Torej še vedno obstaja upanje ... upamo.
To je vse. Tako kot avtor članka tudi mi še naprej upamo, kaj pravite na to? Zapiši v komentarje
Vabimo vse, da nas obiščete v okviru katerega vam bomo podrobno povedali o tečaju od OTUS.
Vir: www.habr.com