Disponibilidad y Coste en Bases de Datos Distribuidas Replicadas
Explica cómo afecta la disponibilidad de los datos en una base de datos distribuida replicada y cómo afecta al coste del sistema.
Replicada: El esquema de BDD de replicación consiste en que cada nodo debe tener su copia completa de la base de datos. Es fácil ver que este esquema tiene un alto costo en el almacenamiento de la información. Debido a que la actualización de los datos debe ser realizada en todas las copias, también tiene un alto costo de escritura. Pero todo esto vale la pena si tenemos un sistema en el que se va a escribir pocas veces y leer muchas, y dónde la disponibilidad y fiabilidad de los datos sea de máxima importancia. Con este sistema, si un nodo se cae, podemos seguir accediendo a la BDD porque todos tienen una copia de la base de datos.
Cuanta más disponibilidad tenga una base de datos, significa que tiene que estar activa durante un periodo de tiempo, y eso implica que el coste sea más alto, ya que la tenemos que mantener disponible durante todo ese tiempo. Por ejemplo, en el caso de las bases de datos distribuidas replicadas, la disponibilidad es muy alta, pero el coste de escritura es muy elevado.
Mecanismos de Control de Concurrencia
¿En qué consisten los mecanismos de control de concurrencia?
El control de concurrencia trata con los problemas de aislamiento y consistencia del procesamiento de transacciones. El control de concurrencia distribuido de una DDBMS asegura que la consistencia de la base de datos se mantiene en un ambiente distribuido multiusuario. Si las transacciones son internamente consistentes, la manera más simple de lograr este objetivo es ejecutar cada transacción sola, una después de otra. Sin embargo, esto puede afectar grandemente el desempeño de un DDBMS, dado que el nivel de concurrencia se reduce al mínimo. El nivel de concurrencia, el número de transacciones activas, es probablemente el parámetro más importante en sistemas distribuidos. Por lo tanto, los mecanismos de control de concurrencia buscan encontrar un balance entre el mantenimiento de la consistencia de la base de datos y el mantenimiento de un alto nivel de concurrencia.
Si no se hace un adecuado control de concurrencia, se pueden presentar dos anomalías. En primer lugar, se pueden perder actualizaciones, provocando que los efectos de algunas transacciones no se reflejen en la base de datos. En segundo término, pueden presentarse recuperaciones de información inconsistentes.
Atomicidad Global en Bases de Datos Distribuidas
¿Qué entiendes por el concepto de atomicidad global en una base de datos distribuida? ¿Cuál es el protocolo que permite la atomicidad global?
En bases de datos, se denomina ACID a un conjunto de características necesarias para que una serie de instrucciones puedan ser consideradas como una transacción. Así pues, si un sistema de gestión de bases de datos es ACID compliant, quiere decir que el mismo cuenta con las funcionalidades necesarias para que sus transacciones tengan las características ACID.
En concreto, ACID es un acrónimo de Atomicity, Consistency, Isolation and Durability: Atomicidad, Consistencia, Aislamiento y Durabilidad en español.
Mensaje de Aborto en Transacciones Distribuidas
¿Qué mensaje envía un nodo subordinado a otro nodo coordinador si la transacción no termina satisfactoriamente?
Abort
Ejemplo de Transacción Distribuida
Cita un ejemplo de transacción distribuida.
Transacción bancaria entre distintas entidades.
Modos de Fallo en Sistemas Distribuidos
Describe los modos de fallo del sistema.
Los sistemas distribuidos pueden sufrir los mismos tipos de fallos que los sistemas centralizados (por ejemplo, errores de software, errores de hardware y fallos de discos).
No obstante, hay más tipos de fallos con los que hay que tratar en los entornos distribuidos. Los tipos básicos de fallos son:
- Fallo de un sitio
- Pérdida de mensajes
- Fallo de un enlace de comunicaciones
- División de la red
La pérdida o deterioro de los mensajes siempre constituye una posibilidad en los sistemas distribuidos. El sistema utiliza protocolos de control de las transmisiones, como TCP/IP, para tratar esos errores. Se puede encontrar información sobre esos protocolos en los libros de texto estándar sobre redes (véanse las notas bibliográficas).
Cálculo del Coste de Consulta con Semi-Join
La gestión de los hoteles de la cadena NH se realiza mediante una base de datos distribuida.
- Los datos de cada una de las salas y sus correspondientes actos se encuentran en los nodos correspondientes a cada uno de los hoteles.
- Los datos de los hoteles se encuentran en un nodo situado en la sede de la cadena de hoteles.
- Desde la sede se quiere consultar la descripción de todos los actos por hotel y sus fechas para cada uno de los hoteles de la cadena.
- Esta cadena de hoteles es internacional y posee 4000 hoteles; el código de hotel ocupa 6 bytes.
- Existen 40000 salas distribuidas por los hoteles y un promedio de 200 actos por sala. La descripción de los actos ocupa 128 bytes y la fecha del acto 6 bytes.
¿Cuál será el coste de esa consulta con la técnica de semi-join?
- Del nodo SEDE hacia los nodos HOTEL: 4.000 hoteles * 6 bytes de código de hotel = 24 * 103 bytes
- De los nodos HOTEL al nodo SEDE: 4 * 104 salas * 200 actos * (128 bytes descripción + 6 bytes fecha + 6 bytes código hotel) = 1.120 * 106 bytes
TOTAL semi-join (S): 24 * 103 + 1.120 * 106 = 1.120.024 * 103 bytes