4. Ambientes de bases de datos distribuidas
Las BDD pueden ser:
Homogéneas: Todos los sitios tienen el mismo SGBD, son conscientes de la existencia de los demás sitios y cooperan en el procesamiento de las solicitudes. Los sitios locales mantienen un mismo esquema y SGBD.
Heterogéneas: Cada sitio puede tener un SGBD distinto así como esquemas diferentes. Puede que algunos sitios no conozcan a otros. Puede que solo ofrezcan facilidades limitadas para la cooperación en el procesamiento de transacciones.
5. Problemas fundamentales a resolver en las bases de datos distribuidas
Diseño de bases de datos distribuidas
Procesamiento y optimización de consultas
Manejo de transacciones y control de concurrencia
Etapas del diseño
La etapa diferenciadora entre el diseño de una base de datos centralizada y una base de datos distribuidas es el "Diseño de la distribución" que consta de dos actividades :
Fragmentación: Decidir "como" dividimos la BD y en "que" partes .
Asignación: Decidir "donde" ubicamos cada parte, así como si tendremos replicación de datos.
Aspectos a considerar en el diseño de una BD distribuida
Fragmentación: Una relación puede ser dividida en un número de sub-relaciones, denominadas fragmentos, los cuales son entonces distribuidas
Asignación: cada fragmento debe ser almacenado en un sitio en base a una distribución optima.
Replicación: El SGBDD puede mantener una copia de un fragmento en diferentes sitios
6. Fragmentación
El problema de fragmentación se refiere al particionamiento de la información para distribuir cada parte a los diferentes sitios de la red
Objetivos de la fragmentación
El objetivo de la fragmentación consiste en dividir la relación en un conjunto de relaciones más pequeñas tal que algunas de las aplicaciones de usuario sólo hagan uso de un fragmento.
Sobre este marco, una fragmentación óptima es aquella que produce un esquema de división que minimiza el tiempo de ejecución de las aplicaciones que emplean esos fragmentos.
La unidad de fragmentación ideal no es la tabla sino una subdivisión de ésta.
Esto es debido a:
Las aplicaciones usan vistas definidas sobre varias relaciones, es decir, se forman a partir de "trozos" de varias tablas. Si conseguimos que cada una de las vistas esté definida sobre subtablas locales (o en su defecto lo mas "cerca" posible) a cada aplicación, es de esperar un incremento en el rendimiento.
Si múltiples vistas de diferentes aplicaciones están definidas sobre una tabla no fragmentada, se tiene :
Si la tabla no está replicada entonces se produce generación de tráfico por accesos remotos.
Si la tabla está replicada en todos o algunos de los sitios donde residen cada una de las aplicaciones entonces la generación de trafico innecesario es producida por la necesidad de la actualización de las copias.
Ventajas
Al descomponer una relación en fragmentos (unidades de distribución) :
Permitimos el procesamiento concurrente de transacciones ya que no se bloquean tablas enteras sino subtablas, por lo que dos consultas pueden acceder a la misma tabla a fragmentos distintos.
Permitimos la paralelización de consultas al poder descomponerlas en subconsultas, cada una de la cuales trabajará con un fragmento diferente incrementándose así el rendimiento.
Desventajas
Degradación del rendimiento en vistas definidas sobre varios fragmentos ubicados en sitios distintos (es necesario realizar operaciones con esos trozos lo cual es costoso)
El control semántico se dificulta y el rendimiento se degrada debido que la verificación de restricciones de integridad (claves ajenas, uniques, etc) implican buscar fragmentos en múltiples localizaciones.
Por lo tanto división y ubicación de los fragmentos no es trivial.
Tipos de fragmentación de datos
Existen tres tipos de fragmentación:
Fragmentación horizontal
Fragmentación vertical
Fragmentación híbrida
Para que una la fragmentación de una relación sea correcta debe satisfacer las siguientes condiciones:
Condición de completitud.
La descomposición de una relación R en los fragmentos R1, R2, …, Rn es completa si y solamente si cada elemento de datos en R se encuentra en alguno de los fragmentos Ri.
Condición de Reconstrucción.
La descomposición de una relación R en los fragmentos R1, R2, …, Rn es completa si y solamente si cada elemento de datos en R se encuentra en alguno de los fragmentos Ri.
Condición de Fragmentos Disjuntos.
Si la relación R se descompone en los fragmentos R1, R2, …, Rn, y el dato di está en Rj, entonces, no debe estar en ningún otro fragmento Rk (k?j).
Fragmentación horizontal
La fragmentación horizontal de una relación R produce una serie de fragmentos R1, R2, …, Rr, cada uno de los cuales contiene un subconjunto de las tuplas de R que cumplen determinadas propiedades (predicados)
Fragmentación horizontal primaria y derivada
La Fragmentación Horizontal Primaria (FHP) de una relación se obtiene usando predicados que están definidos en esa relación.
La Fragmentación Horizontal Derivada (FHD) por otra parte, es el particionamiento de una relación como resultado de predicados que se definen en otra relación.
Fragmentación vertical
La fragmentación vertical de una relación R produce una serie de fragmentos R1, R2, …, Rr cada uno de los cuales contiene un subconjunto de los atributos de R así como la clave primaria de R.
Complejidad de la fragmentación Vertical
La fragmentación vertical resulta más complicada que la horizontal. En el caso vertical, si una relación tiene m atributos clave no primarios, el número de posibles fragmentos es igual a B(m), es decir el m-ésimo número de Bell [3]. Para valores grandes de m, B(m)(mm; por ejemplo, para m = 10, B(m) ( 115.000, para m = 15, B(m) ( 109, para m = 30, B(m) = 1023.
Estos valores indican que la obtención de una solución óptima de la fragmentación vertical resultará una tarea imposible, sino nos apoyamos en el uso de heurísticas.
El problema de la asignación de fragmentos
Asumamos que hay un conjunto de fragmentos F = { F1, F2, …, Fn } y una red que consiste de los sitios S = { S1, S2, …, Sm } en los cuales un conjunto Q = { q1, q2, …, qq } de consultas se van a ejecutar.
El problema de asignación consiste en determinar la distribución "óptima" de F en S.
La optimalidad puede ser definida de acuerdo a dos medidas:
Costo mínimo. Consiste del costo de comunicación de datos, del costo de almacenamiento, y del costo procesamiento (lecturas y actualizaciones a cada fragmento). El problema de la asignación, es encontrar un esquema de asignación o ubicación que minimiza la función de costo combinada.
Rendimiento: La estrategia de asignación se diseña para mantener una métrica de rendimiento. Las dos métricas más utilizadas son el tiempo de respuesta y el "throughput" (número de trabajos procesados por unidad de tiempo).
Asignación de fragmentos
Asignación
Proceso mediante el cual se decide donde se ubicaran los fragmentos de la etapa anterior y si se harán replicas de los mismos.
Hacer replicas tiene sentido por :
Confiabilidad : Mayor seguridad ante perdida de datos
Disponibilidad : Mayor tolerancia a fallos ante caídas de los computadores
Aumento del paralelismo : Mayor eficiencia en las consultas de lectura al posibilitarse su descomposición en subconsultas y la paralelización de éstas.
Pero presenta el inconvenientes de las consultas de escritura, que conllevan las actualización de todas las copias de la red.
En la práctica : Sopesar lecturas vs escrituras
Mas lecturas que escrituras : Replicación es buena idea
Mas escrituras que lecturas : No replicamos.
Según el grado de replicación, distinguimos entre :
BD fragmentada : Fragmentos disjuntos, cada uno en un nodo (no hay replicas)
BD totalmente replicada : Se encuentra una copia de toda la BD en cada nodo
BD parcialmente replicada : Mezcla las anteriores. Algunos fragmentos están replicados.
Como se ve las técnicas de fragmentación y replicación se combinan en la práctica.
Replicación de fragmentos
El problema de la replicación de segmentos asignación consiste en la determinación de que fragmentos se replicarán en diferentes sitios a pesar de los problemas que acarrea la actualización.
7. Las 12 reglas de un SGBDD
El principio fundamental de las Bases de Datos Distribuidas o regla cero plantea que:
"Desde el punto de vista del usuario, un sistema distribuido deberá ser idéntico a un sistema no distribuido"
La regla cero conduce a las restantes 12 reglas.
Todas las reglas no son independientes entre sí, ni tienen igual importancia pero son útiles para entender la tecnología distribuida.
1. Autonomía Local: Los sitios de un sistema distribuido deben ser autónomos.
La autonomía Local Implica:
Propietario local.
Administración local.
Responsabilidad local.
Integración local.
Representación local.
2. No dependencia de un sitio central
No debe existir un único sitio, ya que implicaría:
Cuello de botella.
Vulnerabilidad.
3. Operación continua
Adición de elementos
Actualización de versiones
4. Independencia de Localización
El usuario desconoce dónde están físicamente los datos.
5. Independencia de fragmentación.
Deseable porque simplifica los programas de los usuarios y sus actividades en la terminal
6. Independencia de réplica
La creación y destrucción de réplicas debe hacerse transparente al usuario.
La réplica proporciona:
Ventajas:
Mayor Prestación: los datos son locales.
Mayor disponibilidad: los datos son accesibles siempre.
Desventajas
Hay que propagar las actualizaciones.
7. Procesamiento distribuido de consultas
Los Sistemas relacionales brindan herramientas de consulta muy eficientes.
Varias maneras de trasladar los datos
6. Manejo distribuido de transacciones
Transacción distribuida: varios agentes de la transacción en varios lugares.
Control de recuperación: una transacción atómica. Todos los agentes avanzan o retroceden juntos.
Control de concurrencia: Bloqueos mediante paso de mensajes.
8. Independencia con respecto al equipo
El SGBD se ejecutará igual sea cual sea el equipo
10. Independencia con respecto al Sistema Operativo
El SGBD debe ser multioperativo sin afectar al usuario.
11. Independencia con respecto a la Red
El SGBD debe soportar múltiples redes sin afectar al usuario.
12. Independencia con respecto al SGBD
Se pueden manejar distintas copias de SGBD si manejan la misma norma estándar de SQL: Oracle, Informix, Multibase, etc.
8. Conclusiones
Las bases de datos distribuidas son cada vez más usadas por las empresas y suponen una ventaja competitiva frente a los sistemas centralizados, siempre y cuando la empresa en cuestión tenga necesidad de usar una base de datos de este tipo. Lo más habitual es disponer de varias sedes y tener que manejar información común, para lo cual las bases de datos distribuidas son especialmente útiles.
9. BIBLIOGRAFÍA
Bray, O.H "Distributed Database Management", Second Edition, 1982
M. Tamer Ozsus, Patric Valduriez Principles of distributed database systems, Second Edition, 1999
Ceri, S., Pelagatti, G. Distributed Database, Principles and Systems. McGraw-Hill, New York, 1984.
Ceri, S., Pernici, B., Wiederhold, G. Distributed Database Design Methodologies. Proceedings of the IEEE, Vol. 75, No. 5, May 1987.
Meghini, C., Thanos, C. The Complexity of Operation on a Fragmented Relation. ACM Transaction on Database Systems, Vol. 16, No. 1, March 1991.
Sitio Web: www.cs.valberta.ca/~database/distrib.html
Autor:
Vivian Romero Buchilla
| Página siguiente |