Get best of the week

Google Cloud Spanner: bueno, malo, malo

Hola habrovsk Tradicionalmente, seguimos compartiendo material interesante en previsión del lanzamiento de nuevos cursos. Hoy, especialmente para usted, hemos publicado un artículo sobre Google Cloud Spanner, programado para coincidir con el lanzamiento del curso de AWS para desarrolladores .



Publicado originalmente en el blog Lightspeed HQ .

Como una compañía que ofrece muchas soluciones POS basadas en la nube para minoristas, restauradores y minoristas en línea de todo el mundo, Lightspeed utiliza varios tipos diferentes de plataformas de bases de datos para una variedad de casos de transacciones, análisis y búsqueda. Cada una de estas plataformas de bases de datos tiene sus propias fortalezas y debilidades. En consecuencia, cuando Google introdujo el Cloud Spanner en el mercado, características prometedoras sin precedentes en el mundo de las bases de datos relacionales, como la escalabilidad horizontal prácticamente ilimitada y un acuerdo de nivel de servicio (SLA) del 99.999%, ¡No podíamos perder la oportunidad de tenerlo en nuestras manos!

Para dar una visión general de nuestra experiencia con Cloud Spanner, así como los criterios de evaluación que utilizamos, cubriremos los siguientes temas:

  1. Nuestros criterios de evaluación
  2. Cloud Spanner en pocas palabras
  3. Nuestra calificación
  4. Nuestros hallazgos



1. Nuestros criterios de evaluación


Antes de profundizar en las características de Cloud Spanner, sus similitudes y diferencias con otras soluciones en el mercado, primero hablemos sobre los principales casos de usuarios que teníamos en mente al considerar dónde implementar Cloud Spanner en nuestra infraestructura:

  • Como reemplazo de la solución de base de datos SQL tradicional (predominante)
  • Cómo una solución OLTP con soporte OLAP

Nota: Para simplificar y facilitar la comparación, este artículo compara Cloud Spanner con MySQL GCP Cloud SQL y la familia de soluciones Amazon AWS RDS.

Usar Cloud Spanner como reemplazo de una solución de base de datos SQL tradicional


En un entorno de base de datos tradicional , cuando el tiempo de respuesta a una consulta de base de datos se acerca o incluso excede los umbrales de aplicación predefinidos (principalmente debido a un aumento en el número de usuarios y / o consultas), hay varias formas de reducir el tiempo de respuesta a niveles aceptables. Sin embargo, la mayoría de estas soluciones incluyen intervención manual.

Por ejemplo, el primer paso que debe tomar es observar los diversos parámetros de la base de datos relacionados con el rendimiento y configurarlos para que coincidan con los patrones de uso de la aplicación. Si esto no es suficiente, puede optar por escalar la base de datos vertical u horizontalmente.

Ampliar la aplicación implica actualizar la instancia del servidor, generalmente agregando más procesadores / núcleos, más RAM, almacenamiento más rápido, etc. Agregar más recursos de hardware conduce a un aumento en el rendimiento de la base de datos, medido principalmente en transacciones en segundo, y el retraso de la transacción para los sistemas OLTP. Los sistemas de bases de datos relacionales (que utilizan un enfoque de subprocesos múltiples), como MySQL, se escalan bien verticalmente.

Este enfoque tiene varios inconvenientes, pero el más obvio es el tamaño máximo del servidor en el mercado. Una vez que se alcanza el límite de la instancia de servidor más grande, solo hay una forma: escala horizontal.

El escalado horizontal es un enfoque en el que se agregan más servidores al clúster para aumentar de manera ideal el rendimiento de forma lineal con la adición de la cantidad de servidores. La mayoría de los sistemas de bases de datos tradicionales no se escalan bien horizontalmente o no se escalan en absoluto. Por ejemplo, MySQL puede escalar horizontalmente para operaciones de lectura agregando lectores esclavos, pero no puede escalar horizontalmente para operaciones de escritura.

Por otro lado, debido a su naturaleza, Cloud Spanner puede escalar fácilmente horizontalmente con una mínima interferencia. DBMS

con todas las funciones como serviciodebe ser evaluado desde diferentes ángulos. Como base, tomamos el DBMS más popular en la nube: para Google, GCP Cloud SQL y para Amazon, AWS RDS. En nuestra evaluación, nos centramos en las siguientes categorías:

  • Mapeo de características: extensión SQL, DDL, DML; bibliotecas / conectores de conexión, soporte de transacciones, etc.
  • Soporte de desarrollo: facilidad de desarrollo y prueba.
  • Soporte de administración: gestión de instancias, por ejemplo, escalar / actualizar y actualizar instancias; SLA, copia de seguridad y restauración; seguridad / control de acceso.

Uso de Cloud Spanner como OLTP con soporte OLAP


Aunque Google no afirma explícitamente que Cloud Spanner es para procesamiento analítico, comparte algunos atributos con otros mecanismos, como Apache Impala & Kudu y YugaByte, que están diseñados para cargas de trabajo OLAP.

Incluso si hubiera una pequeña posibilidad de que Cloud Spanner incluyera un motor HTAP (procesamiento híbrido transaccional / analítico) consistente y escalable horizontalmente con un conjunto (más o menos) utilizable de características OLAP, creemos que merece nuestra atención.

Con esto en mente, examinamos las siguientes categorías:

  • Soporte de carga de datos, índices y particionamiento
  • Query Performance and DML

2. Cloud Spanner en pocas palabras


Google Spanner es un sistema de gestión de bases de datos relacionales de clúster (RDBMS) que Google utiliza para varios de sus propios servicios. Google lo puso a disposición del público para los usuarios de Google Cloud Platform a principios de 2017.

Estos son algunos de los atributos de Cloud Spanner:

  • Clúster RDBMS escalable altamente coherente: utiliza sincronización de tiempo de hardware para garantizar la coherencia de los datos.
  • Soporte de transacciones entre tablas: las transacciones pueden abarcar varias tablas, no necesariamente limitadas a una tabla (a diferencia de Apache HBase o Apache Kudu).
  • : (), . , . , .
  • : . . , , , -.
  • : Cloud Spanner . . . . , , , . , .

«Cloud Spanner . , Cloud Spanner , - , ».


: Apache Tephra Apache HBase ( Apache Phoenix -).

3.


Por lo tanto, todos leemos las declaraciones de Google sobre los beneficios de Cloud Spanner: escala horizontal prácticamente ilimitada mientras se mantiene una alta consistencia y un SLA muy alto. Aunque estos requisitos son, en cualquier caso, extremadamente difíciles de cumplir, nuestro objetivo no era refutarlos. En cambio, centrémonos en otras cosas que a la mayoría de los usuarios de bases de datos les interesan: paridad y usabilidad.

Calificamos Cloud Spanner como un reemplazo para Sharded MySQL


Google Cloud SQL y Amazon AWS RDS, los dos DBMS OLTP más populares en el mercado de la nube, tienen un conjunto de características muy amplio. Sin embargo, para escalar estas bases de datos más allá del tamaño de un solo nodo, debe realizar una partición de la aplicación. Este enfoque crea una complejidad adicional tanto para las aplicaciones como para la administración. Observamos cómo encaja Spanner en el escenario de combinar varios segmentos en una instancia y qué características (si las hay) pueden tener que ser sacrificadas.

¿Soporte para SQL, DML y DDL, así como conectores y bibliotecas?


Primero, al comenzar con cualquier base de datos, debe crear un modelo de datos. Si cree que puede conectar el JDBC Spanner a su herramienta SQL favorita, encontrará que puede consultar sus datos con ella, pero no puede usarla para crear una tabla o cambio (DDL) o cualquier operación de inserción / actualización / eliminación ( DML). El JDBC oficial de Google tampoco es compatible.
"Los controladores no son compatibles actualmente con DML o DDL".
Documentación de llave

Con la consola GCP, la situación no es mejor: solo puede enviar consultas SELECT. Afortunadamente, hay un controlador JDBC con soporte DML y DDL de la comunidad, que incluye transacciones github.com/olavloite/spanner-jdbc . Aunque este controlador es extremadamente útil, la falta del propio controlador JDBC de Google es sorprendente. Afortunadamente, Google ofrece un soporte bastante amplio para las bibliotecas de clientes (basadas en gRPC): C #, Go, Java, node.js, PHP, Python y Ruby.

El uso casi obligatorio de las interfaces de usuario de Cloud Spanner (debido a la falta de DDL y DML en JDBC) conlleva algunas restricciones para áreas de código relacionadas, como grupos de conexiones o marcos de enlace de bases de datos (por ejemplo, Spring MVC). Por lo general, cuando usa JDBC, puede elegir libremente su grupo de conexiones favorito (por ejemplo, HikariCP, DBCP, C3PO, etc.), que se prueba y funciona bien. En el caso de las API de Spanner personalizadas, debemos confiar en los marcos / grupos de enlace / sesiones que creamos nosotros mismos.

El diseño de la clave principal (PC) permite que Cloud Spanner sea muy rápido al acceder a los datos a través de una PC, pero también genera algunos problemas de consulta.

  • ; . ( / .)
  • UPDATE DELETE WHERE, , DELETE all — , : UPDATE xxx WHERE id IN (SELECT id FROM table1)
  • - , . , .

?


Google Cloud Spanner tiene soporte incorporado para índices secundarios. Esta es una característica muy agradable que no siempre está presente en otras tecnologías. Apache Kudu no admite actualmente índices secundarios, y Apache HBase no admite índices directamente, pero puede agregarlos a través de Apache Phoenix.

Los índices en Kudu y HBase se pueden modelar como una tabla separada con una composición diferente de las claves primarias, pero la atomicidad de las operaciones realizadas en la tabla principal y las tablas de índice relacionadas deben realizarse a nivel de aplicación y no es trivial en la implementación correcta.

Como se mencionó en la revisión de Cloud Spanner, sus índices pueden diferir de los índices de MySQL. Por lo tanto, se debe tener especial cuidado al crear consultas y crear perfiles para garantizar que se utilice el índice adecuado donde sea necesario.

¿Representación?


Un objeto muy popular y útil en la base de datos son las vistas. Pueden ser útiles para una gran cantidad de casos de usuarios; Mis dos favoritos son el nivel de abstracción lógica y el nivel de seguridad. Desafortunadamente, Cloud Spanner NO admite envíos. Sin embargo, esto solo nos limita parcialmente, porque para los permisos de acceso no hay granularidad a nivel de columna donde las representaciones pueden ser una solución aceptable.

La documentación de Cloud Spanner tiene una sección que detalla las cuotas y restricciones ( llave / cuotas), hay, en particular, uno que puede ser problemático para algunas aplicaciones: Cloud Spanner listo para usar tiene un límite de un máximo de 100 bases de datos por instancia. Obviamente, esto puede ser un serio obstáculo para una base de datos diseñada para escalar a más de 100 bases de datos. Afortunadamente, después de hablar con nuestro representante técnico de Google, descubrimos que este límite se puede aumentar a casi cualquier valor a través del soporte de Google.

Apoyo al desarrollo?


Cloud Spanner ofrece un soporte bastante decente para que los lenguajes de programación funcionen con su API. Las bibliotecas admitidas oficialmente se encuentran en las áreas de C #, Go, Java, node.js, PHP, Python y Ruby. La documentación es bastante detallada, pero, al igual que con otras tecnologías avanzadas, la comunidad es bastante pequeña en comparación con las tecnologías de bases de datos más populares, lo que puede conducir a un aumento en el tiempo dedicado a resolver casos o problemas de uso menos comunes.

Entonces, ¿qué pasa con el apoyo al desarrollo local?


No encontramos una manera de crear una instancia de Cloud Spanner en el entorno local. Lo más parecido que tenemos es la imagen de CockroachDB Docker , que en principio es similar, pero en la práctica es muy diferente. Por ejemplo, CockroachDB puede usar PostgreSQL JDBC. Dado que el entorno de desarrollo debe ser lo más cercano posible al entorno de trabajo, Cloud Spanner no es ideal, ya que debe confiar en una instancia completa de Spanner. Para ahorrar costos, puede elegir una instancia para una región.

¿Apoyo a la administración?


Crear una instancia de Cloud Spanner es fácil. Solo necesita elegir entre crear una instancia o región multirregional para una región, especificar las regiones y la cantidad de nodos. En menos de un minuto, la instancia estará en funcionamiento.

Varias métricas básicas están disponibles directamente en la página de Spanner en la consola de Google. Hay vistas más detalladas disponibles a través de Stackdriver, donde también puede establecer métricas de umbral y políticas de alerta.

¿Acceso a los recursos?


MySQL ofrece permisos de usuario extensos y muy detallados / configuraciones de roles. Puede configurar fácilmente el acceso a una tabla específica, o incluso a un subconjunto de sus columnas. Cloud Spanner utiliza la herramienta Google Identity & Access Management (IAM), que le permite establecer políticas y permisos solo a un nivel muy alto. La opción más detallada es una resolución a nivel de base de datos que no se ajusta a la mayoría de los casos de producción. Esta restricción lo obliga a agregar medidas de seguridad adicionales a su código, infraestructura o ambas para evitar el uso no autorizado de los recursos de Spanner.

Copias de seguridad?


En términos simples, no hay copias de seguridad en Cloud Spanner. Aunque los altos requisitos del SLA de Google pueden garantizar que no perderá ningún dato debido a fallas de hardware o de la base de datos, errores humanos, defectos de la aplicación, etc. Todos conocemos la regla: la alta disponibilidad no reemplaza una estrategia de respaldo razonable. Por el momento, la única forma de hacer una copia de seguridad de los datos es transmitirlos mediante programación desde la base de datos a un entorno de almacenamiento separado.

Consulta de rendimiento?


Utilizamos Yahoo! para descargar datos y probar consultas. Benchmark de servicio en la nube. La siguiente tabla muestra la carga de trabajo YCSB B con una relación de lectura del 95% y una relación de escritura del 5%.



* La prueba de carga se realizó en el motor computacional (CE) n1-standard-32 (32 vCPU, 120 GB de memoria), y la instancia de prueba nunca fue un cuello de botella en las pruebas.
** El número máximo de subprocesos en una instancia de YCSB es 400. En total, se tuvieron que ejecutar seis instancias paralelas de pruebas YCSB para obtener un total de 2400 subprocesos.

Al observar los resultados de la prueba, en particular la combinación de carga del procesador y TPS, vemos claramente que Cloud Spanner escala bastante bien. La gran carga creada por una gran cantidad de subprocesos se compensa con la gran cantidad de nodos en el clúster de Cloud Spanner. Aunque el retraso parece bastante alto, especialmente cuando se trabaja con 2400 subprocesos, puede ser necesario volver a probar con 6 instancias más pequeñas del motor computacional para obtener números más precisos. Cada instancia ejecutará una prueba YCSB en lugar de una instancia CE grande con 6 pruebas paralelas. Por lo tanto, será más fácil distinguir entre los retrasos de solicitud de Cloud Spanner y los retrasos añadidos por la conexión de red entre Cloud Spanner y la instancia CE en la que se ejecuta la prueba.

¿Cómo maneja Cloud Spanner OLAP?


¿Fraccionamiento?


La división de datos en segmentos físicos y / o lógicamente independientes, llamados particiones, es un concepto muy popular inherente a la mayoría de los mecanismos OLAP. Las particiones pueden mejorar significativamente el rendimiento de las consultas y el soporte de la base de datos. Una mayor profundización en la partición aparecería en un artículo (s) por separado, así que solo mencionemos la importancia de tener un esquema de partición y subpartición. La capacidad de particionar datos en particiones y aún más en subparticiones es clave para el desempeño de las consultas analíticas.

Cloud Spanner no admite particiones per se. Divide los datos internamente en la llamada divisións basado en rangos de clave primaria. La separación se realiza automáticamente para equilibrar la carga en el clúster de Cloud Spanner. Una característica muy conveniente de Cloud Spanner es dividir la carga base de la tabla principal (una tabla que no se alterna con otra). Spanner determina automáticamente si la división contiene datos que se leen con más frecuencia que los datos de otras divisiones , y puede decidir una separación adicional. Por lo tanto, pueden participar más nodos en la solicitud, lo que también aumenta efectivamente el rendimiento.

¿Cargando datos?


El método de Cloud Spanner para datos masivos es el mismo que para las descargas regulares. Para lograr el máximo rendimiento, debe seguir algunas recomendaciones, que incluyen:

  • Ordene sus datos por clave principal.
  • Divídalos por 10 * el número de nodos de secciones individuales.
  • Cree un conjunto de tareas de trabajo que carguen datos en paralelo.

Con esta descarga de datos, se utilizan todos los nodos de Cloud Spanner.

Utilizamos la carga de trabajo A YCSB para generar un conjunto de datos de 10 millones de filas.



* La prueba de carga se realizó en el motor informático n1-standard-32 (32 vCPU, 120 GB de memoria), y la instancia de prueba nunca fue un cuello de botella en las pruebas.
** No se recomienda una configuración de 1 nodo para ninguna carga de producción.

Como se mencionó anteriormente, Cloud Spanner procesa automáticamente las divisiones según su carga, por lo que los resultados mejoran después de varias repeticiones sucesivas de la prueba. Los resultados presentados aquí son los mejores resultados que hemos recibido. Mirando los números anteriores, podemos ver cómo Cloud Spanner se escala (bien) con un aumento en el número de nodos en el clúster. Los números que se destacan son retrasos promedio extremadamente bajos que contrastan con los resultados de cargas de trabajo mixtas (95% para lectura y 5% para escritura), como se describe en la sección anterior.

¿Escalada?


Aumentar y disminuir el número de nodos de Cloud Spanner es una tarea de un solo clic. Si desea cargar rápidamente los datos, puede considerar aumentar la instancia al máximo (en nuestro caso, fueron 25 nodos en la región US-EAST), y luego reducir la cantidad de nodos adecuados para su carga regular, después de todos los datos en la base de datos teniendo en cuenta la limitación de 2 TB / nodo.

Se nos recordó este límite incluso con una base de datos mucho más pequeña. Después de varias ejecuciones de pruebas de carga, nuestra base de datos tenía un tamaño de aproximadamente 155 GB, y cuando se redujo a una instancia de 1 nodo, recibimos el siguiente error:



pudimos reducir la escala de 25 a 2 instancias, pero estábamos atascados en dos nodos.

El aumento y la disminución del número de nodos en un clúster de Cloud Spanner se pueden automatizar mediante la API REST. Esto puede ser especialmente útil para reducir el aumento de carga en el sistema durante las horas ocupadas.

Rendimiento de la consulta OLAP?


Inicialmente, planeamos dedicar un tiempo considerable a nuestra evaluación de Spanner para esta parte. Después de varios RECUENTOS SELECCIONADOS, inmediatamente nos dimos cuenta de que las pruebas serían cortas y que Spanner NO sería un motor OLAP. Independientemente del número de nodos en el clúster, una selección simple del número de filas en una tabla de 10 millones de filas tomó de 55 a 60 segundos. Además, cualquier solicitud que requirió más memoria para almacenar resultados intermedios falló con un error OOM.

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

Se pueden encontrar algunos números para las solicitudes de TPC-H en el artículo Nosql-kudu-spanner-slides.html , diapositivas 42 y 43 de Todd Lipcon . Estos números son consistentes con nuestros propios resultados (desafortunadamente).



4. Nuestros hallazgos


Dado el estado actual de las características de Cloud Spanner, es difícil imaginarlo como un simple reemplazo de una solución OLTP existente, especialmente cuando sus necesidades lo superan. Tendría que dedicar una gran cantidad de tiempo a construir una solución que tenga en cuenta los defectos de Cloud Spanner.

Cuando comenzamos a evaluar Cloud Spanner, esperábamos que sus funciones de administración estuvieran al menos o no tan lejos de otras soluciones de Google SQL. Pero nos sorprendió la falta total de copias de seguridad y el control muy limitado del acceso a los recursos. Sin mencionar la falta de vistas, la falta de un entorno de desarrollo local, secuencias no compatibles, JDBC sin compatibilidad con DML y DDL, etc.

Entonces, ¿a dónde va el que necesita escalar la base de datos transaccional? Parece que no existe una solución única en el mercado que sea adecuada para todos los casos de uso. Hay muchas soluciones de código abierto y cerrado (algunas de las cuales se mencionan en este artículo), cada una de las cuales tiene sus propias fortalezas y debilidades, pero ninguna de ellas ofrece SaaS con un 99.999% de SLA y un alto grado de consistencia. Si su objetivo principal es un SLA alto y no está dispuesto a crear su propia solución para múltiples entornos de nube, Cloud Spanner puede ser la solución que está buscando. Pero debes ser consciente de todas sus limitaciones.

Para ser justos, debe tenerse en cuenta que Cloud Spanner no se lanzó al público solo en la primavera de 2017, por lo que es razonable esperar que algunas de sus deficiencias actuales eventualmente desaparezcan (espero), y cuando eso suceda, puede cambiar el juego. Después de todo, Cloud Spanner no es solo un proyecto de terceros para Google. Google lo usa como base para otros productos de Google. Y cuando Google reemplazó recientemente a Megastore en Google Cloud Storage con Cloud Spanner, permitió que Google Cloud Storage fuera estrictamente coherente para las listas de objetos a nivel mundial (que todavía no se aplica al S3 de Amazon ). Entonces, todavía hay esperanza ... esperamos.



Eso es todo. Al igual que el autor del artículo, también seguimos esperando, pero ¿qué opinas sobre esto? Escriba los comentarios.

Todos están invitados a visitar nuestro seminario web gratuito, en cuyo marco hablaremos en detalle sobre el curso OTUS AWS para desarrolladores .

More articles:


All Articles