Transacciones ácidas. Actas. Propiedades de las transacciones ACID. Gestión de recuperación. Algoritmo ARIES. Fijación en dos fases. Mira qué es "ÁCIDO" en otros diccionarios
No es ningún secreto que en presencia de una regla heurística formulada llamada Teorema CAP, a diferencia del sistema RDBMS habitual, la clase de soluciones NoSQL no puede proporcionar apoyo totalÁCIDO. Hay que decir que para una serie de tareas esto no es necesario y el apoyo a uno de los elementos conduce a un compromiso en la resolución de los demás, como resultado: una amplia variedad de soluciones existentes. En este artículo me gustaría considerar varios enfoques arquitectónicos para resolver problemas de cumplimiento parcial de los requisitos de un sistema transaccional.Atomicidad "A"
La atomicidad garantiza que ninguna transacción se envíe parcialmente al sistema. O se realizarán todas sus suboperaciones o no se realizará ninguna.Generalmente se eligen sistemas NoSQL rendimiento alto no por el bien de la semántica transaccional, ya que su cumplimiento introduce costos de procesamiento adicionales. Muchos sistemas todavía ofrecen garantías a nivel de clave o de fila (Google BigTable) o proporcionan una API de operaciones atómicas (Amazon DynamoDB) en la que solo un subproceso puede modificar un registro si, por ejemplo, desea tener un contador de visitas de usuario distribuido en todo el sistema. grupo . La mayoría de los sistemas se adhieren a bucles de lectura, modificación y escritura sin bloqueo. El ciclo consiste en tres etapas- leer el valor, modificar, escribir. Como puede ver, en un entorno multiproceso hay muchas cosas que pueden salir mal, por ejemplo, ¿qué pasa si alguien cambia un registro entre las fases de lectura y escritura? El principal mecanismo para resolver tales conflictos es el uso del algoritmo Comparar e Intercambiar: si alguien cambió un registro durante el ciclo, debemos entender que el registro ha cambiado y repetir el ciclo hasta que se establezca nuestro valor, este algoritmo parece preferible a completamente Mecanismo de bloqueo de escritura. El número de dichos ciclos puede ser muy grande, por lo que necesitamos un cierto tiempo de espera para la operación, después del cual la operación será rechazada.
Consistencia "C"
Una transacción que alcanza su finalización normal y, por lo tanto, confirma sus resultados, mantiene la coherencia de la base de datos. Teniendo en cuenta la especificidad de NoSQL para la distribución de información entre servidores, esto significa si todas las réplicas que contienen una copia de los datos siempre contienen la misma versión de los datos.Debido a sus características específicas, el NoSQL moderno debe elegir alta disponibilidad y capacidad para escalado horizontal clúster: resulta que el sistema no puede garantizar la coherencia total de los datos y hace algunas suposiciones al definir el concepto de coherencia. Hay dos enfoques:
estricta coherencia
Dichos sistemas garantizan que las réplicas siempre puedan ponerse de acuerdo sobre una versión de los datos devueltos al usuario. Algunas réplicas no contendrán este valor, pero cuando el sistema procesa una solicitud de un valor por clave, la máquina siempre podrá decidir qué valor devolver; simplemente no siempre será el último. Cómo funciona: por ejemplo, tenemos norte réplicas de la misma clave. Cuando llega una solicitud para actualizar un valor clave, el sistema no devolverá el resultado al usuario hasta que W. Las réplicas no responderán que han recibido la actualización. Cuando el usuario solicita un valor, el sistema devuelve una respuesta al usuario cuando al menos R las réplicas devolvieron el mismo valor. Entonces consideramos que el sistema es estrictamente consistente si se cumple la condición R+W>N. Seleccionar valores R Y W. afecta cuántas máquinas deben responder antes de que la respuesta sea devuelta al usuario, generalmente seleccionando una condición R+W=N+1- mínimo condición necesaria para garantizar una estricta coherencia.Posible consistencia
Algunos sistemas ( Voldemort, Cassandra, Riak) le permite seleccionar R Y W. en el cual R+WLa resolución de este conflicto varía en diferentes sistemas; Voldemort devuelve múltiples copias del valor, dejando que el usuario resuelva el conflicto. Se pueden fusionar dos versiones del carrito de compras de un usuario en un sitio sin pérdida de información, mientras que fusionar dos versiones del mismo documento editable requiere la intervención del usuario. Cassandra, que almacena la marca de tiempo de cada registro, devuelve el último si se detecta un conflicto. Este enfoque no permite fusionar dos versiones sin perder información, pero simplifica la parte del cliente.
Cassandra, desde la versión 1.1, asegura que si actualizas:
ACTUALIZAR Usuarios
SET login="iniciar sesión" AND contraseña="contraseña"
DONDE clave="clave"
Entonces, ninguna lectura simultánea verá una actualización parcial de los datos (el inicio de sesión ha cambiado, pero la contraseña no), y esto solo es cierto en el nivel de las filas que están dentro de la misma familia de columnas y tener una clave común. Esto puede corresponder al nivel de aislamiento de transacciones. leer no comprometido, en el que se resuelven los conflictos actualización perdida. Pero casandra no proporciona un mecanismo de reversión a nivel de clúster; por ejemplo, es posible una situación en la que el inicio de sesión y la contraseña se guarden en una cierta cantidad de nodos, pero no en cantidades suficientes W. Para darle al usuario el resultado correcto, el usuario se ve obligado a resolver este conflicto por sí mismo. El mecanismo para garantizar el aislamiento es que por cada registro que se modifica se crea una versión invisible y aislada para los clientes, que posteriormente reemplaza automáticamente la versión anterior a través de los mecanismos de Comparación e Intercambio descritos anteriormente.
Confiabilidad "D"
Independientemente de los problemas en niveles inferiores (por ejemplo, apagones del sistema o fallas de hardware), los cambios realizados por una transacción completada con éxito deben permanecer guardados después de que el sistema vuelva a funcionar. Es decir, si el usuario recibió confirmación por parte del sistema de que la transacción se completó, puede estar seguro de que los cambios que realizó no se desharán por algún fallo.El escenario de falla más predecible es un corte de energía o un reinicio del servidor. En este caso, un sistema totalmente confiable no debería devolver una respuesta al usuario hasta que escriba todos los cambios de la memoria en el disco duro. Escribir en el disco lleva demasiado tiempo y muchos sistemas NoSQL hacen concesiones en aras del rendimiento.
Garantizar la confiabilidad dentro de un único servidor
Un disco estándar puede soportar entre 70 y 150 operaciones por segundo, lo que supone un rendimiento de hasta 150 MB/s, SSD - 700 MB/s, DDR - 6000 - 17000 MB/s. Por lo tanto, garantizar la confiabilidad dentro de un único servidor y al mismo tiempo garantizar un alto rendimiento consiste en reducir la cantidad de escrituras de acceso aleatorio y aumentar las escrituras secuenciales. Idealmente, el sistema debería minimizar el número de entradas entre llamadas. sincronización f(sincronización de datos en memoria y en disco). Para ello se utilizan varias técnicas.control de frecuencia sincronización f
Redis ofrece varias formas de configurar cuándo llamar sincronización f. Puede configurarlo para que se llame después de cada cambio de registro, que es la opción más lenta y segura. Para mejorar el rendimiento, puede activar un vaciado del disco cada norte segundos, en el peor de los casos perderá datos en norteúltimos segundos, lo que puede resultar bastante aceptable para algunos usuarios. Si la confiabilidad no es crítica en absoluto, entonces puede desactivar fsync y confiar en que el sistema en algún momento sincronice la memoria con el disco.Aumento de la escritura secuencial mediante el registro
Para buscar datos de forma eficaz, los sistemas NoSQL suelen utilizar estructuras adicionales, por ejemplo, árboles B para crear índices. Trabajar con ellos provoca múltiples accesos aleatorios al disco; Para reducir esto, algunos sistemas ( Cassandra, HBase, Riak) agregar operaciones de actualización a un archivo escrito secuencialmente llamado rehacer registro. Si bien algunas estructuras se escriben en el disco con bastante poca frecuencia, el registro se escribe con frecuencia. Después de una falla, los registros faltantes se pueden restaurar usando el registro.Aumento del rendimiento agrupando registros
casandra agrupa múltiples cambios simultáneos dentro de una ventana corta que se puede combinar en uno sincronización f. Este enfoque, llamado compromiso de grupo, aumenta el tiempo de respuesta para un usuario, porque se ve obligado a esperar a que otras transacciones registren la suya. La ventaja aquí se obtiene aumentando el rendimiento general, porque Se pueden combinar varias entradas aleatorias.Garantizar la confiabilidad dentro de un clúster de servidores
Debido a la posibilidad de que se produzcan fallos inesperados en el disco y el servidor, es necesario distribuir la información entre varias máquinas.Redis representa un clásico amo-esclavo Arquitectura para la replicación de datos. Todas las operaciones asociadas con el maestro pasan a las réplicas en forma de registro.
MongoDB es una estructura en la que un número determinado de servidores almacena cada documento, y es posible configurar el número de servidores W.
HBase logra confiabilidad multiservidor mediante el uso de un sistema de archivos distribuido HDFS.
En general, se puede notar una cierta tendencia en las herramientas NoSQL modernas a proporcionar una mayor coherencia en los datos. Pero aún así, las herramientas SQL y NoSQL pueden existir y desarrollarse en paralelo y resolver problemas completamente diferentes.
Es posible que ya hayas escuchado el término como transacción . Si no es así o lo has olvidado, te recordamos que bajo transacción se refiere a una determinada secuencia de operaciones (acciones de inserción, actualización o eliminación) en la base de datos que deben realizarse como parte de un todo único.
Todos utilizamos los servicios de los bancos y realizamos diversas transacciones con fondos. ¿Cómo lograr confiabilidad en este caso? Se aumentan los requisitos de seguridad para realizar operaciones en dichos sistemas. Ahora imagina que estás transfiriendo fondos a alguien que conoces. Quiere que los fondos se debiten de su cuenta y se transfieran a la cuenta del destinatario. Pero, ¿qué sucede en caso de un corte de energía, como un corte de energía u otra emergencia? Quién te garantiza que no te encontrarás en una situación en la que el dinero haya salido de tu cuenta, pero no se haya producido la transferencia a la cuenta del destinatario. Ayuda a prevenir este tipo de situaciones. actas.
Confirmar y revertir una transacción.
Una transacción combina varias declaraciones. SQL. Si se produce algún fallo como resultado de la ejecución de al menos una de las solicitudes, la transacción se revierte inmediatamente ( revertir). Si todo está bien y todas las acciones dentro de una transacción se completaron exitosamente, entonces se realiza la confirmación ( comprometerse) transacciones y solo en este caso los cambios correspondientes se escriben en la base de datos.
Ahora demostremos un ejemplo del uso de transacciones en SGBD MySQL(en los más populares SGBD este mecanismo no es fundamentalmente diferente):
Tengamos una mesa de prueba. cuentas, que almacena información sobre las cuentas de usuario. Y un campo que nos interesa se llama balance. Al transferir de una cuenta a otra, los fondos deben cargarse en una cuenta y acreditarse en otra (para fines prácticos, usted mismo puede crear una pequeña base de datos).
La transacción comienza con una palabra clave. COMENZAR. Dos operadores ACTUALIZAR Las transacciones internas son parte de la misma transacción y se pueden ejecutar ambas al mismo tiempo o ninguna de ellas (debe ocurrir una reversión). Equipo COMPROMETERSE sirve para indicar el final de una transacción y la realización de cambios. Si la confirmación es exitosa, se mostrarán todos los cambios en la base de datos de origen.
Para revertir una transacción, puede escribir explícitamente el comando RETROCEDER.
Propiedades ácidas.
Entonces, nos familiarizamos con los conceptos de transacción, confirmación y reversión. Ahora veamos cuatro propiedades muy importantes de una transacción sobre las que a la gente le gusta preguntar en las entrevistas. Requisitos ÁCIDO a finales de los 70 formulado por Jim Gray (ganador del Premio Turing por su contribución al desarrollo de bases de datos). Y así es como suenan:
- Atomicidad- atomicidad. De lo que hablamos arriba. la transacción es atómica, es decir, todas las acciones realizadas dentro de una transacción son un todo único.
- Consistencia- consistencia. Cada nueva transacción mueve la base de datos de un estado consistente a otro. Si su base de datos está distribuida, todas sus réplicas deben contener la misma versión de los datos para garantizar la disponibilidad. Esta regla es a menudo violada por muchos No SQL bases de datos.
- Aislamiento- aislamiento. Las transacciones no se afectan entre sí. En caso de ejecución paralela, no debería producirse una actualización parcial de los datos.
- Durabilidad- fiabilidad. ¿Quieres que todos los cambios realizados por esta transacción se guarden en caso de fallas? Por eso esta lista tiene la propiedad de ser fiable.
Requisitos de ácido
Atomicidad - Atomicidad
La atomicidad garantiza que ninguna transacción se envíe parcialmente al sistema. O se realizarán todas sus suboperaciones o no se realizará ninguna. Dado que en la práctica es imposible realizar de forma simultánea y atómica toda la secuencia de operaciones dentro de una transacción, se introduce el concepto de "reversión": si una transacción no se puede completar por completo, los resultados de todas sus acciones realizadas anteriormente se cancelarán y la El sistema volverá a su estado original.
Consistencia - Consistencia
Una de las propiedades más complejas y ambiguas de los cuatro ÁCIDOS. Según este requisito, el sistema está en un estado consistente antes de que comience una transacción y debe permanecer en un estado consistente después de que se completa la transacción. El requisito de coherencia no debe confundirse con el requisito de integridad. Estas últimas reglas son más estrictas y, en muchos sentidos, específicas de los DBMS relacionales: existen requisitos de integridad de tipo, integridad referencial e integridad de entidad, que no pueden violarse físicamente debido a las características de implementación del sistema.
La coherencia es un concepto más amplio. Por ejemplo, en el sistema bancario puede existir el requisito de que el monto debitado de una cuenta sea igual al monto acreditado en otra. Esta es una regla comercial y no puede garantizarse únicamente mediante comprobaciones de integridad, sino que los programadores deben seguirla al escribir el código de transacción. Si alguna transacción se carga pero no se carga, el sistema permanecerá en un estado incorrecto y se violará la propiedad de coherencia.
Finalmente, otra nota se refiere al hecho de que durante coherencia en la ejecución de transacciones no requerido. En nuestro ejemplo, el débito y el abono probablemente serán dos suboperaciones diferentes, y entre su ejecución dentro de una transacción será visible un estado inconsistente del sistema. Sin embargo, no debemos olvidar que si se cumple el requisito de aislamiento, esta inconsistencia no será visible para ninguna otra transacción. Y la atomicidad garantiza que la transacción se completará por completo o no se realizará ninguna de las operaciones de la transacción. Así, esta inconsistencia intermedia queda oculta.
Aislamiento - Aislamiento
Mientras se ejecuta una transacción, las transacciones simultáneas no deberían afectar su resultado. Esta propiedad no se respeta en el nivel de aislamiento de lectura confirmada ni en niveles inferiores.
Durabilidad - Fiabilidad
Independientemente de los problemas en niveles inferiores (por ejemplo, apagones del sistema o fallas de hardware), los cambios realizados por una transacción completada con éxito deben permanecer guardados después de que el sistema vuelva a funcionar. Es decir, si el usuario recibió confirmación por parte del sistema de que la transacción se completó, puede estar seguro de que los cambios que realizó no se desharán por algún fallo.
Literatura
- PENSILVANIA. Bernstein, N. Goodman, V. Hadzilacos. Control y Recuperación de Concurrencia en Sistemas de Bases de Datos. - Addison-Wesley, 1986.
Notas
Fundación Wikimedia.
2010.
Vea qué es "ÁCIDO" en otros diccionarios:ácido
- ACÍD, Ă, acizi, de, s.m., adj. 1. s.m. Sustancia química, cu gust acru şi miros înţepător, care înroşeste hârtia albastră de turnesol şi care, în combinaţie cu o bază, formează o sare. 2.adj. (Adesea fig.) Los cuidados son proprietăţile unui acid (1),… … Dicționar RomânÁcido
Vea qué es "ÁCIDO" en otros diccionarios:- Productions (ACiD) es un grupo de arte escénico welche sich, 1990 creado, creado en ANSI Art für Mailboxen spezialisiert hat. In den letzten Jahren fand mit dem Niedergang der Mailbox Szene ein Wechsel zu anderen Hauptaktivitäten wie… … Deutsch Wikipedia
- ACÍD, Ă, acizi, de, s.m., adj. 1. s.m. Sustancia química, cu gust acru şi miros înţepător, care înroşeste hârtia albastră de turnesol şi care, în combinaţie cu o bază, formează o sare. 2.adj. (Adesea fig.) Los cuidados son proprietăţile unui acid (1),… … Dicționar Român- Desde que en los años 60 se utilizó por primera vez ácido para referirse a la droga alucinógena LSD, la palabra ha desarrollado todas las connotaciones de una subcultura. Aquellos que tomaban drogas llegaron a ser llamados acid heads o acid freaks; y su forma de vida pasó a depender de… … Uso del inglés moderno
- Productions ACiD Productions (ACiD) es un grupo artístico y numérico underground. Fundado en 1990, el grupo fue originalmente especializado en el grafismo ANSI para BBS. Además, ahora vamos a ampliar el dominio de la aplicación a versiones… … Wikipédia en Français
Vea qué es "ÁCIDO" en otros diccionarios:- (inglés “acid”): En la música, el acid house y el acid techno son géneros musicales. Acid es una banda de rock japonesa. Acid es una banda belga de speed/thrash metal. Ácido Sustancia narcótica LSD 25. En informática Sony ACID Pro editor de audio ACID set... ... Wikipedia
- amargo, de sabor agrio, agrio, ácido, mordaz, picante, picante, picante, agrio, avinagrado, avinagrado; concepto 613 Hormiga. ácido suave, dulce que tiene propiedades ácidas, corrosivas, acerba, acidulada, acre, antialcalina, mordiente,… … Nuevo tesauroÁcido
- amargo, de sabor agrio, agrio, ácido, mordaz, picante, picante, picante, agrio, avinagrado, avinagrado; concepto 613 Hormiga. ácido suave, dulce que tiene propiedades ácidas, corrosivas, acerba, acidulada, acre, antialcalina, mordiente,… … Nuevo tesauro- Ácido, a. 1. De sabor ácido, picante o picante; tarta; que tiene sabor a vinagre: como, frutas o licores ácidos. También fig.: Templado agrio.
Atomicidad - Atomicidad
La atomicidad garantiza que ninguna transacción se envíe parcialmente al sistema. O se realizarán todas sus suboperaciones o no se realizará ninguna. Dado que en la práctica es imposible realizar de forma simultánea y atómica toda la secuencia de operaciones dentro de una transacción, se introduce el concepto de "reversión": si una transacción no se puede completar por completo, los resultados de todas sus acciones realizadas anteriormente se cancelarán y la El sistema volverá al estado "externamente inicial"; desde fuera parecerá que la transacción nunca se realizó. (Por supuesto, los contadores, índices y otras estructuras internas pueden cambiar, pero si el DBMS se programa sin errores, esto no afectará su comportamiento externo).
Consistencia - Consistencia
Una transacción que alcanza su final normal (EOT - fin de transacción) y, por lo tanto, confirma sus resultados, mantiene la coherencia de la base de datos. En otras palabras, cada transacción exitosa, por definición, registra sólo resultados válidos. Esta condición es necesaria para sustentar la cuarta propiedad.
La coherencia es un concepto más amplio. Por ejemplo, en el sistema bancario puede existir el requisito de que el monto debitado de una cuenta sea igual al monto acreditado en otra. Esta es una regla comercial y no puede garantizarse únicamente mediante comprobaciones de integridad, sino que los programadores deben seguirla al escribir el código de transacción. Si alguna transacción se carga pero no se carga, el sistema permanecerá en un estado incorrecto y se violará la propiedad de coherencia.
Finalmente, otra nota se refiere al hecho de que durante coherencia en la ejecución de transacciones no requerido. En nuestro ejemplo, el débito y el abono probablemente serán dos suboperaciones diferentes, y entre su ejecución dentro de una transacción será visible un estado inconsistente del sistema. Sin embargo, no debemos olvidar que si se cumple el requisito de aislamiento, esta inconsistencia no será visible para ninguna otra transacción. Y la atomicidad garantiza que la transacción se completará por completo o no se realizará ninguna de las operaciones de la transacción. Así, esta inconsistencia intermedia queda oculta.
Aislamiento - Aislamiento
Mientras se ejecuta una transacción, las transacciones simultáneas no deberían afectar su resultado. El aislamiento es un requisito costoso, por lo que en bases de datos reales existen modos que no aíslan completamente la transacción (niveles de aislamiento Lectura repetible y abajo).
Durabilidad - Durabilidad
Independientemente de los problemas en niveles inferiores (por ejemplo, apagones del sistema o fallas de hardware), los cambios realizados por una transacción completada con éxito deben permanecer guardados después de que el sistema vuelva a funcionar. Es decir, si el usuario recibió confirmación por parte del sistema de que la transacción se completó, puede estar seguro de que los cambios que realizó no se desharán por algún fallo.
Ver también
Escribe una reseña sobre el artículo "ÁCIDO"
Literatura
- PENSILVANIA. Bernstein, N. Goodman, V. Hadzilacos. Control y Recuperación de Concurrencia en Sistemas de Bases de Datos. - Addison-Wesley, 1986.
Notas
|
||||||||||||||||||||||||||
Extracto que describe ACID
Natasha guardó silencio, como pensaba Marya Dmitrievna, por timidez, pero en esencia a Natasha le desagradaba que estuvieran interfiriendo en su historia de amor con el príncipe Andrei, que le parecía tan especial de todos los asuntos humanos que nadie, según sus conceptos, podría entenderlo. Ella amaba y conocía a un tal Príncipe Andrei, él la amaba y se suponía que vendría un día de estos y se la llevaría. Ella no necesitaba nada más."Verás, lo conozco desde hace mucho tiempo y amo a Mashenka, tu cuñada". Las cuñadas son golpeadoras, pero esta no lastimará ni a una mosca. Ella me pidió que la arreglara contigo. Mañana tu padre y tú iréis a verla y le daréis un buen abrazo: sois más jóvenes que ella. De alguna manera llegará el tuyo, y ya conoces a tu hermana y a tu padre, y ellos te aman. ¿Sí o no? ¿Seguramente será mejor?
"Mejor", respondió Natasha de mala gana.
Al día siguiente, siguiendo el consejo de Marya Dmitrievna, el conde Ilya Andreich fue con Natasha al príncipe Nikolai Andreich. El conde se preparó para esta visita con un espíritu lúgubre: en el fondo tenía miedo. La última reunión durante la milicia, cuando el conde, en respuesta a su invitación a cenar, escuchó una acalorada reprimenda por no entregar a la gente, fue memorable para el conde Ilya Andreich. Natasha, vestida con su mejor vestido, estaba por el contrario de muy buen humor. “Es imposible que no me quieran”, pensó: todos me han querido desde siempre. ¡Y estoy tan dispuesta a hacer por ellos lo que quieran, estoy tan dispuesta a amarlo a él, porque él es padre y a ella, porque es hermana, que no hay razón por la cual ellos no me amarían!
Condujeron hasta una casa vieja y lúgubre en Vzdvizhenka y entraron al pasillo.
“Bueno, Dios los bendiga”, dijo el conde, medio en broma, medio en serio; pero Natasha notó que su padre tenía prisa, entró al salón y, tímidamente y en voz baja, preguntó si el príncipe y la princesa estaban en casa. Tras el informe de su llegada, hubo confusión entre los sirvientes del príncipe. El lacayo que corrió a denunciarlos fue detenido por otro lacayo en el vestíbulo y susurraron algo. Una doncella corrió hacia el pasillo y también dijo algo apresuradamente, mencionando a la princesa. Finalmente, un viejo lacayo con mirada enojada salió e informó a los Rostov que el príncipe no podía recibirlo, pero que la princesa pedía ir con ella. La señorita Bourienne fue la primera en saludar a los invitados. Ella recibió con especial cortesía al padre y a la hija y los llevó ante la princesa. La princesa, con el rostro excitado y asustado cubierto de manchas rojas, salió corriendo, con pasos pesados, hacia los invitados, y trató en vano de parecer libre y acogedora. A la princesa Marya no le agradó Natasha a primera vista. Le parecía demasiado elegante, frívolamente alegre y vanidosa. La princesa María no sabía que antes de ver a su futura nuera, ya estaba mal dispuesta hacia ella por envidia involuntaria de su belleza, juventud y felicidad y por celos del amor de su hermano. Además de este irresistible sentimiento de antipatía hacia ella, la princesa María en ese momento también estaba excitada por el hecho de que ante el informe de la llegada de los Rostov, el príncipe gritó que no los necesitaba, que debía dejar que la princesa María los recibiera. si ella quisiera, y que no se les debería permitir verlo. La princesa María decidió recibir a los Rostov, pero a cada minuto temía que el príncipe le hiciera algún tipo de broma, ya que parecía muy entusiasmado con la llegada de los Rostov.
"Bueno, querida princesa, te traje mi pájaro cantor", dijo el conde, arrastrando los pies y mirando inquieto a su alrededor, como si temiera que el viejo príncipe pudiera aparecer. "Me alegro mucho de haberos conocido... Es una lástima, es una lástima que el príncipe todavía no se encuentre bien", y después de decir algunas frases más generales, se puso de pie. “Si me permitieras, princesa, darte una idea de mi Natasha durante un cuarto de hora, iría, a sólo dos pasos, al parque para perros, a ver a Anna Semyonovna y la recogería. "
Las características de la transacción se describen en términos de ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad).
· Una transacción es indivisible en el sentido de que es un todo único. Todos sus componentes tienen lugar o no. No existe nada parecido a una transacción parcial. Si sólo se puede completar una parte de la transacción, se rechaza.
· La transacción es consistente porque no viola la lógica de negocios ni las relaciones entre los elementos de datos. Esta propiedad es muy importante a la hora de desarrollar sistemas cliente-servidor, ya que el almacén de datos recibe una gran cantidad de transacciones de diferentes sistemas y objetos. Si al menos uno de ellos viola la integridad de los datos, todos los demás pueden producir resultados incorrectos.
· Una transacción siempre está aislada porque sus resultados son autónomos. Son independientes de transacciones anteriores o posteriores; esta propiedad se llama serializabilidad y significa que las transacciones en una secuencia son independientes.
· La transacción es estable. Una vez finalizado, se almacena en el sistema, y nada puede devolverlo a su estado original (antes de la transacción), es decir. La transacción se compromete, lo que significa que su efecto es permanente incluso si el sistema falla. Esto implica alguna forma de almacenamiento de información en memoria persistente como parte de una transacción.
Niveles de aislamiento de transacciones
Idealmente, las transacciones entre diferentes usuarios deberían realizarse de tal manera que se cree la ilusión de que el usuario de la transacción actual es el único. Sin embargo, en realidad, por razones de rendimiento y para realizar algunas tareas especiales, los DBMS proporcionan diferentes niveles de aislamiento de transacciones. Los niveles se describen en orden de creciente aislamiento de transacciones y confiabilidad de los datos.
0 - Lectura no confirmada (lectura no confirmada, lectura sucia, lectura sucia): es posible leer cambios no confirmados en su transacción y transacciones competidoras, lecturas sucias, no repetibles y fantasmas
1 - Lectura confirmada (lectura confirmada): lectura de todos los cambios en la propia transacción y cambios confirmados en transacciones competidoras, las lecturas sucias son imposibles, las lecturas no repetibles y los fantasmas son posibles
2 - Lectura repetible (lectura repetible, instantánea): leer todos los cambios en su transacción, cualquier cambio realizado por transacciones competidoras después del inicio de la suya no está disponible, las lecturas sucias y no repetibles son imposibles, los fantasmas son posibles
3 - Ordenadas - (Serializables, serializables) - Transacciones ordenadas (serializables). Idéntico a la situación en la que las transacciones se ejecutan estrictamente secuencialmente una tras otra. Es decir, transacciones cuyos resultados no dependen del orden en que se ejecutan los pasos de la transacción (está prohibido leer todos los datos modificados desde el comienzo de la transacción, incluso los de la propia transacción). Los fantasmas son imposibles.
Cuanto mayor sea el nivel de aislamiento, más recursos se necesitarán para mantenerlos.
En un DBMS, el nivel de aislamiento de transacciones se puede seleccionar tanto para todas las transacciones a la vez como para una transacción específica. De forma predeterminada, la mayoría de las bases de datos utilizan el nivel 1 (lectura confirmada). El nivel 0 se utiliza principalmente para rastrear cambios en transacciones de larga duración o para leer datos que cambian con poca frecuencia. Los niveles 2 y 3 se utilizan para mayores requisitos de aislamiento de transacciones.
Atomicidad - Atomicidad
Artículo principal: Atomicidad
La atomicidad garantiza que ninguna transacción se envíe parcialmente al sistema. O se realizarán todas sus suboperaciones o no se realizará ninguna. Dado que en la práctica es imposible realizar de forma simultánea y atómica toda la secuencia de operaciones dentro de una transacción, se introduce el concepto de "reversión": si una transacción no se puede completar por completo, los resultados de todas sus acciones realizadas anteriormente se cancelarán y la El sistema volverá a su estado original.
[editar]
Consistencia - Consistencia
Artículo principal: coherencia de los datos
Una de las propiedades más complejas y ambiguas de los cuatro ÁCIDOS. Según este requisito, el sistema está en un estado consistente antes de que comience una transacción y debe permanecer en un estado consistente después de que se completa la transacción. El requisito de coherencia no debe confundirse con el requisito de integridad. Estas últimas reglas son más estrictas y, en muchos sentidos, específicas de los DBMS relacionales: existen requisitos de integridad de tipo, integridad referencial e integridad de entidad, que no pueden violarse físicamente debido a las características específicas de la implementación del sistema.
La coherencia es un concepto más amplio. Por ejemplo, en el sistema bancario puede existir el requisito de que el monto debitado de una cuenta sea igual al monto acreditado en otra. Esta es una regla comercial y no puede garantizarse únicamente mediante comprobaciones de integridad, sino que los programadores deben seguirla al escribir el código de transacción. Si alguna transacción se carga pero no se carga, el sistema permanecerá en un estado incorrecto y se violará la propiedad de coherencia.
Finalmente, otra nota es que no se requiere coherencia durante la ejecución de la transacción. En nuestro ejemplo, el débito y el abono probablemente serán dos suboperaciones diferentes, y entre su ejecución dentro de una transacción será visible un estado inconsistente del sistema. Sin embargo, no debemos olvidar que si se cumple el requisito de aislamiento, esta inconsistencia no será visible para ninguna otra transacción. Y la atomicidad garantiza que la transacción se completará por completo o no se realizará ninguna de las operaciones de la transacción. Así, esta inconsistencia intermedia queda oculta.
Aislamiento - Aislamiento
Mientras una transacción está en progreso, otros procesos no deberían ver los datos en el estado intermedio. Por ejemplo, si una transacción modifica varios campos en una base de datos a la vez, otra consulta ejecutada mientras la transacción está en progreso no debería devolver algunos de esos campos con nuevos valores y otros con sus valores originales.
Durabilidad - Durabilidad
Independientemente de los problemas en niveles inferiores (por ejemplo, apagones del sistema o fallas de hardware), los cambios realizados por una transacción completada con éxito deben permanecer guardados después de que el sistema vuelva a funcionar. Es decir, si el usuario recibió confirmación por parte del sistema de que la transacción se completó, puede estar seguro de que los cambios que realizó no se desharán por algún fallo.
