BaseDeDatosEnMemoria
Escrito por Martin Fowler
Traducido por Carmen Vidal
Revisado por Jorge Ferrer
Una base de datos en memoria (también denominada base de datos embebida) es una base de datos que corre completamente en la memoria principal, sin utilizar el disco duro. Por lo general, es creada cuando un proceso comienza, se ejecuta embebida dentro del proceso, y es destruida cuando el proceso termina.
A primera vista una idea tan bestia parece ridícula. Los dos objetivos principales de la mayor parte de bases de datos son persistir la información entre invocaciones del proceso y manejar el acceso concurrente a datos entre procesos. Las bases de datos en memoria no cumplen ninguno de estos objetivos – ¿ Cuál es su utilidad?
El caso más común en el que las he usado recientemente es para pruebas. Cuando se desarrolla una aplicación empresarial, las pruebas que atacan a la base de datos pueden consumir mucho tiempo cuando se ejecutan las baterías de pruebas. En estos casos, emplear una base de datos en memoria puede tener un efecto de un orden de magnitud que reduce tiempos de construcción radicalmente. Ya que a la mayor parte de los ThoughtWorkers se les da un aviso si no han tenido una barra verde recientemente, esta arquitectura es un hecho diferenciador.
Hay dos caminos que la gente parece usar para obtener una base de datos en memoria para las pruebas. El primero es usar una librería de base de datos SQL en memoria. En el mundo Java el popular parece ser HSQLDB. En el otro
SQLite y Firebird aparecen. Lo bonito de estas herramientas es que permiten usar sentencias SQL regulares para las consultas. Un tema pendiente es que no soportan los mismos dialectos o las mismas funcionalidades que una base de datos final. Se puede hacer algo parecido ejecutando una base datos basada en archivos en una RAM.
Otro camino es abstraer todo el acceso de base de datos detrás de un
Repositorio. Entonces se puede cambiar la base de datos con estructuras de datos regulares en memoria. A menudo solamente un conjunto de tablas hash para los puntos de entrada para los grafos de objetos es suficiente. Una de las ventajas de la aproximación del repositorio es que esto te da un modo consistente de acceder sin fuentes de datos SQL. Esto quiere decir que tu sistema de mapeo objeto-relacional está escondido en el repositorio.
Sin embargo, un pequeño número de gente se opone activamente al uso de bases de datos en memoria argumentando que animan a esparcir sentencias SQL o código relacionado con el sistema objeto-relacional alrededor del modelo de dominio. Ejecutar SQL en memoria puede quitar la mayor parte del problema del acceso lento, pero actúa como un desodorante para cubrir el olor de un repositorio que falta.
Las pruebas es el principal uso hasta ahora, pero creo que hay más por venir de bases de datos en memoria. Los tamaños de memoria son ahora suficientes como para que muchas bases de datos de aplicaciones puedan ser cargadas en memoria. Si usas una aproximación que mantenga un log de eventos de todos los cambios del estado de tu aplicación, puedes utilizar la base de datos en memoria como una caché del resultado de generar el log, reconstruyéndolo y haciendo una foto de ella (snapshotting) cuando lo necesites. Estas soluciones pueden ser muy escalables y tener un alto rendimiento en casos donde se tienen muchos lectores y pocos escritores.
Prevayler consiguió llamar la atención al tomar este tipo de aproximación. Gente que conozco que lo intentó encontró un alto grado de acoplamiento de los objetos en memoria y la falta de herramientas de migración causó serios problemas. Pero pienso que la aproximación de logs de cambios persistentes como sistemas de registro es un campo fértil que explorar en el futuro.
