Persistencia en la Base de Datos

Distribuida
ltima Actualizacin: 12 de Mayo de 2003 - Lunes
Este documento describe con detalle el sistema de persistencia para la base de
Datos Distribuida de IRC-Hispano.

El problema
La BDD (Base de Datos Distribuida) se almacena en disco, pero se carga
completamente en memoria cuando lanza el servidor. Los cambios subsiguientes
se realizan simultaneamente tanto en disco duro como en memoria.
Este esquema permite que las bsquedas y las modificaciones sean muy rpidas,
pero tiene dos problemas fundamentales:
a. La carga en memoria de la BDD es un proceso muy lento, del tipo O(n),
donde "n" es el nmero de registros en la BDD. Ese valor puede ser mucho
mayor que el nmero de registros "activos" en la BDD, en funcin de las
modificaciones, borrados y compactaciones que se realicen en la BDD.
b. Al tener toda la BDD en memoria, se necesita disponer de RAM o, en su
defecto, de una memoria virtual "decente". Esto no debera ser un
problema real para las mquinas UNIX actuales.
Obviando el segundo punto, se ve claramente que el tiempo de arranque de un
servidor de IRCD puede ser muy elevado, en funcin del nmero de registros en
la BDD. En mi sistema de desarrollo, lento, cargar una BDD de unos 250.000
registros consume aproximadamente un minuto de CPU.
Esta situacin no es tolerable, y lo ser an menos cuando el nmero de registros
(en particular, modificaciones) crezca para acomodar las nuevas funcionalidades
de registros distribuidos de canales.
Optimizar este proceso tambin reduce la necesidad y frecuencia de las
compactaciones de la BDD, proceso lento y delicado.

La solucin
La carga de la BDD en memoria se puede optimizar (por ejemplo, fusionando
"malloc()"), pero siempre tendr una dependencia O(n) del nmero de registros
en la BDD. La alternativa evidente es utilizar una base de datos clave/registro
clsica, como la BerkeleyDB, pero ello supone un mantenimiento extra (a nivel
de BDD) que muchos administradores no tendrn conocimientos, tiempo o ganas
de hacer.
Una solucin ms sencilla es utilizar tecnologa de "persistencia".
Es decir, ya que cargamos la BDD en memoria al arrancar el servidor IRCD, y
vamos siguiendo los cambios de la BDD en las estructuras en memoria, una
solucin sera que dicha memoria fuera "persistente" y mantuviese su valor entre
"reinicios" del servidor IRCD (incluyendo reinicios de la propia mquina que
soporta el IRCD). De esta forma podemos arrancar el servidor IRCD y
encontrarnos con que ya tenemos toda la BDD en memoria, tal y como la
dejamos al cerrar la instancia previa del programa. No necesitamos recrear
ninguna estructura o releer las tablas en disco duro.
En un entorno as es imprescindible, no obstante, asegurarnos de que las
estructuras que "persisten" no estn incompletas o corruptas, como ocurrira si el
servidor IRCD "muere" en un momento inconveniente (bug) o hay un corte de
suministro elctrico. Es decir, el sistema de persistencia debe utilizar tambin un
sistema de control de integridad y "frescura" de la informacin, para asegurarnos
que las estructuras en memoria se corresponden, escrupulosamente con la ltima
versin de la BDD.

Implementacin
El primer paso para implementar una BDD persistente es definir un mecanismo
persistente para crear, borrar y modificar registros. El mecanismo ya existe, en
forma de "malloc()". En vez de reescribir el sistema de BDD para emplear otro
sistema, lo que hacemos es dividir los "malloc()" en dos tipos: "normales" y
"persistentes".
Los "malloc()" "normales" son las funciones de toda la vida, que proporcionan
memoria que se pierde cuando el programa muere.
Definimos un nuevo tipo de "malloc()", "persistente", cuyo contenido "persiste"
incluso entre reinicios del sistema operativo. Esto se hace utilizando una nueva
librera "malloc" y empleando un fichero en disco, mapeado en memoria, para
realizar los "malloc()" y "free()" persistentes. Dicho fichero en disco existe
siempre, independientemente de que se est ejecutando el IRCD.
Cuando el IRCD arranca, mapea el fichero persistente en memoria. Este mapa
proporciona, as, de forma automtica, el contenido del fichero en memoria, sin
tener que leerlo manualmente (esto lo hace el sistema automticamente,
bajo "demand paging"). Ese mapa contiene una implementacin "malloc"
completa, con todos los punteros y estructuras como estaban cuando se cerr el
IRCD. Es decir, tenemos todos los datos disponibles automticamente y podemos
hacer "malloc()" y "free()" sobre esa memoria como si no hubiera habido un
corte intermedio en la ejecucin del programa.
Es as como se obtiene el sistema de persistencia.
Naturalmente hay que asegurarse de que el fichero es consistente, reciente y
utilizable. Puede ser, por ejemplo, que hubiese habido un corte en el suministro
elctrico mientras haba bloques de memoria "sucios", an no enviados al disco
duro. O puede ser que el IRCD corrompa memoria y que, al reiniciarse, se
encuentre con la memoria corrompida en el sistema de persistencia y sea incapaz
de recuperarse.
As pues, el siguiente paso consiste en asegurarnos que el fichero en disco es
correcto, antes de utilizarlo. Si detectamos cualquier problema simplemente
recrearemos el fichero desde cero, recargando la BDD de disco, como si no
hubiese persistencia. Ello soluciona el problema y, adems, inicializa el sistema
de persistencia para que pueda utilizarse en el siguiente reinicio.
El sistema de verificacin de integridad y "frescura" del fichero persistente se
basa en tres componentes:
1. Mapeo inicial del fichero de persistencia en memoria. Se comprueba:
o Que el fichero se haya cerrado correctamente y no est corrupto.
Para ello se realiza una verificacin criptogrfica, cuya probabilidad
de error es despreciable (mucho menor que 2
-64
).
o Que el sistema de persistencia sea compatible con el IRCD actual,
por si hay actualizaciones incompatibles.
o Que no se hayan cambiado configuraciones del sistema de
persistencia. En particular, que no se haya reconfigurado el tamao
del fichero MMAP.
o Que los ficheros de BDD no hayan sido alterados.
Exceptuando la verificacin criptogrfica, el resto de operaciones son
prcticamente instantaneas. La verificacin criptogrfica en s tiene un
tiempo de ejecucin O(m) proporcional a la cantidad de memoria
persistente utilizada, no al nmero de registros en la BDD. En general
m<<n. Adems, el coeficiente O(m) es mucho menor que el de O(n), por
lo que el tiempo de inicializacin ser muy bajo. En el caso descrito ms
arriba, el tiempo necesario para inicializar el sistema de persistencia es de
unos 2 o 3 segundos.
2. Cada vez que se modifica una BDD, se comprueba que la BDD en disco
duro no haya sido alterada por ningn otro proceso.
3. Cuando se cierra el IRCD nos aseguramos de que el sistema de
persistencia tenga datos actualizados. Se genera una verificacin
criptogrfica, por si el fichero no se actualiza correctamente. Por ejemplo,
se puede cerrar el IRCD con pginas "sucias" en el sistema de persistencia.
El sistema de memoria virtual del sistema operativo se asegura de que esas
pginas sucias sean a) vistas por cualquier otro proceso del sistema,
aunque no estn almacenadas an en disco duro y b) almacenadas en disco
duro tras un tiempo prudencial. Si antes de grabar en disco se produce un
fallo elctrico, el sistema de persistencia queda corrupto (le faltan
pginas), y la suma criptogrfica se asegura de que lo detectemos.
Un ltimo detalle del sistema de persistencia es que algunos registros tienen
efectos colaterales que debemos recrear. Por ejemplo, los canales persistentes.
Para este caso concreto tenemos tres opciones:
1. Migrar cada canal del sistema de persistencia al sistema "clsico" y
viceversa, en funcin de sus visicitudes con los registros. Este proceso es
complejo porque no sabemos cuntos punteros sealan un canal y, por
tanto, resulta muy recomendable no cambiar su posicin en memoria
durante su existencia.
2. Dado que en el futuro la inmensa mayora de los canales existentes en la
red sern persistentes, podramos almacenar directamente todos los
canales en el sistema de persistencia, independientemente de que sean
persistentes o no. Ello supone recorrer la lista de canales cuando se arranca
el programa, a la caza de canales no persistentes para borrarlos.
Surge la duda tambin de dnde almacenar la informacin adicional de un
canal, como su lista de usuarios, su "topic" o la la lista
de "invites" o "baneos".
Toda esa informacin puede introducir una carga apreciable en el sistema
de persistencia, pero probablemente sea el camino a seguir en el futuro.
3. Por ltimo, la opcin implementada en u2.10.H.06.99 simplemente
recorre la BDD de canales persistentes y los recrea en memoria en el
momento de reiniciar el servidor de IRCD. Es la opcin apropiada cuando
tenemos pocos canales persistentes. Ser deseable migrar a la opcin
anterior a medida que el nmero de registros aumente.
Los programadores interesados en estudiar las interioridades del sistema de
persistencia pueden curiosear los cambios en "s_bdd.c" y el nuevo
fichero "persistent_malloc.c".