Arquitectura de Btrieve

Btrieve es una base de datos desarrollada por Pervasive Software . Su arquitectura se ha diseñado pensando en la gestión de registros. Esto significa que Btrieve se encarga únicamente de las operaciones básicas de creación, recuperación, actualización y eliminación de registros. Junto con el motor de base de datos MicroKernel, utiliza ISAM ( Método de Acceso Secuencial Indexado ) como mecanismo de almacenamiento.

Btrieve es esencialmente una base de datos que utiliza claves e índices para organizar los datos . Sin embargo, la estructura del archivo se basa principalmente en unidades de datos más pequeñas, llamadas "páginas" en Btrieve. Aunque la estructura ha cambiado a lo largo de las distintas versiones de Btrieve, sigue girando en torno a un Registro de Control de Archivo (FCR), que define la configuración de las páginas, y las páginas del archivo Btrieve que contienen datos. Históricamente, Btrieve utilizaba "páginas físicas", es decir, páginas ubicadas en posiciones fijas del archivo. A partir de la versión 6.0, se empezaron a utilizar "páginas lógicas", que se asignaban a tablas de asignación de páginas (PAT). Esto permitió a Btrieve cambiar su técnica de actualización de registros, pasando de lo que más tarde se conocería como "paginación de preimagen" a una técnica llamada "paginación en la sombra".

Btrieve está comprometido con la retrocompatibilidad , ya que las versiones de Btrieve hasta la versión 6.15 utilizan un formato de archivo estándar y, hasta que se lanzó Btrieve 6.0, eran completamente retrocompatibles. Btrieve 6.0 introdujo nuevas características y tuvo que romper la compatibilidad con versiones anteriores del software para implementar características más avanzadas. La API también se mantuvo retrocompatible, con solo una característica (dividir archivos en medios separados) que se eliminó. En un momento dado, el ex director ejecutivo de Btrieve , Ron Harris, declaró que "¡La API de la versión 1.0 todavía es compatible con la versión 6.15, y la vamos a mantener para siempre!" ^{[ 1 ] : 11} .

Inicialmente, Pervasive utilizó el término "base de datos de navegación" para describir Btrieve, pero posteriormente lo cambió a "base de datos transaccional". El uso del término "base de datos de navegación" era inusual porque una base de datos de navegación utiliza "punteros" y "rutas" para navegar entre los registros de datos , y estos punteros están contenidos en el propio registro; ISAM, que es la estructura fundamental de Btrieve, utiliza una tabla de índices secundaria para almacenar estos punteros y así reducir los tiempos de búsqueda. Por lo tanto, los dos tipos de bases de datos son diferentes, lo que podría explicar, o no, por qué Pervasive comenzó a utilizar una terminología distinta para clasificar su base de datos. ^{[ a ]}

A partir de la versión 6.15, Pervasive comenzó a utilizar un nuevo método modular para separar el backend de la base de datos de la interfaz que utilizaban los desarrolladores. Separaron las operaciones principales de la base de datos (como actualizar, escribir y eliminar registros) de los módulos Btrieve y Scalable SQL . Al separar el Motor de Base de Datos de Micro-Kernel (MKDE) de las demás funciones, permitió a los programadores utilizar varios métodos para acceder a la base de datos simultáneamente. Por ejemplo, una aplicación puede crearse utilizando la API de Btrieve y otra aplicación que necesite acceder a los mismos datos puede utilizar un método totalmente diferente, como Scalable SQL. Dado que las primitivas de registro se han separado de estos métodos, ambas aplicaciones pueden utilizar el MKDE para acceder al mismo archivo de datos .

El motor de base de datos de microkernel no guarda relación con los núcleos de los sistemas operativos de microkernel .

El formato de archivo Btrieve se compone exclusivamente de páginas, que son los datos que se transfieren entre la memoria y el medio de almacenamiento cuando el motor realiza una operación de entrada/salida . Las versiones anteriores a la 6.0 solo utilizaban páginas de datos, páginas de índice y un registro de control de archivo (FCR). El archivo tenía un índice de búsqueda vinculado a páginas físicas. A partir de la versión 6.0, se empezaron a utilizar páginas lógicas , que son páginas que se asignan a páginas físicas (páginas en una ubicación fija del archivo) en el disco mediante un conjunto de tablas de asignación de páginas (PAT).

Btrieve utiliza un formato de árbol B para almacenar índices de registros en columnas de tabla específicas . El índice asigna cada conjunto de valores de columna indexados al conjunto de identificadores únicos de las filas que contienen dichos valores, lo que permite encontrar rápidamente las filas dentro de una tabla utilizando la columna indexada. Los árboles B son estructuras de datos de árbol y resultan muy eficientes como mecanismo para la recuperación rápida de datos. La desventaja de un árbol B es que los datos deben estar constantemente equilibrados al insertarse en el árbol; por lo tanto, Btrieve solo almacena el índice de registro como un árbol B para reducir el tiempo necesario para insertar y actualizar registros. Se mantiene un árbol B independiente para cada índice del sistema, y ​​la información del nodo raíz se guarda en el FCR. En Btrieve 6.xa, se puede crear un nuevo índice al crear un archivo, o agregarlo y eliminarlo después de su creación. Las páginas de índice también se crean según sea necesario. Antes de Btrieve 6.0, no se podían eliminar los índices de clave existentes, aunque sí se podían crear y eliminar índices suplementarios según fuera necesario.

Btrieve permite valores de clave duplicados en un índice. Btrieve maneja las claves duplicadas mediante un método de duplicado vinculado o un método de duplicado repetido (esta terminología comenzó a usarse con el lanzamiento de la versión 6.0). El método de duplicado vinculado utilizaba un par de punteros de registro en la propia página del índice para apuntar al principio y al final de una lista doblemente enlazada de claves duplicadas. Esto significaba que el orden de las claves duplicadas en la lista era el orden en que se introdujeron. El método de clave duplicada no utilizaba una lista enlazada, sino que hacía que todas las claves fueran únicas creando una nueva clave de índice y añadiendo la dirección del puntero de registro al final de la clave. Esto significa que la clave se recupera según su posición.

Cuando Btrieve necesitaba compartir archivos para acceder a los registros, podía utilizar dos modos diferentes: el modo de uso compartido de archivos de un solo motor (SEFS) y el modo de uso compartido de archivos de varios motores (MEFS). El modo SEFS solo permitía a los clientes que accedían a ese motor modificar la base de datos; otros clientes que accedían a un motor diferente no podían acceder a ella. El modo MEFS permite que diferentes clientes que se ejecutan en distintos motores accedan a la base de datos.

Btrieve pudo gestionar transacciones concurrentes en la serie 6.x. Antes de Btrieve 6.0, el motor solo permitía el bloqueo a nivel de archivo o el bloqueo exclusivo ; a partir de la versión 6.0, los registros podían bloquearse individualmente. El bloqueo a nivel de registro (o página) se conocía como bloqueo concurrente . Las ventajas eran evidentes: varios clientes podían acceder al archivo simultáneamente, siempre que no intentaran acceder al mismo registro, lo que mejoraba el rendimiento. Además, otros clientes podían leer las páginas bloqueadas y no veían ningún cambio en un archivo involucrado en una transacción de escritura realizada por otro proceso que hubiera bloqueado el registro.

El modo MEFS no admitía completamente el bloqueo concurrente. Si un cliente iniciaba una transacción concurrente y luego intentaba realizar una operación de escritura en un registro, el motor Btrieve devolvía un código de estado 85 que indicaba que el archivo estaba bloqueado, incluso aunque se estuviera utilizando un bloqueo concurrente.

A partir de la versión 6.15 de Btrieve, se introdujo un nuevo tipo de transacción de base de datos denominada transacción del sistema , que se separó de las transacciones de usuario . Las transacciones de usuario son exclusivas y concurrentes, mientras que las transacciones del sistema son un conjunto de operaciones no transaccionales y/o transacciones de usuario. Las transacciones del sistema se utilizaban exclusivamente para la recuperación de datos por parte del MKDE. Si un fallo del sistema provocaba corrupción de datos, al reiniciar el MKDE, este detectaba todos los archivos que habían sufrido una transacción del sistema fallida e intentaba recuperarlos. Sin embargo, dado que las transacciones de usuario podrían haberse perdido al revertirse la última transacción del sistema, se podía configurar una opción que obligaba al MKDE a completar las transacciones del sistema que contenían transacciones de usuario cuando el motor recibía una solicitud de "Fin de operación".