Salutami, Khabrovites. Tradizionalmente, cuntinuemu à sparte materiale interessante à a vigilia di l'iniziu di novi corsi. Oghje, soprattuttu per voi, avemu traduttu un articulu nantu à Google Cloud Spanner, cronometratu per coincide cù u lanciamentu di u corsu. .
Originariamente publicatu in .
Cum'è una sucietà chì offre una varietà di soluzioni POS basate in nuvola per i rivenditori, i risturatori è i cummircianti in linea in u mondu, Lightspeed usa diversi tipi di piattaforme di basa di dati per una varietà di casi di transazzione, analitiche è di ricerca. Ciascuna di queste piattaforme di basa di dati hà i so punti di forza è di debule, per quessa, quandu Google hà introduttu Cloud Spanner à u mercatu - caratteristiche promettenti mai vistu prima in u mondu di basa di dati relazionale, cum'è scalabilità horizontale virtualmente illimitata è un accordu di livellu di serviziu (SLA) di 99,999%. , Ùn pudemu micca lasciate l'oppurtunità di avè ella in e nostre mani !
Per dà una visione generale di a nostra sperienza cù Cloud Spanner, è ancu di i criteri di valutazione chì avemu usatu, copreremu i seguenti temi:
- I nostri criteri di valutazione
- Cloud Spanner in poche parole
- A nostra valutazione
- I nostri risultati
1. I nostri criteri di valutazione
Prima di immersione in e specificità di Cloud Spanner, e so similitudini è e so differenze cù altre soluzioni in u mercatu, parlemu prima di i casi d'usu principali chì avemu avutu in mente quandu cunsiderà induve implementà Cloud Spanner in a nostra infrastruttura:
- Cum'è un sustitutu per a suluzione tradiziunale di basa di dati SQL (prevalente).
- Cum'è una suluzione OLTP cù supportu OLAP
Nutate bè: Per facilità di paragone, questu articulu paraguna Cloud Spanner cù e varianti MySQL di e famiglie di soluzioni GCP Cloud SQL è Amazon AWS RDS.
Utilizendu Cloud Spanner cum'è sustituzione per una soluzione tradiziunale di basa di dati SQL
In l'ambienti tradiziunale basa di dati, quandu u tempu di risposta per una dumanda di basa di dati si avvicina o ancu supera i limiti di l'applicazione predefiniti (principalmente per un aumentu di u numeru di utilizatori è / o richieste), ci sò parechje manere di riduce u tempu di risposta à livelli accettabili. Tuttavia, a maiò parte di sti suluzioni implicanu intervenzione manuale.
Per esempiu, u primu passu da piglià hè di guardà e diverse paràmetri di basa di dati in relazione à u rendiment è sintonizzale per cuncordà megliu i mudelli di scenarii d'usu di l'applicazione. Se questu ùn hè micca abbastanza, pudete sceglie di scala a basa di dati verticalmente o horizontale.
A scala di una applicazione implica l'aghjurnà l'istanza di u servitore, tipicamente aghjunghjendu più processori / core, più RAM, almacenamentu più veloce, etc. L'aghjunzione di più risorse hardware si traduce in un rendimentu di basa di dati aumentatu, misuratu principarmenti in transazzione per seconda, è a latenza di transazzione per i sistemi OLTP. Sistemi di basa di dati relazionale (chì utilizanu un approcciu multi-threaded) cum'è MySQL scala bè verticalmente.
Ci hè parechje svantaghji à questu approcciu, ma u più evidenti hè a dimensione massima di u servitore in u mercatu. Quandu u limitu più grande di l'istanza di u servitore hè righjuntu, ci hè solu un percorsu lasciatu: scala.
Scale-out hè un approcciu chì aghjunghje più servitori à un cluster per aumentà idealmente u rendiment lineale cum'è più servitori sò aghjuntu. Maiurità tradiziunale I sistemi di basa di dati ùn scalanu micca bè o ùn scalanu micca in tuttu. Per esempiu, MySQL pò scala per leghje aghjunghjendu lettori slave, ma ùn pò micca scala per scrive.
Per d 'altra banda, per via di a so natura, Cloud Spanner pò facilmente scala horizontale cù intervenzione minima.
Full featured DBMS cum'è serviziu deve esse valutatu da diverse prospettive. Comu basa, avemu pigliatu u DBMS più populari in u nuvulu - per Google, GCP Cloud SQL è per Amazon, AWS RDS. In a nostra valutazione, avemu focu annantu à e seguenti categurie:
- Cartografia di funziunalità: estensione SQL, DDL, DML; biblioteche di cunnessione / connettori, supportu di transazzione, etc.
- Supportu di sviluppu: Facilità di sviluppu è teste.
- Supportu di Amministrazione: Gestione di l'istanze cum'è scaling up/down and upgrading instances; SLA, salvezza è ricuperazione; cuntrollu di sicurità / accessu.
Utilizendu Cloud Spanner cum'è una Soluzione OLTP attivata per OLAP
Mentre Google ùn dice micca esplicitamente chì Cloud Spanner hè per l'analitiche, sparte certi attributi cù altri motori cum'è Apache Impala & Kudu è YugaByte chì sò pensati per carichi di travagliu OLAP.
Ancu s'ellu ci era solu una piccula chance chì Cloud Spanner includia un mutore HTAP (Hybrid Transactional/Analytic Processing) in scala coherente cù un set di funzioni OLAP (più o menu) utilizable, pensemu chì meritaria a nostra attenzione.
In questu in mente, avemu guardatu e seguenti categurie:
- Carica di dati, indici è supportu di partizionamentu
- Prestazione di dumanda è DML
2. Cloud Spanner in a Nutshell
Google Spanner hè un sistema di gestione di basa di dati relazionale clustered (RDBMS) chì Google usa per parechji di i so servizii. Google l'hà fattu publicamente dispunibule per l'utilizatori di Google Cloud Platform à principiu di 2017.
Eccu alcuni di l'attributi di Cloud Spanner:
- Cluster RDBMS Altamente Coerente, Scalable: Utiliza a sincronizazione di u tempu di hardware per assicurà a coerenza di e dati.
- Supportu di transazzione cross-table: e transazzioni ponu spannà parechje tavule - micca necessariamente limitate à una sola tabella (cuntrariu di Apache HBase o Apache Kudu).
- Tavule basate nantu à a chjave primaria: Tutte e tavule devenu avè una Chjave Primaria (PC) dichjarata, chì pò esse composta da parechje colonne di tavule. I dati tabulari sò almacenati in ordine di PC, chì a rende assai efficace è veloce per e ricerche di PC. Cum'è cù altri sistemi basati in PC, l'implementazione deve esse modellata contr'à casi d'usu preconceived per ottene .
- Tavule strisciate: I tavulini ponu avè dipendenze fisiche l'una di l'altru. E fila di a tavola di u zitellu pò esse cumminata cù e fila di a tavola parent. Stu approcciu accelera a ricerca di rilazioni chì ponu esse determinate in u stadiu di modellazione di dati, per esempiu, quandu si mette i clienti è e so fatture inseme.
- Indici: Cloud Spanner supporta indici secundari. Un indice hè custituitu da e colonne indiciate è tutte e colonne PC. Opcionalmente, l'indici pò ancu cuntene altre colonne non-indiciate. L'indici pò esse interleaved cù a tavola parent per accelerà e dumande. Diversi restrizioni s'applicanu à l'indici, cum'è u numeru massimu di culonni supplementari chì ponu esse guardati in un indici. Inoltre, e dumande à traversu l'indici pò esse micca cusì simplici cum'è in altri RDBMS.
"Cloud Spanner selezziunate un indice automaticamente solu in casi rari. In particulare, Cloud Spanner ùn selezziunà micca automaticamente un indice secundariu se a dumanda dumanda una colonna chì ùn hè micca almacenata in ».
- Accordu di Livellu di serviziu (SLA): Implementazione di una sola regione cù 99,99% SLA; implementazioni multi-regione cù 99,999% SLA. Mentre chì u SLA stessu hè solu un accordu è micca una guaranzia di ogni tipu, crede chì a ghjente di Google hà qualchi dati duru per fà una pretensione cusì forte. (Per riferimentu, 99,999% significa 26,3 seconde di tempu d'inattività di serviziu per mese.)
- Più:
Nutate bè: U prughjettu Apache Tephra aghjusta un supportu avanzatu di transazzione à Apache HBase (ancu implementatu in Apache Phoenix cum'è beta).
3. A nostra valutazione
Dunque, tutti avemu lettu dichjarazioni di Google nantu à i benefici di Cloud Spanner - scala horizontale praticamente illimitata mentre mantene una alta coerenza è un SLA assai altu. Ancu s'è sti rivindicazioni sò, in ogni casu, estremamente difficiuli di ghjunghje, u nostru scopu ùn era micca di sbulicà. Invece, focalizemu nantu à altre cose chì a maiò parte di l'utilizatori di basa di dati curanu: parità è usabilità.
Avemu valutatu Cloud Spanner cum'è un sustitutu di Sharded MySQL
Google Cloud SQL è Amazon AWS RDS, duie di e basa di dati OLTP più populari in u mercatu di nuvola, anu un set di funzioni assai grande. Tuttavia, per scala queste basa di dati oltre a dimensione di un unicu node, avete bisognu di eseguisce a splitting di l'applicazione. Stu approcciu crea una cumplessità addiziale per l'applicazioni è l'amministrazione. Avemu vistu cumu Spanner si inserisce in u scenariu di cumminà parechji frammenti in una sola istanza è quali caratteristiche (se ci hè) puderanu esse sacrificate.
Supportu per SQL, DML è DDL, è ancu u cunnessu è e librerie?
Prima, quandu principia cù qualsiasi basa di dati, avete bisognu di creà un mudellu di dati. Se pensate chì pudete cunnette JDBC Spanner à u vostru strumentu SQL preferitu, truverete chì pudete interrogà i vostri dati cun ellu, ma ùn pudete micca aduprà per creà una tabella o aghjurnamentu (DDL) o qualsiasi inserimentu / aghjurnamentu / sguassate. operazioni (DML). JDBC ufficiale di Google ùn supporta nè.
"I cunduttori ùn supportanu attualmente dichjarazioni DML o DDL".
Documentazione di Spanner
A situazione ùn hè micca megliu cù a cunsola GCP - pudete solu mandà dumande SELECT. Per furtuna, ci hè un driver JDBC cù supportu DML è DDL da a cumunità, cumprese transacciones . Mentre chì stu driver hè estremamente utile, l'assenza di u propiu driver JDBC di Google hè sorprendente. Fortunatamente, Google offre un supportu di libreria di cliente abbastanza largu (basatu nantu à gRPC): C#, Go, Java, node.js, PHP, Python è Ruby.
L'usu quasi ubligatoriu di l'API persunalizati di Cloud Spanner (per via di a mancanza di DDL è DML in JDBC) si traduce in alcune limitazioni per e aree di codice cunnesse, cum'è l'agrupazione di cunnessione o i quadri di basa di dati (cum'è Spring MVC). In generale, quandu aduprate JDBC, site liberu di sceglie a vostra piscina di cunnessione preferita (per esempiu HikariCP, DBCP, C3PO, etc.) chì hè pruvatu è funziona bè. In u casu di l'API di Spanner persunalizati, avemu da cunfidassi in frameworks / binding / pools di sessione chì avemu creatu noi stessi.
U disignu orientatu à a chjave primaria (PC) permette à Cloud Spanner d'esse assai veloce quandu accede à e dati via u PC, ma ancu introduce alcune questioni di quistione.
- Ùn pudete micca aghjurnà u valore di una chjave primaria; Duvete prima sguassà l'entrata di u PC originale è reinserite cù u novu valore. (Questu hè simile à l'altri basa di dati / mutori di almacenamiento orientati à PC.)
- Ogni dichjarazione UPDATE è DELETE deve specificà u PC in u WHERE, per quessa, ùn pò micca esse vuote DELETE tutte e dichjarazioni - ci deve esse sempre una sottoquestione, per esempiu: UPDATE xxx WHERE id IN (SELECT id FROM table1)
- Mancanza di una opzione auto-incrementu o qualcosa simili chì stabilisce a sequenza per u campu di PC. Per fà questu, u valore currispundente deve esse creatu da u latu di l'applicazione.
Indici secondari ?
Google Cloud Spanner hà un supportu integratu per l'indici secundari. Questa hè una funzione assai bella chì ùn hè micca sempre presente in altre tecnulugia. Apache Kudu ùn sustene micca l'indici secundarii in tuttu, è Apache HBase ùn sustene micca l'indici direttamente, ma pò aghjunghje via Apache Phoenix.
L'indici in Kudu è HBase ponu esse modellati cum'è una tavola separata cù una cumpusizioni differenti di chjavi primari, ma l'atomicità di l'operazioni realizate nantu à a tavola parent è e tavule d'indici rilativi deve esse realizatu à u livellu di l'applicazione è ùn hè micca triviale per implementà currettamente.
Comu citatu in a rivista di Cloud Spanner, i so indici pò esse diffirenti da l'indici MySQL. Cusì, una cura particulare deve esse presa in a custruzzione di e dumande è u prufilu per assicurà chì l'indici curretti hè utilizatu induve hè necessariu.
Rapprisintà ?
Un ughjettu assai populari è utile in una basa di dati hè vista. Puderanu esse utili per un gran numaru di casi d'usu; i mo dui preferiti sò a strata di astrazione logica è a strata di sicurità. Sfortunatamente, Cloud Spanner ùn sustene micca e viste. Tuttavia, questu ci limita solu parzialmente, postu chì ùn ci hè micca una granularità à livellu di colonna per i permessi d'accessu induve a vista pò esse una suluzione accettabile.
Vede a documentazione di Cloud Spanner per una sezione chì detalla quote è limiti (), ci hè unu in particulare chì pò esse problematicu per alcune applicazioni: Cloud Spanner fora di a scatula hà un massimu di 100 basa di dati per esempiu. Ovviamente, questu pò esse un ostaculu maiò per una basa di dati chì hè pensata per scala à più di 100 basa di dati. Per furtuna, dopu avè parlatu cù u nostru rappresentante tecnicu di Google, avemu scupertu chì stu limitu pò esse aumentatu à quasi ogni valore attraversu Google Support.
Supportu à u sviluppu?
Cloud Spanner offre un supportu di lingua di prugrammazione abbastanza decentu per travaglià cù a so API. E biblioteche supportate ufficialmente sò in l'area di C#, Go, Java, node.js, PHP, Python è Ruby. A ducumentazione hè abbastanza dettagliata, ma cum'è cù l'altri tecnulugii di punta, a cumunità hè abbastanza chjuca paragunata à e tecnulugia di basa di dati più populari, chì ponu risultatu in più tempu passatu in casi o prublemi d'usu menu cumuni.
Allora chì hè di u sustegnu di u sviluppu lucale ?
Ùn avemu micca truvatu un modu per creà una istanza di Cloud Spanner in situ. U più vicinu chì avemu avutu hè una maghjina Docker chì hè simile in principiu, ma assai sfarente in pratica. Per esempiu CockroachDB pò aduprà PostgreSQL JDBC. Siccomu l'ambiente di sviluppu duveria esse u più vicinu pussibule à l'ambiente di produzzione, Cloud Spanner ùn hè micca ideale perchè avete bisognu di cunfidassi in una istanza di Spanner cumpleta. Per risparmià i costi, pudete selezziunate una sola istanza di regione.
Supportu di l'amministrazione ?
Crià una istanza di Cloud Spanner hè assai simplice. Basta à sceglie trà creà una istanza multi-regione o una sola regione, specificà a regione (s) è u numeru di nodi. In menu di un minutu, l'istanza sarà in funzione.
Diversi metrichi elementari sò direttamente dispunibili nantu à a pagina Spanner in a Console di Google. Viste più dettagliate sò dispunibuli via Stackdriver, induve pudete ancu stabilisce soglie metriche è pulitiche d'alerta.
Accessu à e risorse?
MySQL offre ampiezza è assai granulare permissione di l'utilizatori / paràmetri di rolu. Pudete facilmente persunalizà l'accessu à una tavola specifica, o ancu solu un subset di e so colonne. Cloud Spanner usa l'uttene Google Identity & Access Management (IAM), chì permette solu di stabilisce pulitiche è permessi à un livellu assai altu. L'opzione più granulare hè u permessu à livellu di basa di dati, chì ùn si mette micca in a maiò parte di i casi di produzzione. Questa restrizione vi obliga à aghjunghje misure di sicurezza supplementari à u vostru codice, infrastruttura, o tramindui per impedisce l'usu micca autorizatu di e risorse Spanner.
Backups?
Per esse simplicemente, ùn ci hè micca copia di salvezza in Cloud Spanner. Mentre chì l'alti requisiti di SLA di Google pò assicurà chì ùn perde micca alcuna dati per via di fallimenti di hardware o di basa di dati, errore umanu, difetti di l'applicazione, etc. Tutti sapemu a regula: l'alta dispunibilità ùn hè micca sustitutu per una strategia di salvezza intelligente. Attualmente, l'unicu modu per fà una copia di salvezza di e dati hè di trasmette programaticamente da a basa di dati à un ambiente di almacenamiento separatu.
Interrogazione di prestazione?
Avemu usatu Yahoo! per carricà dati è testà e dumande. Cloud Serving Benchmark. A tavula sottu mostra a carica di travagliu B YCSB cù un rapportu di scrittura di 95% di lettura à 5%.
* A prova di carica hè stata eseguita nantu à n1-standard-32 Compute Engine (CE) (32 vCPU, 120 GB di memoria) è l'istanza di prova ùn hè mai statu u collu di bottiglia in i testi.
** U numaru massimu di filamenti in una istanza YCSB hè 400. In totale, sei casi paralleli di testi YCSB anu da esse eseguiti per ottene un totale di filamenti 2400.
Fighjendu i risultati di benchmark, in particulare a cumminazzioni di CPU load and TPS, pudemu vede chjaramente chì Cloud Spanner scala abbastanza bè. A grande carica creata da un gran numaru di fili hè cumpensata da un gran numaru di nodi in u cluster Cloud Spanner. Ancu s'è a latenza pare abbastanza alta, soprattuttu quandu si esegue à 2400 fili, pò esse necessariu di retestà cù 6 casi più chjuchi di u mutore di calculu per ottene numeri più precisi. Ogni istanza eseguirà una prova YCSB invece di una grande istanza CE cù 6 teste parallele. Questu facilita a distinzione trà i ritardi di dumanda di Cloud Spanner è i ritardi aghjuntu da a cunnessione di rete trà Cloud Spanner è l'istanza CE chì esegue a prova.
Cumu funziona Cloud Spanner cum'è OLAP?
Spartizione ?
Dividing data in segmenti fisicamenti è / o logicamente indipendenti, chjamati partizioni, hè un cuncettu assai populari chì si trova in a maiò parte di i motori OLAP. E partizioni ponu migliurà assai u rendiment di e dumande è a manutenibilità di a basa di dati. A più approfondita in u particionamentu seria un articulu (s) separatu (s), allora circhemu solu l'impurtanza di avè un schema di partizionamentu è sub-partitioning. A capacità di split data in partizioni è ancu più in sub-partizioni hè chjave per u rendiment di e dumande analitiche.
Cloud Spanner ùn sustene micca partizioni per sè. Si separa dati internu in cusì-chiamatu Split-s basati nantu à intervalli di chjave primaria. A partizione hè fatta automaticamente per equilibrà a carica nantu à u cluster Cloud Spanner. Una funzione assai utile di Cloud Spanner hè di sparte a carica di basa di una tavola parent (una tavola chì ùn hè micca interleaved cù un altru). Spanner rileva automaticamente s'ellu cuntene Split dati chì sò leghjite più freti chè dati in altri Split-ah, è pò decide di una separazione ulteriore. Cusì, più nodi ponu esse implicati in una dumanda, chì ancu aumenta in modu efficace u throughput.
Caricà i dati?
U metudu Cloud Spanner per i dati bulk hè u listessu cum'è per un upload regular. Per u massimu rendiment, avete bisognu di seguità alcune linee guida, cumprese:
- Ordine i vostri dati per chjave primaria.
- Divideli per 10*numeru di nodi sezioni individuali.
- Crea un settore di travaglii di u travagliu chì carica dati in parallelu.
Questa carica di dati usa tutti i nodi Cloud Spanner.
Avemu usatu a carica di travagliu A YCSB per generà un dataset di fila 10M.
* A prova di carica hè stata eseguita nantu à u mutore di compute n1-standard-32 (32 vCPU, 120 GB di memoria) è l'istanza di prova ùn hè mai statu u collu di bottiglia in i testi.
** Una configurazione di 1 nodu ùn hè micca cunsigliatu per qualsiasi carichi di travagliu di produzzione.
Cumu l'esitatu sopra, Cloud Spanner processa automaticamente splits secondu a so carica, cusì i risultati migliurà dopu à parechje iterazioni consecutivi di a prova. I risultati presentati quì sò i migliori risultati chì avemu ricevutu. Fighjendu i numeri sopra, pudemu vede cumu Cloud Spanner scala (bene) cum'è u numeru di nodi in u cluster aumenta. I numeri chì si distinguenu sò una latenza media estremamente bassa, chì cuntrasta cù i risultati di carichi di travagliu misti (95% di lettura è 5% di scrittura) cum'è descrittu in a sezione sopra.
Scala ?
Aumentà è diminuite u numeru di nodi Cloud Spanner hè un compitu di un clic. Se vulete carricà e dati rapidamente, pudete vulete cunsiderà à rinfurzà l'istanza à u massimu (in u nostru casu era 25 nodi in a regione US-EAST) è dopu riduce u numeru di nodi adattati per a vostra carica normale dopu à tutti i dati. in a basa di dati, tenendu in mente u limitu di 2 TB / node.
Ci hè statu ricurdatu di questu limitu ancu cù una basa di dati assai più chjuca. Dopu à parechje teste di carica, a nostra basa di dati era di circa 155 GB di dimensione, è quandu hè scalatu à una istanza di 1 nodu, avemu avutu u seguente errore:
Pudemu scalate da 25 à 2 casi, ma simu chjappi nantu à dui nodi.
Aumentà è diminuite u numeru di nodi in un cluster Cloud Spanner pò esse automatizatu cù l'API REST. Questu pò esse particularmente utile per riduce a carica aumentata nantu à u sistema durante l'ore occupate.
Prestazione di dumanda OLAP?
In origine, avemu pensatu di dedicà un tempu considerableu à a nostra valutazione di Spanner da questa parte. Dopu uni pochi di SELECT COUNTs, avemu capitu subitu chì a prova seria corta è chì Spanner ùn saria micca un mutore adattatu per OLAP. Indipendentemente da u nùmeru di nodi in u cluster, solu sceglie u nùmeru di fila in una tavola di fila 10M hà pigliatu da 55 à 60 seconde. Inoltre, ogni dumanda chì necessitava più memoria per almacenà risultati intermedi falliu cù un errore OOM.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Certi numeri per e dumande TPC-H ponu esse truvati in l'articulu di Todd Lipcon , slides 42 è 43. Questi numeri sò coerenti cù i nostri risultati (sfurtunatamente).
4. I nostri scuperti
Data u statu attuale di e funzioni di Cloud Spanner, hè difficiule di vede cum'è un sustitutu simplice per una soluzione OLTP esistente, soprattuttu quandu i vostri bisogni superanu. Una quantità significativa di tempu duveria esse spesa à custruisce una soluzione intornu à e carenze di Cloud Spanner.
Quandu avemu cuminciatu à valutà Cloud Spanner, avemu aspittatu chì e so funzioni di gestione sò à parità, o almenu micca luntanu da, altre soluzioni Google SQL. Ma avemu statu sorpresu da a mancanza cumpleta di backups è un cuntrollu di accessu assai limitatu à e risorse. Per ùn dì micca di vista, senza ambiente di sviluppu lucale, sequenze senza supportu, JDBC senza supportu DML è DDL, etc.
Allora, induve andà per qualchissia chì hà bisognu di scala una basa di dati transazzione? Ùn pare micca esse una solu suluzione nantu à u mercatu chì si adatta à tutti i casi d'usu. Ci sò parechje suluzioni chjusi è aperti (alcuni di quali sò citati in questu articulu), ognunu cù i so punti di forza è debule, ma nimu offre SaaS cù un SLA 99,999% è un altu gradu di coerenza. Se un altu SLA hè u vostru scopu primariu è ùn site micca inclinu à custruisce a vostra propria suluzione per parechje nuvole, Cloud Spanner puderia esse a suluzione chì cercate. Ma duvete esse cuscenti di tutte e so limitazioni.
Per esse ghjustu, Cloud Spanner hè statu liberatu à u publicu solu in a primavera di u 2017, cusì hè ragiunate di aspittà chì alcuni di i so difetti attuali puderanu eventualmente sparisce (sperendu), è quandu si faci, puderia esse un cambiamentu di ghjocu. Dopu tuttu, Cloud Spanner ùn hè micca solu un prughjettu laterale per Google. Google l'utilice cum'è a basa per altri prudutti di Google. È quandu Google hà recentemente rimpiazzatu Megastore in Google Cloud Storage cù Cloud Spanner, hà permessu à Google Cloud Storage di diventà assai coherente per listi d'ogetti à scala globale (chì ùn hè ancu micca u casu per ).
Allora, ci hè sempre a speranza... speramu.
Eccu tuttu. Cum'è l'autore di l'articulu, cuntinuemu ancu à sperà, ma chì ne pensate di questu? Scrivite in i cumenti
Invitemu tutti à visità u nostru in quale vi cuntaremu in dettagliu nantu à u corsu da OTUS.
Source: www.habr.com