Herramientas ‹ Modelos de Base de Datos — WordPress

BASES DE DATOS DISTRIBUIDAS

 Historia

La necesidad de almacenar datos de forma masiva dio paso a la creación de los sistemas de bases de datos. En 1970 Edgar Frank Codd escribió un artículo con nombre: “A Relational Model of Data for Large Shared Data Banks” (“Un modelo relacional para grandes bancos de datos compartidos”). Con este artículo y otras publicaciones, definió el modelo de bases de datos relacionales y reglas para poder evaluar un administrador de bases de datos relacionales.

Originalmente se almacenaba la información de manera centralizada, pero con el paso del tiempo las necesidades aumentaron y esto produjo ciertos inconvenientes que no era posible solucionarlos o volverlos eficientes de la forma centralizada. Estos problemas impulsaron la creación de almacenamiento distribuido, los cuales hoy en día proveen características indispensables en el manejo de información; es decir, la combinación de las redes de comunicación y las bases de datos.

Evolución 

Hay varios factores que han hecho que las bases de datos evolucionen a bases de datos distribuidas. En el mundo de los negocios se ha dado una globalización y a la vez las operaciones de las empresas son cada vez más descentralizadas geográficamente. También el poder de las computadoras personales aumentó y el costo de los Mainframes ya no tenía sentido. Además la necesidad de compartir datos ha hecho que crezca el mercado de las bases de datos distribuidas.

Bases De Datos Distribuidas

Una base de datos distribuida (BDD) es un conjunto de múltiples bases de datos lógicamente relacionadas las cuales se encuentran distribuidas en diferentes espacios lógicos (pej. un servidor corriendo 2 maquinas virtuales) e interconectados por una red de comunicaciones. Dichas BDD tienen la capacidad de realizar procesamiento autónomo, esto permite realizar operaciones locales o distribuidas. Un sistema de Bases de Datos Distribuida (SBDD) es un sistema en el cual múltiples sitios de bases de datos están ligados por un sistema de comunicaciones de tal forma que, un usuario en cualquier sitio puede acceder los datos en cualquier parte de la red exactamente como si estos fueran accedidos de forma local.

Un sistema distribuido de bases de datos se almacena en varias computadoras. Los principales factores que distinguen un SBDD de un sistema centralizado son los siguientes:

  • Hay múltiples computadores, llamados sitios o nodos.
  • Estos sitios deben de estar comunicados por medio de algún tipo de red de comunicaciones para transmitir datos y órdenes entre los sitios.

 

Características de las BDD

 

–          Los datos deben estar físicamente en más de un ordenador (distintas sedes)

–           Las sedes deben estar interconectadas mediante una red (cada sede es un nodo de la red)

–          Los datos han de estar lógicamente integrados (recuperación y actualización) tanto en local como remoto (esquema lógico global y único)

–          En una única operación se puede acceder (recuperar o actualizar) datos que se encuentran en más de una sede (acceso a datos locales o remotos).

–          Todas las acciones que necesiten realizarse sobre más de una sede serán transparentes al usuario (transparencia de distribución para el usuario)

Ventajas de las BDD

 

      Compartimiento de datos. Los usuarios de un nodo son capaces de acceder a los datos de otro nodo. Por ejemplo, desde el Rectorado, se puede consultar los datos de los alumnos de Informática.

      Autonomía. Cada nodo tiene cierto grado de control sobre sus datos, en un sistema centralizado, hay un administrador del sistema responsable de los datos a nivel global. Cada administrador local puede tener un nivel de autonomía local diferente.

      Disponibilidad. Si en un sistema distribuido falla un nodo, los nodos restantes pueden seguir funcionando. Si se duplican los datos en varios nodos, la transacción que necesite un determinado dato puede encontrarlo en cualquiera de los diferentes nodos.

Desventajas de las BDD

 

      Coste de desarrollo del software. La complejidad añadida que es necesaria para mantener la coordinación entre nodos hace que el desarrollo de software sea más costoso.

      Mayor probabilidad de errores. Como los nodos que constituyen el sistema funcionan en paralelo, es más difícil asegurar el funcionamiento correcto de los algoritmos, así como de los procedimientos de recuperación de fallos del sistema.

      Mayor sobrecarga de procesamiento. El intercambio de mensajes y ejecución de algoritmos para el mantenimiento de la coordinación entre nodos supone una sobrecarga que no se da en los sistemas centralizados.

Consideraciones Generales

En un sistema de base de datos distribuida, los datos se almacenan en varios computadores. Los computadores de un sistema distribuido se comunican entre sí a través de diversos medios de comunicación, tales como cables de alta velocidad o líneas telefónicas. No comparten la memoria principal ni el reloj.

Los procesadores de un sistema distribuido pueden variar en cuanto su tamaño y función. Pueden incluir microcomputadores pequeños, estaciones de trabajo y sistemas de computadores grandes de aplicación general. Estos procesadores reciben diferentes nombres, tales como localidades, nodos o computadores.

Un sistema distribuido de bases de datos consiste en un conjunto de localidades, cada uno de las cuales puede participar en la ejecución de transacciones que accedan a datos de una o varias localidades. La diferencia principal entre los sistemas de base de datos centralizados y distribuidos es que, en los primeros, los datos residen en una sola localidad, mientras que, en los últimos, se encuentran en varias localidades.

 

Calendarizador Distribuido

El calendarizador está encargado de ordenar un conjunto de transacciones u operaciones que se deseen realizar sobre una base de datos. Cualquier orden en el que se decidan hacer este conjunto de operaciones se denomina calendarización. Parte del trabajo del calendarizador es realizar estas operaciones de forma que sean serializables y recuperables.

Dos calendarizaciones son serializables (o equivalentes) si:

  • Cada operación de lectura lee valores de los datos que son producidos por la misma operación de escritura en ambas calendarizaciones (es decir son iguales)
  • La operación final de escritura en cada elemento de la data es la misma en ambas calendarizaciones

Tipos de BDD

  1. HETEROGENEA
    Las Bases de datos heterogéneas con un alto grado de autonomía local. Cada nodo en el sistema tiene sus propios usuarios, aplicaciones y datos locales y es el sistema el que trata con ellos directamente y sólo conecta con otros nodos en busca de información que no tiene. Este tipo de base de datos se suele llamar sistema federado o federación. Se ha hecho cada día más popular en las organizaciones, tanto por su escalabilidad, su capacidad de mezclar distintos paquetes software y su reducido coste al añadir nuevos nodos cuando es necesario. A diferencia de los sistemas homogéneos, los sistemas heterogéneos pueden incluir diferentes SGBD en los nodos. Esto los hace atractivos en grandes corporaciones, ya que pueden mantener sus sistemas heredados antiguos (legacy systems) junto con los nuevos sistemas.

DDBMS HETEROGÉNEO

  • Esquema global único.
  • Modelo de datos y lenguaje de consultas común.
  • Esquema integrado.
  • Consultas reales distribuidas.

INTERFAZ HETEROGÉNEA

  • Acceso en línea a una única base de datos
  • No hay integración de bases de datos
  • El acceso usa un modelo de datos; el DBMS, otro

 

  1. SISTEMA HOMOGÉNEO

Las bases de datos distribuidas homogéneas usan el mismo software de SGBD y tienen las mismas aplicaciones en cada nodo. Tienen un esquema común y pueden tener grados diversos de autonomía local. Pueden estar basadas en cualquier SGBD que soporte estas características, pero no puede haber más de un SGBD en el sistema. La autonomía local especifica cómo el sistema funciona desde la perspectiva de los usuarios y programadores. Por ejemplo, podemos tener un sistema con poca o sin autonomía local, donde todas las peticiones se envían a un nodo central, llamado gateway. Desde aquí se asigna al nodo que contiene esa información o aplicación requerida. Esto es lo típico que se ve con los mirrors de sitios web muy populares a los cuales una página central deriva las peticiones de sus usuarios dependiendo de su origen geográfico.

Son Sistemas Donde Se Utiliza Un Mismo SGBDD.

 

Si el proyecto parte de cero, es decir, no hay nada desarrollado, probablemente pueda usarse esta metodología. Digamos que una vez entendido el problema de información, es decir levantamiento de información, de procesos, reglas de juego, etc., podemos diseñas el MER (modelo entidad relación) del sistema.

En la base de datos distribuida surgen las primeras dudas: Donde almacenar el modelo?, en cada sitio?, que almacenamos en un sitio?

Probablemente el esquema deba repartirse entre los sitios, para ello existe el concepto de fragmentación. La fragmentación es la ubicación de una parte de una o varias tablas del modelo en un sitio. El fragmento puede ser horizontal, vertical o mixto.

      Un fragmento vertical, usa la operación de álgebra relacional conocida como proyección.

      Un fragmento horizontal, es generado por la operación del álgebra relacional conocida como selección.

      Un fragmento mixto combina las dos operaciones mencionadas (selección y proyección).

Bloqueos

Un bloqueo en general es cuando una acción que debe ser realizada está esperando a un evento. Para manejar los bloqueos hay distintos acercamientos: prevención, detección, y recuperación. También es necesario considerar factores como que hay sistemas en los que permitir un bloqueo es inaceptable y catastrófico, y sistemas en los que la detección del bloqueo es demasiado costosa.

En el caso específico de las bases de datos distribuidas usar bloqueo de recursos, peticiones para probar, establecer o liberar bloqueos requiere mensajes entre los manejadores de transacciones y el calendarizador. Para esto existen dos formas básicas:

  • Autónoma: cada nodo es responsable por sus propios bloqueos de recursos.

        Una transacción sobre un elemento con n replicas requiere 5n mensajes

        Petición del recurso

        Aprobación de la petición

        Mensaje de la transacción

        Reconocimientos de transacción exitosa

        Peticiones de liberación de recursos

  • Copia Primaria: un nodo primario es responsable para todos los bloqueos de recursos

        Una transacción sobre un elemento con n copias requiere 2n+3 mensajes

        Una petición del recurso

        Una aprobación de la petición

        n mensajes de la transacción

        n reconocimientos de transacción exitosa

        Una petición de liberación de recurso

Podemos definir que dos operaciones entran en conflicto que debe ser resuelto si ambas acceden a la misma data, y una de ellas es de escritura y si fueron realizadas por transacciones distintas.

Concurrencia

El ejemplo más común de un bloqueo mutuo es cuando un recurso A está siendo utilizado por una transacción A que a su vez solicita un recurso B que está siendo utilizado por una transacción B que solicita el recurso A. Entre los ejemplos específicos para las bases de datos distribuidas podemos destacar:

  • Actualización perdida: cuando dos transacciones concurrentes borran el efecto una de la otra
  • La extracción inconsistente: acceder a información modificada parcialmente por una transacción

 

Estructura de Base de Datos Distribuidas

Un sistema distribuido de base de datos consiste en un conjunto de localidades, cada una de las cuales mantiene un sistema de base de datos local. Cada localidad puede procesar transacciones locales, o bien transacciones globales entre varias localidades, requiriendo para ello comunicación entre ellas.

Las localidades pueden conectarse físicamente de diversas formas, las principales son:

      Red totalmente conectada

      Red prácticamente conectada

      Red con estructura de árbol

      Red de estrella

      Red de anillo

Las diferencias principales entre estas configuraciones son:

      Coste de instalación: El coste de conectar físicamente las localidades del sistema

      Coste de comunicación: El coste en tiempo y dinero que implica enviar un mensaje desde la localidad A a la B.

      Fiabilidad: La frecuencia con que falla una línea de comunicación o una localidad.

      Disponibilidad: La posibilidad de acceder a información a pesar de fallos en algunas localidades o líneas de comunicación.

Las localidades pueden estar dispersas, ya sea por un área geográfica extensa (a lo largo de un país), llamadas redes de larga distancia; o en un área reducida (en un mismo edificio), llamadas redes de área local. Para las primeras se utilizan en la comunicación líneas telefónicas,  conexiones de microondas y canales de satélites; mientras que para las segundas se utiliza cables coaxiales de banda base o banda ancha y fibra óptica.

Componentes de las BDD

HARDWARE INVOLUCRADO

El hardware utilizado no difiere mucho del hardware utilizado en un servidor normal. Al principio se creía que si los componentes de una base de datos eran especializados serían más eficientes y rápidos, pero se comprobó que el descentralizar todo y adoptar un enfoque “nada compartido” (shared-nothing) resultaba más barato y eficaz. Por lo que el hardware que compone una base de datos distribuida se reduce a servidores y la red.

SOFTWARE

1.      Sistema Manejador de Base de Datos Distribuida (DDBMS): Este sistema está formado por las transacciones y los administradores de la base de datos distribuidos. Un DDBMS implica un conjunto de programas que operan en diversas computadoras, estos programas pueden ser subsistemas de un único DDBMS de un fabricante o podría consistir de una colección de programas de diferentes fuentes.

2.      Sistema Manejador de base de datos (DBMS): Es un programa que procesa cierta porción de la base de datos distribuida. Se encarga de recuperar y actualizar datos del usuario y generales de acuerdo con los comandos recibidos de los DTM.

3.      Nodo: Un nodo es una computadora que ejecuta un DTM o un DBM o ambos. Un nodo de transacción ejecuta un DTM y un nodo de base de datos ejecuta un DBM.

4.      Administrador de transacciones distribuidas (DTM): Este es un programa que recibe las solicitudes de procesamiento de los programas de consulta o transacciones y las traduce en acciones para los administradores de la base de datos. Los DTM se encargan de coordinar y controlar estas acciones. Este DTM puede ser propietario o desarrollado en casa.

 

Transacciones

Una transacción es una secuencia de una o más operaciones agrupadas como una unidad. El inicio y el final de la transacción definen los puntos de consistencia de la base de datos. Si una acción de la transacción no se puede ejecutar, entonces ninguna acción dentro de la secuencia que conforma la transacción tendrá efecto.

Propiedades de las transacciones
  • Atomicidad: Una transacción es una unidad atómica de procesamiento, esta se realiza o no se realiza.
  • Consistencia: Si se ejecuta una transacción sobre un estado consistente, el resultado será un nuevo estado consistente.
  • Aislamiento: Una transacción no hara visibles sus modificaciones a otras transacciones hasta que termine de ejecutarse completamente. Es decir, una transacción desconoce si otras transacciones se estén ejecutando en el sistema.
  • Durabilidad: Una vez una transacción se ejecuta exitosamente y realiza cambios sobre el sistema, estos cambios nunca se deben perder a causa de fallas en el sistema.
Tipos de transacciones

Una transacción puede clasificarse de diferentes maneras dependiendo básicamente de tres criterios:

  1. Á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.
  2. 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 diferenciar también como transacciones de corta y larga vida. Las transacciones en línea se caracterizan por tiempos de respuesta muy cortos y por acceder un porción relativamente pequeña de la base de datos. Por otro lado, las transacciones de tipo batch toman tiempos relativamente largos y accedan grandes porciones de la base de datos.
  3. Estructura. Considerando la estructura que puede tener una transacción se examinan dos aspectos: si una transacción puede contener a su vez sub transacciones o el orden de las acciones de lectura y escritura dentro de una transacción.

Función del manejador de transacciones

El manejador de transacciones es el encargado de definir la estructura de las transacciones, mantener la consistencia en la base de datos cuando se ejecuta una transacción o se cancela la ejecución de una, mantener protocolos de fiabilidad, implementar algoritmos para el control de la concurrencia y sincronizar las transacciones que se ejecutan simultáneamente.

El manejador recibe solicitudes de procesamiento de transacciones y las traduce en acciones para el calendarizador.

La operación COMMIT señala el término exitoso de la transacción: le dice al manejador de transacciones que se ha finalizado con éxito una unidad lógica de trabajo, que la base de datos esta (o debería estar) de nuevo en un estado consistente, y que se pueden hacer permanentes todas las modificaciones efectuadas por esa unidad de trabajo.

La operación ROLLBACK, en cambio, señala el término no exitoso de la transacción: le dice al manejador de transacciones que algo salió mal, que la base de datos podría estar en un estado inconsistente y que todas las modificaciones efectuadas hasta el momento por la unidad lógica de trabajo deben retroceder o anularse.

 

Distribución de los Datos

Una de las decisiones más importantes que el diseñador de bases de datos distribuidas debe tomar es el posicionamiento de la data en el sistema y el esquema bajo el cuál lo desea hacer. Para esto existen cuatro alternativas principales: centralizada, replicada, fragmentada, e híbrida. La forma centralizada es muy similar al modelo de Cliente/Servidor en el sentido que la BDD está centralizada en un lugar y los usuarios están distribuidos. Este modelo solo brinda la ventaja de tener el procesamiento distribuido ya que en sentido de disponibilidad y fiabilidad de los datos no se gana nada.

Replicadas

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.

Particionadas

Este modelo consiste en que solo hay una copia de cada elemento, pero la información está distribuida a través de los nodos. En cada nodo se aloja uno o más fragmentos disjuntos de la base de datos. Como los fragmentos no se replican esto disminuye el costo de almacenamiento, pero también sacrifica la disponibilidad y fiabilidad de los datos. Algo que se debe tomar en cuenta cuando se desea implementar este modelo es la granularidad de la fragmentación. La fragmentación se puede realizar también de tres formas:

  • Horizontal: Los fragmentos son subconjuntos de una tabla (análogo a un restringir)
  • Vertical: Los fragmentos son subconjuntos de los atributos con sus valores (análogo a un proyectar)
  • Mixto: Se almacenan fragmentos producto de restringir y proyectar una tabla.

Una ventaja significativa de este esquema es que las consultas (SQL) también se fragmentan por lo que su procesamiento es en paralelo y más eficiente, pero también se sacrifica con casos especiales como usar JUNTAR o PRODUCTO, en general casos que involucren varios fragmentos de la BDD.

Para que una fragmentación sea correcta esta debe cumplir con las siguientes reglas:

  • Debe ser Completa: Si una relación R se fragmenta en R1,R2, … , Rn, cada elemento de la data de R debe estar en algún Ri.
  • Debe ser Reconstruible: Debe ser posible definir una operación relacional que a partir de los fragmentos obtenga la relación.
  • Los fragmentos deben ser Disjuntos: Si la fragmentación es horizontal entonces si un elemento e está en Ri este elemento no puede estar en ningún Rk (para k distinto a i). En el caso de fragmentación vertical es necesario que se repitan las llaves primarias y esta condición solo se debe cumplir para el conjunto de atributos que no son llave primaria.

Híbrida

Este esquema simplemente representa la combinación del esquema de partición y replicación. Se particiona la relación y a la vez los fragmentos están selectivamente replicados a través del sistema de BDD.

Tipos de arquitecturas / Implementaciones

En un sistema de bases de datos distribuidas, existen varios factores que deben tomar en consideración que definen la arquitectura del sistema:

  1. Distribución: Los componentes del sistema están localizados en la misma computadora o no.
  2. Heterogeneidad: Un sistema es heterogéneo cuando existen en él componentes que se ejecutan en diversos sistemas operativos, de diferentes fuentes, etc.
  3. Autonomía: Se puede presentar en diferentes niveles, los cuales se describen a continuación:

      Autonomía de diseño: Habilidad de un componente del sistema para decidir cuestiones relacionadas a su propio diseño.

      Autonomía de comunicación: Habilidad de un componente del sistema para decidir como y cuando comunicarse con otros SGBD (Sistema Gestor de Bases de Datos).

      Autonomía de ejecución: Habilidad de un componente del sistema para ejecutar operaciones locales como quiera.

Multi Base de Datos Distribuida

Cuando una base de datos distribuida es muy homogénea se dice que es multi base de datos distribuida.

Base de Datos Federada

Cuando una base de datos distribuida tiene mucha autonomía local se dice que es federada.

Objetivos de Implementación

Al implementar una base de datos distribuida se tienen ciertos objetivos comunes:

  • Transparencia de ubicación. Permite a los usuarios tener acceso a los datos sin que tenga conocimiento de la ubicación de éstos. Se puede conseguir este nivel de transparencia al utilizar los administradores de transacciones distribuidas, los cuales son capaces de determinar la localización de los datos y de emitir acciones a los calendarizadores apropiados, lo cual puede ejecutarse cuando los administradores de transacciones distribuidas poseen acceso a los directorios de localizaciones de los datos.
  • Transparencia de duplicación. Para que la transparencia de duplicación sea posible, los administradores de transacciones deben traducir las solicitudes de procesamiento de transacción en acciones para el administrador de datos. Para las lecturas el administrador de transacciones selecciona uno de los nodos que almacena los datos y ejecuta la lectura. Para optimizar el proceso, el administrador de transacciones necesita información sobre el rendimiento de varios nodos respecto al sitio de consulta, así podrá seleccionar el nodo de mejor rendimiento. La actualización y escritura de datos duplicados suelen ser más complicadas, ya que el manejador de transacciones debe emitir una acción de escritura para cada uno de los calendarizadores que almacena una copia de los datos.
  • Transparencia de concurrencia. Cuando varias transacciones se ejecuten al mismo tiempo, los resultados de las transacciones no deberán afectarse. La trasparencia de concurrencia se logra si los resultados de todas las transacciones concurrentes son consistentes de manera lógica con los resultados que se habrían obtenido si las transacciones se hubieran ejecutado una por una, en cualquier orden secuencial.
  • Transparencia de fallas. Significa que a pesar de fallas las transacciones sean procesadas de un modo correcto. Frente a una falla, las transacciones deben ser atómicas, significa que se procesen todas o ninguna de ellas. Para este tipo de problemas es importante tener resguardo de la base de datos, y así poder restaurarla cuando sea conveniente. El sistema debe detectar cuándo falla una localidad y tomar las medidas necesarias para recuperarse del fallo. El sistema no debe seguir utilizando la localidad que falló. Por último, cuando se recupere o repare esta localidad, debe contarse con mecanismos para reintegrarla al sistema con el mínimo de complicaciones.
  • Localidad del procesamiento. Los datos se deben distribuir lo más cerca posible de las aplicaciones que los usan para maximizar la localidad del procesamiento, este principio responde a minimizar el acceso remoto a los datos. Diseñar una distribución que maximice localidad del procesamiento puede hacerse añadiendo la cantidad de referencias locales y remotas correspondientes a cada fragmentación candidata y asignar la fragmentación eligiendo la mejor solución. Independencia de configuración. La independencia de configuración permite añadir o reemplazar hardware sin tener que cambiar componentes de software existentes en el sistema de base de datos distribuida.
  • Particionado de la Base de Datos. La base de datos se distribuye de modo que no haya solapamiento o duplicación de los datos mantenidos en las diferentes localidades, como no hay duplicaciones de los datos, se evitan los costos asociados con el almacenamiento y mantenimiento de datos redundantes. Si un mismo segmento de datos se usa en más de una localidad se ve limitada la disponibilidad de los datos. La fiabilidad también puede verse limitada cuando se produce un fallo en el sistema de cálculo de una localidad se afecta la disponibilidad de los datos de esa localidad no estén disponible para los usuarios en cualquier parte del sistema.
  • Fragmentación de datos. Consiste en subdividir las relaciones y distribuirlas entre los sitios de la red, tiene como objetivo buscar formas alternativas de dividir una las instancias (tablas) de relaciones en otras más pequeñas. La fragmentación se puede realizar por tuplas individuales (fragmentación horizontal), por atributos individuales fragmentación vertical) o una combinación de ambas (fragmentación híbrida). El principal problema de la fragmentación radica en encontrar la unidad apropiada de distribución. Una relación no es una buena unidad por muchas razones. Normalmente las vistas de una relación están formadas por subconjuntos de relaciones. Además, las aplicaciones acceden localmente a subconjuntos de relaciones. Por ello, es necesario considerar a los subconjuntos de relaciones como unidad de distribución. Al descomponer de una relación en fragmentos, tratados cada uno de ellos como una unidad de distribución, permite el proceso concurrente de las transacciones. El conjunto de estas relaciones, provocará la ejecución paralela de una consulta al ser dividida en una serie de subconsultas que operará sobre los fragmentos. Cuando las vistas definidas sobre una relación son consideradas como unidad de distribución que se ubican en diferentes sitios de la red, podemos optar por dos alternativas diferentes: La relación no estará replicada y se almacena en un único sitio, o existe réplica en todos o algunos de los sitios en los cuales reside la aplicación. Las consecuencias de esta estrategia son la generación de un volumen de accesos remotos que pueden ser innecesarios con un mal manejo de estas replicas. Además, las réplicas innecesarias pueden causar problemas en la ejecución de las actualizaciones y puede no ser deseable si el espacio de almacenamiento está limitado. Los inconvenientes de la fragmentación están dados en que si las pueden estar definidas por fragmentos mutuamente exclusivos y al recuperar los datos de dos fragmentos situados en sitios diferentes es necesario trasmitir los datos de un sitio a otro y realizar sobre ellos la operación de unión (Join), lo cual puede ser costoso. El control semántico cuando los atributos implicados en una dependencia una relación se descompone en diferentes fragmentos y estos se ubican en sitios diferentes puede ser muy costos porque es necesario hacer búsquedas en un gran número de sitios.

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.

•  Autonomía Local : Los sitios distribuidos deben ser autónomos, es decir que todas las operaciones en un sitio dado se controlan en ese sitio.

•  No dependencia de un sitio central : No debe de haber dependencia de un sitio central para obtener un servicio.

•  Operación Continua : Nunca debería apagarse para que se pueda realizar alguna función, como añadir un nuevo sitio.

•  Independencia con respecto a la localización : No debe de ser necesario que los usuarios sepan dónde están almacenados físicamente los datos, sino que más el usuario lo debe de ver como si solo existiera un sitio local

•  Independencia con respecto a la fragmentación : La fragmentación es deseable por razones de desempeño, los datos, pueden almacenarse en la localidad donde se utilizan con mayor frecuencia de manera que la mayor parte de las operaciones sean sólo locales y se reduzca el tráfico en la red.

•  Independencia de réplica : Si una relación dada (es decir, un fragmento dado de una relación ) se puede presentar en el nivel físico mediante varias copias almacenadas o réplicas, en muchos sitios distintos.

•  Procesamiento Distribuido de Consultas : El objetivo es convertir transacciones de usuario en instrucciones para manipulación de datos, y así reducir el trafico en la red implica que el proceso mismo de optimización de consultas debe ser distribuido.

•  Manejo Distribuido de Transacciones : Tiene dos aspectos principales, el control de recuperación y el control de concurrencia, cada uno de los cuales requiere un tratamiento más amplio en el ambiente distribuido.

•  Independencia con respecto al equipo : El SGBDD debe ser ejecutable en diferentes plataformas hardware .

•  Independencia con respecto al Sistema Operativo: El sistema debe ser ejecutable varios diferentes SO.

•  Independencia con respecto a la red : El sistema debe poder ejecutarse en diferentes redes.

•  Todos los usuarios accesan a la BDD a través de un esquema global en forma transparente al usuario. Debe ser posible ejecutar diferentes SGBDD locales que utilicen distintos modelos de datos.

Integración Intra Empresa: Bases de Datos Corporativas

Al unificarse los estándares de desarrollo, fue posible empezar a integrar los diversos sistemas de las empresas, el principio más básico para ello, es compartir la información de las Bases de Datos en un único servidor y que los usuarios de cada uno de los sistemas accedan a su propio subconjunto de datos.

Esta opción dio excelentes resultados para empresas de tamaño relativamente pequeño. Sin embargo, para empresas de gran tamaño (Transnacionales, Fiscales, etc.) o, cuando menos, geográficamente distribuidas (mineras, otras), la red de área local que soporta el esquema C/S es claramente insuficiente. Se intentó entonces otras opciones de acceso remoto, pero los costos y los bajos tiempos de respuesta, lo hacían impracticable.

En este orden de cosas, se inserta la extensión a Cliente/Servidor que permite que las empresas geográficamente distribuidas, puedan disponer de un servidor independiente en cada uno de los centros de trabajo:

Bases de Datos Distribuidas

Bajo este mecanismo, los usuarios de cada centro geográfico disponen de sus datos locales, para todos los sistemas que utilizan, y cuando necesitan un dato de otro centro geográfico, entonces el servidor local se comunica con el servidor remoto (del otro centro geográfico) y pide la información de un modo trasparente al usuario. En este tipo de organización del equipamiento computacional, un usuario prácticamente no nota cuando le responde el servidor local o el remoto, en el último caso, a lo más tiene unos segundos adicionales de espera.

Acceso a Datos Remotos

El cliente realiza tanto las funciones de presentación como los procesos. Por su parte, el servidor almacena y gestiona los datos que permanecen en una base de datos centralizada. En esta situación se dice que hay una gestión de datos remota.

La principal ventaja de esta arquitectura radica en su sencillez de uso, y su proliferación al ser adaptada por lenguajes de cuarta generación (como Oracle Forms). La desventaja es la latencia de red introducida. Al descargarse toda la lógica de proceso en los aplicativos clientes, estos necesitan descargar los datos necesarios (entradas al proceso) que circulan por la red.

El modelo  Bases de datos Distribuidas es similar al de Acceso a Datos Remoto, pero además el gestor de base de datos divide sus componentes entre el cliente y el servidor. Las interfaces entre ambos están dentro de las funciones del gestor de datos y, por lo tanto, no tienen impacto en el desarrollo de las aplicaciones. En este nivel se da lo que se conoce como bases de datos distribuidas.

La principal ventaja de este modelo es que facilita el acceso a los datos desde entornos heterogéneos. Los componentes de acceso a datos ubicados en el cliente permiten independizar la base de datos del entorno en el que corren las aplicaciones cliente. Además, permite implementar la “transparencia de ubicación”. Este sistema presenta dos importantes inconvenientes:

  • Las bases de datos distribuídas son más difíciles de implementar, y son dependientes del gestor de base de datos (siempre que no existan acuerdos y estándares)
  • La integridad de los datos puede verse comprometida.

 

Apache Cassandra

El Proyecto Apache Cassandra desarrolla una base de datos altamente escalable distribuidos de segunda generación, que reúne diseño totalmente distribuido Dynamo y ColumnFamily Bigtable basado en el modelo de datos.

El crecimiento de Internet y con ello la aparición de grandes corporaciones como Google, Yahoo, eBay, Facebook, Twitter, Digg o Lingedin basadas, todas ellas, en la gestión y búsqueda de contenidos, ha planteado nuevos retos a la industria de las bases de datos.

Manejar volúmenes de datos del orden de Petabytes = 1.000 Terabytes y además hacerlo de forma ágil y rápida hacía inviable seguir con el sistema tradicional de bases de datos relacional ACID gestionada por una CPU.

La solución estaba en la antigua Roma, Julio César con aquella frase “Divide et vinces”, una vez más el divide y vencerás llevó a los ingenieros de Google a pensar en un nuevo concepto.

Las Bases de Datos Distribuidas

En este caso, la base de datos queda bajo el control de “un sistema central de gestión de la base de datos”  DBMS, que no es más que una red de servidores que se reparten la responsabilidad de almacenar la base de datos.

De hecho, lo que hacen es partir la base de datos en rebanadas ( … si … pensad en las rebanadas de pan ) , de forma que cada servidor se responsabiliza de una de estas rebanadas (Chunk Nodes).

Google lideró esta carrera desde el principio, con dos revolucionarios proyectos:

  1. Google File System
  2. Google MapReduce, un potente entorno de trabajo, pensado para trabajar con bases de datos distribuidas

Yahoo tomó el relevo, más tarde, y con el proyecto Hadoop creó un nuevo entorno de trabajo mejorando los proyectos iniciales de Google, hasta convertirse en la actualidad en un entorno de referencia al albergar la base de datos Cassandra utilizada por Facebook, Twitter y Digg entre otros.

El contenido de este material es proveniente de algunas de las siguientes Fuentes:

http://es.wikipedia.org/wiki/Bases_de_datos_distribuidas

http://es.wikipedia.org/wiki/Bases_de_datos_distribuidas

http://jms.caos.cl/si/si03.html

http://www.monografias.com/trabajos82/base-datos-distribuidas/base-datos-distribuidas2.shtml

 

 

 

 

 

 

 

Equipo # 7

Hernandez Maria Carolina

Romero Juan José

Mogollón Yeline Vanessa

Moreno Joannis

Lucena Gilbert

Posted in Uncategorized | Leave a comment

Hello world!

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!

Posted in Uncategorized | 1 Comment