eDirectory utiliza una base de datos FLAIM. FLAIM (gestor de información adaptable flexible) se utiliza para obtener información tradicional, compleja y volátil. Es un motor de base de datos muy adaptable que admite varios lectores y un modelo de simultaneidad de un solo escritor. Los lectores no bloquean a los escritores y escritores no bloquean a los lectores.
Físicamente, FLAIM organiza los datos en bloques. Normalmente, algunos de los bloques se almacenan en la memoria. Estos representan la caché de bloques aleatorios. La caché de bloques lógicos (a veces denominada caché de registros) almacena en caché las entradas lógicas de la base de datos. Las entradas se construyen a partir de los elementos de la caché de bloques aleatorios. FLAIM mantiene tablas de algoritmos hash para ambas cachés. El tamaño de la papelera de algoritmos hash se ajusta periódicamente en función del número de elementos.
Por defecto, eDirectory utiliza un tamaño de bloque de 4 KB. El tamaño de la caché de bloques aleatorios para el almacenamiento en caché del archivo DIB completo es igual que el tamaño del archivo DIB, y el tamaño necesario para la caché de bloques lógicos es entre dos y cuatro veces el tamaño del archivo DIB.
Al recuperar una entrada, FLAIM busca primero la entrada en la caché de bloques lógicos. Si la entrada existe, no es necesaria la lectura desde la caché de bloques aleatorios. Al recuperar un bloque del disco, FLAIM busca primero el bloque en la caché. Si el bloque existe, no es necesaria la operación de lectura de disco.
Cuando se añade o se modifica una entrada, los bloques correspondientes a dicha entrada no se añaden al disco directamente, por lo que puede que el disco y la memoria no estén sincronizados. Sin embargo, las actualizaciones realizadas en la entrada se registran en el registro de operaciones en progresión (RFL). Los RFL se utilizan para recuperar transacciones tras un fallo del sistema.
LRU (menos usados recientemente) es el algoritmo de reemplazo que se utiliza para reemplazar elementos de la caché.
Un punto de verificación pone la versión de la base de datos disponible en el disco en el mismo estado coherente que la base de datos de la memoria (caché). FLAIM puede aplicar un punto de verificación durante la actividad de actualización mínima de la base de datos. Se ejecuta cada segundo y escribe en el disco los bloques modificados (caché modificada). Los bloques que se modificaron en la caché pero aún no se han escrito en el disco se denominan “bloques modificados”. FLAIM adquiere un bloqueo en la base de datos y realiza la máxima cantidad de trabajo posible hasta que el punto de verificación se completa o hay otro hilo esperando para actualizar la base de datos. Para evitar que la base de datos en disco no esté sincronizada, existen varias situaciones en las que se fuerza un punto de verificación aunque haya hilos esperando para actualizar la base de datos:
Si el hilo de punto de verificación no puede completar un punto de verificación dentro de un intervalo de tiempo especificado (el valor por defecto es 3 minutos), se fuerza y se borra la caché modificada.
Si el tamaño de la caché usada es mayor que el de maxdirtycache (si se ha definido), se fuerza un punto de verificación para reducir el tamaño de la caché modificada a mindirtycache (si se ha definido) o para ponerlo a cero.
Un índice es un conjunto de claves organizadas de forma que se acelere considerablemente la búsqueda de una clave dada en el índice. Las claves de índice se construyen extrayendo el contenido de uno o más campos (atributos) de las entradas. Los índices se mantienen en la caché de bloques aleatorios. Los cambios realizados en los atributos indexados requieren cambios en los bloques de índice.
eDirectory define un conjunto de índices por defecto para los atributos (campos) del sistema. Los atributos del sistema como parentID y ancestorID se utilizan para búsquedas de un nivel y de subárbol. Estos índices no se pueden suspender ni eliminar. El directorio los utiliza internamente. Los índices por defecto se definen para atributos como CN, apellidos, nombre, etc. Los índices pueden ser de tipo presencia, valor y subcadena. Estos índices se pueden suspender. Cuando se eliminan, se vuelven a crear automáticamente.
Puede utilizar iManager o la utilidad LDAP (protocolo ligero de acceso a directorios) ndsindex para crear índices. Los índices son específicos del servidor.
Si habilita la etiqueta Gestor de almacenamiento (StrMan) en DSTrace (ndstrace), puede ver el índice seleccionado para las consultas de búsqueda.
El ejemplo siguiente corresponde a un registro de DSTrace para una búsqueda de subárbol con “cn=admin”, CN.
3019918240 StrMan: Iter #b239c18 query ((Flags&1)==1) && ((CN$217A$.Flags&8=="admin") && (AncestorID==32821))
3019918240 StrMan: Iter #b239c18 index = CN$IX$220
El ejemplo siguiente corresponde a un registro de DSTrace para una búsqueda de subárbol con “Description= This is for testing”, AncestorID.
2902035360 StrMan: Iter #83075b0 query ((Flags&1)==1) && ((Description$225A$.Flags&8=="This is for testing") && (AncestorID==32821))
2902035360 StrMan: Iter #83075b0 index = AncestorID_IX
FLAIM registra las operaciones de cada transacción de actualización en un archivo de registro de operaciones en progresión (RFL). Los RFL se utilizan para recuperar transacciones tras un fallo del sistema o al restaurar desde una copia de seguridad. El archivo RFL se trunca al completar cada punto de verificación, a menos que se active en (rflkeepfiles) mediante el uso de una copia de seguridad continua con la DB encendida.