Hola, residentes de Khabrovsk. Como es habitual, seguimos compartiendo material interesante de cara al inicio de nuevos cursos. Hoy, especialmente para ti, hemos publicado un artículo sobre Google Cloud Spanner coincidiendo con el lanzamiento del curso. .
Publicado originalmente en .
Como empresa que ofrece una variedad de soluciones POS basadas en la nube a minoristas, restauradores y vendedores en línea de todo el mundo, Lightspeed utiliza varios tipos diferentes de plataformas de bases de datos para una variedad de casos de uso transaccionales, analíticos y de búsqueda. Cada una de estas plataformas de bases de datos tiene sus propias fortalezas y debilidades, por lo que cuando Google introdujo Cloud Spanner en el mercado, características prometedoras nunca vistas en el mundo de las bases de datos relacionales, como una 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 brindar una descripción general completa de nuestra experiencia con Cloud Spanner, así como los criterios de evaluación que utilizamos, cubriremos los siguientes temas:
- Nuestros criterios de evaluación
- Cloud Spanner en pocas palabras
- Nuestra calificación
- Nuestros resultados
1. Nuestros criterios de evaluación
Antes de profundizar en los detalles de Cloud Spanner, sus similitudes y diferencias con otras soluciones del mercado, hablemos primero de los principales casos de uso 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 utilizar una solución OLTP con soporte OLAP
Nota: Para simplificar y facilitar la comparación, este artículo compara Cloud Spanner con las variantes de MySQL de las familias de soluciones GCP Cloud SQL y Amazon AWS RDS.
Usar Cloud Spanner como reemplazo de una solución de base de datos SQL tradicional
En el ambiente tradicional En las bases de datos, cuando el tiempo de respuesta de la consulta de la 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 solicitudes), existen varias formas de reducir el tiempo de respuesta a niveles aceptables. Sin embargo, la mayoría de estas soluciones implican intervención manual.
Por ejemplo, el primer paso a seguir es observar los diversos parámetros de la base de datos relacionados con el rendimiento y ajustarlos para que coincidan mejor con los patrones de casos de uso de la aplicación. Si esto no es suficiente, puede optar por escalar la base de datos vertical u horizontalmente.
Escalar verticalmente una 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 da como resultado un mayor rendimiento de la base de datos, medido principalmente en transacciones en segundos y latencia de transacciones para 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 varias desventajas, pero la más obvia es el tamaño máximo de servidor en el mercado. Una vez que se alcanza el límite de la instancia de servidor más grande, solo queda una opción: el escalado horizontal.
El escalado horizontal es un enfoque en el que se agregan más servidores a un clúster, lo ideal es aumentar el rendimiento de forma lineal a medida que se agrega la cantidad de servidores. Mayoría tradicional Los sistemas de bases de datos no escalan bien horizontalmente o no escalan en absoluto. Por ejemplo, MySQL puede escalar horizontalmente para operaciones de lectura agregando lectores esclavos, pero no puede escalar horizontalmente para escrituras.
Por otro lado, debido a su naturaleza, Cloud Spanner puede escalar horizontalmente fácilmente con una mínima intervención.
Totalmente destacado DBMS como servicio deben ser evaluados 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: fácil desarrollo y pruebas.
- Soporte de administración: gestión de instancias, por ejemplo, ampliación/reducción de escala y actualización de instancias; SLA, respaldo y recuperación; seguridad/control de acceso.
Uso de Cloud Spanner como solución OLTP habilitada para OLAP
Si bien Google no afirma explícitamente que Cloud Spanner esté diseñado para procesamiento analítico, comparte algunos atributos con otros motores como Apache Impala & Kudu y YugaByte, que están diseñados para cargas de trabajo OLAP.
Incluso si hubiera solo una pequeña posibilidad de que Cloud Spanner incluyera un motor HTAP (procesamiento híbrido transaccional/analítico) consistente y escalable con un conjunto de características OLAP (más o menos) utilizables, creemos que merecería nuestra atención.
Con esto en mente, analizamos las siguientes categorías:
- Carga de datos, índices y soporte de partición
- Rendimiento de consultas y DML
2. Cloud Spanner en pocas palabras
Google Spanner es un sistema de gestión de bases de datos relacionales agrupadas (RDBMS) que Google utiliza para varios de sus propios servicios. Google lo puso a disposición de los usuarios de Google Cloud Platform a principios de 2017.
Estos son algunos de los atributos de Cloud Spanner:
- Clúster RDBMS escalable y altamente consistente: utiliza sincronización horaria de hardware para garantizar la coherencia de los datos.
- Compatibilidad con transacciones entre tablas: las transacciones pueden abarcar varias tablas, no necesariamente limitadas a una sola tabla (a diferencia de Apache HBase o Apache Kudu).
- Tablas basadas en clave primaria: todas las tablas deben tener una clave primaria (PC) declarada, que puede constar de varias columnas en la tabla. Los datos tabulares se almacenan en el orden de la PC, lo que los hace muy eficientes y rápidos para la búsqueda en la PC. Al igual que otros sistemas basados en PC, la implementación debe modelarse teniendo en cuenta casos de uso prediseñados para lograr .
- Tablas rayadas: las tablas pueden tener dependencias físicas entre sí. Las filas de una tabla secundaria se pueden comparar con las filas de una tabla principal. Este enfoque acelera la búsqueda de relaciones que puedan identificarse durante la fase de modelado de datos, como la ubicación conjunta de los clientes y sus facturas.
- Índices: Cloud Spanner admite índices secundarios. El índice consta de las columnas indexadas y todas las columnas de PC. Si lo desea, el índice también puede contener otras columnas no indexadas. El índice se puede intercalar con la tabla principal para acelerar las consultas. Se aplican varias restricciones a los índices, como el número máximo de columnas adicionales almacenadas en el índice. Además, las consultas a través de índices pueden no ser tan sencillas como en otros RDBMS.
“Cloud Spanner selecciona un índice automáticamente sólo en casos excepcionales. En particular, Cloud Spanner no selecciona automáticamente un índice secundario si una consulta solicita columnas que no están almacenadas en ".
- Acuerdo de Nivel de Servicio (SLA): Implementación en una región con un SLA del 99,99%; Implementaciones multirregionales con 99,999% SLA. Si bien el SLA en sí es solo un acuerdo y no una garantía de ningún tipo, creo que la gente de Google tiene algunos datos concretos para hacer una afirmación tan sólida. (Como referencia, 99,999% significa 26,3 segundos de indisponibilidad del servicio por mes).
- Más:
Nota: El proyecto Apache Tephra agrega soporte de transacciones mejorado a Apache HBase (ahora también implementado en Apache Phoenix como versión beta).
3. Nuestra valoración
Entonces, todos hemos leído las afirmaciones de Google sobre los beneficios de Cloud Spanner: escalamiento horizontal prácticamente ilimitado manteniendo una alta consistencia y un SLA muy alto. Aunque estos requisitos son, en cualquier caso, extremadamente difíciles de alcanzar, nuestro objetivo no era refutarlos. En lugar de ello, centrémonos en otras cosas que preocupan a la mayoría de los usuarios de bases de datos: la paridad y la usabilidad.
Evaluamos Cloud Spanner como reemplazo de MySQL fragmentado
Google Cloud SQL y Amazon AWS RDS, dos de los DBMS OLTP más populares en el mercado de la nube, tienen un conjunto muy amplio de funciones. Sin embargo, para escalar estas bases de datos más allá del tamaño de un único nodo, es necesario realizar la partición de la aplicación. Este enfoque crea una complejidad adicional tanto para las aplicaciones como para la administración. Analizamos cómo Spanner encaja en el escenario de combinar múltiples fragmentos en una sola instancia y qué características (si corresponde) podrían necesitar ser sacrificadas.
¿Soporte SQL, DML y DDL, así como conectores y bibliotecas?
Primero, al comenzar con cualquier base de datos, es necesario crear un modelo de datos. Si cree que puede conectar JDBC Spanner a su herramienta SQL favorita, encontrará que puede consultar sus datos con ella, pero no puede usarla para crear una tabla o modificar (DDL) o cualquier inserción/actualización/eliminación. operaciones (DML). El JDBC oficial de Google no es compatible con ninguno de estos.
"Los controladores actualmente no admiten declaraciones DML o DDL".
Documentación de llave inglesa
La situación no es mejor con la consola GCP: solo puedes enviar consultas SELECT. Por suerte existe un driver JDBC con soporte para DML y DDL de la comunidad, incluyendo transacciones . Si bien este controlador es extremadamente útil, sorprende la falta del controlador JDBC propio de Google. Afortunadamente, Google ofrece soporte bastante amplio para bibliotecas cliente (basadas en gRPC): C#, Go, Java, node.js, PHP, Python y Ruby.
El uso casi obligatorio de las API personalizadas de Cloud Spanner (debido a la falta de DDL y DML en JDBC) genera algunas limitaciones para áreas de código relacionadas, como grupos de conexiones o marcos de enlace de bases de datos (por ejemplo, Spring MVC). Normalmente, cuando utiliza JDBC, puede elegir su grupo de conexiones favorito (por ejemplo, HikariCP, DBCP, C3PO, etc.) que esté probado y funcione bien. En el caso de las API de Spanner personalizadas, tenemos que confiar en marcos/grupos de enlaces/sesiones que hemos creado nosotros mismos.
El diseño centrado en la clave principal (PC) permite que Cloud Spanner sea muy rápido al acceder a los datos a través de la PC, pero también introduce algunos problemas de consulta.
- No puede actualizar el valor de la clave principal; Primero debe eliminar la entrada de la PC original y reinsertarla con el nuevo valor. (Esto es similar a otros motores de almacenamiento/bases de datos orientados a PC).
- Cualquier declaración ACTUALIZAR y ELIMINAR debe especificar PC en WHERE, por lo tanto, no puede haber declaraciones ELIMINAR todas vacías; siempre debe haber una subconsulta, por ejemplo: ACTUALIZAR xxx WHERE id IN (SELECT id FROM table1)
- Falta de opción de incremento automático o algo similar que establezca la secuencia para el campo de PC. Para que esto funcione, se debe crear el valor correspondiente en el lado de la aplicación.
¿Índices secundarios?
Google Cloud Spanner tiene soporte integrado para índices secundarios. Esta es una característica muy interesante que no siempre está presente en otras tecnologías. Actualmente, Apache Kudu no admite ningún índice secundario 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 claves primarias, pero la atomicidad de las operaciones realizadas en la tabla principal y las tablas de índice asociadas se debe realizar en el nivel de la aplicación y no es trivial implementarlo correctamente.
Como se menciona 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 una base de datos son las vistas. Pueden resultar útiles para una gran cantidad de casos de uso; Mis dos favoritos son la capa de abstracción lógica y la capa de seguridad. Lamentablemente, Cloud Spanner NO admite vistas. Sin embargo, esto sólo nos limita parcialmente porque no hay granularidad para los permisos de acceso a nivel de columna donde las vistas podrían ser una solución viable.
Consulte la documentación de Cloud Spanner para obtener una sección que detalla cuotas y restricciones (), hay uno en particular que puede resultar 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 cuello de botella importante 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 soporte de lenguaje de programación bastante decente para trabajar con su API. Las bibliotecas oficialmente admitidas 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 llevar a dedicar más tiempo a resolver casos de uso o problemas menos comunes.
¿Qué pasa entonces con el apoyo al desarrollo local?
No hemos encontrado una manera de crear una instancia de Cloud Spanner local. Lo más parecido que obtuvimos fue una imagen de Docker. , que es similar en principio, pero muy diferente en la práctica. Por ejemplo, CockroachDB puede utilizar PostgreSQL JDBC. Dado que el entorno de desarrollo debe ser lo más parecido posible al entorno de producción, Cloud Spanner no es ideal ya que debe depender de una instancia completa de Spanner. Para ahorrar costos, puede seleccionar una instancia de una sola región.
¿Apoyo a la administración?
Crear una instancia de Cloud Spanner es muy sencillo. Solo necesita elegir entre crear una instancia de varias regiones o de una sola región, especificar las regiones y la cantidad de nodos. En menos de un minuto, su instancia estará operativa.
Se puede acceder directamente a varias métricas rudimentarias desde la página de Spanner en Google Console. Hay vistas más detalladas disponibles a través de Stackdriver, donde también puedes establecer umbrales de métricas y políticas de alerta.
¿Acceso a recursos?
MySQL ofrece configuraciones extensas y muy granulares para permisos/roles de usuario. Puede configurar fácilmente el acceso a una tabla específica, o incluso solo a un subconjunto de sus columnas. Cloud Spanner utiliza la herramienta de gestión de identidad y acceso (IAM) de Google, que sólo le permite establecer políticas y permisos en un nivel muy alto. La opción más granular es la resolución a nivel de base de datos, que no se adapta a la mayoría de los casos de uso de producción. Esta limitación lo obliga a agregar medidas de seguridad adicionales a su código, infraestructura o ambos para evitar el uso no autorizado de los recursos de Spanner.
¿Copias de seguridad?
En pocas palabras, no hay copias de seguridad en Cloud Spanner. Aunque los altos requisitos de SLA de Google pueden garantizar que no se pierda ningún dato debido a fallas de hardware o de bases de datos, errores humanos, defectos de aplicaciones, etc. Todos conocemos la regla: la alta disponibilidad no reemplaza una estrategia de respaldo sólida. Actualmente, la única forma de realizar una copia de seguridad de los datos es transmitirlos mediante programación desde una base de datos a un entorno de almacenamiento independiente.
¿Consulta el rendimiento?
Usamos Yahoo! para cargar datos y probar consultas. Punto de referencia de servicio en la nube. La siguiente tabla muestra la carga de trabajo B de YCSB con una proporción de lectura del 95 % y escritura del 5 %.
* La prueba de carga se ejecutó en Compute Engine (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 sola instancia de YCSB es 400. Se tuvieron que ejecutar un total de seis instancias paralelas de pruebas de YCSB para obtener un total de 2400 subprocesos.
Al observar los resultados de las pruebas comparativas, particularmente la combinación de carga de CPU y TPS, podemos ver claramente que Cloud Spanner escala bastante bien. La gran carga creada por la gran cantidad de subprocesos se ve compensada por la gran cantidad de nodos en el clúster de Cloud Spanner. Si bien la latencia parece bastante alta, especialmente cuando se ejecuta con 2400 subprocesos, puede ser necesario volver a realizar pruebas con 6 instancias más pequeñas del motor informático para obtener números más precisos. Cada instancia ejecutará una prueba YCSB en lugar de una instancia CE grande con 6 pruebas paralelas. De esta manera, será más fácil diferenciar entre la latencia de solicitud de Cloud Spanner y la latencia agregada por la conexión de red entre Cloud Spanner y la instancia CE que ejecuta la prueba.
¿Cómo funciona Cloud Spanner como OLAP?
¿Fraccionamiento?
Dividir datos en segmentos física y/o lógicamente independientes, llamados particiones, es un concepto muy popular que se encuentra en la mayoría de los motores OLAP. Las particiones pueden mejorar significativamente el rendimiento de las consultas y la capacidad de mantenimiento de la base de datos. Profundizar en la partición sería un artículo aparte, así que mencionemos la importancia de tener un esquema de partición y subpartición. La capacidad de dividir los datos en particiones e incluso más en subparticiones es clave para el rendimiento de las consultas analíticas.
Cloud Spanner no admite particiones como tales. Divide los datos internamente en los llamados dividido-s basado en rangos de claves principales. El particionamiento se realiza automáticamente para equilibrar la carga en un clúster de Cloud Spanner. Una característica muy útil de Cloud Spanner es la división de la carga base de la tabla principal (una tabla que no está intercalada con otra). Spanner detecta automáticamente si contiene dividido Datos que se leen con más frecuencia que los datos de otros. dividido-Ah, y puede que decidamos una mayor separación. De esta manera, se pueden involucrar más nodos en una 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 la carga normal. Para lograr el máximo rendimiento, es necesario seguir algunas pautas, que incluyen:
- Ordene sus datos por clave principal.
- Divídelos por 10*número de nodos secciones separadas.
- Cree un conjunto de tareas de trabajo que carguen datos en paralelo.
Esta carga de datos utiliza todos los nodos de Cloud Spanner.
Utilizamos la carga de trabajo A de YCSB para generar un conjunto de datos de 10 millones de filas.
* La prueba de carga se ejecutó 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 la configuración de un solo nodo para ninguna carga de trabajo de producción.
Como se mencionó anteriormente, Cloud Spanner procesa automáticamente las divisiones en función de su carga, por lo que los resultados mejoran después de varias repeticiones de prueba consecutivas. Los resultados presentados aquí son los mejores resultados que obtuvimos. Al observar los números anteriores, podemos ver cómo Cloud Spanner escala (bien) a medida que aumenta la cantidad de nodos en el clúster. Las cifras que destacan son las latencias promedio extremadamente bajas, que contrastan con los resultados para cargas de trabajo mixtas (95 % de lectura y 5 % de escritura), como se describe en la sección anterior.
¿Escalada?
Aumentar y disminuir la cantidad de nodos de Cloud Spanner es una tarea de un solo clic. Si desea cargar datos rápidamente, podría considerar aumentar su instancia al máximo (en nuestro caso fueron 25 nodos en la región EE. UU. ESTE) y luego reducir la cantidad de nodos elegibles para su carga normal una vez que todos los datos estén en la base de datos, en referencia al límite de 2 TB/nodo.
Recordamos 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:
Logramos reducir la escala de 25 a 2 instancias, pero estábamos atrapados en dos nodos.
El aumento y la disminución de la cantidad de nodos en un clúster de Cloud Spanner se pueden automatizar mediante la API REST. Esto puede resultar especialmente útil para reducir el aumento de la carga del sistema durante las horas de trabajo ocupadas.
¿Rendimiento de consultas OLAP?
Originalmente planeamos dedicar una cantidad significativa de tiempo a nuestra evaluación de Spanner en esta parte. Después de varios SELECT COUNT, inmediatamente nos dimos cuenta de que las pruebas serían breves y que Spanner NO sería un motor adecuado para OLAP. Independientemente de la cantidad de nodos en el clúster, simplemente seleccionar la cantidad de filas en una tabla de 10 millones de filas tomó entre 55 y 60 segundos. Además, cualquier consulta que requiriera más memoria para almacenar resultados intermedios fallaba con un error OOM.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Algunos números para consultas de TPC-H se pueden encontrar en el artículo de Todd Lipcon. , diapositivas 42 y 43. Estos números son consistentes con nuestros propios resultados (desafortunadamente).
4. Nuestras conclusiones
Dado el estado actual de las funciones de Cloud Spanner, es difícil imaginar que sea un simple reemplazo de su solución OLTP existente, especialmente cuando sus necesidades la superan. Se tendría que dedicar una cantidad significativa de tiempo a crear una solución que solucione las deficiencias de Cloud Spanner.
Cuando comenzamos a evaluar Cloud Spanner, esperábamos que sus funciones de administración estuvieran a la par, o al menos no muy lejos, de otras soluciones de Google SQL. Pero nos sorprendió la total falta de copias de seguridad y el control muy limitado sobre el acceso a los recursos. Sin mencionar la falta de vistas, el entorno de desarrollo local, las secuencias no compatibles, JDBC sin soporte DML y DDL, etc.
Entonces, ¿a dónde va alguien que necesita escalar una base de datos transaccional? No parece haber una solución única en el mercado que se adapte a todos los casos de uso. Hay muchas soluciones de código abierto y cerradas (algunas de las cuales se mencionan en este artículo), cada una con sus propias fortalezas y debilidades, pero ninguna ofrece SaaS con un SLA del 99,999% y alta consistencia. Si su objetivo principal es un SLA alto y no está dispuesto a crear una solución multinube personalizada, Cloud Spanner puede ser la solución que está buscando. Pero debes ser consciente de todas sus limitaciones.
Para ser justos, Cloud Spanner solo se lanzó al público en la primavera de 2017, por lo que es razonable esperar que algunas de sus deficiencias actuales eventualmente desaparezcan (con suerte), y cuando lo hagan, podría cambiar las reglas del juego. Después de todo, Cloud Spanner no es sólo un proyecto paralelo de Google. Google lo utiliza como base para otros productos de Google. Y cuando Google recientemente reemplazó Megastore en Google Cloud Storage con Cloud Spanner, permitió que Google Cloud Storage se volviera altamente consistente para listas de objetos a escala global (lo que todavía no es el caso para ).
Así que todavía hay esperanza... esperamos.
Eso es todo. Al igual que el autor del artículo, nosotros también seguimos teniendo esperanza, pero ¿qué opinas de esto? Escribe en los comentarios.
Invitamos a todos a visitar nuestro dentro del cual te contaremos detalladamente sobre el curso de OTUS.
Fuente: habr.com