Google Cloud Spanner: dobar, loš, ružan

Zdravo, stanovnici Khabrovsk. Kao i obično, nastavljamo dijeliti zanimljiv materijal uoči početka novih kurseva. Danas smo, posebno za vas, objavili članak o Google Cloud Spanner-u koji se poklopio s pokretanjem kursa "AWS za programere".

Originalno objavljeno u Lightspeed HQ blog.

Kao kompanija koja nudi raznovrsna POS rješenja zasnovana na oblaku trgovcima na malo, ugostiteljima i online prodavcima širom svijeta, Lightspeed koristi nekoliko različitih tipova platformi baza podataka za različite transakcijske, analitičke i slučajeve pretraživanja. Svaka od ovih platformi baza podataka ima svoje prednosti i slabosti. Stoga, kada je Google predstavio Cloud Spanner na tržištu - obećavajuće karakteristike koje nisu viđene u svijetu relacijskih baza podataka, kao što su praktično neograničena horizontalna skalabilnost i 99,999% ugovor o nivou usluge (SLA), — nismo mogli propustiti priliku da se dočepamo toga!

Da bismo pružili sveobuhvatan pregled našeg iskustva sa Cloud Spanner-om, kao i kriterijume evaluacije koje smo koristili, pokriti ćemo sljedeće teme:

1. Naši kriterijumi evaluacije
2. Cloud Spanner ukratko
3. Naš rejting
4. Naši nalazi

1. Naši kriterijumi evaluacije

Prije nego što uđemo u specifičnosti Cloud Spanner-a, njegove sličnosti i razlike s drugim rješenjima na tržištu, hajde da prvo razgovaramo o glavnim slučajevima upotrebe koje smo imali na umu kada smo razmatrali gdje implementirati Cloud Spanner u našoj infrastrukturi:

• Kao zamjena za (preovlađujuće) tradicionalno rješenje SQL baze podataka
• Kako OLTP rješenje s OLAP podrškom

Napomena: Radi jednostavnosti i lakšeg poređenja, ovaj članak upoređuje Cloud Spanner sa MySQL varijantama GCP Cloud SQL i Amazon AWS RDS porodica rješenja.

Korištenje Cloud Spanner-a kao zamjene za tradicionalno rješenje SQL baze podataka

U okruženju tradicionalno baze podataka, kada se vrijeme odgovora na upit baze podataka približi ili čak premaši unaprijed definirane pragove aplikacije (uglavnom zbog povećanja broja korisnika i/ili zahtjeva), postoji nekoliko načina da se vrijeme odgovora smanji na prihvatljive nivoe. Međutim, većina ovih rješenja uključuje ručnu intervenciju.

Na primjer, prvi korak koji treba poduzeti je pogledati različite parametre baze podataka koji se odnose na performanse i podesiti ih tako da najbolje odgovaraju obrascima upotrebe aplikacije. Ako to nije dovoljno, možete odabrati skaliranje baze podataka okomito ili horizontalno.

Vertikalno skaliranje aplikacije podrazumijeva nadogradnju instance servera, obično dodavanjem više procesora/jezgri, više RAM-a, bržeg skladištenja, itd. Dodavanje više hardverskih resursa rezultira povećanjem performansi baze podataka, mjereno prvenstveno u transakcijama u sekundi, i kašnjenjem transakcije za OLTP sisteme. Sistemi relacionih baza podataka (koji koriste pristup sa više niti) kao što je MySQL dobro se vertikalno skaliraju.

Postoji nekoliko nedostataka ovog pristupa, ali najočitiji je maksimalna veličina servera na tržištu. Kada se dostigne granica najveće instance servera, preostaje samo jedna opcija: horizontalno skaliranje.

Horizontalno skaliranje je pristup u kojem se više servera dodaje u klaster, u idealnom slučaju povećavajući performanse linearno kako se dodaje broj servera. Većina tradicionalno Sistemi baza podataka ne skaliraju dobro horizontalno ili se uopće ne skaliraju. Na primjer, MySQL može horizontalno skalirati za operacije čitanja dodavanjem podređenih čitača, ali ne može horizontalno skalirati za upisivanje.

S druge strane, zbog svoje prirode, Cloud Spanner se lako može horizontalno skalirati uz minimalnu intervenciju.

Potpuno opremljen DBMS kao usluga moraju se procijeniti iz različitih uglova. Kao osnovu uzeli smo najpopularniji DBMS u oblaku - za Google, GCP Cloud SQL i za Amazon, AWS RDS. U našoj procjeni fokusirali smo se na sljedeće kategorije:

• Mapiranje karakteristika: opseg SQL, DDL, DML; biblioteke povezivanja/konektori, podrška za transakcije i tako dalje.
• Razvojna podrška: jednostavan razvoj i testiranje.
• Administrativna podrška: upravljanje instancama - na primjer, povećanje/smanjenje i nadogradnja instanci; SLA, backup i oporavak; sigurnost/kontrola pristupa.

Korištenje Cloud Spanner-a kao OLAP-omogućenog OLTP rješenja

Iako Google eksplicitno ne tvrdi da je Cloud Spanner dizajniran za analitičku obradu, on dijeli neke atribute s drugim mašinama kao što su Apache Impala & Kudu i YugaByte, koji su dizajnirani za OLAP radna opterećenja.

Čak i da je postojala samo mala šansa da Cloud Spanner uključi konzistentan HTAP (hibridna obrada transakcija/analitička obrada) motor sa (manje ili više) upotrebljivim skupom OLAP funkcija, mislimo da bi to bilo vrijedno naše pažnje.

Imajući to na umu, pogledali smo sljedeće kategorije:

• Podrška za učitavanje podataka, indekse i particioniranje
• Performanse upita i DML

2. Cloud Spanner ukratko

Google Spanner je klasterizovani sistem za upravljanje relacionim bazama podataka (RDBMS) koji Google koristi za nekoliko svojih usluga. Google ga je učinio općenito dostupnim korisnicima Google Cloud Platforme početkom 2017.

Evo nekih od atributa Cloud Spannera:

• Visoko konzistentan skalabilni RDBMS klaster: Koristi hardversku vremensku sinhronizaciju kako bi osigurao konzistentnost podataka.
• Podrška za transakcije između tablica: Transakcije mogu obuhvatiti više tablica - ne moraju nužno biti ograničene na jednu tablicu (za razliku od Apache HBase ili Apache Kudua).
• Tabele zasnovane na primarnom ključu: Sve tabele moraju imati deklarisani primarni ključ (PC), koji se može sastojati od više kolona u tabeli. Tabelarni podaci se pohranjuju u PC redosledu, što ga čini veoma efikasnim i brzim za pretraživanje računara. Kao i drugi sistemi zasnovani na računaru, implementacija se mora modelovati sa unapred dizajniranim slučajevima upotrebe da bi se to postiglo najbolje performanse.
• Prugaste tabele: Tabele mogu imati fizičke zavisnosti jedna od druge. Redovi u podređenoj tabeli mogu se upariti sa redovima u nadređenoj tabeli. Ovaj pristup ubrzava potragu za odnosima koji se mogu identifikovati tokom faze modeliranja podataka, kao što je ko-lociranje kupaca i njihovih faktura.
• Indeksi: Cloud Spanner podržava sekundarne indekse. Indeks se sastoji od indeksiranih kolona i svih PC stupaca. Po želji, indeks može sadržavati i druge neindeksirane kolone. Indeks se može preplitati s roditeljskom tablicom kako bi se ubrzali upiti. Nekoliko ograničenja se primjenjuje na indekse, kao što je maksimalni broj dodatnih stupaca pohranjenih u indeksu. Takođe, upiti kroz indekse možda neće biti tako jednostavni kao u drugim RDBMS-ovima.

“Cloud Spanner automatski bira indeks samo u rijetkim slučajevima. Konkretno, Cloud Spanner ne bira automatski sekundarni indeks ako upit zahtijeva bilo koje stupce koji nisu pohranjeni u index ".

• Ugovor o nivou usluge (SLA): Raspoređivanje u jednoj regiji sa SLA od 99,99%; multi-regionalne implementacije sa 99,999% SLA. Iako je sam SLA samo sporazum, a ne garancija bilo koje vrste, vjerujem da ljudi u Googleu imaju neke čvrste podatke da iznesu tako jaku tvrdnju. (Za referencu, 99,999% znači 26,3 sekunde nedostupnosti usluge mjesečno.)
• Više: https://cloud.google.com/spanner/

Napomena: Apache Tephra projekat dodaje poboljšanu podršku za transakcije u Apache HBase (također je sada implementiran u Apache Phoenix kao beta).

3. Naša procjena

Dakle, svi smo čitali Googleove tvrdnje o prednostima Cloud Spanner-a - praktično neograničeno horizontalno skaliranje uz održavanje visoke konzistentnosti i vrlo visokog SLA. Iako su ovi zahtjevi, u svakom slučaju, izuzetno teško ostvarivi, naš cilj nije bio da ih pobijemo. Umjesto toga, fokusirajmo se na druge stvari do kojih je stalo većini korisnika baze podataka: paritet i upotrebljivost.

Procijenili smo Cloud Spanner kao zamjenu za Sharded MySQL

Google Cloud SQL i Amazon AWS RDS, dva od najpopularnijih OLTP DBMS-a na tržištu oblaka, imaju veoma veliki skup funkcija. Međutim, da biste skalirali ove baze podataka iznad veličine jednog čvora, trebate izvršiti particioniranje aplikacije. Ovaj pristup stvara dodatnu složenost i za aplikacije i za administraciju. Pogledali smo kako se Spanner uklapa u scenario kombinovanja više delova u jednu instancu i koje karakteristike (ako ih ima) možda treba žrtvovati.

SQL, DML i DDL podrška, kao i konektor i biblioteke?

Prvo, kada počinjete sa bilo kojom bazom podataka, morate kreirati model podataka. Ako mislite da možete povezati JDBC Spanner sa svojim omiljenim SQL alatom, otkrit ćete da pomoću njega možete ispitivati ​​svoje podatke, ali ga ne možete koristiti za kreiranje tablice ili modificiranje (DDL) ili bilo koje umetanje/ažuriranje/brisanje operacije (DML). Googleov službeni JDBC ne podržava nijedno od ovih.

"Upravljački programi trenutno ne podržavaju DML ili DDL izjave."
Spanner dokumentacija

Ništa bolja situacija nije ni sa GCP konzolom - možete slati samo SELECT upite. Srećom, postoji JDBC drajver sa podrškom za DML i DDL iz zajednice, uključujući transakcije github.com/olavloite/spanner-jdbc. Iako je ovaj drajver izuzetno koristan, iznenađuje nedostatak Googleovog sopstvenog JDBC drajvera. Srećom, Google nudi prilično široku podršku za klijentske biblioteke (bazirane na gRPC): C#, Go, Java, node.js, PHP, Python i Ruby.

Gotovo obavezna upotreba prilagođenih API-ja Cloud Spanner (zbog nedostatka DDL-a i DML-a u JDBC-u) rezultira nekim ograničenjima za srodna područja koda kao što su spremišta veza ili okviri za povezivanje baze podataka (npr. Spring MVC). Obično, kada koristite JDBC, možete slobodno odabrati svoj omiljeni skup veza (npr. HikariCP, DBCP, C3PO, itd.) koji je testiran i dobro radi. U slučaju prilagođenih Spanner API-ja, moramo se osloniti na okvire/skupove vezivanja/sesije koje smo sami kreirali.

Dizajn usredsređen na primarni ključ (PC) omogućava Cloud Spanner-u da bude veoma brz kada pristupa podacima preko računara, ali takođe uvodi neke probleme sa upitima.

• Ne možete ažurirati vrijednost primarnog ključa; Prvo morate izbrisati unos sa originalnog računara i ponovo ga umetnuti sa novom vrednošću. (Ovo je slično drugim PC orijentisanim mašinama za bazu podataka/skladištenje.)
• Bilo koji naredbe UPDATE i DELETE moraju specificirati PC u WHERE, stoga ne može biti praznih DELETE all naredbi - uvijek mora postojati podupit, na primjer: UPDATE xxx WHERE id IN (SELECT id FROM table1)
• Nedostatak opcije automatskog povećanja ili bilo čega sličnog što postavlja sekvencu za PC polje. Da bi ovo funkcioniralo, odgovarajuća vrijednost mora biti kreirana na strani aplikacije.

Sekundarni indeksi?

Google Cloud Spanner ima ugrađenu podršku za sekundarne indekse. Ovo je vrlo zgodna karakteristika koja nije uvijek prisutna u drugim tehnologijama. Apache Kudu trenutno uopće ne podržava sekundarne indekse, a Apache HBase ne podržava indekse direktno, ali ih može dodati preko Apache Phoenixa.

Indeksi u Kudu i HBase-u mogu se modelirati kao zasebna tabela sa različitim sastavom primarnih ključeva, ali atomičnost operacija koje se izvode na nadređenoj tabeli i povezanim indeksnim tabelama mora da se uradi na nivou aplikacije i nije trivijalna za ispravnu implementaciju.

Kao što je spomenuto u pregledu Cloud Spanner-a, njegovi indeksi se mogu razlikovati od MySQL indeksa. Stoga, posebnu pažnju treba posvetiti konstruiranju upita i profiliranju kako bi se osiguralo da se odgovarajući indeks koristi tamo gdje je potreban.

Zastupanje?

Vrlo popularan i koristan objekat u bazi podataka su pogledi. Mogu biti korisni za veliki broj slučajeva upotrebe; moja dva favorita su sloj logičke apstrakcije i sigurnosni sloj. Nažalost, Cloud Spanner NE podržava poglede. Međutim, ovo nas samo djelimično ograničava jer ne postoji granularnost za dozvole pristupa na nivou stupca gdje bi pogledi mogli biti održivo rješenje.

Pogledajte dokumentaciju Cloud Spanner za odjeljak koji detaljno opisuje kvote i ograničenja (ključ/kvote), postoji jedna posebno koja može biti problematična za neke aplikacije: Cloud Spanner iz kutije ima ograničenje od maksimalno 100 baza podataka po instanci. Očigledno, ovo može biti veliko usko grlo za bazu podataka koja je dizajnirana za skaliranje na preko 100 baza podataka. Srećom, nakon razgovora sa našim tehničkim predstavnikom Google-a, saznali smo da se ovo ograničenje može povećati na gotovo bilo koju vrijednost putem Google podrške.

Razvojna podrška?

Cloud Spanner nudi prilično pristojnu podršku za programski jezik za rad sa svojim API-jem. Zvanično podržane biblioteke su u oblastima C#, Go, Java, node.js, PHP, Python i Ruby. Dokumentacija je prilično detaljna, ali kao i kod drugih naprednih tehnologija, zajednica je prilično mala u odnosu na najpopularnije tehnologije baza podataka, što može dovesti do više vremena utrošenog na rješavanje manje uobičajenih slučajeva korištenja ili problema.

Dakle, što je s podrškom lokalnom razvoju?

Nismo pronašli način da kreiramo Cloud Spanner instancu lokalno. Najbliža stvar koju smo dobili je Docker slika. cockroachDB, koji je u principu sličan, ali u praksi veoma različit. Na primjer, CockroachDB može koristiti PostgreSQL JDBC. Pošto razvojno okruženje treba da bude što bliže proizvodnom okruženju, Cloud Spanner nije idealan jer se mora oslanjati na punu Spanner instancu. Da biste uštedjeli troškove, možete odabrati instancu za jednu regiju.

Podrška administraciji?

Kreiranje Cloud Spanner instance je vrlo jednostavno. Vi samo trebate izabrati između kreiranja instance sa više regija ili jedne regije, specificirati region(e) i broj čvorova. Za manje od minute vaša instanca će biti pokrenuta.

Nekoliko rudimentarnih metrika je direktno dostupno sa stranice Spanner u Google konzoli. Detaljniji prikazi dostupni su preko Stackdrivera, gdje također možete postaviti metričke pragove i politike upozorenja.

Pristup resursima?

MySQL nudi opsežna i vrlo detaljna podešavanja za korisničke dozvole/uloge. Možete lako konfigurisati pristup određenoj tabeli, ili čak samo podskupu njenih kolona. Cloud Spanner koristi Googleov alat za upravljanje identitetom i pristupom (IAM), koji vam omogućava samo postavljanje pravila i dozvola na vrlo visokom nivou. Najpreciznija opcija je rezolucija na razini baze podataka, koja se ne uklapa u većinu slučajeva upotrebe u proizvodnji. Ovo ograničenje vas prisiljava da dodate dodatne sigurnosne mjere vašem kodu, infrastrukturi ili oboje kako biste spriječili neovlašteno korištenje Spanner resursa.

Sigurnosne kopije?

Pojednostavljeno rečeno, u Cloud Spanner-u nema rezervnih kopija. Iako Googleovi visoki SLA zahtjevi mogu osigurati da ne izgubite nikakve podatke zbog kvarova hardvera ili baze podataka, ljudskih grešaka, defekata aplikacija, itd. Svi znamo pravilo: visoka dostupnost nije zamjena za dobru strategiju sigurnosnog kopiranja. Trenutno, jedini način da napravite sigurnosnu kopiju podataka je da ih programski strimujete iz baze podataka u zasebno okruženje za skladištenje.

Učinak upita?

Koristili smo Yahoo! za učitavanje podataka i testiranje upita. Cloud Serving Benchmark. Tabela ispod prikazuje YCSB radno opterećenje B sa omjerom čitanja od 95% prema 5% pisanja.

* Test opterećenja je izveden na n1-standard-32 Compute Engine (CE) (32 vCPU, 120 GB memorije), a testna instanca nikada nije predstavljala usko grlo u testovima.
** Maksimalan broj niti u jednoj YCSB instanci je 400. Ukupno je trebalo pokrenuti šest paralelnih instanci YCSB testova da bi se dobilo ukupno 2400 niti.

Gledajući benchmark rezultate, posebno kombinaciju opterećenja CPU-a i TPS-a, možemo jasno vidjeti da Cloud Spanner prilično dobro skalira. Veliko opterećenje stvoreno velikim brojem niti je nadoknađeno velikim brojem čvorova u klasteru Cloud Spanner. Iako latencija izgleda prilično visoka, posebno kada se radi sa 2400 niti, ponovno testiranje sa 6 manjih instanci računarskog mehanizma može biti potrebno da bi se dobili precizniji brojevi. Svaka instanca će pokrenuti jedan YCSB test umjesto jedne velike CE instance sa 6 paralelnih testova. Na ovaj način će biti lakše razlikovati kašnjenje zahtjeva za Cloud Spanner i kašnjenje koje dodaje mrežna veza između Cloud Spannera i CE instance koja pokreće test.

Kako Cloud Spanner funkcionira kao OLAP?

Particioniranje?

Podjela podataka na fizički i/ili logički nezavisne segmente, zvane particije, vrlo je popularan koncept koji se nalazi u većini OLAP motora. Particije mogu značajno poboljšati performanse upita i održavanje baze podataka. Ići dublje u particioniranje bi bio zaseban(i) članak(i), pa hajde da spomenemo samo važnost postojanja šeme particioniranja i podparticioniranja. Sposobnost razlaganja podataka na particije i još dalje na podparticije ključna je za performanse analitičkog upita.

Cloud Spanner ne podržava particije kao takve. Interno dijeli podatke na tzv Split-s bazirane na rasponima primarnog ključa. Particioniranje se izvodi automatski kako bi se izbalansiralo opterećenje u klasteru Cloud Spanner. Veoma korisna karakteristika Cloud Spanner-a je podela osnovnog opterećenja roditeljske tabele (tabela koja nije isprepletena sa drugom). Spanner automatski otkriva da li sadrži Split podatke koji se čitaju češće od podataka u drugima Split-ah, i može odlučiti o daljem razdvajanju. Na ovaj način, više čvorova može biti uključeno u zahtjev, što također efektivno povećava propusnost.

Učitavanje podataka?

Metoda Cloud Spanner za masovne podatke je ista kao i za normalno učitavanje. Da biste postigli maksimalan učinak, morate slijediti neke smjernice, uključujući:

• Sortirajte svoje podatke po primarnom ključu.
• Podijelite ih sa 10*broj čvorova odvojene sekcije.
• Kreirajte skup radnih zadataka koji paralelno učitavaju podatke.

Ovo učitavanje podataka koristi sve Cloud Spanner čvorove.

Koristili smo YCSB radno opterećenje A da generišemo skup podataka od 10M redova.

* Test opterećenja je pokrenut na računarskoj mašini n1-standard-32 (32 vCPU, 120 GB memorije), a testna instanca nikada nije bila usko grlo u testovima.
**Postavljanje jednog čvora se ne preporučuje za bilo koje proizvodno opterećenje.

Kao što je gore spomenuto, Cloud Spanner automatski obrađuje podjele na osnovu njihovog opterećenja, tako da se rezultati poboljšavaju nakon nekoliko uzastopnih ponavljanja testa. Ovdje predstavljeni rezultati su najbolji rezultati koje smo dobili. Gledajući gore navedene brojeve, možemo vidjeti kako se Cloud Spanner skalira (dobro) kako se broj čvorova u klasteru povećava. Brojevi koji se ističu su izuzetno niske prosječne latencije, koje su u suprotnosti s rezultatima za mješovita opterećenja (95% čitanja i 5% pisanja) kao što je opisano u gornjem dijelu.

Skaliranje?

Povećanje i smanjenje broja Cloud Spanner čvorova je zadatak jednim klikom. Ako želite brzo učitati podatke, razmislite o tome da povećate svoju instancu do maksimuma (u našem slučaju to je bilo 25 čvorova u US-EAST regiji), a zatim smanjite broj čvorova koji ispunjavaju uslove za vaše normalno učitavanje nakon što svi podaci budu u bazu podataka, pozivajući se na ograničenje od 2TB/čvor.

Podsjetili smo se na ovo ograničenje čak i sa mnogo manjom bazom podataka. Nakon nekoliko pokretanja testova opterećenja, naša baza podataka je bila veličine oko 155 GB, a kada se smanjila na 1 instancu čvora, dobili smo sljedeću grešku:

Uspjeli smo smanjiti s 25 na 2 instance, ali smo zapeli na dva čvora.

Povećanje i smanjenje broja čvorova u klasteru Cloud Spanner može se automatizirati korištenjem REST API-ja. Ovo može biti posebno korisno za smanjenje povećanog opterećenja sistema tokom radnog vremena.

Performanse OLAP upita?

Prvobitno smo planirali da potrošimo značajnu količinu vremena na našu procjenu Spannera na ovom dijelu. Nakon nekoliko SELECT COUNTs, odmah smo shvatili da će testiranje biti kratko i da Spanner NEĆE biti prikladan motor za OLAP. Bez obzira na broj čvorova u klasteru, jednostavno odabiranje broja redova u tabeli od 10M redova trajalo je između 55 i 60 sekundi. Dodatno, svaki upit koji je zahtijevao više memorije za pohranjivanje međurezultata nije uspio s OOM greškom.

SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.

Neki brojevi za TPC-H upite mogu se naći u članku Todda Lipcona Nosql-kudu-spanner-slides.html, slajdovi 42 i 43. Ovi brojevi su u skladu s našim vlastitim rezultatima (nažalost).

4. Naši zaključci

S obzirom na trenutno stanje funkcija Cloud Spanner-a, teško je zamisliti da je to jednostavna zamjena za vaše postojeće OLTP rješenje, posebno kada ga vaše potrebe prerastu. Trebalo bi utrošiti značajnu količinu vremena na izgradnju rješenja u skladu sa nedostacima Cloud Spanner-a.

Kada smo počeli procjenjivati ​​Cloud Spanner, očekivali smo da će njegove funkcije upravljanja biti u rangu, ili barem ne previše udaljene od drugih Google SQL rješenja. Ali bili smo iznenađeni potpunim nedostatkom rezervnih kopija i vrlo ograničenom kontrolom pristupa resursima. Da ne spominjemo nikakve poglede, lokalno razvojno okruženje, nepodržane sekvence, JDBC bez DML i DDL podrške, itd.

Dakle, gdje ide neko ko treba da skalira transakcijsku bazu podataka? Čini se da na tržištu ne postoji jedinstveno rješenje koje odgovara svim slučajevima upotrebe. Postoje mnoga rješenja zatvorenog i otvorenog koda (od kojih su neka spomenuta u ovom članku), svako sa svojim prednostima i slabostima, ali nijedno od njih ne nudi SaaS sa 99,999% SLA i visokom konzistentnošću. Ako je visok SLA vaš glavni cilj i niste skloni izradi prilagođenog rješenja za više oblaka, Cloud Spanner može biti rješenje koje tražite. Ali trebali biste biti svjesni svih njegovih ograničenja.

Da budemo pošteni, Cloud Spanner je objavljen tek u proljeće 2017. godine, tako da je razumno očekivati ​​da bi neki od njegovih trenutnih nedostataka na kraju mogli nestati (nadamo se), a kada to učine, to bi moglo promijeniti igru. Uostalom, Cloud Spanner nije samo sporedni projekat za Google. Google ga koristi kao osnovu za druge Google proizvode. A kada je Google nedavno zamijenio Megastore u Google Cloud Storageu sa Cloud Spannerom, omogućio je da Google Cloud Storage postane visoko dosljedan za liste objekata na globalnoj razini (što još uvijek nije slučaj za Amazon S3).

Dakle, još ima nade... nadamo se.

To je sve. Kao i autor članka, i mi se i dalje nadamo, ali šta mislite o ovome? Pišite u komentarima

Pozivamo sve da posjete našu besplatni webinar u okviru koje ćemo vam detaljno reći o kursu "AWS za programere" od OTUS-a.

izvor: www.habr.com