Ola, veciños de Khabrovsk. Como é habitual, seguimos compartindo material interesante antes do comezo dos novos cursos. Hoxe, especialmente para vós, publicamos un artigo sobre Google Cloud Spanner coincidindo co lanzamento do curso .
Publicado orixinalmente en .
Como empresa que ofrece unha variedade de solucións POS baseadas na nube para venda polo miúdo, restauradores e vendedores en liña de todo o mundo, Lightspeed usa varios tipos diferentes de plataformas de bases de datos para unha variedade de casos de uso transaccionais, analíticos e de busca. Cada unha destas plataformas de bases de datos ten os seus propios puntos fortes e débiles. Por iso, cando Google presentou Cloud Spanner ao mercado, características prometedoras que non se ven no mundo das bases de datos relacionais, como unha escalabilidade horizontal practicamente ilimitada e un acordo de nivel de servizo (SLA) do 99,999 %. — Non podíamos perder a oportunidade de botar man del!
Para ofrecer unha visión xeral da nosa experiencia con Cloud Spanner, así como dos criterios de avaliación que utilizamos, trataremos os seguintes temas:
- Os nosos criterios de avaliación
- Cloud Spanner en poucas palabras
- A nosa valoración
- Os nosos achados
1. Os nosos criterios de avaliación
Antes de mergullarnos nas especificidades de Cloud Spanner, as súas semellanzas e diferenzas con outras solucións do mercado, imos falar primeiro dos principais casos de uso que tiñamos en mente á hora de considerar onde implantar Cloud Spanner na nosa infraestrutura:
- Como substituto da solución de base de datos SQL tradicional (predominante).
- Como a solución OLTP con soporte OLAP
Nota: Para simplificar e facilitar a comparación, este artigo compara Cloud Spanner coas variantes de MySQL das familias de solucións GCP Cloud SQL e Amazon AWS RDS.
Usando Cloud Spanner como substituto dunha solución de base de datos SQL tradicional
No medio ambiente tradicional bases de datos, cando o tempo de resposta á consulta da base de datos se achega ou mesmo supera os limiares de aplicación predefinidos (principalmente debido a un aumento do número de usuarios e/ou solicitudes), existen varias formas de reducir o tempo de resposta a niveis aceptables. Non obstante, a maioría destas solucións implican intervención manual.
Por exemplo, o primeiro paso a dar é mirar os distintos parámetros da base de datos relacionados co rendemento e axustalos para que coincidan mellor cos patróns de casos de uso das aplicacións. Se isto non é suficiente, pode optar por escalar a base de datos vertical ou horizontalmente.
A escala vertical dunha aplicación implica actualizar a instancia do servidor, normalmente engadindo máis procesadores/núcleos, máis memoria RAM, almacenamento máis rápido, etc. Engadir máis recursos de hardware produce un aumento do rendemento da base de datos, medido principalmente en transaccións en segundo lugar, e a latencia de transacción para os sistemas OLTP. Os sistemas de bases de datos relacionais (que usan un enfoque multiproceso) como MySQL escalan ben verticalmente.
Este enfoque ten varias desvantaxes, pero o máis obvio é o tamaño máximo do servidor no mercado. Unha vez alcanzado o límite da maior instancia do servidor, só queda unha opción: a escala horizontal.
O escalado horizontal é un enfoque no que se engaden máis servidores a un clúster, o que ideal é aumentar o rendemento de forma lineal a medida que se engade o número de servidores. Maioría tradicional Os sistemas de bases de datos non escalan ben horizontalmente ou non se escalan en absoluto. Por exemplo, MySQL pode escalar horizontalmente para operacións de lectura engadindo lectores escravos, pero non pode escalar horizontalmente para escribir.
Por outra banda, debido á súa natureza, Cloud Spanner pode escalar facilmente horizontalmente cunha intervención mínima.
Completamente destacado DBMS como servizo deben ser avaliados desde diferentes ángulos. Como base, tomamos o DBMS máis popular na nube: para Google, GCP Cloud SQL e para Amazon, AWS RDS. Na nosa avaliación centrámonos nas seguintes categorías:
- Mapeo de características: extensión SQL, DDL, DML; bibliotecas de conexión/conectores, soporte de transaccións, etc.
- Apoio ao desenvolvemento: desenvolvemento e probas fáciles.
- Soporte de administración: xestión de instancias, por exemplo, escalar/reducir e actualizar instancias; SLA, copia de seguridade e recuperación; seguridade/control de acceso.
Usando Cloud Spanner como solución OLTP habilitada para OLAP
Aínda que Google non afirma expresamente que Cloud Spanner estea deseñado para o procesamento analítico, comparte algúns atributos con outros motores como Apache Impala & Kudu e YugaByte, que están deseñados para cargas de traballo OLAP.
Aínda que só houbese unha pequena posibilidade de que Cloud Spanner incluíse un motor HTAP (procesamento híbrido transaccional/analítica) de escalado consistente cun conxunto de funcións OLAP (máis ou menos) utilizable, pensamos que merecería a nosa atención.
Con isto en mente, analizamos as seguintes categorías:
- Soporte de carga de datos, índices e partición
- Rendemento de consulta e DML
2. Cloud Spanner en poucas palabras
Google Spanner é un sistema de xestión de bases de datos relacionais en clúster (RDBMS) que Google utiliza para varios dos seus propios servizos. Google púxoo a disposición xeral dos usuarios de Google Cloud Platform a principios de 2017.
Estes son algúns dos atributos de Cloud Spanner:
- Clúster de RDBMS escalable altamente consistente: utiliza a sincronización horaria de hardware para garantir a coherencia dos datos.
- Compatibilidade con transaccións entre táboas: as transaccións poden abarcar varias táboas, non necesariamente limitadas a unha única táboa (a diferenza de Apache HBase ou Apache Kudu).
- Táboas baseadas en claves primarias: todas as táboas deben ter unha chave primaria (PC) declarada, que pode constar de varias columnas na táboa. Os datos tabulares almacénanse na orde do PC, o que o fai moi eficiente e rápido para a busca do PC. Do mesmo xeito que outros sistemas baseados en PC, a implementación debe modelarse tendo en conta casos de uso previamente deseñados para lograr .
- Táboas con raias: as táboas poden ter dependencias físicas entre si. As filas dunha táboa filla pódense comparar coas filas dunha táboa principal. Este enfoque acelera a busca de relacións que se poidan identificar durante a fase de modelado de datos, como a co-localización dos clientes e as súas facturas.
- Índices: Cloud Spanner admite índices secundarios. O índice está composto polas columnas indexadas e todas as columnas do PC. Se o desexa, o índice tamén pode conter outras columnas non indexadas. O índice pódese intercalar coa táboa principal para acelerar as consultas. Aplícanse varias restricións aos índices, como o número máximo de columnas adicionais almacenadas no índice. Ademais, as consultas a través de índices poden non ser tan sinxelas como noutros RDBMS.
"Cloud Spanner selecciona un índice automaticamente só en casos raros. En particular, Cloud Spanner non selecciona automaticamente un índice secundario se unha consulta solicita columnas que non estean almacenadas en ».
- Acordo de nivel de servizo (SLA): implantación nunha rexión cun SLA do 99,99 %; implantacións multirrexionais cun SLA do 99,999 %. Aínda que o SLA en si é só un acordo e non unha garantía de ningún tipo, creo que a xente de Google ten algúns datos duros para facer unha afirmación tan forte. (Para referencia, o 99,999 % significa 26,3 segundos de non dispoñibilidade do servizo ao mes).
- Máis:
Nota: O proxecto Apache Tephra engade soporte de transaccións mellorado a Apache HBase (tamén agora implementado en Apache Phoenix como versión beta).
3. A nosa valoración
Entón, todos lemos as afirmacións de Google sobre os beneficios de Cloud Spanner: escala horizontal practicamente ilimitada mantendo unha alta consistencia e un SLA moi alto. Aínda que estes requisitos son, en todo caso, extremadamente difíciles de acadar, o noso obxectivo non era refutalos. En vez diso, centrémonos noutras cousas que importan á maioría dos usuarios de bases de datos: paridade e usabilidade.
Avaliamos Cloud Spanner como substituto de Sharded MySQL
Google Cloud SQL e Amazon AWS RDS, dous dos DBMS OLTP máis populares no mercado da nube, teñen un conxunto moi grande de funcións. Non obstante, para escalar estas bases de datos máis aló do tamaño dun só nodo, cómpre realizar a partición da aplicación. Este enfoque crea unha complexidade adicional tanto para as aplicacións como para a administración. Analizamos como encaixa Spanner no escenario de combinación de varios fragmentos nunha única instancia e que funcións (se as hai) poden ter que sacrificarse.
Compatibilidade con SQL, DML e DDL, así como conectores e bibliotecas?
En primeiro lugar, ao comezar con calquera base de datos, cómpre crear un modelo de datos. Se pensas que podes conectar JDBC Spanner á túa ferramenta SQL favorita, verás que podes consultar os teus datos con ela, pero non podes usalos para crear unha táboa ou modificar (DDL) nin para inserir/actualizar/eliminar. operacións (DML). O JDBC oficial de Google non admite ningún destes.
"Actualmente, os controladores non admiten declaracións DML ou DDL".
Documentación da chave
A situación non é mellor coa consola GCP: só podes enviar consultas SELECT. Afortunadamente, hai un controlador JDBC con soporte para DML e DDL da comunidade, incluídas as transaccións . Aínda que este controlador é moi útil, a falta do propio controlador JDBC de Google é sorprendente. Afortunadamente, Google ofrece un soporte bastante amplo para as bibliotecas de clientes (baseadas en gRPC): C#, Go, Java, node.js, PHP, Python e Ruby.
O uso case obrigatorio das API personalizadas de Cloud Spanner (debido á falta de DDL e DML en JDBC) provoca algunhas limitacións para áreas de código relacionadas, como grupos de conexión ou marcos de vinculación de bases de datos (por exemplo, Spring MVC). Normalmente, cando usas JDBC, podes escoller o teu grupo de conexións favorito (por exemplo, HikariCP, DBCP, C3PO, etc.) que se proba e funciona ben. No caso das API de Spanner personalizadas, temos que depender de marcos/grupos de enlace/sesións que creamos nós mesmos.
O deseño centrado na clave primaria (PC) permite que Cloud Spanner sexa moi rápido ao acceder aos datos a través do PC, pero tamén introduce algúns problemas de consulta.
- Non pode actualizar o valor da chave principal; Primeiro debes eliminar a entrada do PC orixinal e reinserila co novo valor. (Isto é semellante a outros motores de almacenamento/base de datos orientados a PC).
- Calquera instrución UPDATE e DELETE debe especificar PC no WHERE, polo que non pode haber todas as instrucións DELETE baleiras; sempre debe haber unha subconsulta, por exemplo: UPDATE xxx WHERE id IN (SELECT id FROM table1)
- Falta de opción de incremento automático ou algo similar que estableza a secuencia para o campo PC. Para que isto funcione, debe crearse o valor correspondente no lado da aplicación.
Índices secundarios?
Google Cloud Spanner ten compatibilidade integrada para índices secundarios. Esta é unha característica moi agradable que non sempre está presente noutras tecnoloxías. Apache Kudu actualmente non admite índices secundarios en absoluto, e Apache HBase non admite índices directamente, pero pode engadilos a través de Apache Phoenix.
Os índices en Kudu e HBase pódense modelar como unha táboa separada cunha composición diferente de claves primarias, pero a atomicidade das operacións realizadas na táboa pai e nas táboas de índices asociadas debe facerse a nivel de aplicación e non é trivial implementar correctamente.
Como se mencionou na revisión de Cloud Spanner, os seus índices poden diferir dos índices de MySQL. Polo tanto, débese ter especial coidado á hora de construír as consultas e a elaboración de perfís para garantir que se utiliza o índice axeitado onde sexa necesario.
¿Representación?
Un obxecto moi popular e útil nunha base de datos son as vistas. Poden ser útiles para un gran número de casos de uso; Os meus dous favoritos son a capa de abstracción lóxica e a capa de seguridade. Desafortunadamente, Cloud Spanner NON admite vistas. Non obstante, isto só nos limita parcialmente porque non hai unha granularidade para os permisos de acceso a nivel de columna onde as vistas poden ser unha solución viable.
Consulte a documentación de Cloud Spanner para ver unha sección que detalla as cotas e restricións (), hai un en particular que pode ser problemático para algunhas aplicacións: Cloud Spanner ten un límite de 100 bases de datos por instancia. Obviamente, isto pode ser un gran pescozo de botella para unha base de datos deseñada para escalar a máis de 100 bases de datos. Afortunadamente, despois de falar co noso representante técnico de Google, descubrimos que este límite pódese aumentar a case calquera valor a través do soporte de Google.
Apoio ao desenvolvemento?
Cloud Spanner ofrece compatibilidade de linguaxe de programación bastante decente para traballar coa súa API. As bibliotecas admitidas oficialmente están nas áreas de C#, Go, Java, node.js, PHP, Python e Ruby. A documentación é bastante detallada, pero como ocorre con outras tecnoloxías avanzadas, a comunidade é bastante pequena en comparación coas tecnoloxías de bases de datos máis populares, o que pode levar a que se dedique máis tempo a resolver casos de uso ou problemas menos comúns.
Entón, que hai de apoiar o desenvolvemento local?
Non atopamos unha forma de crear unha instancia de Cloud Spanner local. O que máis nos achegamos foi unha imaxe de Docker. , que é semellante en principio, pero moi diferente na práctica. Por exemplo, CockroachDB pode usar PostgreSQL JDBC. Dado que o ambiente de desenvolvemento debe estar o máis próximo posible ao ambiente de produción, Cloud Spanner non é ideal xa que debe confiar nunha instancia completa de Spanner. Para aforrar custos, pode seleccionar unha instancia dunha soa rexión.
Apoio administrativo?
Crear unha instancia de Cloud Spanner é moi sinxelo. Só ten que escoller entre crear unha instancia de varias rexións ou dunha única rexión, especificar a(s) rexión(s) e o número de nós. En menos dun minuto, a túa instancia estará en funcionamento.
Pódese acceder directamente a varias métricas rudimentarias desde a páxina de Spanner na Consola de Google. Están dispoñibles vistas máis detalladas a través de Stackdriver, onde tamén pode establecer limiares métricos e políticas de alerta.
Acceso aos recursos?
MySQL ofrece configuracións extensas e moi granulares para os permisos/roles dos usuarios. Pode configurar facilmente o acceso a unha táboa específica, ou incluso só a un subconxunto das súas columnas. Cloud Spanner usa a ferramenta Identity & Access Management (IAM) de Google, que só che permite establecer políticas e permisos a un nivel moi alto. A opción máis granular é a resolución a nivel de base de datos, que non encaixa na maioría dos casos de uso de produción. Esta limitación obrígache a engadir medidas de seguridade adicionais ao teu código, á infraestrutura ou a ambos para evitar o uso non autorizado dos recursos de Spanner.
Copia de seguranza?
Para dicilo simplemente, non hai copias de seguridade en Cloud Spanner. Aínda que os altos requisitos de SLA de Google poden garantir que non perdas ningún dato debido a fallos de hardware ou de bases de datos, erros humanos, defectos das aplicacións, etc. Todos coñecemos a regra: a alta dispoñibilidade non é un substituto dunha estratexia de copia de seguridade sólida. Actualmente, a única forma de facer unha copia de seguranza dos datos é transmitilos mediante programación desde unha base de datos a un ambiente de almacenamento separado.
Queres consultar o rendemento?
Usamos Yahoo! para cargar datos e probar consultas. Punto de referencia de servizo na nube. A seguinte táboa mostra a carga de traballo B de YCSB cunha proporción de lectura do 95% e escritura do 5%.
* A proba de carga realizouse no n1-standard-32 Compute Engine (CE) (32 vCPU, 120 GB de memoria) e a instancia de proba nunca foi un pescozo de botella nas probas.
** O número máximo de fíos nunha única instancia de YCSB é 400. Houbo que executar un total de seis instancias paralelas de probas de YCSB para obter un total de 2400 fíos.
Mirando os resultados de referencia, especialmente a combinación de carga da CPU e TPS, podemos ver claramente que Cloud Spanner escala bastante ben. A gran carga creada pola gran cantidade de fíos compénsase pola gran cantidade de nós do clúster Cloud Spanner. Aínda que a latencia parece bastante alta, especialmente cando se executa con fíos de 2400, pode ser necesario volver a probar con 6 instancias máis pequenas do motor de cálculo para obter números máis precisos. Cada instancia executará unha proba YCSB en lugar dunha gran instancia CE con 6 probas paralelas. Deste xeito, será máis doado diferenciar entre a latencia de solicitude de Cloud Spanner e a latencia engadida pola conexión de rede entre Cloud Spanner e a instancia CE que executa a proba.
Como funciona Cloud Spanner como OLAP?
Particionar?
Dividir os datos en segmentos independentes física e/ou lóxica, chamados particións, é un concepto moi popular que se atopa na maioría dos motores OLAP. As particións poden mellorar significativamente o rendemento das consultas e o mantemento da base de datos. Afondar no particionamento sería un artigo(s) separado(s), así que imos só mencionar a importancia de ter un esquema de partición e sub-particionamento. A capacidade de dividir os datos en particións e aínda máis en subparticións é clave para o rendemento das consultas analíticas.
Cloud Spanner non admite particións como tales. Divide os datos internamente en chamados división-s baseado en intervalos de claves primarias. A partición realízase automaticamente para equilibrar a carga nun clúster de Cloud Spanner. Unha característica moi útil de Cloud Spanner é a división da carga base da táboa principal (unha táboa que non está entrelazada con outra). Spanner detecta automaticamente se contén división datos que se len con máis frecuencia que os datos doutros división-ah, e pode decidir sobre unha nova separación. Deste xeito, máis nodos poden estar implicados nunha solicitude, o que tamén aumenta efectivamente o rendemento.
Cargando datos?
O método de Cloud Spanner para datos masivos é o mesmo que para a carga normal. Para conseguir o máximo rendemento, cómpre seguir algunhas pautas, incluíndo:
- Ordena os teus datos por clave principal.
- Divídelos por 10*número de nodos seccións separadas.
- Crea un conxunto de tarefas de traballo que carguen datos en paralelo.
Esta carga de datos usa todos os nodos de Cloud Spanner.
Usamos a carga de traballo A de YCSB para xerar un conxunto de datos de 10 millóns de filas.
* A proba de carga realizouse no motor de cálculo n1-standard-32 (32 vCPU, 120 GB de memoria) e a instancia de proba nunca foi un pescozo de botella nas probas.
**Non se recomenda a configuración dun só nodo para ningunha carga de traballo de produción.
Como se mencionou anteriormente, Cloud Spanner procesa automaticamente as divisións en función da súa carga, polo que os resultados melloran despois de varias repeticións de proba consecutivas. Os resultados aquí presentados son os mellores resultados que obtivemos. Mirando os números anteriores, podemos ver como Cloud Spanner escala (ben) a medida que aumenta o número de nodos do clúster. As cifras que destacan son as latencias medias extremadamente baixas, que contrastan cos resultados das cargas de traballo mixtas (95 % de lectura e 5 % de escritura) tal e como se describe no apartado anterior.
Escalar?
Aumentar e diminuír o número de nós de Cloud Spanner é unha tarefa dun só clic. Se queres cargar datos rapidamente, podes considerar aumentar a túa instancia ao máximo (no noso caso eran 25 nodos na rexión EU-EAST) e despois reducir o número de nós aptos para a túa carga normal unha vez que todos os datos estean dentro. a base de datos , facendo referencia ao límite de 2 TB/nodo.
Lembráronnos este límite incluso cunha base de datos moito máis pequena. Despois de varias probas de carga, a nosa base de datos tiña un tamaño duns 155 GB e, cando se reduciu a unha instancia de 1 nodo, recibimos o seguinte erro:
Conseguimos reducir de 25 a 2 instancias, pero quedamos atrapados en dous nodos.
O aumento e a diminución do número de nós nun clúster de Cloud Spanner pódese automatizar mediante a API REST. Isto pode ser especialmente útil para reducir o aumento da carga do sistema durante as horas de traballo ocupadas.
Rendemento das consultas OLAP?
Inicialmente planeamos dedicar unha cantidade significativa de tempo á nosa avaliación de Spanner nesta parte. Despois de varios SELECT COUNTs, inmediatamente decatámonos de que as probas serían curtas e que Spanner NON sería un motor axeitado para OLAP. Independentemente do número de nodos do clúster, a simple selección do número de filas nunha táboa de filas de 10 M levou entre 55 e 60 segundos. Ademais, calquera consulta que requirise máis memoria para almacenar resultados intermedios produciuse un erro de MOO.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Algúns números para consultas TPC-H pódense atopar no artigo de Todd Lipcon , diapositivas 42 e 43. Estes números son consistentes cos nosos propios resultados (por desgraza).
4. As nosas conclusións
Dado o estado actual das funcións de Cloud Spanner, é difícil imaxinar que sexa un simple substituto da túa solución OLTP existente, especialmente cando as túas necesidades superan. Habería que dedicar moito tempo a construír unha solución sobre as deficiencias de Cloud Spanner.
Cando comezamos a avaliar Cloud Spanner, esperábamos que as súas funcións de xestión estivesen á par con outras solucións SQL de Google, ou polo menos non moi lonxe. Pero sorprendeunos a total falta de copias de seguridade e un control moi limitado sobre o acceso aos recursos. Sen mencionar sen vistas, sen ambiente de desenvolvemento local, secuencias non compatibles, JDBC sen soporte DML e DDL, etc.
Entón, onde vai alguén que necesite escalar unha base de datos transaccional? Non parece haber unha única solución no mercado que se adapte a todos os casos de uso. Existen moitas solucións pechadas e de código aberto (algunhas das cales se mencionan neste artigo), cada unha coas súas propias fortalezas e debilidades, pero ningunha delas ofrece SaaS cun SLA do 99,999% e alta consistencia. Se o teu obxectivo principal é un alto SLA e non tes inclinación a crear unha solución multi-nube personalizada, Cloud Spanner pode ser a solución que buscas. Pero debes ser consciente de todas as súas limitacións.
Para ser xustos, Cloud Spanner só se lanzou ao público na primavera de 2017, polo que é razoable esperar que algunhas das súas deficiencias actuais poidan desaparecer (con sorte) e, cando o fagan, podería ser un cambio de xogo. Despois de todo, Cloud Spanner non é só un proxecto paralelo para Google. Google utilízao como base para outros produtos de Google. E cando Google substituíu recentemente Megastore en Google Cloud Storage por Cloud Spanner, permitiu que Google Cloud Storage fose moi consistente para as listas de obxectos a escala global (o que aínda non é o caso para ).
Entón, aínda hai esperanza... esperamos.
Iso é todo. Como o autor do artigo, tamén seguimos esperando, pero que opinas disto? Escribe nos comentarios
Convidamos a todos a visitar o noso dentro do cal vos contaremos polo miúdo sobre o curso de OTUS.
Fonte: www.habr.com