Estrategias de Proceso de Consultas y Optimización de Consultas Distribuidas//Administración de las Transacciones Distribuidas.

el

Estrategias de Proceso de Consultas  y Optimización de Consultas Distribuidas.

Estrategias de Proceso de Consultas.

El procesamiento de consultas tiene varias etapas a seguir para resolver una consulta SQL, las características del modelo relacional permiten que cada motor de base de datos elija su propia representación que, comúnmente, resulta ser el álgebra relacional. La optimización de consultas es, entonces, una de estas etapas.

Existen distintos métodos para optimizar consultas relacionales, sin embargo el enfoque de optimización basada en costos combinado con heurísticas que permitan reducir el espacio de búsqueda de la solución es el método mayormente utilizado por los motores de base de datos relaciones de la actualidad, en todo caso, independiente del método elegido para optimizar la consulta, la salida de este proceso debe ser un plan de ejecución, el cual comúnmente es representado en su forma de árbol relacional.

Transformaciones equivalentes:

  1. El servidor recibe una petición de un nodo
  2. El servidor es atacado por el acceso concurrente a la base de datos cargada localmente
  3. El servidor muestra un resultado y le da un hilo a cada una de las maquinas nodo de la red local.

Una base de datos es accesada de esta manera la técnica que se utiliza es la de fragmentación de datos que puede ser hibrida, horizontal y vertical.

En esta fragmentación lo que no se quiere es perder la consistencia de los datos, por lo tanto se respetan las formas normales de la base de datos.

Para realizar una transformación en la consulta primero desfragmentamos siguiendo los estandares marcados por las reglas formales y posteriormente realizamos el envio y la maquina que recibe es la que muestra el resultado pertinente para el usuario, de esta se puede producir una copia que sera la equivalente a la original.

La sentencia join en SQL permite combinar registros de dos o más tablas en una base de datos relacional. En el Lenguaje de Consultas Estructurado (SQL), hay tres tipo de JOIN: interno, externo, y cruzado.

En casos especiales una tabla puede unirse a sí misma, produciendo una auto-combinación,SELF-JOIN.

Matemáticamente, JOIN es composición relacional, la operación fundamental en el álgebra relacional, y generalizando es una función de composición.


Optimización de Consultas Distribuidas.

La optimizacion de las consultas distribuidas requiere la evaluacion de una gran cantidad de arboles de consultas, cada uno de los cuales produce los resultados necesarios de una consulta. Esto se debe principalmente a la presencia de una gran cantidad de data fragmentados y replicados. Por tanto, el objetivo es encontrar una solucion optima alen lugar de la mejor solucion.

Los principales problemas para la optimizacion de consultas distribuidas son:

  • Uso optimo de recursos en el sistema distribuido.
  • Negociacion de consultas.
  • Reduccion del espacio de solucion de la consulta.
  • Uso optimo de recursos en el sistema distribuido
Un sistema distribuido tiene varios servidores de bases de data en diferentes sitios para realizar operaciones relacionadas con un solicitud. Estos son los enfoques para un uso optimo de los recursos:
  • Operacion Envio : En la operacion de envio, la operacion se realiza en el sitio donde se almacenan los data y no en el sitio del cliente. . Luego, los resultados se transfieren al sitio del cliente. Esto es apropiado para operaciones donde los operandos estan disponibles en el mismo sitio. Ejemplo: operaciones de seleccion y proyecto.
  • Envio de data - En el envio de data, los fragmentos de data se transfieren al servidor de la base de data, donde se realizan las operaciones. Esto se usa en operaciones donde los operandos se distribuyen en diferentes sitios. Esto tambien es apropiado en sistemas donde los costos de comunicacion son bajos y los procesadores locales son mucho mas lentos que el servidor cliente.
  • Envio hibrido : es una combinacion de envio de data y operaciones. Aqui, los fragmentos de data se transfieren a los procesadores de alta velocidad, donde tiene lugar la operacion. Luego, los resultados se envian al sitio del cliente.


Administración de las Transacciones Distribuidas.

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.

PROPIEDADES DE LAS TRANSACCIONES
La discusión en la sección previa clarifica el concepto de transacción. Sin embargo, aun no se ha dado ninguna justificación para afirmar que las transacciones son unidades de procesamiento consistentes y confiables. Las propiedades de una transacción son las siguientes:

Atomicidad. Se refiere al hecho de que una transacción se trata como una unidad de operación. Por lo tanto, o todas las acciones de la transacción se realizan o ninguna de ellas se lleva a cabo. La atomicidad requiere que si una transacción se interrumpe por una falla, sus resultados parciales deben ser deshechos. La actividad referente a preservar la atomicidad de transacciones en presencia de abortos debido a errores de entrada, sobrecarga del sistema o interbloqueos se le llama recuperación de transacciones. La actividad de asegurar la atomicidad en presencia de caídas del sistema se le llama recuperación de caídas. 
Consistencia. La consistencia de una transacción es simplemente su correctitud. En otras palabras, una transacción es un programa correcto que lleva la base de datos de un estado consistente a otro con la misma característica. Debido a esto, las transacciones no violan las restricciones de integridad de una base de datos. 
Aislamiento. Una transacción en ejecución no puede revelar sus resultados a otras transacciones concurrentes antes de su commit. Más aún, si varias transacciones se ejecutan concurrentemente, los resultados deben ser los mismos que si ellas se hubieran ejecutado de manera secuencial (seriabilidad). 
Durabilidad. Es la propiedad de las transacciones que asegura que una vez que una transacción hace su commit, sus resultados son permanentes y no pueden ser borrados de la base de datos. Por lo tanto, los DBMS aseguran que los resultados de una transacción sobrevivirán a fallas del sistema. Esta propiedad motiva el aspecto de recuperación de bases de datos, el cual trata sobre como recuperar la base de datos a un estado consistente en donde todas las acciones que han hecho un commit queden reflejadas. 
Las transacciones proporcionan una ejecución atómica y confiable en presencia de fallas, una ejecución correcta en presencia de accesos de usuario múltiples y un manejo correcto de réplicas (en el caso de que se soporten).

TIPOS DE TRANSACCIONES
Las transacciones pueden pertenecer a varias clases. Aun cuando los problemas fundamentales son los mismos para las diferentes clases, los algoritmos y técnicas que se usan para tratarlas pueden ser considerablemente diferentes. Las transacciones pueden ser agrupadas a lo largo de las siguientes dimensiones:

Áreas de aplicación. En primer lugar, las transacciones se pueden ejecutar en aplicaciones no distribuidas. Las transacciones que operan en datos distribuidos se les conoce como transacciones distribuidas. Por otro lado, dado que los resultados de una transacción que realiza un commit son durables, la única forma de deshacer los efectos de una transacción con commit es mediante otra transacción. A este tipo de transacciones se les conoce como transacciones compensatorias. Finalmente, en ambientes heterogéneos se presentan transacciones heterogéneas sobre los datos. 
Tiempo de duración. Tomando en cuenta el tiempo que transcurre desde que se inicia una transacción hasta que se realiza un commit o se aborta, las transacciones pueden ser de tipo batch o en línea. Estas se pueden diferencias también como transacciones de corta y larga vida. Las transacciones en línea se caracterizan por tiempos de respuesta muy cortos y por accesar un porción relativamente pequeña de la base de datos. Por otro lado, las transacciones de tipo batch toman tiempos relativamente largos y accesan grandes porciones de la base de datos. 
Estructura. Considerando la estructura que puede tener una transacción se examinan dos aspectos: si una transacción puede contener a su vez subtransacciones o el orden de las acciones de lectura y escritura dentro de una transacción. 

ASPECTOS RELACIONADOS AL PROCESAMIENTO DE TRANSACCIONES
Los siguientes son los aspectos más importantes relacionados con el procesamiento de transacciones:

Modelo de estructura de transacciones. Es importante considerar si las transacciones son planas o pueden estar anidadas. 
  • 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. 
  • 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. 
  • 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. 
  • 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). 

INCORPORACIÓN DEL MANEJADOR DE TRANSACCIONES A LA ARQUITECTURA DE UN SMBD

El monitor de ejecución distribuida consiste de dos módulos: El administrador de transacciones (TM) y el despachador (SC). El administrador de transacciones es responsable de coordinar la ejecución en la base de datos de las operaciones que realiza una aplicación. El despachador, por otra parte, es responsable de implementar un algoritmo específico de control de concurrencia para sincronizar los accesos a la base de datos.

Un tercer componente que participa en el manejo de transacciones distribuidas es el administrador de recuperación local cuya función es implementar procedimientos locales que le permitan a una base de datos local recuperarse a un estado consistente después de una falla.

A continuación un video sobre el tema...



Conclusión.

 Debemos considerar todo este tipo de características para que al momento de que se requiera accesar a la información, la BD no se confunda; o bien, tener un mejor control de ella.


Referencias.

Toda la información se obtuvo de los siguientes links.


Comentarios

Publicar un comentario