Persistencia y motores de persistencia

Persistencia

La persistencia es la capacidad que tiene una aplicación de mantener el estado más allá de su ejecución. Esto permite a que ejecuciones posteriores puedan utilizar los datos generados en ejecuciones previas.

La incorporación de persistencia en una aplicación surge por al menos uno de estos dos motivos: Los datos en memoria se pierden y se requieren ser utilizados con posterioridad ó la cantidad de memoria que puede usar el programa es menor a la cantidad de datos que debe manejar, por lo cual deberá mantener en memoria un conjunto acotado de información y el resto estará en el repositorio.

La persistencia implica los siguientes conceptos:

• Medio Persistente: Es el soporte físico donde se almacenan los datos, puede ser un disco o un array de discos
• Base de datos o repositorio: es el conjunto de datos persistidos de la aplicación
• Estructura de la base de datos: Es el formato en el cual se guarda la información (Archivos planos, tablas relacionadas, archivos xml, etc)
• Metadata: Es información acerca de los datos, por ejemplo el tipo de dato de un campo, el nombre, etc.
• API de consulta: Un mecanismo para recuperar la información.
• API de actualización: Un mecanismo para alterar la base de datos

Estos conceptos a veces aparecen con nombres distintos en otras fuentes, o a veces se utiliza "Base de datos" como sinónimo de "base de datos relacional" o de "motor de base de datos" o "motor de base de datos relacional". Nosotros vamos a utilizar el concepto de base de datos como lo definimos anteriormente.

Motor de Persistencia

Un motor de persistencia (DBMS: data base managment system) es una aplicación o componente que resuelve la persistencia pero soporta además un número significativo de las siguientes características

• Encapsulamiento del medio persistente
• Integridad
  • mecanismos que permitan mantener la correctitud de la información
  • versionado de la información
• Permite compartir la base de datos entre varias aplicaciones y/o usuarios
  • Transacciones (ACID: atomicity, consistency, isolation, durability)
  • Comunicación
  • lockeos
  • seguridad (autenticación y autorización)
• Mecanismo para recupararse
  • logs
  • backups
  • auditoría
• Performance y escalabilidad
  • volumen de transacciones
  • volumen de datos
  • concurrencia
  • Explotación de la metadata para optimizaciones

Algunas de estas características no son propias de la persistencia, pero la tecnología evolucionó de cierta forma en que los motores fueron soportándolas. En particular, la capacidad de tener transacciones ACID no necesita de un motor, se puede garantizar desde el código del programa -con un gran esfuerzo-. Es así como aparece el concepto de "Unit of work": un entorno aislado en el cual la aplicación realiza operaciones. Los esquemas más simples son los que pueden establecer una relación 1 a 1 entre unidad de trabajo y transacción de base de datos, pero no siempre eso es posible. Una operación que necesita de varias acciones del usuario no puede tener una transaccion abierta durante todo el unit of work, ya que mantener la transacción es costoso y afectaría a la capacidad de tener un gran número de usuarios concurrentes.