PDF de programación - Bases de datos distribuidas

Imágen de pdf Bases de datos distribuidas

Bases de datos distribuidasgráfica de visualizaciones

Publicado el 5 de Junio del 2018
843 visualizaciones desde el 5 de Junio del 2018
2,7 MB
23 paginas
Creado hace 8a (16/02/2016)
Bases de datos distribuidas
© Fernando Berzal, [email protected]

Acceso a los datos

 Bases de datos relacionales: SQL

 O/R Mapping

 Bases de datos distribuidas

 Bases de datos NoSQL

 Bases de datos multidimensionales: Data Warehousing

1

Bases de datos distribuidas

 Arquitectura de un DBMS

 Sistemas C/S
 Sistemas P2P
 Sistemas MDBS

 Diseño de bases de datos distribuidas

 Fragmentación
 Asignación de recursos

 Replicación de datos

Arquitectura de un DBMS

Capas funcionales
DBMS centralizado

2

3

Arquitectura de un DBMS

Alternativas de implementación de un DBMS distribuido

Arquitectura de un DBMS

Sistemas cliente/servidor

4

5

Arquitectura de un DBMS

Sistemas cliente/servidor
con múltiples servidores

6

Arquitectura de un DBMS

Bases de datos distribuidas
Extensión del modelo ANSI/SPARC

ES
External Schema

GCS
Global Conceptual Schema

LCS
Local Conceptual Schema

LIS
Local Internal Schema

7

Arquitectura de un DBMS

Sistemas MDBS
Multidatabase Systems

Arquitectura de un DBMS

Sistemas MDBS
Mediators & wrappers

8

9

Arquitectura de un DBMS

Ejemplo: Apache Drill
https://drill.apache.org/

NOTA:Inspirado en Dremel (Google, VLDB’2010),

base de Google BigQuery [IaaS]:
https://cloud.google.com/bigquery/

10

Arquitectura de un DBMS

Ejemplo: Apache Drill
https://drill.apache.org/

11

Arquitectura de un DBMS

Ejemplo: Apache Drill
https://drill.apache.org/

Arquitectura de un DBMS

Bases de datos distribuidas
DBMS distribuido

12

13

Arquitectura de un DBMS

Sistemas P2P [Peer-to-peer]
Arquitectura

Arquitectura de un DBMS

Ejemplo: Impala (Cloudera)
http://impala.io/

14

15

Arquitectura de un DBMS

Parallel DBMS
e.g. MPP DBMS [Massively Parallel Processing DBMS]

Arquitectura de un DBMS

Ejemplo: Greenplum (Pivotal Software)
http://greenplum.org/

16

17

Arquitectura de un DBMS

Ejemplo: PrestoDB (Facebook)
https://prestodb.io/

Usuarios:
Facebook (300PB Hive), Netflix (25PB Amazon S3),
AirBnB (1.5PB Hive), Groupon (HBase)…

18

Diseño

19

Diseño

Fragmentación
¿Por qué fragmentar los datos?

 Localidad de acceso

(las vistas utilizadas por las aplicaciones suelen ser
subconjuntos de las relaciones globales).

 Distribución de los datos

(minimización del volumen de acceso a datos remotos).

 Rendimiento

(ejecución en paralelo de consultas y transacciones).

Diseño

Fragmentación

Estrategias de fragmentación de los datos:

 Fragmentación horizontal (selección / tuplas)

 Fragmentación vertical (proyección / columnas)

 Fragmentación anidada (híbrida)

20

21

Diseño

Particionamiento
Fragmentación horizontal
en sistemas distribuidos

Diseño

Fragmentación horizontal

 Fragmentación horizontal primaria

(predicados definidos sobre la propia relación).

 Fragmentación horizontal secundaria

(predicados definidos sobre otras relaciones).

22

23

Diseño

Fragmentación horizontal
Información necesaria (cualitativa y cuantitativa):

Base de datos: Esquema conceptual global (GCS).
 Enlaces entre relaciones (claves externas).
 Cardinalidad de cada relación.

Aplicaciones:
 Predicados utilizados en las consultas (regla 80/20:

20% de las consultas, 80% de los accesos).

 Selectividad de los términos de las consultas (número

de tuplas a las que se accede al utilizar un término).

 Frecuencias de acceso.

24

Diseño

Fragmentación horizontal primaria
Ri = σσσσ

1 ≤≤≤≤ i ≤≤≤≤ w

Fi(R)

Propiedades deseables:
 Predicados completos (misma probabilidad de acceso

a cualquier tupla de cualquier fragmento)
 Balanceado de carga.

 Predicados minimales (dados dos fragmentos fi y fj, al
menos una aplicación debería acceder a ellos de forma
diferente): acceso(Fi)/card(Ri) ≠ acceso(Fj)/card(Rj)

25

Diseño

Fragmentación horizontal derivada
Ri = R ◊◊◊◊ σσσσ

1 ≤≤≤≤ i ≤≤≤≤ w

Fi(S)

La fragmentación se define sobre R a partir de su
“propietaria” S mediante una equi-reunión [equi-join].

Ejemplo: Entidades débiles

26

Diseño

Fragmentación vertical

OBJETIVO:
Dividir una relación en relaciones más pequeñas de forma
que cada aplicación trabaje sólo con un fragmento.

¡Peligro! La reconstrucción de los datos requiere el uso de
reuniones (operaciones costosas, más si son distribuidas).

27

Diseño

Fragmentación vertical

También en bases de datos centralizadas:
 Disminución del número de accesos a páginas de disco

(menor tamaño de las relaciones).

 Uso de cachés (memoria más rápida para fragmentos a

los que se accede con mayor frecuencia).

28

Diseño

Fragmentación vertical
Criterios heurísticos:

 Agrupamiento [grouping]: Inicialmente, cada atributo

a un fragmento, que se va combinando con otros
hasta que se cumplan las condiciones deseadas
 Fragmentos con solapamiento.

 División [splitting]: Se decide la fragmentación en
función del acceso de las aplicaciones a los datos
 Fragmentos no solapados.

NOTA: La clave primaria, por razones obvias, sí se replica.

29

Diseño

Fragmentación vertical
Información necesaria (cualitativa y cuantitativa):

Aplicaciones (para colocar en el mismo fragmento los
atributos a los que se accede conjuntamente):
 Predicados utilizados en las consultas (regla 80/20:

20% de las consultas, 80% de los accesos).

 Frecuencias de acceso de las consultas a los atributos

individuales: use(qi,Aj).

 Afinidad entre los atributos (a partir del número de
accesos conjuntos a los atributos y la frecuencia de
cada consulta): aff(Ai,Aj).

30

Diseño

Distribución de los datos [data allocation]

PROBLEMA DE OPTIMIZACIÓN
Dados un conjunto de fragmentos F
y un sistema distribuido con un conjunto de nodos N
sobre el que debe funcionar un conjunto de aplicaciones Q,
encontrar la distribución “óptima” de F sobre N.

Criterios de optimalidad:
 Coste mínimo (almacenamiento & comunicación).
 Rendimiento (tiempo de respuesta o throughput).

31

Diseño

Distribución de los datos [data allocation]
Información necesaria

Base de datos:
 Selectividad (de fragmentos con respecto a consultas).
 Tamaño de los fragmentos (MB).
Aplicaciones:
 Accesos de lectura y accesos de actualización.
Sistema de almacenamiento de datos:
 Capacidad de almacenamiento de cada nodo.
 Capacidad de procesamiento de cada nodo.
 Coste de comunicación entre nodos.

32

Diseño

Distribución de los datos [data allocation]
Problema de optimización

DAP [Database Allocation Problem]
Minimizar el coste total
sujeto a…

restricciones de tiempo de respuesta
restricciones de almacenamiento
restricciones de procesamiento

33

Diseño

Distribución de los datos [data allocation]

Modelo (más que) simplificado:
 Coste de transmisión de las actualizaciones.
 Coste de ejecución de las consultas.
 Coste de almacenamiento de las réplicas de un fragmento.

Incluso así, el problema es NP-completo

 Soluciones heurísticas subóptimas.

34

Replicación de datos

Objetivos

 Disponibilidad

(datos accesibles aunque se produzcan fallos)

 Rendimiento

(mover los datos cerca de su punto de acceso)

 Escalabilidad

(tiempo de respuesta de las consultas)

 Requisitos de las aplicaciones (p.ej. legales)

35

Replicación de datos

Decisiones de diseño

¿Dónde se permiten las actualizaciones?
 Actualizaciones centralizadas (copia “maestra”)
 Actualizaciones distribuidas

¿Cómo se propagan las actualizaciones?
 De forma síncrona: “Eager update propagation”

(en el contexto de la transacción actual).

 De forma asíncrona: “Lazy update propagation”

(la transacción termina sin esperar la propagación).

Replicación de datos

Actualizaciones centralizadas “eager”

36

37

Replicación de datos

Actualizaciones centralizadas “lazy”

Replicación de datos

Actualizaciones distribuidas “eager”

38

39

Replicación de datos

Actualizaciones distribuidas “lazy”

Replicación de datos

Soporte en DBMSs comerciales
Oracle DB

Oracle Streams
 Balanceado de carga
con múltiples réplicas.

 Actualizaciones

distribuidas.

Oracle GoldenGate
 Replicación en entornos heterogéneos

(p.ej. con otras bases de datos no Oracle).

40

41

Replicación de datos

Soporte en DBMSs comerciales
IBM DB2

Tres métodos diferentes de replicación:
 CDC [Change Data Capture], usando TCP/IP
 Q Replication, usando MQ Series (middleware)
 SQL Replication, usando DRDA (estándar)

Distributed Relational Database Architecture
https://en.wikipedia.org/wiki/DRDA

42

Replicación de datos

Soporte en DBMSs comerciales
Microsoft SQL Server
SQL Replication Services

Modelo “publisher/subscriber” con agentes de replicación
(DBMS en el servidor o cachés en el cliente):
 Replicación de

transacciones (síncrona).

 Merge (actualizaciones

bidireccionales periódicas).

 Snapshot (instantánea:

copia completa del estado
actual de la base de datos).

43

Bibliografía recomendada

 M. Tamer Özsu & Patrick Valduriez:

Principles of Distributed Database Systems.
Springer, 3rd edition, 2011.
ISBN 1441988335

44
  • Links de descarga
http://lwp-l.com/pdf11602

Comentarios de: Bases de datos distribuidas (0)


No hay comentarios
 

Comentar...

Nombre
Correo (no se visualiza en la web)
Valoración
Comentarios...
CerrarCerrar
CerrarCerrar
Cerrar

Tienes que ser un usuario registrado para poder insertar imágenes, archivos y/o videos.

Puedes registrarte o validarte desde aquí.

Codigo
Negrita
Subrayado
Tachado
Cursiva
Insertar enlace
Imagen externa
Emoticon
Tabular
Centrar
Titulo
Linea
Disminuir
Aumentar
Vista preliminar
sonreir
dientes
lengua
guiño
enfadado
confundido
llorar
avergonzado
sorprendido
triste
sol
estrella
jarra
camara
taza de cafe
email
beso
bombilla
amor
mal
bien
Es necesario revisar y aceptar las políticas de privacidad