stringtranslate.com

Durabilidad (sistemas de bases de datos)

En los sistemas de bases de datos , la durabilidad es la propiedad ACID que garantiza que los efectos de las transacciones que se han confirmado sobrevivirán de forma permanente, incluso en caso de fallos, [1] incluidos incidentes y eventos catastróficos. Por ejemplo, si una reserva de vuelo informa que se ha reservado un asiento con éxito, entonces el asiento permanecerá reservado incluso si el sistema falla. [2]

Formalmente, un sistema de base de datos asegura la propiedad de durabilidad si tolera tres tipos de fallos: fallos de transacción, del sistema y del medio. [1] En particular, una transacción falla si su ejecución se interrumpe antes de que el sistema haya procesado todas sus operaciones. [3] Este tipo de interrupciones pueden originarse a nivel de transacción por errores de entrada de datos, cancelación del operador, tiempo de espera o errores específicos de la aplicación, como retirar dinero de una cuenta bancaria con fondos insuficientes. [1] A nivel de sistema, se produce un fallo si se pierde el contenido del almacenamiento volátil , debido, por ejemplo, a fallos del sistema , como eventos de falta de memoria . [3] A nivel de medio, donde medio significa un almacenamiento estable que resiste fallos del sistema, los fallos ocurren cuando se pierde el almacenamiento estable, o parte de él. [3] Estos casos suelen estar representados por fallos de disco . [1]

Por lo tanto, para ser durable, el sistema de base de datos debe implementar estrategias y operaciones que garanticen que los efectos de las transacciones que se han confirmado antes del fallo sobrevivirán al evento (incluso mediante la reconstrucción), mientras que los cambios de las transacciones incompletas, que aún no se han confirmado en el momento del fallo, se revertirán y no afectarán el estado del sistema de base de datos. Se ha demostrado que estos comportamientos son correctos cuando la ejecución de las transacciones tiene respectivamente las propiedades de resiliencia y recuperabilidad . [3]

Mecanismos

Un autómata de estados finitos simplificado que muestra los posibles estados posteriores a una falla (en rojo) del DBMS y las transiciones (en negro) que son necesarias para regresar a un sistema en funcionamiento y lograr durabilidad.

En los sistemas basados ​​en transacciones, los mecanismos que aseguran la durabilidad se asocian históricamente con el concepto de confiabilidad de los sistemas, tal como lo propuso Jim Gray en 1981. [1] Este concepto incluye la durabilidad, pero también se basa en aspectos de las propiedades de atomicidad y consistencia . [4] En concreto, un mecanismo de confiabilidad requiere primitivas que establezcan explícitamente el comienzo, el final y la reversión de las transacciones, [1] que también están implícitas para las otras dos propiedades mencionadas anteriormente. En este artículo, solo se han considerado los mecanismos estrictamente relacionados con la durabilidad. Estos mecanismos se dividen en tres niveles: nivel de transacción, nivel de sistema y nivel de medio. Esto también se puede ver en escenarios en los que podrían ocurrir fallas y que deben considerarse en el diseño de sistemas de bases de datos para abordar la durabilidad. [3]

Nivel de transacción

La durabilidad frente a fallos que se producen a nivel de transacción, como llamadas canceladas y acciones inconsistentes que pueden ser bloqueadas antes de confirmarse por restricciones y disparadores , está garantizada por la propiedad de serialización de la ejecución de transacciones. El estado generado por los efectos de las transacciones confirmadas previamente está disponible en la memoria principal y, por tanto, es resiliente, mientras que los cambios llevados por las transacciones no confirmadas pueden deshacerse. De hecho, gracias a la serialización, se pueden discernir de otras transacciones y, por tanto, sus cambios se descartan. [3] Además, es relevante considerar que los cambios in situ, que sobrescriben valores antiguos sin mantener ningún tipo de historial, son desaconsejados. [1] Existen múltiples enfoques que mantienen un registro del historial de cambios, como las soluciones basadas en marcas de tiempo [5] o el registro y bloqueo . [1]

Nivel de sistema

A nivel de sistema, los fallos ocurren, por definición, [3] cuando se pierde el contenido del almacenamiento volátil. Esto puede ocurrir en eventos como caídas del sistema o cortes de energía . Los sistemas de bases de datos existentes utilizan el almacenamiento volátil (es decir, la memoria principal del sistema) para diferentes propósitos: algunos almacenan todo su estado y datos en él, incluso sin ninguna garantía de durabilidad; otros mantienen el estado y los datos, o parte de ellos, en la memoria, pero también utilizan el almacenamiento no volátil para los datos; otros sistemas solo mantienen el estado en la memoria principal, mientras que mantienen todos los datos en el disco. [6] La razón detrás de la elección de tener almacenamiento volátil, que está sujeto a este tipo de fallo, y almacenamiento no volátil, se encuentra en las diferencias de rendimiento de las tecnologías existentes que se utilizan para implementar este tipo de almacenamiento. Sin embargo, es probable que la situación evolucione a medida que crezca la popularidad de las tecnologías de memorias no volátiles (NVM) . [7]

En sistemas que incluyen almacenamiento no volátil, la durabilidad se puede lograr manteniendo y vaciando un registro secuencial inmutable de las transacciones en dicho almacenamiento no volátil antes de reconocer el compromiso. Gracias a su propiedad de atomicidad, las transacciones pueden considerarse la unidad de trabajo en el proceso de recuperación que garantiza la durabilidad mientras se explota el registro. En particular, el mecanismo de registro se llama registro de escritura anticipada (WAL) y permite la durabilidad al almacenar en búfer los cambios en el disco antes de que se sincronicen desde la memoria principal. De esta manera, mediante la reconstrucción a partir del archivo de registro, todas las transacciones comprometidas son resistentes a fallas a nivel de sistema, porque se pueden rehacer. Las transacciones no comprometidas, en cambio, son recuperables, ya que sus operaciones se registran en el almacenamiento no volátil antes de que modifiquen efectivamente el estado de la base de datos. [8] De esta manera, las operaciones parcialmente ejecutadas se pueden deshacer sin afectar el estado del sistema. Después de eso, aquellas transacciones que estaban incompletas se pueden rehacer. Por lo tanto, el registro de transacciones del almacenamiento no volátil se puede volver a procesar para recrear el estado del sistema justo antes de cualquier falla posterior a nivel del sistema. El registro se realiza como una combinación de datos de seguimiento y operaciones (es decir, transacciones) por razones de rendimiento. [9]

Nivel de medios

A nivel de medios, los escenarios de falla afectan a los almacenamientos no volátiles, como unidades de disco duro , unidades de estado sólido y otros tipos de componentes de hardware de almacenamiento . [8] Para garantizar la durabilidad a este nivel, el sistema de base de datos debe apoyarse en una memoria estable, que es una memoria que es completamente e idealmente resistente a fallas. Este tipo de memoria se puede lograr con mecanismos de replicación y protocolos de escritura robustos. [4]

Existen muchas herramientas y tecnologías disponibles para proporcionar una memoria lógica estable, como la duplicación de discos, y su elección depende de los requisitos de las aplicaciones específicas. [4] En general, las estrategias y arquitecturas de replicación y redundancia que se comportan como memoria estable están disponibles en diferentes niveles de la pila de tecnología. De esta manera, incluso en caso de eventos catastróficos donde el hardware de almacenamiento se dañe, se puede prevenir la pérdida de datos . [10] En este nivel, existe un fuerte vínculo entre la durabilidad y la recuperación del sistema y de los datos , en el sentido de que el objetivo principal es preservar los datos, no necesariamente en réplicas en línea, sino también como copias fuera de línea. [4] Estas últimas técnicas entran en las categorías de copia de seguridad , prevención de pérdida de datos y recuperación de desastres de TI . [11]

Por lo tanto, en caso de fallo de los medios, la durabilidad de las transacciones está garantizada por la capacidad de reconstruir el estado de la base de datos a partir de los archivos de registro almacenados en la memoria estable, de cualquier forma que se haya implementado en el sistema de base de datos. [8] Existen varios mecanismos para almacenar y reconstruir el estado de un sistema de base de datos que mejoran el rendimiento, tanto en términos de espacio como de tiempo, en comparación con la gestión de todos los archivos de registro creados desde el principio del sistema de base de datos. Estos mecanismos a menudo incluyen volcado incremental , archivos diferenciales y puntos de control . [12]

Bases de datos distribuidas

En las transacciones distribuidas , garantizar la durabilidad requiere mecanismos adicionales para preservar una secuencia de estados consistente en todos los nodos de la base de datos. Esto significa, por ejemplo, que un solo nodo puede no ser suficiente para decidir concluir una transacción confirmándola. De hecho, los recursos utilizados en esa transacción pueden estar en otros nodos, donde otras transacciones están ocurriendo simultáneamente. De lo contrario, en caso de falla, si no se puede garantizar la consistencia, sería imposible reconocer un estado seguro de la base de datos para la recuperación. Por esta razón, todos los nodos participantes deben coordinarse antes de que se pueda reconocer una confirmación. Esto generalmente se hace mediante un protocolo de confirmación de dos fases . [13]

Además, en bases de datos distribuidas , incluso los protocolos de registro y recuperación deben abordar los problemas de los entornos distribuidos , como los bloqueos , que podrían impedir la resiliencia y la capacidad de recuperación de las transacciones y, por lo tanto, la durabilidad. [13] Una familia de algoritmos ampliamente adoptada que garantiza estas propiedades es Algorithms for Recovery and Isolation Exploiting Semantics (ARIES) . [8]

Véase también

Referencias

  1. ^ abcdefgh Gray, Jim (1981). "El concepto de transacción: virtudes y limitaciones" (PDF) . VLDB . 81 : 144–154.
  2. ^ "Cumplimiento de ACID: qué significa y por qué debería importarle". MariaDB . 29 de julio de 2018 . Consultado el 22 de septiembre de 2021 .
  3. ^ abcdefg Hadzilacos, Vassos (1988). "Una teoría de la confiabilidad en los sistemas de bases de datos". Revista de la ACM . 35 (1): 121-145. doi : 10.1145/42267.42272 . ISSN  0004-5411. S2CID  7052304.
  4. ^ abcd Atzeni, Paolo, ed. (1999). Sistemas de bases de datos: conceptos, lenguajes y arquitecturas . Nueva York: McGraw-Hill. págs. 311–320. ISBN 978-0-07-709500-0.
  5. ^ Svobodova, L. (1980). "GESTIÓN DE HISTORIAS DE OBJETOS EN EL REPOSITORIO SWALLOW". Mit/LCS Tr-243 . Estados Unidos.
  6. ^ Petrov, Oleksandr (2019). Funcionamiento interno de las bases de datos: una mirada profunda al funcionamiento de los sistemas de datos distribuidos (1.ª ed.). Pekín, Boston, Farnham, Sebastopol, Tokio: O'Reilly. Págs. 40-42. ISBN 978-1-4920-4034-7.
  7. ^ Arulraj, Joy; Pavlo, Andrew (9 de mayo de 2017). "Cómo construir un sistema de gestión de bases de datos con memoria no volátil". Actas de la Conferencia internacional ACM de 2017 sobre gestión de datos . SIGMOD '17. Nueva York, NY, EE. UU.: Association for Computing Machinery. págs. 1753–1758. doi :10.1145/3035918.3054780. ISBN 978-1-4503-4197-4.S2CID648876  .​
  8. ^ abcd Petrov, Oleksandr (2019). Funcionamiento interno de las bases de datos: una mirada profunda al funcionamiento de los sistemas de datos distribuidos (1.ª ed.). Pekín, Boston, Farnham, Sebastopol, Tokio: O'Reilly. pp. 185–195. ISBN 978-1-4920-4034-7.
  9. ^ Mohan, C.; Haderle, Don; Lindsay, Bruce; Pirahesh, Hamid; Schwarz, Peter (1992-03-01). "ARIES: un método de recuperación de transacciones que admite bloqueos de granularidad fina y reversiones parciales mediante el registro de escritura anticipada". ACM Transactions on Database Systems . 17 (1): 94–162. doi : 10.1145/128765.128770 . ISSN  0362-5915. S2CID  8759704.
  10. ^ Eich, Margaret H. (1 de febrero de 1987). "Una clasificación y comparación de las técnicas de recuperación de bases de datos de la memoria principal". Tercera Conferencia Internacional sobre Ingeniería de Datos del IEEE de 1987. IEEE. págs. 332–339. doi :10.1109/ICDE.1987.7272398. ISBN 978-0-8186-0762-2. Número de identificación del sujeto  207773738.
  11. ^ Choy, Manhoi; Leong, Hong Va; Wong, Man Hon (2000). "Técnicas de recuperación ante desastres para sistemas de bases de datos". Comunicaciones de la ACM . 43 (11es): 6. doi :10.1145/352515.352521. ISSN  0001-0782. S2CID  14781378.
  12. ^ Verhofstad, Joost SM (1 de junio de 1978). "Técnicas de recuperación para sistemas de bases de datos". Encuestas de computación de ACM . 10 (2): 167–195. doi :10.1145/356725.356730. S2CID  8847522.
  13. ^ ab Mohan, C.; Haderle, Don; Lindsay, Bruce; Pirahesh, Hamid; Schwarz, Peter (1992-03-01). "ARIES: un método de recuperación de transacciones que admite bloqueo de granularidad fina y reversiones parciales mediante el registro de escritura anticipada". ACM Transactions on Database Systems . 17 (1): 94–162. doi : 10.1145/128765.128770 . ISSN  0362-5915. S2CID  8759704.

Lectura adicional

Enlaces externos