Me llegó una notificación sobre una conferencia de Michael StoneBraker en el Postgres Build 2021 y teniendo en cuenta su papel como diseñador de una de las bases de datos más empleadas en el mundo, merece la pena oírlo. ¿Lo comentamos?
Para quien no lo sepa, Michael Stonebraker es quien desarrolló la base de datos PostgreSQL e incluso su antecesora, Ingress y otros proyectos posteriores como HBase. Podría decir mucho más pero creo que Camilo Chacón hizo una buena revisión de esta mente genial en su libro de Mentes Geniales el cual recomiendo.
Volviendo al tema central. Comencé a ver la conferencia y me encontré en su primera exposición algo que me llamó la atención:
The Cloud is in Your Future
O dicho en español: La Nube está en Tu Futuro. Esta es una afirmación muy fuerte y va alineada con las apuestas de grandes empresas como Amazon con su AWS, Google con su GCP o Microsoft con Azure. Incluso otros actores no tan conocidos como DigitalOcean, Scaleway o OVH comienzan a invertir en dar soluciones orientadas a la nube.
Tu futuro está en la nube
Stonebraker expone inicialmente un par de frases de otras personas:
Amazon can stand up a server for 25% of your cost.
-- James Hamilton
Esta frase (acuñada a James Hamilton) viene a decir que Amazon puede levantar un servidor por el 25% de su coste. Principalmente por mantener centros de datos "al por mayor" y sus propios centros de datos.
Microsoft Azure data centers are shipping containers.
-- David Dewitt
Aquí David Dewitt nos ilustra como decíamos antes que Microsoft Azure trabaja principalmente con contenedores en lugar de servidores al uso.
A esto agregamos el precio en aumento del suelo en Londres o Frankfurt y podemos inducir un futuro donde será mejor adquirir una porción de la nube de grandes actores en lugar de un servidor en un centro de datos.
Además, apunta que nos cambiaremos a la nube para:
-
Abaratar costes. El dinero es un factor determinante, Stonebraker señala que el precio es ahora más barato pero que incluso lo será aún más. Se están creando muchos más centros de datos y se espera un abaratamiento del coste de estos servidores y contenedores en la nube aún mayor.
-
Obtener elasticidad. También señala la elasticidad de los servicios. Pagar únicamente por lo que se emplea pudiendo emplear algunos servidores o contenedores extra durante los períodos del año que más se necesiten y bajar el nivel de uso en otros momentos.
Sobre los contras, hace mención de algunos de ellos como la seguridad, las restricciones geográficas, restricciones legales, restricciones de la compañía donde trabajamos. Todos estos problemas han surgido y se han solucionado ya en el pasado. Aunque Stonbraker no lo menciona, podemos echar un vistazo a plataformas como Microsoft Azure que ha sido certificada para poder dar servicio al gobierno de los EEUU, por ejemplo.
Punto de Inicio
Stonebraker nos posiciona en nuestro punto de vista para migrar a la nube. Nos insta a detectar dos elementos a tener en cuenta: La actividad OLTP (On-line Transaction Processing) con pequeñas transacciones con buen tiempo de respuesta y Almacen de Datos con una base de datos histórica de datos de clientes, cargada y consultada y eliminada meses o años más tarde.
Es importante evitar las características propietarias de los proveedores de la Nube. Redes como las de Oracle proporcionan características no compatibles con otros y mantienen precios más altos que el resto. El problema radica en terminar dependiendo de estas características y no poder migrar a otro proveedor en caso de ser necesario.
La Nube
Stonebraker nos recuerda que AWS tiene muchos tamaños, más de 50, con diferentes combinaciones de CPU, memoria, recursos de E/S. Debemos decidir cuál es el tamaño que mejor se ajusta a nuestros datos pero igualmente, la nube nos proporciona esa elasticidad que nos permite probar y ajustarnos. Podemos almacenar datos en S3, en bloque elásticos de bloques (EBS) o sistemas de ficheros elásticos (EFS).
También podemos decidir entre dos opciones:
-
Platform as a Service (PaaS), alquilamos la plataforma y nos encargamos de todo lo que vayamos a instalar en esas instancias.
-
Database as a Service (DBaaS), alquilamos el uso de la base de datos como servicio y nos conectamos con las credenciales que nos proporcionan.
Acerca de esta gran variedad de opciones podemos tener claro que todo depende y cambia MUCHO. El precio entre las diferentes opciones cambia incluso la misma opción entre diferentes proveedores cambia y MUCHO y los tiempos de respuesta para cada una de las opciones y entre los diferentes proveedores también cambia MUCHO.
La decepción
Tienes que optimizar el dinero y los diferentes tamaños a los requisitos:
Lo último que quiero es tener que estar probando "tamaños de camisas" y lo que quiero es un optimizador de tamaños y no esperar días para tener una nueva base de datos preparada para funcionar.
PaaS sería la mejor solución, pero es solo la mitad de la historia. Perdemos elasticidad pudiendo necesitar más en momentos como el Black Friday o menos en otros momentos.
Algunas Estrategias
Una forma de tratar el problema es crear una instancia ENORME, ejecutar diferentes elementos dentro de esa instancia y ajustar los recursos necesarios de forma dinámica. No obstante, esta arquitectura puede producir el problema del "vecino ruidoso". Un usuario que emplee en un momento dado demasiados recursos y obstruya el uso de los demás dentro de la misma instancia.
Otra estrategia es separar el almacenamiento arquitecturalmente en una base de consulta a consulta siguiendo el liderazgo de Snowflake creando almacenes de datos y lagos de datos (datalakes) en la nube.
Stonebraker considera buenas ambas opciones e incluso ambas a la vez. E incluso deja entrever la posibilidad de obtener todo dentro de contenedores.
OLTP es muy difícil de adaptar a estos requisitos. Stonebraker nos insta a comenzar primero con Decision Support (DS, o Soporte de Decisión). Mientras que OLTP está ligado a software legado difícil de mover, comenzar con DS es mucho más sencillo.
Almacenes de Datos
Hay bases de datos de filas. Normalmente, la mayoría de las bases de datos que empleamos como MySQL, PostgreSQL, Microsoft SQL Server y demás están basadas y organizadas en filas. Sin embargo, otras bases de datos como Redshift, Presto o Vertica están basadas en columnas. Esta organización las hace mejores para compresión debido a que es más fácil encontrar datos similares dentro de la misma columna.
PostgreSQL tiene opciones para almacenar datos en columnas (Greenplum) pero tiene el problema de que PostgreSQL sigue manejando los datos basados en filas. Sistemas como Vertica, Redshift o Snowflake organizan los almacenes y la ejecución de consultas por columna y esto permite acelerar las consultas entre 3 y 5 veces.
Finalmente, este tipo de sistemas de almacenamiento por columnas permiten una escalabilidad lineal con el número de nodos y es el camino deseable.
Stonebraker nos brinda una receta para la instalación de nuestra base de datos:
- Ejecuta un PostgreSQL convencional en un tamaño grande de instancia.
- Si es demasiado lento, implementa un esquema en estrella.
- Si sigue siendo demasiado lento, cambia a un almacenamiento por columnas.
- Si aún es demasiado lento, cambia a un sistema multi-nodo Postgres-compatible.
Algunas Consideraciones
Stonebraker nos da algunas notas adicionales sobre la nube. Si podemos permitirnos tener nuestro sistema caído o no esto implica mantener un sistema de replicación para prevenir caídas. Nos proporciona una alta disponibilidad pero a mayor coste.
También, ¿podemos soportar el incremento de latencia? Mantener las bases de datos en nuestro centro de datos, en máquinas en nuestros centros de datos tiende a generar menos latencias y sobre todo cuando nos conectamos empleando herramientas para realizar consultas directamente sobre estas bases de datos. Si podemos minimizar estas acciones podremos mover nuestros OLTP sin molestarnos excesivamente por estos detalles.
¿Necesitas elasticidad? ¿Puede ahorrarte dinero? Quizás tu aplicación no tiene un impacto en momentos temporales y mantiene un nivel de carga lineal. En este caso la elasticidad no es un factor determinante para tu base de datos.
Al mismo tiempo, tenemos algunas restricciones con respecto a configuraciones de red, por ejemplo en el uso de QoS (Quality of Service, Calidad de Servicio) que suele ser imposible de configurar en un servicio prestado como PaaS o DBaaS.
Estrategias de Rendimiento
Stonebraker nos da algunas guías para intentar mejorar el rendimiento de nuestras bases de datos en la nube. Principalmente, minimizar la interacción de humanos con la base de datos. También otros detalles como:
- Usar una interface basada en procedimientos almacenados para evitar cursores.
- Cambiar nuestra aplicación para evitar la contención de control de concurrencia. Realizar cambios de forma ciega.
- Emplear un pool de conexiones y otros trucos para cambios en caliente de Postgres.
Como nota a todo lo propuesto por Stonebraker yo agregaría otras optimizaciones a nivel de implementación del código:
- Intenta no modificar datos. Insertar tiende a ser más rápido si no hay muchas restricciones (claves únicas).
- Si tienes que modificar datos, intenta siempre modificar un único dato y a ser posible localizado por su clave primaria.
- Realiza búsquedas filtrando por índices. Agrega índices compuestos para las consultas más comunes a modo de incrementar la velocidad de búsqueda y obtención de datos. Aunque es mejor si la toma de datos se basa en pocos o un solo filtro.
Si queremos tener una base de datos de alto rendimiento, no obstante, mucho de lo anterior no basta y debemos realizar algunos cambios materiales en la configuración de la base de datos para:
- Emplear memoria principal para la el SGBD (Sistema Gestor de Base de Datos). Nada de buffer pool. Lo que permitiría recortar hasta un máximo de un 35% de uso de CPU.
- Configurar PostgreSQL para emplear un único hilo, evitando así el tiempo de sincronía (latches). Particionar los datos e insistir en que xact interactúe con una única partición y sin multi-hilo. Lo que permitiría recortar hasta un máximo de un 15% de uso de CPU.
- Sin control de concurrencia. Ejecutar xacts en algún orden. Otro recorte de máximo 15% en uso de CPU.
- Sin anotaciones (log). Apostando por la replicación lógica (alta disponibilidad) y recortaríamos otro 15% en uso de CPU.
Conclusiones
Stonebraker concluye con una llamada a la acción:
If you have an OLTP App and you are unhappy with performance, I would like to hear from you: stonebraker@csail.mi.edu
Como puede leerse, Stonebraker abre su contacto para ayudar a todo aquél que tenga una aplicación y no consiga obtener de por sí un rendimiento aceptable con su base de datos. Lo cual es una garantía y un acto muy noble por su parte.
Por mi parte he disfrutado bastante escuchando la charla de Stonebraker y te insto a que le eches un vistazo. Mi resumen puede no ser lo suficientemente preciso por lo que si ves alguna inconsistencia házmela saber.
¿Y tú? ¿Saltaste ya a la nube con todos tus datos? ¿Tu empresa aún mantiene sus centros de datos, bases de datos y toda la infraestructura? ¿Cuál es su excusa? ¡Déjanos un comentario!
