La semana pasada en el CHAR(10) conferencia tuvimos un taller sobre “Bases de datos en la nube”. En pocas palabras:qué hacer cuando los requisitos del caso de uso superan los recursos disponibles en el servidor de la base de datos.
Este fue el tema principal de toda la conferencia y se han ilustrado varias soluciones durante el día. Un tema común ha sido que ninguna solución se adapta a todos los casos de uso y que cada solución tiene su costo; por lo tanto, debe elegir la solución que su caso de uso pueda permitirse.
Otro punto común (aunque implícito) ha sido el enfoque en soluciones de "alto nivel", es decir:conectar varios servidores de bases de datos a un nivel superior para emular un único servidor con mayores recursos.
Una ventaja obvia es que no necesita alterar el código PostgreSQL bien analizado; un inconveniente es que al utilizar varios servidores de bases de datos con sus líneas de tiempo independientes, se pierden algunas propiedades útiles. Dos ejemplos:la pérdida parcial de la semántica transaccional genera conflictos; el análisis previo de cada consulta fuera de la base de datos introduce limitaciones en las consultas aceptadas.
La discusión fue bastante interesante, y cuando Dimitri Fontaine mencionó espacios de tabla remotos, comencé a pensar en una idea relacionada pero distinta, a saber:si un enfoque de nivel inferior al problema de la puesta en común de recursos sería realmente poco práctico. Antes de que pudiera elaborar los detalles, el taller terminó, y solo pude esbozar la idea para algunas de las personas que estaban alrededor de la pizarra (entre las que se encontraban Gabriele Bartolini, Nic Ferrier, Marko Kreen, Hannu Krosing, Greg Smith) junto con la base preguntas "¿parece factible?" y "¿se parece a algo que ya conoces?".
Un breve bosquejo:una pila de aplicaciones se puede representar de esta manera
(application) --> (connection) --> (db server) --> (resources)
donde los recursos utilizados por la base de datos incluyen almacenamiento, RAM y CPU. El propósito es permitir que la aplicación controle más recursos para aumentar la capacidad y la velocidad. Las aplicaciones "inteligentes" que gestionan varias bases de datos se pueden representar como
(application) --> (connection) --> (db server) --> (resources) | +---------> (connection) --> (db server) --> (resources)
mientras que las soluciones de "agrupación de conexiones" se pueden representar como
(application) --> (connection) --> (db server) --> (resources) | +---------> (db server) --> (resources)
por soluciones de "nivel inferior" me refiero a algo como
(application) --> (connection) --> (db server) --> (resources) | +---------> (resources)
que puede parecer algo familiar, pero no es lo que estoy proponiendo aquí. Para explicar la diferencia puedo aumentar el detalle y escribir
(resources) = (virtual resources) --> (physical resources)
para representar el hecho de que en el nivel más bajo puede tener un mapeo no trivial entre objetos físicos y virtuales. Por ejemplo, el almacenamiento SAN o la creación de bandas RAID pueden proporcionar discos virtuales más grandes al unir discos físicos más pequeños. Estos casos podrían representarse como
(application) --> (connection) --> (db server) --> (virt.res.) --> (ph.res.) | +--------> (ph.res.)
Mi propuesta es agrupar recursos en el servidor de base de datos nivel, para que podamos tener una “virtualización” más eficiente utilizando el conocimiento de los casos de uso específicos para cada recurso (CPU, RAM, disco), y al mismo tiempo podemos evitar muchas de las dificultades del paradigma transaccional. La imagen sería:
(application) --> (connection) --> (db server) --> (virt.res.) --> (ph.res.) | +--------> (virt.res.) --> (ph.res.)
La ventaja es que no necesitamos gestionar todos los casos de uso posibles para cada recurso virtual; solo tenemos que administrar (y optimizar) los casos de uso que realmente necesita PostgreSQL. Por ejemplo:WAL aún debe escribirse en almacenamiento local "no virtualizado", bgwriter accederá a recursos locales y remotos (RAM y disco), etc.
Algunas palabras finales sobre confiabilidad. Para operar correctamente, todo el sistema necesita cada subsistema; no se gestionan los fallos parciales, porque esta arquitectura no es redundante. Es un sistema distribuido, pero no compartido. Si esta arquitectura pudiera proporcionar una escalabilidad simple y económica a través de un servidor de base de datos virtual que es funcionalmente equivalente a un servidor físico con mayores recursos, entonces se podría obtener una alta disponibilidad de la manera estándar configurando dos servidores virtuales idénticos en una configuración Hot Standby.
La calidad de la red tiene un gran impacto en el rendimiento general; este diseño puede ser útil solo si tiene una matriz de máquinas en la misma LAN, no solo por razones de velocidad, sino también porque una falla en la red en realidad sería una falla en el sistema. Incluso con estas restricciones, mi opinión es que contar con esta opción sería bastante útil.
Esto sigue siendo un boceto, para ser utilizado como referencia para futuras discusiones. Próximos pasos posibles:
- para hacer una lista detallada de los casos de uso de recursos
- para decidir qué tecnologías pueden ayudar mejor en cada caso de uso
- para estimar los costes reales de rendimiento/desarrollo
