Hola, Khabrovites. Tradicionalment, seguim compartint material interessant la vigília de l'inici de nous cursos. Avui, especialment per a tu, hem traduït un article sobre Google Cloud Spanner, programat coincidint amb el llançament del curs .
Publicat originalment a .
Com a empresa que ofereix una varietat de solucions de TPV basades en núvol per a minoristes, restauradors i comerciants en línia de tot el món, Lightspeed utilitza diversos tipus diferents de plataformes de bases de dades per a una varietat de casos d'ús transaccionals, analítics i de cerca. Cadascuna d'aquestes plataformes de bases de dades té els seus propis punts forts i febles. Per tant, quan Google va introduir Cloud Spanner al mercat, funcions prometedores mai vistes abans al món de les bases de dades relacionals, com ara una escalabilitat horitzontal pràcticament il·limitada i un acord de nivell de servei (SLA) del 99,999%. , No podíem deixar passar l'oportunitat de tenir-la a les nostres mans!
Per oferir una visió general completa de la nostra experiència amb Cloud Spanner, així com dels criteris d'avaluació que hem utilitzat, tractarem els següents temes:
- Els nostres criteris d'avaluació
- Cloud Spanner en poques paraules
- La nostra valoració
- Les nostres conclusions
1. Els nostres criteris d'avaluació
Abans d'endinsar-nos en les especificitats de Cloud Spanner, les seves similituds i diferències amb altres solucions del mercat, primer parlem dels principals casos d'ús que teníem en ment a l'hora de plantejar-nos on implementar Cloud Spanner a la nostra infraestructura:
- Com a reemplaçament de la solució de base de dades SQL tradicional (prevalent).
- Com a solució OLTP habilitat per OLAP
Nota: Per facilitar la comparació, aquest article compara Cloud Spanner amb les variants de MySQL de les famílies de solucions GCP Cloud SQL i Amazon AWS RDS.
Utilitzant Cloud Spanner com a reemplaçament d'una solució de base de dades SQL tradicional
En el medi ambient tradicional bases de dades, quan el temps de resposta per a una consulta de base de dades s'acosta o fins i tot supera els llindars d'aplicació predefinits (principalment a causa d'un augment del nombre d'usuaris i/o de sol·licituds), hi ha diverses maneres de reduir el temps de resposta a nivells acceptables. Tanmateix, la majoria d'aquestes solucions impliquen una intervenció manual.
Per exemple, el primer pas a fer és mirar els diferents paràmetres de la base de dades relacionats amb el rendiment i ajustar-los per adaptar-los millor als patrons d'escenari d'ús de l'aplicació. Si això no és suficient, podeu triar escalar la base de dades verticalment o horitzontalment.
Ampliar una aplicació implica actualitzar la instància del servidor, normalment afegint més processadors/nuclis, més RAM, emmagatzematge més ràpid, etc. L'addició de més recursos de maquinari augmenta el rendiment de la base de dades, mesurat principalment en transaccions per segon, i la latència de transaccions per als sistemes OLTP. Els sistemes de bases de dades relacionals (que utilitzen un enfocament multifils) com MySQL s'escalen bé verticalment.
Aquest enfocament té diversos inconvenients, però el més evident és la mida màxima del servidor al mercat. Un cop s'ha arribat al límit més gran d'instància del servidor, només queda un camí: escalar.
L'escala-out és un enfocament que afegeix més servidors a un clúster per augmentar idealment el rendiment de manera lineal a mesura que s'afegeixen més servidors. Majoria tradicional els sistemes de bases de dades no s'escalen bé o no s'escalen gens. Per exemple, MySQL pot escalar per a operacions de lectura afegint lectors esclaus, però no pot escalar per a operacions d'escriptura.
D'altra banda, a causa de la seva naturalesa, Cloud Spanner pot escalar fàcilment horitzontalment amb una intervenció mínima.
Amb totes les funcions DBMS com a servei s'han d'avaluar des de diferents perspectives. Com a base, vam agafar el SGBD més popular al núvol: per a Google, GCP Cloud SQL i per a Amazon, AWS RDS. En la nostra avaluació, ens hem centrat en les categories següents:
- Mapatge de característiques: extensió SQL, DDL, DML; biblioteques/connectors de connexió, suport de transaccions, etc.
- Suport al desenvolupament: facilitat de desenvolupament i prova.
- Suport a l'administració: gestió d'instàncies, com ara augmentar/reduir l'escala i actualitzar instàncies; SLA, còpia de seguretat i recuperació; seguretat/control d'accés.
Utilitzant Cloud Spanner com a solució OLTP habilitada per OLAP
Tot i que Google no indica de manera explícita que Cloud Spanner serveix per a l'anàlisi, sí que comparteix alguns atributs amb altres motors com Apache Impala & Kudu i YugaByte que estan dissenyats per a càrregues de treball OLAP.
Fins i tot si només hi hagués una petita possibilitat que Cloud Spanner inclogués un motor HTAP (processament híbrid transaccional/analític) d'escalada uniforme amb un conjunt de funcions OLAP (més o menys) utilitzable, creiem que mereixeria la nostra atenció.
Tenint això en compte, hem analitzat les categories següents:
- Suport de càrrega de dades, índexs i particions
- Rendiment de consultes i DML
2. Cloud Spanner en poques paraules
Google Spanner és un sistema de gestió de bases de dades relacionals agrupades (RDBMS) que Google utilitza per a diversos dels seus propis serveis. Google el va posar a disposició pública per als usuaris de Google Cloud Platform a principis del 2017.
Aquests són alguns dels atributs de Cloud Spanner:
- Clúster de RDBMS molt coherent i escalable: utilitza la sincronització de temps de maquinari per garantir la coherència de les dades.
- Suport de transaccions entre taules: les transaccions poden abastar diverses taules, no necessàriament limitades a una única taula (a diferència d'Apache HBase o Apache Kudu).
- Taules basades en clau primària: totes les taules han de tenir una clau primària (PC) declarada, que pot consistir en diverses columnes de la taula. Les dades tabulars s'emmagatzemen en ordre d'ordinador, la qual cosa la fa molt eficient i ràpida per a les cerques d'ordinador. Com passa amb altres sistemes basats en PC, la implementació s'ha de modelar amb casos d'ús preconcebuts per aconseguir-ho .
- Taules amb ratlles: les taules poden tenir dependències físiques entre si. Les files de la taula fill es poden relacionar amb les files de la taula pare. Aquest enfocament accelera la cerca de relacions que es poden determinar en l'etapa de modelització de dades, per exemple, quan es col·loquen clients i les seves factures.
- Índexs: Cloud Spanner admet índexs secundaris. Un índex consta de columnes indexades i totes les columnes de PC. Opcionalment, l'índex també pot contenir altres columnes no indexades. L'índex es pot intercalar amb la taula pare per accelerar les consultes. S'apliquen diverses restriccions als índexs, com ara el nombre màxim de columnes addicionals que es poden emmagatzemar en un índex. A més, les consultes mitjançant índexs poden no ser tan senzilles com en altres RDBMS.
"Cloud Spanner selecciona un índex automàticament només en casos excepcionals. En particular, Cloud Spanner no selecciona automàticament un índex secundari si la consulta sol·licita columnes que no estiguin emmagatzemades a ».
- Acord de nivell de servei (SLA): desplegament d'una sola regió amb un SLA del 99,99%; desplegaments multiregionals amb un SLA del 99,999%. Tot i que el SLA en si és només un acord i no una garantia de cap tipus, crec que la gent de Google té algunes dades difícils per fer una afirmació tan contundent. (Com a referència, el 99,999% significa 26,3 segons de temps d'inactivitat del servei al mes.)
- Més:
Nota: El projecte Apache Tephra afegeix suport avançat de transaccions a Apache HBase (també implementat ara a Apache Phoenix com a beta).
3. La nostra valoració
Per tant, tots hem llegit les declaracions de Google sobre els avantatges de Cloud Spanner: escala horitzontal pràcticament il·limitada mantenint una gran consistència i un SLA molt alt. Tot i que aquestes afirmacions són, en tot cas, extremadament difícils d'aconseguir, el nostre objectiu no era refutar-les. En lloc d'això, centrem-nos en altres coses que preocupen a la majoria dels usuaris de bases de dades: la paritat i la usabilitat.
Hem classificat Cloud Spanner com a substitut de Sharded MySQL
Google Cloud SQL i Amazon AWS RDS, dues de les bases de dades OLTP més populars del mercat del núvol, tenen un conjunt de funcions molt gran. Tanmateix, per tal d'escalar aquestes bases de dades més enllà de la mida d'un únic node, cal que feu la divisió d'aplicacions. Aquest enfocament crea una complexitat addicional tant per a les aplicacions com per a l'administració. Hem analitzat com encaixa Spanner en l'escenari de combinar diversos fragments en una sola instància i quines funcions (si n'hi ha) podrien haver de sacrificar-se.
Suport per a SQL, DML i DDL, així com el connector i les biblioteques?
En primer lloc, quan comenceu amb qualsevol base de dades, heu de crear un model de dades. Si creieu que podeu connectar JDBC Spanner a la vostra eina SQL preferida, trobareu que podeu consultar les vostres dades amb ella, però no les podreu utilitzar per crear una taula o actualització (DDL) o cap inserció/actualització/eliminació. operacions (DML). El JDBC oficial de Google tampoc és compatible.
"Els controladors no admeten actualment declaracions DML o DDL".
Documentació de la clau
La situació no és millor amb la consola GCP: només podeu enviar consultes SELECT. Afortunadament, hi ha un controlador JDBC amb suport DML i DDL de la comunitat, incloses les transaccions . Tot i que aquest controlador és extremadament útil, l'absència del controlador JDBC de Google és sorprenent. Afortunadament, Google ofereix un suport de biblioteques de client força ampli (basat en gRPC): C#, Go, Java, node.js, PHP, Python i Ruby.
L'ús gairebé obligatori de les API personalitzades de Cloud Spanner (a causa de la manca de DDL i DML a JDBC) comporta algunes limitacions per a àrees de codi relacionades, com ara l'agrupació de connexions o els marcs d'enllaç de bases de dades (com Spring MVC). En general, quan utilitzeu JDBC, podeu triar el vostre grup de connexions preferit (per exemple, HikariCP, DBCP, C3PO, etc.) que estigui provat i funcioni bé. En el cas de les API de Spanner personalitzades, hem de confiar en marcs/enllaços/grups de sessions que hem creat nosaltres mateixos.
El disseny orientat a la clau primària (PC) permet que Cloud Spanner sigui molt ràpid quan accedeix a dades mitjançant l'ordinador, però també introdueix alguns problemes de consulta.
- No podeu actualitzar el valor d'una clau primària; Primer heu de suprimir l'entrada original de l'ordinador i tornar-la a inserir amb el nou valor. (Això és similar a altres motors de base de dades/emmagatzematge orientats a PC.)
- Qualsevol declaració UPDATE i DELETE ha d'especificar el PC a WHERE, per tant, no hi pot haver sentències DELETE buides; sempre hi ha d'haver una subconsulta, per exemple: UPDATE xxx WHERE id IN (SELECT id FROM table1)
- Manca d'una opció d'increment automàtic o alguna cosa semblant que estableixi la seqüència per al camp PC. Perquè això funcioni, s'ha de crear el valor corresponent al costat de l'aplicació.
Índexs secundaris?
Google Cloud Spanner té suport integrat per a índexs secundaris. Aquesta és una característica molt agradable que no sempre està present en altres tecnologies. Apache Kudu actualment no admet índexs secundaris en absolut, i Apache HBase no admet índexs directament, però pot afegir-los mitjançant Apache Phoenix.
Els índexs en Kudu i HBase es poden modelar com una taula separada amb una composició diferent de claus primàries, però l'atomicitat de les operacions realitzades a la taula pare i les taules d'índex relacionades s'han de realitzar a nivell d'aplicació i no és trivial implementar correctament.
Com s'ha esmentat a la revisió de Cloud Spanner, els seus índexs poden diferir dels índexs de MySQL. Per tant, s'ha de tenir especial cura en la creació de consultes i en l'elaboració de perfils per garantir que s'utilitza l'índex correcte allà on calgui.
Representació?
Un objecte molt popular i útil en una base de dades són les vistes. Poden ser útils per a un gran nombre de casos d'ús; els meus dos preferits són la capa d'abstracció lògica i la capa de seguretat. Malauradament, Cloud Spanner NO admet visualitzacions. Tanmateix, això només ens limita parcialment, ja que no hi ha una granularitat a nivell de columna per als permisos d'accés on les vistes puguin ser una solució acceptable.
Consulteu la documentació de Cloud Spanner per obtenir una secció que detalla les quotes i els límits (), n'hi ha un en particular que pot ser problemàtic per a algunes aplicacions: Cloud Spanner té un màxim de 100 bases de dades per instància. Òbviament, això pot ser un obstacle important per a una base de dades dissenyada per escalar a més de 100 bases de dades. Afortunadament, després de parlar amb el nostre representant tècnic de Google, vam descobrir que aquest límit es pot augmentar a gairebé qualsevol valor mitjançant l'assistència de Google.
Suport al desenvolupament?
Cloud Spanner ofereix un suport de llenguatge de programació força decent per treballar amb la seva API. Les biblioteques oficialment compatibles es troben a l'àrea de C#, Go, Java, node.js, PHP, Python i Ruby. La documentació és bastant detallada, però com passa amb altres tecnologies d'avantguarda, la comunitat és bastant petita en comparació amb les tecnologies de bases de dades més populars, cosa que pot comportar més temps dedicat a casos d'ús o problemes menys habituals.
Aleshores, què passa amb el suport al desenvolupament local?
No hem trobat cap manera de crear una instància de Cloud Spanner a les instal·lacions. El més proper que tenim és una imatge de Docker que és semblant en principi, però molt diferent a la pràctica. Per exemple, CockroachDB pot utilitzar PostgreSQL JDBC. Com que l'entorn de desenvolupament ha d'estar el més a prop possible de l'entorn de producció, Cloud Spanner no és ideal perquè cal confiar en una instància completa de Spanner. Per estalviar costos, podeu seleccionar una única instància de regió.
Suport administratiu?
Crear una instància de Cloud Spanner és molt senzill. Només cal que escolliu entre crear una instància multiregió o una instància d'una sola regió, especifiqueu les regions i el nombre de nodes. En menys d'un minut, la instància estarà en funcionament.
Diverses mètriques elementals estan disponibles directament a la pàgina Spanner de la consola de Google. Hi ha vistes més detallades disponibles a Stackdriver, on també podeu establir llindars de mètriques i polítiques d'alerta.
Accés als recursos?
MySQL ofereix una configuració àmplia i molt granular de permisos/rol d'usuari. Podeu personalitzar fàcilment l'accés a una taula específica, o fins i tot només a un subconjunt de les seves columnes. Cloud Spanner utilitza l'eina Google Identity & Access Management (IAM), que només us permet establir polítiques i permisos a un nivell molt alt. L'opció més granular és el permís a nivell de base de dades, que no s'adapta a la majoria dels casos de producció. Aquesta restricció us obliga a afegir mesures de seguretat addicionals al vostre codi, infraestructura o tots dos per evitar l'ús no autoritzat dels recursos de l'Spanner.
Còpies de seguretat?
Per dir-ho simplement, no hi ha còpies de seguretat a Cloud Spanner. Tot i que els alts requisits de SLA de Google poden garantir que no perdis cap dada a causa d'errors de maquinari o de bases de dades, errors humans, defectes de l'aplicació, etc. Tots coneixem la regla: l'alta disponibilitat no substitueix una estratègia de còpia de seguretat intel·ligent. Actualment, l'única manera de fer una còpia de seguretat de les dades és transmetre-les mitjançant programació des de la base de dades a un entorn d'emmagatzematge independent.
Voleu consultar el rendiment?
Hem utilitzat Yahoo! per carregar dades i provar consultes. Punt de referència de servei al núvol. La taula següent mostra la càrrega de treball de B YCSB amb una ràtio de lectura del 95% i escriptura del 5%.
* La prova de càrrega es va executar a n1-standard-32 Compute Engine (CE) (32 vCPU, 120 GB de memòria) i la instància de prova mai va ser el coll d'ampolla de les proves.
** El nombre màxim de fils en una instància YCSB és de 400. En total, s'han hagut d'executar sis instàncies paral·leles de proves YCSB per obtenir un total de 2400 fils.
Si observem els resultats de referència, en particular la combinació de càrrega de CPU i TPS, podem veure clarament que Cloud Spanner s'escala força bé. La gran càrrega creada per un gran nombre de fils es compensa amb un gran nombre de nodes del clúster Cloud Spanner. Tot i que la latència sembla bastant alta, especialment quan s'executa a 2400 fils, pot ser que sigui necessari tornar a provar amb 6 instàncies més petites del motor de càlcul per obtenir números més precisos. Cada instància executarà una prova YCSB en lloc d'una gran instància CE amb 6 proves paral·leles. Això fa que sigui més fàcil distingir entre els retards de sol·licitud de Cloud Spanner i els retards afegits per la connexió de xarxa entre Cloud Spanner i la instància CE que executa la prova.
Com funciona Cloud Spanner com a OLAP?
Particions?
Dividir les dades en segments físicament i/o lògicament independents, anomenats particions, és un concepte molt popular que es troba a la majoria de motors OLAP. Les particions poden millorar molt el rendiment de les consultes i el manteniment de la base de dades. Aprofundir en el particionament seria un article separat, així que només esmentem la importància de tenir un esquema de particions i subparticions. La capacitat de dividir les dades en particions i encara més en subparticions és clau per al rendiment de les consultes analítiques.
Cloud Spanner no admet particions per se. Separa les dades internament en els anomenats dividit-s basat en rangs de claus primàries. La partició es fa automàticament per equilibrar la càrrega del clúster de Cloud Spanner. Una característica molt útil de Cloud Spanner és dividir la càrrega base d'una taula pare (una taula que no s'entrellaça amb una altra). Spanner detecta automàticament si conté dividit dades que es llegeixen amb més freqüència que les dades d'altres dividit-ah, i pot decidir una altra separació. Així, es poden implicar més nodes en una sol·licitud, la qual cosa també augmenta efectivament el rendiment.
S'està carregant dades?
El mètode Cloud Spanner per a dades massives és el mateix que per a una càrrega normal. Per obtenir el màxim rendiment, heu de seguir algunes pautes, com ara:
- Ordena les teves dades per clau primària.
- Dividiu-los per 10*nombre de nodes seccions individuals.
- Creeu un conjunt de tasques de treball que carreguin dades en paral·lel.
Aquesta càrrega de dades utilitza tots els nodes de Cloud Spanner.
Hem utilitzat la càrrega de treball A YCSB per generar un conjunt de dades de 10 milions de files.
* La prova de càrrega es va executar al motor de càlcul n1-standard-32 (32 vCPU, 120 GB de memòria) i la instància de prova mai va ser el coll d'ampolla de les proves.
** No es recomana una configuració d'1 node per a cap càrrega de treball de producció.
Com s'ha esmentat anteriorment, Cloud Spanner processa automàticament les divisions en funció de la seva càrrega, de manera que els resultats milloren després de diverses iteracions consecutives de la prova. Els resultats que es presenten aquí són els millors resultats que hem rebut. Mirant els números anteriors, podem veure com Cloud Spanner escala (bé) a mesura que augmenta el nombre de nodes del clúster. Les xifres que destaquen són una latència mitjana extremadament baixa, que contrasta amb els resultats de càrregues de treball mixtes (95% de lectura i 5% d'escriptura) tal com es descriu a la secció anterior.
Escalar?
Augmentar i disminuir el nombre de nodes de Cloud Spanner és una tasca d'un sol clic. Si voleu carregar dades ràpidament, podeu considerar augmentar la instància al màxim (en el nostre cas eren 25 nodes a la regió dels EUA-EAST) i després reduir el nombre de nodes adequats per a la vostra càrrega normal després de totes les dades. a la base de dades, tenint en compte el límit de 2 TB/node.
Ens va recordar aquest límit fins i tot amb una base de dades molt més petita. Després de diverses proves de càrrega, la nostra base de dades tenia una mida d'uns 155 GB i, quan es va reduir a una instància d'1 node, vam rebre l'error següent:
Hem pogut reduir de 25 a 2 instàncies, però estem atrapats en dos nodes.
L'augment i la disminució del nombre de nodes en un clúster de Cloud Spanner es pot automatitzar mitjançant l'API REST. Això pot ser especialment útil per reduir l'augment de la càrrega del sistema durant les hores de feina.
Rendiment de la consulta OLAP?
Originalment teníem previst dedicar un temps considerable a la nostra avaluació de Spanner en aquesta part. Després d'uns quants SELECT COUNT, ens vam adonar immediatament que la prova seria curta i que Spanner NO seria un motor adequat per a OLAP. Independentment del nombre de nodes del clúster, escollint simplement el nombre de files en una taula de files de 10 milions va trigar entre 55 i 60 segons. A més, qualsevol consulta que requeria més memòria per emmagatzemar resultats intermedis va fallar amb un error OOM.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Alguns números per a consultes TPC-H es poden trobar a l'article de Todd Lipcon , diapositives 42 i 43. Aquests números són coherents amb els nostres propis resultats (malauradament).
4. Les nostres troballes
Tenint en compte l'estat actual de les funcions de Cloud Spanner, és difícil veure'l com un simple reemplaçament d'una solució OLTP existent, sobretot quan les vostres necessitats la superen. Es necessitaria molt de temps per crear una solució sobre les deficiències de Cloud Spanner.
Quan vam començar a avaluar Cloud Spanner, esperàvem que les seves funcions de gestió estiguessin a l'igual, o almenys no lluny d'altres solucions de Google SQL. Però ens va sorprendre la manca total de còpies de seguretat i un control d'accés molt limitat als recursos. Per no parlar de cap visualització, cap entorn de desenvolupament local, seqüències no compatibles, JDBC sense suport DML i DDL, etc.
Aleshores, a on anar per a algú que necessita escalar una base de dades transaccional? Encara no sembla que hi hagi una solució única al mercat que s'adapti a tots els casos d'ús. Hi ha moltes solucions tancades i de codi obert (algunes de les quals s'esmenten en aquest article), cadascuna amb els seus punts forts i febles, però cap d'elles ofereix SaaS amb un SLA del 99,999% i un alt grau de coherència. Si el vostre objectiu principal és un SLA elevat i no esteu disposat a crear la vostra pròpia solució per a diversos núvols, Cloud Spanner pot ser la solució que busqueu. Però heu de ser conscients de totes les seves limitacions.
Per ser justos, Cloud Spanner només es va llançar al públic a la primavera del 2017, per la qual cosa és raonable esperar que alguns dels seus defectes actuals eventualment desapareguin (esperem) i, quan ho faci, podria ser un canvi de joc. Després de tot, Cloud Spanner no és només un projecte secundari per a Google. Google l'utilitza com a base per a altres productes de Google. I quan Google va substituir recentment Megastore a Google Cloud Storage per Cloud Spanner, va permetre que Google Cloud Storage es tornés molt coherent per a les llistes d'objectes a escala global (que encara no és el cas de ).
Per tant, encara hi ha esperança... esperem.
Això és tot. Com l'autor de l'article, també seguim esperant, però què en penseu? Escriu als comentaris
Convidem a tothom a visitar el nostre en el qual us explicarem detalladament el curs d'OTUS.
Font: www.habr.com