Servidor de base de datos y bases de datos embebidas
Servidor de Base de Datos
Un servidor de base de datos se refiere a una base de datos que se ejecuta como un proceso de servidor independiente y procesa las solicitudes de la aplicación a través de la red. La mayoría de los RDBMS que nos resultan familiares, como MySQL, PostgreSQL y Oracle DB, pertenecen a este modelo. Un servidor de base de datos tiene las siguientes ventajas:
- Gestión Centralizada: Los datos se gestionan de forma integrada en un solo lugar, lo que facilita la coherencia, la seguridad, la copia de seguridad y la recuperación.
- Independencia de Recursos: Se le asignan su propia CPU, memoria y almacenamiento, lo que garantiza un rendimiento estable independientemente del estado de la aplicación.
- Alta Concurrencia y Escalabilidad: Está optimizado para el acceso concurrente de muchos usuarios, y la escalabilidad horizontal mediante la agrupación en clústeres o la replicación es relativamente sencilla.
Gracias a estas características, el servidor de base de datos se ha establecido como el estándar de la infraestructura de software durante las últimas décadas. Sin embargo, debido al avance tecnológico y a los cambios ambientales, las desventajas del servidor de base de datos han comenzado a manifestarse en algunos entornos, y la base de datos embebida está atrayendo nuevamente la atención como alternativa.
Una Nueva Tendencia: Base de Datos Embebida
Una base de datos embebida es un motor de base de datos que se incluye como una biblioteca dentro de la aplicación y se ejecuta dentro del mismo proceso, sin un proceso de servidor separado. SQLite, LevelDB y RocksDB son ejemplos representativos de bases de datos embebidas. El contexto por el cual estas bases de datos embebidas han surgido como una alternativa poderosa en los entornos tecnológicos modernos es el siguiente:
El Surgimiento de los SSD
En los entornos de sistemas anteriores, centrados en HDD, el rendimiento del acceso aleatorio era significativamente inferior al rendimiento de lectura/escritura de datos secuencial. Por lo tanto, minimizar el I/O de disco y maximizar el almacenamiento en caché de memoria era clave para la optimización del rendimiento. Los servidores de bases de datos superaron las limitaciones físicas de los HDD operando cachés a gran escala y procesando las operaciones de escritura de forma agrupada.
Sin embargo, la aparición de los SSD ha cambiado completamente esta premisa. Los SSD son miles de veces más rápidos en el rendimiento de I/O aleatorio que los HDD, y su latencia es drásticamente más corta. Como resultado, la percepción anterior de que "el I/O de disco es el mayor cuello de botella" ha desaparecido, y la latencia resultante del acceso remoto al servidor de base de datos a través de la red ha comenzado a destacarse como un nuevo cuello de botella.
MSA e Independencia de Datos
Anteriormente, la estructura común era una aplicación monolítica y gigantesca que dependía de una única base de datos centralizada. Aunque este enfoque es simple, a medida que el tamaño del servicio crecía, surgían problemas como la dificultad para cambiar el esquema de datos y una cohesión excesivamente fuerte al compartir todos los servicios la misma DB.
En la arquitectura moderna de microservicios, se enfatiza el principio de "Database per Service" para resolver estos problemas. Al poseer y encapsular cada servicio su propio almacén de datos dedicado, se garantiza la independencia entre servicios, y el aislamiento de fallos y la escalabilidad se vuelven más fáciles. En este proceso, la DB embebida se convierte en una opción ideal como almacén de datos a nivel de servicio. Al ser ligera, rápida y poder distribuirse junto con el código del servicio, se adapta muy bien al entorno de MSA.
Por ejemplo, en el entorno de Kubernetes, se utiliza ampliamente el patrón sidecar para colocar una DB embebida junto al contenedor de la aplicación, optimizando el procesamiento de datos locales. Esto tiene el efecto de reducir el cuello de botella de la red y minimizar la latencia de acceso a los datos.
Simplificación del Entorno Operativo
Los servidores de bases de datos requieren procedimientos operativos complejos esenciales, como instalación, aplicación de parches, copias de seguridad, recuperación de fallos, replicación y monitoreo del rendimiento, y esto exige un DBA dedicado y personal operativo especializado. La carga de gestión es particularmente alta en entornos a gran escala.
La DB embebida mitiga significativamente estos problemas. Cuando la base de datos se integra dentro de la aplicación, las pruebas unitarias, la compilación, la gestión de versiones y la distribución se realizan conjuntamente, eliminando la necesidad de una operación de servidor separada. Además, cuando la aplicación se Scale-out, la DB embebida también se expande, y es posible una gestión automatizada a través de la cultura DevOps y las tuberías de CI/CD. Especialmente en startups, servicios pequeños y entornos de desarrollo de prototipos, la base de datos embebida reduce drásticamente la complejidad operativa y acelera significativamente la velocidad de desarrollo y distribución.
Lenguajes de Sistemas de Alto Rendimiento y Evolución del Ecosistema
Anteriormente, era común que la base de datos y la aplicación se escribieran en lenguajes diferentes. Por ejemplo, los motores de bases de datos que requerían alto rendimiento se escribían principalmente en C, C++, y las aplicaciones se desarrollaban en lenguajes como Java, Python, PHP. Este enfoque era efectivo para la optimización del rendimiento, pero tenía limitaciones como problemas de estabilidad de la memoria, manejo complejo de la concurrencia, latencia, y dificultad en la integración y distribución de bibliotecas.
Sin embargo, estas limitaciones se han mitigado considerablemente con el auge de lenguajes de programación de sistemas modernos como Go y Rust. Particularmente, Go es adecuado no solo para aplicaciones de alto rendimiento, sino también para escribir programas de bajo nivel como motores de bases de datos, permitiendo que la base de datos y la aplicación se manejen juntas dentro de un único ecosistema de lenguaje.
De hecho, en Golang se utilizan activamente bases de datos embebidas de alto rendimiento como BadgerDB y PebbleDB. Esto significa que la base de datos embebida se está posicionando como una opción importante con competitividad propia, más allá de ser simplemente una alternativa ligera al servidor de base de datos.
Conclusión
El servidor de base de datos sigue siendo la solución más potente en condiciones que requieren gestión centralizada de grandes volúmenes de datos, transacciones complejas y alta concurrencia. Sin embargo, en servicios individuales dentro de entornos MSA, dispositivos periféricos IoT, prototipado rápido y proyectos donde la eficiencia operativa es crucial, la base de datos embebida puede ser una opción más eficiente y racional. En última instancia, lo importante es seleccionar la herramienta óptima que mejor se adapte a la situación y a los requisitos dados, y el avance de la base de datos embebida nos está proporcionando opciones más amplias y diversas.