¿Qué aporta Google Cloud Spanner al sector financiero?

Como ya hemos abordado en posts anteriores, Google Cloud Spanner ofrece una gran variedad de prestaciones; se trata del primer servicio de bases de datos relacionales del mundo horizontalmente escalable y altamente consistente, y ha sido diseñado para aplicaciones OLTP de misión crítica. Además, ofrece lo mejor de las bases de datos relacionales y de las NoSQL, por lo que ya no es necesario sacrificar la escalabilidad o la consistencia, como pasa en otras soluciones.

Los requisitos para el procesamiento de datos en el sector financiero exigen, cada vez más, algunas de las características que Google Cloud Spanner ofrece, por lo que, en teoría, su viabilidad para el sector es indiscutible. Sin embargo y a pesar de las ventajas de Spanner, algunos clientes aún muestran su escepticismo a cómo sería el modelado de datos o, en concreto, como de compleja sería una migración desde un sistema relacional clásico. Para confirmar dicha viabilidad y comprobar si Google Cloud Spanner presenta todas las características que requiere un sistema OLTP, la Practice de Data decidió realizar una prueba de concepto implementando el benchmark TPC-E, famosa en el sector de las bases de datos.

Alcance

El alcance de esta prueba de concepto consistió en implementar de forma pragmática un subconjunto de TPC-E, representando éste una aplicación cualquiera con una carga de trabajo OLTP, con especial foco en el modelado de datos. El rendimiento, la escalabilidad y la alta disponibilidad se dan por sentados y no se han incluido en la prueba. Así, el objetivo principal es hacer un resumen de las experiencias obtenidas durante esta prueba de concepto y extrapolar algunas conclusiones para determinar la viabilidad de esta tecnología en una aplicación real.

TPC-E

TPC es una sociedad sin ánimo de lucro creada para definir benchmarks de procesamiento de transacciones y bases de datos, así como para difundir datos de rendimiento objetivos y verificables en el sector. Entre los miembros de esta organización destacan Cisco, Dell, Fujitsu, HP, Huawei, IBM, Microsoft, Oracle y SAP. Existen benchmarks para diferentes escenarios: TPCx-IoT para Internet de las cosas, TPCx-BB para tecnologías de Big Data, TPC-H para sistemas de soporte a las decisiones o TPC-C y TPC-E para sistemas de procesamiento de transacciones, por nombrar unos cuantos.

Desde 2007, TPC-E es el benchmark de referencia para sistemas OLTP y reemplaza al ya obsoleto TPC-C. TPC-E, aunque no está limitado a la actividad de ningún segmento de negocio en particular, emula un modelo de negocio financiero y representa la actividad de una agencia de brokers.

Muy brevemente, el benchmark TPC-E define 33 tablas que cubren tres áreas: clientes, brokers y mercado, con una amplia gama de columnas, cardinalidad y propiedades de escalado. Además, define diez transacciones que generan una carga de trabajo OLTP: cuatro de ellas de lectura/escritura y seis solo de lectura. Incluso algunas de ellas podrían considerarse consultas de business intelligence pues su huella es mayor de lo habitual para una consulta OLTP. Como en el resto de benchmarks de TPC, el rendimiento se mide en transacciones por segundo (tpsE y $/tpsE).

Implementación

Para la construcción del modelo, se ha creado el modelo de datos completo, compuesto por las 33 tablas definidas en el benchmark. Para la generación de datos, se ha utilizado en software proporcionado por TPC. Y para la carga inicial, se han implementado unos cargadores a medida a partir de los CSV generados. Para las pruebas, consideramos dos datasets con distinta cardinalidad de datos:

–       Conjunto de datos pequeño – 1000 clientes, cinco días laborables – 285 MB.

–       Conjunto de datos grande – 50 000 clientes, cinco días laborables – 13 GB

Para la implementación de las transacciones y siendo pragmáticos, solo se han implementado tres que hemos considerado representativas:

• Trade-Order(orden de transacción) – Lectura/escritura (RW, por sus siglas en inglés)
• Trade-Status(estado de la transacción) – Solo lectura (RO, por sus siglas en inglés)
• Broker-Volume(volumen de bróker) – Solo lectura (RO, analítica)

Criterios de selección

La transacción Trade-Orderaña de registros a la tabla TradeRequesty Broker-Volume consulta dicha tabla.

La transacción Trade-Status es de solo lectura y con una huella pequeña, mientras que Broker-Volume parece una consulta más tipo business intelligence.

En el contexto de TPC, una transacción es una operación lógica de negocio, no una transacción de la base de datos. En realidad, de media cada transacción consiste en unas cinco instrucciones SELECT/MUTATE. Además, el benchmark requiere que parte de la lógica debe ser implementada en el lado cliente. Así y por ejemplo, no es posible implementar toda la lógica como un único procedimiento almacenado en el lado servidor.

Los apartados siguientes resumen las experiencias durante la implementación del benchmark TPC-E: problemas encontrados y cómo se solucionaron.

Modelo de datos

DML y tipos de datos. Google Cloud Spanner proporciona soporte para crear bases de datos, tablas e índices. Admite incluso cambios de los esquemas en línea sin tener que interrumpir la actividad de la base de datos. No obstante, no ofrece soporte para vistas ni comandos CTAS (Create Table As Select). En cuanto a los tipos de datos válidos, admite BOOL, INT64, FLOAT64, STRING, BYTES (hasta 10 MB), DATE y TIMESTAMP. También permite ARRAY y STRUCTS con estos tipos de datos primitivos. Sin embargo, no incluye soporte para large objects. Durante el desarrollo de la prueba de concepto no fueron necesarias las vistas, pero se echó en falta el soporte de CTAS, específicamente cuando se probaron diferentes modelos físicos para el mismo modelo lógico. Tampoco es posible optimizar el almacenamiento (y, por tanto, el coste) debido a que no se admiten tipos de datos más pequeños (int/float small o tiny). TPC-E no requiere almacenar objetos grandes. De ser necesario, la alternativa sería usar Google Cloud Storage.

Modelo físico. El número de optimizaciones físicas a aplicar es bastante reducido, por lo que pasar del modelo lógico al físico es fácil. Por otra parte, no es posible realizar optimizaciones creando índices de mapa de bits, b-treeo hash, o estrategias de partición horizontal y vertical. Elegir la clave principal con cuidado es uno de los puntos claves en Google Cloud Spanner para evitar hotspots. Habitualmente, en vez de usar columnas numéricas autoincrementadas para la clave principal, en su lugar se pueden convertir mediante un hash o reemplazar por un UUID. En general, cualquier acceso a los datos se debe realizar mediante la clave principal o un índice secundario para garantizar el rendimiento pero, sorprendentemente, la falta de particionado horizontal no permite reducir el espacio de búsqueda.

Restricciones de integridad. El soporte para restricciones de integridad solo incluye PRIMARY KEY, NOT NULL y UNIQUE, por lo que no se admiten restricciones de integridad FOREIGN KEY, CHECK ni DEFAULT. Si es necesario, todas esas restricciones de integridad se deben gestionar directamente en la aplicación. Las tablas intercaladas merecen una mención especial: cuando se utilizan, colocan físicamente filas de tablas relacionadas para aumentar la localización de los datos. Al mismo tiempo, permiten modelar una restricción de integridad FOREIGN KEY para un tipo de relación específico: tablas padre-hijo.

Cargas masivas. Dado que no se admiten instrucciones DML ni herramientas de carga masiva específicas, cualquier migración desde otro sistema de gestión de bases de datos relacionales es más complejo de lo esperado. En la implementación de TPC-E, la carga de datos iniciales se llevó a cabo mediante cargadores CSV desarrollados a medida. Como decíamos antes, es esencial elegir la clave principal con cuidado y hay que tenerlo en cuenta a la hora de cargar datos desde fuentes externas. Por ejemplo, en caso de cargar valores con incremento monolítico para una columna de clave principal, algo tan sencillo como invertir el valor evita los hotspots. Otro enfoque más elegante podría ser aplicar una función hashen la entrada del valor.

Desarrollo de la aplicación

Interfaces. Dado que no se admiten instrucciones DML ni procedimientos almacenados, el desarrollo completo de la aplicación se debe realizar mediante uno de los múltiples kits de desarrollo de software que ofrece Google Cloud Spanner. Para implementar esta prueba de concepto se empleó el JDK de Java con SQL:2011 de ANSI para instrucciones SELECT y API Mutation para escrituras, actualizaciones y borrados. No se requería para implementar esta prueba de concepto, pero también faltaba el soporte para triggers.

Índices. En la práctica, el optimizador raramente usa otros índices aparte de la clave principal, principalmente porque los índices secundarios no evitan escaneos en la tabla, a menos que se utilice la cláusula STORING, a costa de la desnormalización de los datos y, por tanto, de un almacenamiento adicional.

Joins.La optimización de joinses complicada, pero es indispensable para mejorar el rendimiento. En general, los índices secundarios no suelen ayudar. No obstante, la materialización de joins (también llamada «join colocalizado») mediante tablas intercaladas puede aumentar el rendimiento considerablemente. En cualquier caso, el orden de las tablas en los joins influye radicalmente en el plan de ejecución y, por lo tanto, en los tiempos de rendimiento y ejecución con resultados de diferentes magnitudes. Aunque algunos sistemas de gestión de bases de datos relacionales populares presentan el mismo problema, esto es un indicador de un optimizador inmaduro. En consecuencia, el mejor enfoque para hallar la consulta más eficaz es seguir una estrategia de ensayo y error probando diferentes consultas y comprobando el plan de ejecución resultante.

Ecosistema. En general, la documentación existente es buena, pero carece de algunos puntos avanzados o complejos. También nos hemos dado cuenta de que la comunidad aún no es muy activa, así que el soporte técnico es bastante limitado. Aunque el desarrollo se realiza de forma local utilizando herramientas de desarrollo tradicionales (IDE, gestores de dependencias, etc.), podría resultar útil realizar algunas pruebas directamente en la interfaz de usuario web de Google Cloud Spanner, en cuyo caso faltarían características básicas en dicha interfaz.

Informe de ejecución

Todas las ejecuciones se realizaron con un generador de cargas de trabajo que funcionaba en local, es decir, remotamente y fuera de GCP (Google Cloud Platform), por lo que la sobrecarga de la red fue considerable. Esto influye mucho en las cargas masivas. La carga de datos inicial para el conjunto de datos pequeño tardó pocos minutos, mientras que para el grande se necesitaron unas cinco horas. Siempre de forma secuencial, sin paralelizar.

Para las transacciones, la carga de trabajo generada consistió en una mezcla aleatoria de transacciones: 40 % para Trade-Order, 40 % para Trade-Statusy 20 % para Broker-Volume. Toda la carga de trabajo se generó desde un cliente local y con un máximo de diez hilos, ya que con un grupo mayor de hilos la mejora era mínima, si es que la había. La capacidad de procesamiento fue de unas 13 transacciones por segundo, lo que significa una latencia media de 75 ms. Advertir que TPC-E establece una latencia máxima permitida de 3 s.

Tanto la carga masiva como la ejecución de transacciones se realizaron con dos nodos de Spanner, aunque la recomendación mínima para un entorno de tipo productivo es de tres. En cualquier caso, la prueba de concepto se centraba en las capacidades de modelado, no en el rendimiento. A modo informativo, estos dos nodos se utilizaron durante unas 450 horas y el coste fue de 380 €.

Lecciones aprendidas y conclusiones

Google Cloud Spanner engloba un sistema NoSQL clave-valor con una abstracción relacional encima. Salir del mundo relacional es fácil, aunque los ajustes para maximizar el rendimiento no siguen los principios relacionales y, por lo tanto, se siguen aplicando algunas técnicas de NoSQL. Por mencionar algunas:

Se debe elegir la clave principal con cuidado, ya que determina la distribución de datos y, por tanto, el equilibrio de cargas y el rendimiento.

Los índices secundarios básicos sin el uso de la cláusula secundaria Storing pueden no resultar muy útiles, con lo que su uso puede resultar prácticamente obligatorio. Además, disponer de un índice para cada patrón de acceso diferente se convierte en algo muy frecuente, a costa de un almacenamiento extra y de la desnormalización de datos.

El orden de las tablas en joins determina el plan de ejecución y, por consiguiente, los tiempos de ejecución.

Así pues y después de realizar esta prueba de concepto, queda patente que, aunque existen dificultades debido a las particularidades del modelo de datos de Google Spanner, estas son salvables, confirmando su adecuación para el entorno bancario. Las ventajas de Google Cloud Spanner son indiscutibles: es un servicio de bases de datos globalmente distribuido, horizontalmente escalable, altamente disponible y muy consistente. Aunque el coste es considerable, se evitan tareas de administración y de mantenimiento, lo que supone un gran ahorro.