Hispanopedia Wiki
Articulo de referencia

Durability (database systems)

In database systems , durability is the ACID property that guarantees that the effects of transactions that have been committed will survive permanently, even in cases of failur...

Hispanopedia WikiContenido en espanolLectura gratuita

In database systems, durability is the ACID property that guarantees that the effects of transactions that have been committed will survive permanently, even in cases of failures,[1] including incidents and catastrophic events. For example, if a flight booking reports that a seat has successfully been booked, then the seat will remain booked even if the system crashes.[2]

Formally, a database system ensures the durability property if it tolerates three types of failures: transaction, system, and media failures.[1] In particular, a transaction fails if its execution is interrupted before all its operations have been processed by the system.[3] These kinds of interruptions can be originated at the transaction level by data-entry errors, operator cancellation, timeout, or application-specific errors, like withdrawing money from a bank account with insufficient funds.[1] At the system level, a failure occurs if the contents of the volatile storage are lost, due, for instance, to system crashes, like out-of-memory events.[3] At the media level, where media means a stable storage that withstands system failures, failures happen when the stable storage, or part of it, is lost.[3] These cases are typically represented by disk failures.[1]

Thus, to be durable, the database system should implement strategies and operations that guarantee that the effects of transactions that have been committed before the failure will survive the event (even by reconstruction), while the changes of incomplete transactions, which have not been committed yet at the time of failure, will be reverted and will not affect the state of the database system. These behaviours are proven to be correct when the execution of transactions has respectively the resilience and recoverability properties.[3]

Mechanisms

A simplified finite state automaton showing possible DBMS after-failure (in red) states and the transitions (in black) that are necessary to return to a running system to achieve durability

En los sistemas basados ​​en transacciones, los mecanismos que aseguran la durabilidad se asocian históricamente con el concepto de confiabilidad de los sistemas, propuesto por 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 ] Específicamente, un mecanismo de confiabilidad requiere primitivas que indiquen explícitamente el inicio, 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 observar en escenarios donde 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 ocurren 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 serializabilidad de la ejecución de transacciones. El estado generado por los efectos de transacciones confirmadas previamente está disponible en la memoria principal y, por lo tanto, es resiliente, mientras que los cambios llevados por transacciones no confirmadas pueden deshacerse. De hecho, gracias a la serializabilidad, pueden distinguirse de otras transacciones y, por lo 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, están desaconsejados. [ 1 ] Existen múltiples enfoques que mantienen un registro del historial de cambios, como soluciones basadas en marcas de tiempo [ 5 ] o registro y bloqueo . [ 1 ]

Nivel del 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 fallos, y almacenamiento no volátil, se encuentra en las diferencias de rendimiento de las tecnologías existentes que se utilizan para implementar estos tipos de almacenamiento. Sin embargo, es probable que la situación evolucione a medida que crezca la popularidad de las tecnologías de memoria no volátil (NVM) . [ 7 ]

En sistemas que incluyen almacenamiento no volátil, la durabilidad se puede lograr manteniendo y volcando un registro secuencial inmutable de las transacciones en dicho almacenamiento no volátil antes de confirmar la confirmación. Gracias a su atomicidad, las transacciones pueden considerarse la unidad de trabajo en el proceso de recuperación que garantiza la durabilidad al explotar el registro. En particular, el mecanismo de registro se denomina 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 confirmadas son resistentes a fallos a nivel del sistema, ya que pueden rehacerse. Las transacciones no confirmadas, 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 forma, las operaciones ejecutadas parcialmente pueden deshacerse sin afectar el estado del sistema. Después de eso, las transacciones que quedaron incompletas pueden rehacerse. Por lo tanto, el registro de transacciones del almacenamiento no volátil se puede reprocesar para recrear el estado del sistema justo antes de cualquier fallo posterior a nivel del sistema. El registro se realiza mediante una combinación de seguimiento de datos y operaciones (es decir, transacciones) por razones de rendimiento. [ 9 ]

Nivel de medios

A nivel de medios, los escenarios de fallo afectan al almacenamiento no volátil, como discos duros , 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 basarse en una memoria estable, que es una memoria completamente y, en el mejor de los casos, resistente a fallos. Este tipo de memoria se puede lograr con mecanismos de replicación y protocolos de escritura robustos. [ 4 ]

Existen numerosas 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 tecnológica. 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 se engloban en las categorías de copia de seguridad , prevención de pérdida de datos y recuperación ante desastres informáticos . [ 11 ]

Por lo tanto, en caso de fallo del medio, 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, independientemente de cómo 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 inicio del sistema de base de datos. Estos mecanismos suelen incluir 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 estado 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 mediante su confirmación. De hecho, los recursos utilizados en esa transacción pueden estar en otros nodos, donde se están ejecutando otras transacciones simultáneamente. De lo contrario, en caso de fallo, si no se pudiera garantizar la consistencia, sería imposible reconocer un estado seguro de la base de datos para su recuperación. Por esta razón, todos los nodos participantes deben coordinarse antes de que se pueda confirmar una transacción. Esto generalmente se realiza mediante un protocolo de confirmación en dos fases . [ 13 ]

Además, en las bases de datos distribuidas , incluso los protocolos de registro y recuperación deben abordar los problemas de los entornos distribuidos , como los interbloqueos , que podrían impedir la resiliencia y la recuperabilidad 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. 1 2 3 4 5 6 7 8 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 importarte" . MariaDB . 29 de julio de 2018. Consultado el 22 de septiembre de 2021 .
  3. 1 2 3 4 5 6 7 Hadzilacos, Vassos (1988). "Una teoría de la confiabilidad en los sistemas de bases de datos" . Journal of the ACM . 35 (1): 121– 145. doi : 10.1145/42267.42272 . ISSN 0004-5411 . S2CID 7052304 .  
  4. 1 2 3 4 Atzeni, Paolo, ed. (1999). Sistemas de bases de datos: conceptos, lenguajes y arquitecturas . Nueva York: McGraw-Hill. págs. 311 a 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 . EE. UU.
  6. ↑Petrov, Oleksandr (2019). Database internals: a deep dive into how distributed data systems work (1st ed.). Beijing Boston Farnham Sebastopol Tokyo: O'Reilly. pp. 40–42. ISBN 978-1-4920-4034-7.
  7. ↑Arulraj, Joy; Pavlo, Andrew (2017-05-09). "How to Build a Non-Volatile Memory Database Management System". Proceedings of the 2017 ACM International Conference on Management of Data. SIGMOD '17. New York, NY, USA: Association for Computing Machinery. pp. 1753–1758. doi:10.1145/3035918.3054780. ISBN 978-1-4503-4197-4. S2CID 648876.
  8. 1234Petrov, Oleksandr (2019). Database internals: a deep dive into how distributed data systems work (1st ed.). Beijing Boston Farnham Sebastopol Tokyo: 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: a transaction recovery method supporting fine-granularity locking and partial rollbacks using write-ahead logging". ACM Transactions on Database Systems. 17 (1): 94–162. doi:10.1145/128765.128770. ISSN 0362-5915. S2CID 8759704.
  10. ↑Eich, Margaret H. (1987-02-01). "A classification and comparison of main memory database recovery techniques". 1987 IEEE Third International Conference on Data Engineering. IEEE. pp. 332–339. doi:10.1109/ICDE.1987.7272398. ISBN 978-0-8186-0762-2. S2CID 207773738.
  11. ↑Choy, Manhoi; Leong, Hong Va; Wong, Man Hon (2000). "Disaster recovery techniques for database systems". Communications of the ACM. 43 (11es): 6. doi:10.1145/352515.352521. ISSN 0001-0782. S2CID 14781378.
  12. ↑Verhofstad, Joost S. M. (1978-06-01). "Recovery Techniques for Database Systems". ACM Computing Surveys. 10 (2): 167–195. doi:10.1145/356725.356730. S2CID 8847522.
  13. 1 2 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 registro de escritura anticipada" . ACM Transactions on Database Systems . 17 (1): 94– 162. doi : 10.1145/128765.128770 . ISSN 0362-5915 . S2CID 8759704 .  

Lecturas adicionales

  • Campbell, Laine; Majors, Charity (2017). Ingeniería de confiabilidad de bases de datos . O'Reilly Media, Inc. ISBN 9781491926215.
  • Taylor, CA; Gittens, MS; Miranskyy, AV (junio de 2008). «Un estudio de caso sobre la fiabilidad de las bases de datos: tipos de componentes, perfiles de uso y pruebas» . Actas del 1.er taller internacional sobre pruebas de sistemas de bases de datos . págs. 1-6 . doi : 10.1145/1385269.1385283 . ISBN  9781605582337. S2CID 16101765 . 
  • Aspectos de durabilidad en las bases de datos de Oracle
  • Documentación de MySQL InnoDB sobre la compatibilidad con propiedades ACID.
  • Documentación de PostgreSQL sobre fiabilidad
  • Durabilidad de las transacciones de control de Microsoft SQL Server
  • Visualización interactiva de la latencia para diferentes tipos de almacenamiento de Berkeley
Obtenido de " https://en.wikipedia.org/w/index.php?title=Durability_(database_systems)&oldid=1347487362 "