Un sistema distribuido consta de varios procesadores. Estos se pueden organizar como colección de estaciones de trabajo personales, una pila pública de procesadores o alguna forma híbrida. En todos los casos, se necesita cierto algoritmo para decidir cuál proceso hay que ejecutar y en qué máquina. Para el modelo de estaciones de trabajo, la pregunta es cuándo ejecutar el proceso de manera local y cuándo buscar una estación inactiva. Para el modelo de la pila de procesadores, hay que tomar una decisión por cada nuevo proceso.
En cuarto lugar, cada maquina puede tener un sistema de archivos auto contenido, con
la posibilidad de montarlo o tener su sistema de archivos de otras maquinas. La idea
aquí es que cada maquina esta auto contenida en lo fundamental y que el contacto con el
mundo exterior sea limitado. Este sistema proporciona un tiempo de respuesta uniforme
y garantizada para el usuario y pone poca carga en la red.
Uso de estaciones de trabajo inactivas
Plantea el problema de encontrar estaciones de trabajo inactivas en la red que puedan
ejecutar procesos. Por lo cual las estaciones de trabajo deben de anunciar cuando no
cuentan con una carga de trabajo asignada, así todas las demás estaciones toman nota de
esto y lo registran.
Ya sea que existan muchos o pocos registros, existe un peligro potencial de que
aparezcan condiciones de competencia si dos usuarios llaman al mismo tiempo al
comando remote y ambos descubren que la misma maquina esta inactiva, ambos
intentaran iniciar procesos al mismo tiempo. Para detectar y evitar esta situación, el
programa remote verifica la estación de trabajo inactiva, la cual si continua libre se
elimina así misma del registro y da la señal de continuar, de esta manera quien hizo la
llamada puede enviar su ambiente e iniciar el proceso remoto.
Modelo de pila de procesadores
Este método consiste en construir una pila de procesadores, repleta de CPU, en un
cuarto de maquinas, los cuales se pueden asignar de manera dinámica a los usuarios
según la demanda.
Desde el punto de vista conceptual este método es mas parecido al tiempo compartido
tradicional que al modelo de la computadora personal aunque se construye con la
tecnología moderna. La motivación para la idea de la pila de procesadores proviene de
dar un paso mas adelante en la idea de las estaciones de trabajo sin disco. Si el sistema
de archivos se debe concentrar en un pequeño numero de servidores de archivos para
mayor economía, debe ser posible hacer lo mismo con los servidores de computo, es
decir si colocamos todos los CPU en un gabinete de gran tamaño en el cuarto de
maquinas se pueden reducir los costos de suministro de energía y de empaquetamiento,
lo cual produce un mayor poder de computo con una cantidad fija de dinero.
De hecho convertimos todo el poder de cómputo en “estaciones de trabajo inactivas” a
las que se puede tener acceso de manera dinámica. Los usuarios obtienen tantos CPU
como sea necesario, durante periodos cortos, después de lo cual regresan a la pila, de
modo que otros usuarios puedan disponer de ellos.
Algoritmos o Modelos de Asignación
Los algoritmos deterministas son adecuados cuando se sabe anticipadamente todo acerca del comportamiento de los procesos, pero esto generalmente no se da, aunque puede haber en ciertos casos aproximaciones estadísticas. Los algoritmos heurísticos son adecuados cuando la carga es impredecible.
Los diseños centralizados permiten reunir toda la información en un lugar y tomar una mejor decisión; la desventaja es que la máquina central se puede sobrecargar y se pierde robustez ante su posible falla.
Generalmente los algoritmos óptimos consumen más recursos que los sub-óptimos, además, en la mayoría de los sistemas reales se buscan soluciones sub-óptimas, heurísticas y distribuidas.
Cuando se va a crear un proceso se debe decidir si se ejecutará en la máquina que lo genera o en otra (política de transferencia):
La decisión se puede tomar “solo con información local” o “con información global”.
Los algoritmos locales son sencillos pero no óptimos.
Los algoritmos globales son mejores pero consumen muchos recursos.
Cuando una máquina se deshace de un proceso la política de localización debe decidir dónde enviarlo:
Necesita información de la carga en todas partes, obteniéndola de:
Un emisor sobrecargado que busca una máquina inactiva.
Un receptor desocupado que busca trabajo.
‘’Aspectos de la Implantación de Algoritmos de Asignación de Procesadores’‘
Casi todos los algoritmos suponen que las máquinas conocen su propia carga y que pueden informar su estado:
La medición de la carga no es tan sencilla.
Un método consiste en contar el número de procesos (hay que considerar los procesos latentes no activos). Otro método consiste en contar solo los procesos en ejecución o listos.
También se puede medir la fracción de tiempo que la cpu está ocupada.
Otro aspecto importante es el costo excesivo en consumo de recursos para recolectar medidas y desplazar procesos, ya que se debería considerar el tiempo de cpu, el uso de memoria y el ancho de banda de la red utilizada por el algoritmo para asignación de procesadores.
Se debe considerar la complejidad del software en cuestión y sus implicancias para el desempeño, la correctez y la robustez del sistema.
Si el uso de un algoritmo sencillo proporciona casi la misma ganancia que uno más caro y más complejo, generalmente será mejor utilizar el más sencillo.
Se debe otorgar gran importancia a la estabilidad del sistema:
Las máquinas ejecutan sus algoritmos en forma asíncrona por lo que el sistema nunca se equilibra.
La mayoría de los algoritmos que intercambian información:
Son correctos luego de intercambiar la información y de que todo se ha registrado.
Son poco confiables mientras las tablas continúan su actualización, es decir que se presentan situaciones de no equilibrio.
Modelos de Asignación
Generalmente se utilizan las siguientes hipótesis:
-Todas las máquinas son idénticas (o al menos compatibles en el código); difieren a lo sumo en la velocidad.
-Cada procesador se puede comunicar con los demás.
Las estrategias de asignación de procesadores se dividen en:
-No migratorias:
Una vez colocado un proceso en una máquina permanece ahí hasta que termina.
-Migratorias:
Un proceso se puede trasladar aunque haya iniciado su ejecución.
Permiten un mejor balance de la carga pero son más complejas.
Los algoritmos de asignación intentan optimizar algo:
-Uso de las cpu:
Maximizar el número de ciclos de cpu que se ejecutan para trabajos de los usuarios.
Minimizar el tiempo de inactividad de las cpu.
-Tiempo promedio de respuesta:
Minimizar no los tiempos individuales de respuesta sino los tiempos promedio de respuesta.
-Tasa de respuesta:
Minimizar la tasa de respuesta, que es el tiempo necesario para ejecutar un proceso en cierta máquina dividido por el tiempo que tardaría en cierto procesador de referencia.
Los diseños centralizados permiten reunir toda la información en un lugar y tomar una mejor decisión; la desventaja es que la máquina central se puede sobrecargar y se pierde robustez ante su posible falla.
Generalmente los algoritmos óptimos consumen más recursos que los sub-óptimos, además, en la mayoría de los sistemas reales se buscan soluciones sub-óptimas, heurísticas y distribuidas.
Cuando se va a crear un proceso se debe decidir si se ejecutará en la máquina que lo genera o en otra (política de transferencia):
La decisión se puede tomar “solo con información local” o “con información global”.
Los algoritmos locales son sencillos pero no óptimos.
Los algoritmos globales son mejores pero consumen muchos recursos.
Cuando una máquina se deshace de un proceso la política de localización debe decidir dónde enviarlo:
Necesita información de la carga en todas partes, obteniéndola de:
Un emisor sobrecargado que busca una máquina inactiva.
Un receptor desocupado que busca trabajo.
‘’Aspectos de la Implantación de Algoritmos de Asignación de Procesadores’‘
Casi todos los algoritmos suponen que las máquinas conocen su propia carga y que pueden informar su estado:
La medición de la carga no es tan sencilla.
Un método consiste en contar el número de procesos (hay que considerar los procesos latentes no activos). Otro método consiste en contar solo los procesos en ejecución o listos.
También se puede medir la fracción de tiempo que la cpu está ocupada.
Otro aspecto importante es el costo excesivo en consumo de recursos para recolectar medidas y desplazar procesos, ya que se debería considerar el tiempo de cpu, el uso de memoria y el ancho de banda de la red utilizada por el algoritmo para asignación de procesadores.
Se debe considerar la complejidad del software en cuestión y sus implicancias para el desempeño, la correctez y la robustez del sistema.
Si el uso de un algoritmo sencillo proporciona casi la misma ganancia que uno más caro y más complejo, generalmente será mejor utilizar el más sencillo.
Se debe otorgar gran importancia a la estabilidad del sistema:
Las máquinas ejecutan sus algoritmos en forma asíncrona por lo que el sistema nunca se equilibra.
La mayoría de los algoritmos que intercambian información:
Son correctos luego de intercambiar la información y de que todo se ha registrado.
Son poco confiables mientras las tablas continúan su actualización, es decir que se presentan situaciones de no equilibrio.
Modelos de Asignación
Generalmente se utilizan las siguientes hipótesis:
-Todas las máquinas son idénticas (o al menos compatibles en el código); difieren a lo sumo en la velocidad.
-Cada procesador se puede comunicar con los demás.
Las estrategias de asignación de procesadores se dividen en:
-No migratorias:
Una vez colocado un proceso en una máquina permanece ahí hasta que termina.
-Migratorias:
Un proceso se puede trasladar aunque haya iniciado su ejecución.
Permiten un mejor balance de la carga pero son más complejas.
Los algoritmos de asignación intentan optimizar algo:
-Uso de las cpu:
Maximizar el número de ciclos de cpu que se ejecutan para trabajos de los usuarios.
Minimizar el tiempo de inactividad de las cpu.
-Tiempo promedio de respuesta:
Minimizar no los tiempos individuales de respuesta sino los tiempos promedio de respuesta.
-Tasa de respuesta:
Minimizar la tasa de respuesta, que es el tiempo necesario para ejecutar un proceso en cierta máquina dividido por el tiempo que tardaría en cierto procesador de referencia.
Planificación De Sistemas Distribuidos
No hay mucho que decir de la planificación en los sistemas distribuidos. Por lo general, cada procesador hace su planificación local (si tiene varios procesos en ejecución), sin preocuparse por lo que hacen los demás procesadores. Lo normal es que este método funcione. Sin embargo, si un grupo de procesos relacionados entre sí y con gran interacción se ejecutan en distintos procesadores, la planificación independiente no es el camino más eficiente.
La dificultad básica se puede mostrar mediante un ejemplo, en el cual los procesos A y B se ejecutan en un procesador y los procesos C y D en otro. El tiempo de cada procesador se comparte en pedazos de 100 milisegundos, donde A y C se ejecutan en los pedazos pares y B y D en los nones, como se muestra en la figura 4-20(a).
Supongamos que A envía muchos mensajes o lleva a cabo muchas llamadas a procedimientos remotos de D. Durante el tiempo 0, A inicia y llama de inmediato a D, que por desgracia no se ejecuta en ese momento, puesto que es el turno de C. Después de 100 milisegundos, se alternan los procesos, D obtiene el mensaje de A, lleva a cabo el trabajo y responde con rapidez. Puesto que B está ejecutándose, pasarán otros 100 milisegundos antes de que A obtenga la respuesta y pueda proseguir. El resultado neto es un intercambio de mensajes cada 200 milisegundos.
Lo que se necesita es una forma de garantizar que los procesos con comunicación frecuente se ejecuten de manera simultánea.
Aunque es difícil determinar en forma dinámica los patrones de común entre los procesos, en muchos casos, un grupo de procesos relacionados entre sí iniciarán juntos.
Por ejemplo, en general está bien suponer que los filtros de un entubamiento en UNIX se comunicarán entre sí más de lo qué lo harán con otros procesos ya iniciados.
Supongamos que los procesos se crean en grupos y que la comunicación dentro de los grupos prevalece sobre la comunicación entre los grupos. Supongamos además que se dispone de un número de procesadores lo bastante grande como para manejar al grupo de mayor tamaño y que cada procesador se multiprograma con N espacios para los procesos multiprogramación de nivel N).
La dificultad básica se puede mostrar mediante un ejemplo, en el cual los procesos A y B se ejecutan en un procesador y los procesos C y D en otro. El tiempo de cada procesador se comparte en pedazos de 100 milisegundos, donde A y C se ejecutan en los pedazos pares y B y D en los nones, como se muestra en la figura 4-20(a).
Supongamos que A envía muchos mensajes o lleva a cabo muchas llamadas a procedimientos remotos de D. Durante el tiempo 0, A inicia y llama de inmediato a D, que por desgracia no se ejecuta en ese momento, puesto que es el turno de C. Después de 100 milisegundos, se alternan los procesos, D obtiene el mensaje de A, lleva a cabo el trabajo y responde con rapidez. Puesto que B está ejecutándose, pasarán otros 100 milisegundos antes de que A obtenga la respuesta y pueda proseguir. El resultado neto es un intercambio de mensajes cada 200 milisegundos.
Lo que se necesita es una forma de garantizar que los procesos con comunicación frecuente se ejecuten de manera simultánea.
Aunque es difícil determinar en forma dinámica los patrones de común entre los procesos, en muchos casos, un grupo de procesos relacionados entre sí iniciarán juntos.
Por ejemplo, en general está bien suponer que los filtros de un entubamiento en UNIX se comunicarán entre sí más de lo qué lo harán con otros procesos ya iniciados.
Supongamos que los procesos se crean en grupos y que la comunicación dentro de los grupos prevalece sobre la comunicación entre los grupos. Supongamos además que se dispone de un número de procesadores lo bastante grande como para manejar al grupo de mayor tamaño y que cada procesador se multiprograma con N espacios para los procesos multiprogramación de nivel N).
Tolerancia a Fallas
La promesa de los sistemas distribuidos sólo se puede cumplir cuando a la base hardware adecuado se le añaden políticas y mecanismos tolerantes a fallas. El objetivo del diseño y construcción de sistemas tolerantes a fallas consiste en garantizar que el sistema continúe funcionando de manera correcta como un todo, incluso en presencia de fallas.
Se dice que un sistema falla cuando no cumple su especificación. En algunos casos, como en un sistema de ordenamiento distribuido de productos en un supermercado, una falla podría provocar la falta de algunos productos en la tienda. En otros casos, como en un sistema distribuido para el control de tráfico aéreo, una falla podría ser catastrófica. Como las computadoras y los sistemas distribuidos se utilizan cada vez más en misiones donde la seguridad es crítica, la necesidad de soportar las fallas cada vez es mayor.
Un sistema consiste de un conjunto de componentes de hardware y software y son diseñados para proveer un servicio específico. Los componentes de un sistema pueden estar interrelacionados entre ellos. Un desperfecto de un sistema ocurre cuando el sistema no desempeña estos servicios de la manera especificada. Un estado erróneo en un sistema es un estado en el cual podría conducir a un fallo en el sistema. Un fallo es una condición física anormal, las causas de un fallo incluyen: errores de diseño (como errores en la especificación del sistema o en la implementación), problemas de fabricación, deterioro por el uso u otros problemas externos (como condiciones ambientales adversas, interferencia electromagnética, entradas imprevistas o el mal uso del sistema). Un error es una parte del estado del sistema la cual difiere de los valores esperados.
Un error del sistema puede ser visto como una manifestación de mal funcionamiento del sistema, el cual podría conducir a un fallo del sistema. Es necesario entonces, que el sistema sea capaz de recuperarse de las fallas, necesitamos deshacernos del estado de error del sistema, en otras palabras, la recuperación de un fallo, es un proceso que involucra la restauración de un estado erróneo a un estado libre de error.
Se dice que un sistema falla cuando no cumple su especificación. En algunos casos, como en un sistema de ordenamiento distribuido de productos en un supermercado, una falla podría provocar la falta de algunos productos en la tienda. En otros casos, como en un sistema distribuido para el control de tráfico aéreo, una falla podría ser catastrófica. Como las computadoras y los sistemas distribuidos se utilizan cada vez más en misiones donde la seguridad es crítica, la necesidad de soportar las fallas cada vez es mayor.
Un sistema consiste de un conjunto de componentes de hardware y software y son diseñados para proveer un servicio específico. Los componentes de un sistema pueden estar interrelacionados entre ellos. Un desperfecto de un sistema ocurre cuando el sistema no desempeña estos servicios de la manera especificada. Un estado erróneo en un sistema es un estado en el cual podría conducir a un fallo en el sistema. Un fallo es una condición física anormal, las causas de un fallo incluyen: errores de diseño (como errores en la especificación del sistema o en la implementación), problemas de fabricación, deterioro por el uso u otros problemas externos (como condiciones ambientales adversas, interferencia electromagnética, entradas imprevistas o el mal uso del sistema). Un error es una parte del estado del sistema la cual difiere de los valores esperados.
Un error del sistema puede ser visto como una manifestación de mal funcionamiento del sistema, el cual podría conducir a un fallo del sistema. Es necesario entonces, que el sistema sea capaz de recuperarse de las fallas, necesitamos deshacernos del estado de error del sistema, en otras palabras, la recuperación de un fallo, es un proceso que involucra la restauración de un estado erróneo a un estado libre de error.
Transacciones, Definición
Una transacción es una colección de acciones que hacen transformaciones consistentes de los estados de un sistema preservando la consistencia del sistema. Una base de datos está en un estado consistente si obedece todas las restricciones de integridad definidas sobre ella. Los cambios de estado ocurren debido a actualizaciones, inserciones, y supresiones de información. Por supuesto, se quiere asegurar que la base de datos nunca entra en un estado de inconsistencia. Sin embargo, durante la ejecución de una transacción, la base de datos puede estar temporalmente en un estado inconsistente. El punto importante aquí es asegurar que la base de datos regresa a un estado consistente al fin de la ejecución de una transacción
Lo que se persigue con el manejo de transacciones es por un lado tener una transparencia adecuada de las acciones concurrentes a una base de datos y por otro lado tener una transparencia adecuada en el manejo de las fallas que se pueden presentar en una base de datos.
Lo que se persigue con el manejo de transacciones es por un lado tener una transparencia adecuada de las acciones concurrentes a una base de datos y por otro lado tener una transparencia adecuada en el manejo de las fallas que se pueden presentar en una base de datos.
Aspectos relacionados al procesamiento de transacciones
Los siguientes son los aspectos más importantes relacionados con el procesamiento de transacciones:
1. Modelo de estructura de transacciones. Es importante considerar si las transacciones son planas o pueden estar anidadas.
2. Consistencia de la base de datos interna. Los algoritmos de control de datos semántico tienen que satisfacer siempre las restricciones de integridad cuando una transacción pretende hacer un commit.
3. Protocolos de confiabilidad. En transacciones distribuidas es necesario introducir medios de comunicación entre los diferentes nodos de una red para garantizar la atomicidad y durabilidad de las transacciones. Así también, se requieren protocolos para la recuperación local y para efectuar los compromisos (commit) globales.
4. Algoritmos de control de concurrencia. Los algoritmos de control de concurrencia deben sincronizar la ejecución de transacciones concurrentes bajo el criterio de correctitud. La consistencia entre transacciones se garantiza mediante el aislamiento de las mismas.
5. Protocolos de control de réplicas. El control de réplicas se refiere a cómo garantizar la consistencia mutua de datos replicados. Por ejemplo se puede seguir la estrategia read-one-write-all (ROWA).
1. Modelo de estructura de transacciones. Es importante considerar si las transacciones son planas o pueden estar anidadas.
2. Consistencia de la base de datos interna. Los algoritmos de control de datos semántico tienen que satisfacer siempre las restricciones de integridad cuando una transacción pretende hacer un commit.
3. Protocolos de confiabilidad. En transacciones distribuidas es necesario introducir medios de comunicación entre los diferentes nodos de una red para garantizar la atomicidad y durabilidad de las transacciones. Así también, se requieren protocolos para la recuperación local y para efectuar los compromisos (commit) globales.
4. Algoritmos de control de concurrencia. Los algoritmos de control de concurrencia deben sincronizar la ejecución de transacciones concurrentes bajo el criterio de correctitud. La consistencia entre transacciones se garantiza mediante el aislamiento de las mismas.
5. Protocolos de control de réplicas. El control de réplicas se refiere a cómo garantizar la consistencia mutua de datos replicados. Por ejemplo se puede seguir la estrategia read-one-write-all (ROWA).
Utilización de las Transacciones
Las transacciones distribuidas abarcan dos o más servidores conocidos como administradores de recursos. La administración de la transacción debe ser coordinada entre los administradores de recursos mediante un componente de servidor llamado administrador de transacciones. Cada instancia de SQL Server Database Engine (Motor de base de datos de SQL Server) puede funcionar como administrador de recursos en las transacciones distribuidas que coordinan los administradores de transacciones, como el Coordinador de transacciones distribuidas de Microsoft (MS DTC) u otros administradores que admitan la especificación Open Group XA del procesamiento de transacciones distribuidas. Para obtener más información, consulte la documentación de MS DTC.
Una transacción de una sola instancia de Database Engine (Motor de base de datos) que abarque dos o más bases de datos es, de hecho, una transacción distribuida. La instancia administra la transacción distribuida internamente; para el usuario funciona como una transacción local.
En la aplicación, una transacción distribuida se administra de forma muy parecida a una transacción local. Al final de la transacción, la aplicación pide que se confirme o se revierta la transacción. El administrador de transacciones debe administrar una confirmación distribuida de forma diferente para reducir al mínimo el riesgo de que, si se produce un error en la red, algunos administradores de recursos realicen confirmaciones mientras los demás revierten la transacción. Esto se consigue mediante la administración del proceso de confirmación en dos fases (la fase de preparación y la fase de confirmación), que se conoce como confirmación en dos fases (2PC).
Fase de preparación
Cuando el administrador de transacciones recibe una solicitud de confirmación, envía un comando de preparación a todos los administradores de recursos implicados en la transacción. Cada administrador de recursos hace lo necesario para que la transacción sea duradera y todos los búferes que contienen imágenes del registro de la transacción se pasan a disco. A medida que cada administrador de recursos completa la fase de preparación, notifica si la preparación ha tenido éxito o no al administrador de transacciones.
Fase de confirmación
Si el administrador de transacciones recibe la notificación de que todas las preparaciones son correctas por parte de todos los administradores de recursos, envía comandos de confirmación a cada administrador de recursos. A continuación, los administradores de recursos pueden completar la confirmación. Si todos los administradores de recursos indican que la confirmación ha sido correcta, el administrador de transacciones envía una notificación de éxito a la aplicación. Si algún administrador de recursos informó de un error al realizar la preparación, el administrador de transacciones envía un comando para revertir la transacción a cada administrador de recursos e indica a la aplicación que se ha producido un error de confirmación.
Las aplicaciones de Database Engine (Motor de base de datos) pueden administrar transacciones distribuidas a través de Transact-SQL o de la API de base de datos.
Una transacción de una sola instancia de Database Engine (Motor de base de datos) que abarque dos o más bases de datos es, de hecho, una transacción distribuida. La instancia administra la transacción distribuida internamente; para el usuario funciona como una transacción local.
En la aplicación, una transacción distribuida se administra de forma muy parecida a una transacción local. Al final de la transacción, la aplicación pide que se confirme o se revierta la transacción. El administrador de transacciones debe administrar una confirmación distribuida de forma diferente para reducir al mínimo el riesgo de que, si se produce un error en la red, algunos administradores de recursos realicen confirmaciones mientras los demás revierten la transacción. Esto se consigue mediante la administración del proceso de confirmación en dos fases (la fase de preparación y la fase de confirmación), que se conoce como confirmación en dos fases (2PC).
Fase de preparación
Cuando el administrador de transacciones recibe una solicitud de confirmación, envía un comando de preparación a todos los administradores de recursos implicados en la transacción. Cada administrador de recursos hace lo necesario para que la transacción sea duradera y todos los búferes que contienen imágenes del registro de la transacción se pasan a disco. A medida que cada administrador de recursos completa la fase de preparación, notifica si la preparación ha tenido éxito o no al administrador de transacciones.
Fase de confirmación
Si el administrador de transacciones recibe la notificación de que todas las preparaciones son correctas por parte de todos los administradores de recursos, envía comandos de confirmación a cada administrador de recursos. A continuación, los administradores de recursos pueden completar la confirmación. Si todos los administradores de recursos indican que la confirmación ha sido correcta, el administrador de transacciones envía una notificación de éxito a la aplicación. Si algún administrador de recursos informó de un error al realizar la preparación, el administrador de transacciones envía un comando para revertir la transacción a cada administrador de recursos e indica a la aplicación que se ha producido un error de confirmación.
Las aplicaciones de Database Engine (Motor de base de datos) pueden administrar transacciones distribuidas a través de Transact-SQL o de la API de base de datos.
Importancia en la comunicación distribuida
Las transacciones son un mecanismo estándar para manejar los cambios al estado del un sistema distribuido. Proveen un modelo para controlar el acceso concurrente a los datos y para manejar las fallas inherentes al cómputo distribuido. Si se permite que el trabajo que los objetos realizan, progrese concurrentemente sin considerar transacciones, lo único que se obtendrá será un caos total.
Una transacción es generalmente una unidad de trabajo que se hace a nombre de una aplicación o componente. Cada transacción puede estar compuesta de múltiples operaciones realizadas en datos que están dispersos en uno o varios procesos o en una o varias máquinas. Cada transacción asegura el trabajo de proteger la integridad del estado de un sistema al proveer cuatro garantías básicas conocidas como las propiedades ACID: atomicidad (atomicity), consistencia (consistency), aislamiento (isolation) y durabilidad (durability) y que se explican a continuación.
Una transacción tiene que ser atómica lo que significa que es indivisible; todas las operaciones deben ejecutarse o ninguna en lo absoluto. No debe haber posibilidad de que solo una parte se ejecute. En un sistema bancario, por ejemplo, una transferencia de dinero entre dos cuentas de cheques tiene que ser atómica; tomar dinero de una cuenta para agregarlo a otra. No es posible ejecutar una de las operaciones y la otra no. La atomicidad se garantiza a través de mecanismos de base de datos con los que se hace el seguimiento de la transacción. Si la transacción falla por cualquier razón, las actualizaciones que se hayan realizado hasta el momento serán deshechas. Solo si la transacción llega al fin los cambios se volverán parte de la base de datos. La propiedad de atomicidad permite escribir operaciones que emulan transacciones de negocio tales como retiros de cuentas de cheques, reservaciones de vuelo o compra y venta de bonos entre otras. Cada una de estas acciones, requiere actualizar varios datos y al implementarlas acciones en una transacción, se asegura que todas o ninguna de las actualizaciones se realizan. Aún más, la atomicidad garantiza que la base de datos se queda en un estado conocido después de la falla de una transacción lo que reduce el requerimiento de intervención manual. La terminación exitosa de una transacción se conoce como commit mientras que a la falla de una transacción se le conoce como abort.
Consistencia (Consistency). Una transacción mantendrá la consistencia de la base de datos. Esto es, si la base de datos se encuentra en un estado consistente antes de ejecutar la transacción, una vez que ésta termine la consistencia de la base de datos deberá conservarse. Por consistente se debe entender, internamente consistente. En términos de base de datos esto significa que se satisfacen todas las restricciones en cuanto a su integridad que incluyen:
Todos los valores de la llave primaria son únicos.
La base de datos mantiene integridad referencial lo que significa que los registros solo referencian información que existe.
Ciertos predicados se mantienen. Por ejemplo, la suma de los gastos es menor o igual al presupuesto.
A diferencia de la atomicidad, el aislamiento y la durabilidad, la consistencia es una práctica de programación. La atomicidad, el aislamiento y la durabilidad están aseguradas estén o no programadas para preservar la consistencia. Es responsabilidad del desarrollador de la aplicación asegurar que su programa preserva la consistencia.
Aislamiento (Isolation). La tercera propiedad de una transacción es el aislamiento. Se dice que un conjunto de transacciones está aislado si el efecto del sistema que las ejecuta es el mismo que si ejecutara cada una a la vez; las transacciones se ejecutan en secuencia. Tómese, por ejemplo, el caso de un sistema bancario en el que dos transacciones intentaran hacer un retiro de los últimos $200 de una cuenta de cheques. Si se permite que al mismo tiempo, dos transacciones consulten el saldo antes de afectarlo, ambas determinarán que hay fondos suficientes y realizarán el retiro. En cambio, si las transacciones se ejecutan en serie -una detrás de otra-, solo una de las transacciones será capaz de retirar los últimos $200. La siguiente encontrará el saldo de la cuenta en cero. El usuario final tiene la percepción de que su transacción es la única en el sistema. La base de datos típicamente usa técnicas de locking o versioning en los datos que cada transacción accede. El efecto de esto es hacer que la ejecución parezca en serie aunque, internamente, el sistema ejecuta las transacciones en paralelo. Por la importancia y el impacto que tiene el aislamiento (isolation) en la escalabilidad, se le ha dedicado un capítulo completo de este libro.
Durabilidad (Durability). Cuando una transacción termina de ejecutarse, todas sus actualizaciones se graban en algún tipo de medio de almacenamiento, típicamente disco, en donde se asegura que las actualizaciones no se perderán. Aun si el sistema operativo falla, los resultados de la transacción son almacenados en disco y podrán ser encontrados ahí cuando se recupere el sistema operativo. Más aún, la durabilidad a menudo debe mantenerse por un periodo largo. Por ejemplo, por cuestiones de auditoría. La durabilidad se obtiene por medio de un mecanismo que guarda en una bitácora (log) copia de todas las actualizaciones que una transacción realiza. Cuando se ejecuta el commit de la transacción, el sistema se asegura que todos los registros escritos en el log están en disco y entonces informa a la transacción que los resultados son durables. Si después del commit de la transacción y antes de escribirse a la base de datos, el sistema falla, es responsabilidad de éste reparar la base de datos lo que logra por medio de una lectura del log para verificar que se efectuó cada modificación hecha por una transacción committed. De no cumplirse esta condición, entonces vuelve a realizar las actualizaciones. Cuando esta actividad de recuperación se ha terminado, el sistema reanuda su operación normal. Cualquier nueva transacción encontrará un estado en la base de datos que incluye todas las actualizaciones. En resumen, las transacciones garantizan que los cambios al estado de un sistema se aplican atómicamente, dejan al sistema consistente, están aisladas una de otra mientras están en progreso y serán durables aun en casos de una falla catastrófica.
Una transacción es generalmente una unidad de trabajo que se hace a nombre de una aplicación o componente. Cada transacción puede estar compuesta de múltiples operaciones realizadas en datos que están dispersos en uno o varios procesos o en una o varias máquinas. Cada transacción asegura el trabajo de proteger la integridad del estado de un sistema al proveer cuatro garantías básicas conocidas como las propiedades ACID: atomicidad (atomicity), consistencia (consistency), aislamiento (isolation) y durabilidad (durability) y que se explican a continuación.
Una transacción tiene que ser atómica lo que significa que es indivisible; todas las operaciones deben ejecutarse o ninguna en lo absoluto. No debe haber posibilidad de que solo una parte se ejecute. En un sistema bancario, por ejemplo, una transferencia de dinero entre dos cuentas de cheques tiene que ser atómica; tomar dinero de una cuenta para agregarlo a otra. No es posible ejecutar una de las operaciones y la otra no. La atomicidad se garantiza a través de mecanismos de base de datos con los que se hace el seguimiento de la transacción. Si la transacción falla por cualquier razón, las actualizaciones que se hayan realizado hasta el momento serán deshechas. Solo si la transacción llega al fin los cambios se volverán parte de la base de datos. La propiedad de atomicidad permite escribir operaciones que emulan transacciones de negocio tales como retiros de cuentas de cheques, reservaciones de vuelo o compra y venta de bonos entre otras. Cada una de estas acciones, requiere actualizar varios datos y al implementarlas acciones en una transacción, se asegura que todas o ninguna de las actualizaciones se realizan. Aún más, la atomicidad garantiza que la base de datos se queda en un estado conocido después de la falla de una transacción lo que reduce el requerimiento de intervención manual. La terminación exitosa de una transacción se conoce como commit mientras que a la falla de una transacción se le conoce como abort.
Consistencia (Consistency). Una transacción mantendrá la consistencia de la base de datos. Esto es, si la base de datos se encuentra en un estado consistente antes de ejecutar la transacción, una vez que ésta termine la consistencia de la base de datos deberá conservarse. Por consistente se debe entender, internamente consistente. En términos de base de datos esto significa que se satisfacen todas las restricciones en cuanto a su integridad que incluyen:
Todos los valores de la llave primaria son únicos.
La base de datos mantiene integridad referencial lo que significa que los registros solo referencian información que existe.
Ciertos predicados se mantienen. Por ejemplo, la suma de los gastos es menor o igual al presupuesto.
A diferencia de la atomicidad, el aislamiento y la durabilidad, la consistencia es una práctica de programación. La atomicidad, el aislamiento y la durabilidad están aseguradas estén o no programadas para preservar la consistencia. Es responsabilidad del desarrollador de la aplicación asegurar que su programa preserva la consistencia.
Aislamiento (Isolation). La tercera propiedad de una transacción es el aislamiento. Se dice que un conjunto de transacciones está aislado si el efecto del sistema que las ejecuta es el mismo que si ejecutara cada una a la vez; las transacciones se ejecutan en secuencia. Tómese, por ejemplo, el caso de un sistema bancario en el que dos transacciones intentaran hacer un retiro de los últimos $200 de una cuenta de cheques. Si se permite que al mismo tiempo, dos transacciones consulten el saldo antes de afectarlo, ambas determinarán que hay fondos suficientes y realizarán el retiro. En cambio, si las transacciones se ejecutan en serie -una detrás de otra-, solo una de las transacciones será capaz de retirar los últimos $200. La siguiente encontrará el saldo de la cuenta en cero. El usuario final tiene la percepción de que su transacción es la única en el sistema. La base de datos típicamente usa técnicas de locking o versioning en los datos que cada transacción accede. El efecto de esto es hacer que la ejecución parezca en serie aunque, internamente, el sistema ejecuta las transacciones en paralelo. Por la importancia y el impacto que tiene el aislamiento (isolation) en la escalabilidad, se le ha dedicado un capítulo completo de este libro.
Durabilidad (Durability). Cuando una transacción termina de ejecutarse, todas sus actualizaciones se graban en algún tipo de medio de almacenamiento, típicamente disco, en donde se asegura que las actualizaciones no se perderán. Aun si el sistema operativo falla, los resultados de la transacción son almacenados en disco y podrán ser encontrados ahí cuando se recupere el sistema operativo. Más aún, la durabilidad a menudo debe mantenerse por un periodo largo. Por ejemplo, por cuestiones de auditoría. La durabilidad se obtiene por medio de un mecanismo que guarda en una bitácora (log) copia de todas las actualizaciones que una transacción realiza. Cuando se ejecuta el commit de la transacción, el sistema se asegura que todos los registros escritos en el log están en disco y entonces informa a la transacción que los resultados son durables. Si después del commit de la transacción y antes de escribirse a la base de datos, el sistema falla, es responsabilidad de éste reparar la base de datos lo que logra por medio de una lectura del log para verificar que se efectuó cada modificación hecha por una transacción committed. De no cumplirse esta condición, entonces vuelve a realizar las actualizaciones. Cuando esta actividad de recuperación se ha terminado, el sistema reanuda su operación normal. Cualquier nueva transacción encontrará un estado en la base de datos que incluye todas las actualizaciones. En resumen, las transacciones garantizan que los cambios al estado de un sistema se aplican atómicamente, dejan al sistema consistente, están aisladas una de otra mientras están en progreso y serán durables aun en casos de una falla catastrófica.
Suscribirse a:
Entradas (Atom)