Modelización de Sistemas...

1

Big Data – Data Storage

© Jesús Montes & Jose M. Peña

Big DataData Storage (Mejoras de Rendimiento)

2



Mejoras de rendimiento

• Además de los modelos de BD asociados a la tipología de datos a gestionar…

• Hay tecnologías de almacenamiento/recuperación orientadas a la mejora en el rendimiento:• Bases de datos en memoria.

• Bases de datos dispersas (sparse).

3



Bases de datos en memoriaTema 2: Data Storage

4



Concepto de BD en memoria

• BD en memoria• MMDB (Main Memory Data Bases)

• Los datos residen permanentemente en memoria.

• Se usa el disco como back up únicamente.

• BD residentes en disco• DRDB (Disk Resident Data Bases)

• Los datos residen en disco.

• Los datos pueden ser almacenados en memoria como memoria cache.

Principal diferencia: ¿Dónde reside la copia principal?Disco

Memoria

5



Aspectos a considerar en las MMDBs

• ¿Es razonable considerar que toda la BD reside en memoria?• Depende de la aplicación, en algunos casos sí.

• Depende de cuánta memoria estemos hablando (un solo nodo o un cluster).

• ¿Cuál es la diferencia entre una MMDB y una base de datos tradicional con mucha cache?• Un aspecto de diseño: Aunque todos los datos entren en memoria una base de

datos clásica tiene sus estructuras de gestión diseñadas para residir en disco:• Localidad de los accesos.

• Estructuras dinámicas vs. regulares.

6



Aspectos diferenciales en el diseño

• El diseño de las estructuras de control está determinado por una serie de restricciones diferentes en disco y en memoria:• Los tiempos de acceso de memoria frente a

disco son órdenes de magnitud más rápidos.

• La memoria es volátil y el disco no (lo cual implica que se debe mantener su consistencia).

• La ubicación de los datos (lo que es el layout) en el disco es mucho más relevante de cara al rendimiento que en el caso de la memoria.

• Aspectos en los que tiene impacto:• Control de concurrencia.

• Procesamiento de commits.

• Métodos de acceso.

• Representación de datos.

• Procesamiento de queries.

• Recuperación de la BD.

• Rendimiento (en general).

7




• Control de concurrencia:• Al ser más rápidas las operaciones (que no implican lectura/escritura en disco) las

posibilidades de espera en la liberación de los cerrojos son más infrecuentes.

• Procesamiento de commits:• En las BD tradicionales las operaciones englobadas en transacciones mantiene un

registro de log no volátil para recuperación ante fallo.

• La gestión de un log estable (en disco) anularía el beneficio de tener los datos en memoria.

• Métodos de acceso:• Los costes a minimizar en el acceso a estructuras de gestión (índices) son

diferentes.

8




• Representación de datos:• Al gestionar referencias entre registros, en lugar de usar índices a tablas se pueden

explotar el uso de punteros en memoria.

• Procesamiento de queries:• Está relacionado con el uso de los índices en las consultas.

• En BD tradicionales se debe minimizar el acceso a estos índices y que ocupen un tamaño razonable.

• En MMDB es más importante que el tiempo de cómputo que consumen y que lo que ocupan en memoria sea lo mínimo.

• Recuperación de la BD:• Gestión de logs en memoria.

9



Ejemplo de BD en memoria: Redis

• BD de tipo clave-valor.

• Remote Dictionary Server.

• Desarrollado independientemente por Salvatore Sanfilippo luego contratado por VMWare.

• Característica principal: in-memory

• Programado en C

• Licencia BSD

10



Modelo lógico de datos de Redis

• Modelo de datos:• Claves: Cadena de

caracteres ASCII imprimibles.

• Valor:• Primitivas:

• Strings: Array de max. 512MB

• Contenedores:• Hashes

• Listas

• Conjuntos.

• Conjuntos ordenados.

Redis Key

Value: Redis Hash Value: Redis List Value: Redis Set Value: RedisSorted Set

Campo Valor

Campo Valor

Campo Valor

Campo Valor

HEAD Valor 1

Valor 2 Valor 3

Valor 4 TAIL

Valor 1

Valor 3

Valor 2

Valor 4

Score 4

Valor 1Score

Valor 3Score 6

Valor 2Score

Valor 4

11



APIs de desarrollo Redis

• C / C++ / C#

• Java

• Perl

• Python

• Ruby

• PHP

• Objective-C

• …

12



Arquitectura de Redis

• El servidor implementa un único hilo de trabajo (No hay bloqueos).

• En modelos embebidos se pueden implementar otros hilos de proceso a los que sirve.

• Particionado (sharding): Se hace a nivel de aplicación.

• Volcado de respaldo: • Crea otro proceso con la misma memoria (usa COW con las páginas)

• Escribe toda la BD

• Tras una frecuencia y un número de cambios dados.

• Log de operaciones:• Fichero en modo append.

13



Almacenamiento de datos en memoria de Redis

• Pares clave-valor: Tabla hash.

• Hashes:• Menos de 512 entradas: zipmap

• Más de 512 entradas: Tabla hash

• Conjuntos: • Menos de 512 enteros: intset

• El resto: Tabla hash

• Conjuntos ordenados: • Lista por saltos indexada.

• Tabla hash.

• Listas:• Menos de 512 entradas: zipmap

• Más de 512 entradas: Lista doblemente enlazada.

© Wikipedia

14



Bases de datos dispersasTema 2: Data Storage

15



Motivación: La escalabilidad de Google

• Problema de escalabilidad y datos semi-estructurados:

• No existían alternativas comerciales (y el coste sería prohibitivo).

• El almacenamiento de los datos en crudo afecta al rendimiento• Google quería aprovechar el Google File Systems (GFS).

16



Alternativa: BigTable

• Mapa multinivel distribuido.

• Tolerante a fallos y persistente.

• Escalable:• Número de servidores: ~1000s

• En espacio (En memoria: ~TBs y En disco: ~PBs).

• Accesos: • Millones de lectura/escritura por segundo.

• Mejoras especiales de rendimiento en recorridos (scans).

• Facilidades de gestión:• Servidores que pueden darse de alta/baja dinámicamente.

• Servidores con equilibrado de carga.

17



Modelo de datos

• Un mapa con varias dimensiones:• Disperso: Densidad de datos en las combinación de valores de todas las

dimensiones es baja.

• Ordenado: Eficiencia en las búsquedas.

• Distribuido: Despliegue sobre un cluster de gran tamaño.

(row, column, timestamp) -> cell contents

Referencia original: Jing Zhang, Jeff Dean & Google

18



Filas y columnas

• Fila:• Una cadena como clave.

• Acceso a la mis atómico.

• Ordenación lexicográfica.

Por cuestiones de localidad se invierte el orden de la entrada (www.cnn.com com.cnn.www)

• Columna:• Nombrado de la estructura a dos

niveles: family: qualifier

• La familia de columnas es la unidad de control de acceso.

http://www.cnn.com/

19



Timestamps

• Timestamps (sellos de tiempo)• Almacenan diferentes versiones (temporales) de los contenidos de la celda.

• Opciones de búsqueda: • Devolver los k valores más recientes.

• Devolver todos.

20



Tablets

• Una tabla se particionahorizontalmente (en un número de filas).

• A cada partición se le denomina Tablet.

• Las Tablets son la unidad de distribución (para replicación y equilibrado de carga).

Tab

let

XTa

ble

t Y

21



Operaciones

• Operaciones de creación:• Crear/eliminar/modificar tablas y familias de comunas.

• Escritura:• Set(): Escritura de una celda.

• DeleteCells(): Borrado de celdas puntuales en una fila.

• DeleteRow(): Borrado de todas las celdas en esa fila.

• Lectura:• Scans (lectura puntual de celdas):

• Cada fila se lee de forma atómica.

• Se puede fijar las celdas devueltas a un rango de claves de fila.

• Se pueden seleccionar 1/n/todas las filas y 1/m/todas familias de columnas.

22



Despliegue

• Google File System(GFS):• Almacenamiento

persistente (formato SSTable).

• Chubby:• Servicio de cerrojos:

Servidor distribuido.

• Selección de master.

• Planificador.

• MapReduce (opcional)

Conjunto de máquinas que pueden estar ejecutando otras aplicaciones

23



Servidor de cerrojos Chubby

• Servicio cerrojos, pero además puede servir nombres y ficheros.

• Cerrojos de grano grueso.

• Cada cliente estable una sesión con el servidor Chubby:• Funciona por licencias (lease) que el cliente debe renovar.

• Se mantiene 5 réplicas:• Se requiere una votación por mayoría para ser activado.

24



Despliegue

• Cliente: Librería de acceso.

• Nodo maestro:• Asigna tablets a servidores.• Detecta entrada/salida de

servidores.• Equilibrado de carga (tablets

asociados a servidores).• Operaciones: GC y metadata.

• Servidores de tablets:• Gestiona operaciones de

lectura/escritura sobre sus tablets.

• Dividen las tablets que han crecido demasiado.

25



Parámetros de las tablets

• Las tablets se asignan a los servidores de tablets.• Las tablets almacenan un conjunto de filas contiguo.

• Las aplicaciones cliente establecen la clave de fila para mejorar la localidad.

• El tamaño típico son 100-200MB por tablet.

• Un servidor de tablets es responsable de unos 100 tablets:• Recuperación rápida:

• 100 máquinas toman cada una uno de los tablets de la máquina caída.

• Equilibrado de carga de grano fino:• Se migran fuera las tablets de las máquinas sobrecargadas.

• El nodo maestro toma las decisiones sobre el equilibrado de carga.

26



• Dada una fila a recuperar, ¿de qué forma los clientes localizan el rango de filas que incluye dicha fila?

• Tablets de metadatos: Clave={table_id+end_row}, Datos:{location}

• Gestión de caches y pre-fetching agresivo por parte del cliente.

Localización de las tablets

27



Asignación de tablets

• Cada tablet se asigna a un único servidor.

• Responsabilidades:• Servidor chubby:

• Le concede un cerrojo a los servidores de tablets que se registran (vía lease) para acceder a un directorio del GFS.

• Nodo Maestro:• Monitoriza el conjunto de servidores de tablets que están vivos.• Para eso, utiliza el servidor chubby para determinar si los servidores están vivos y recuperarlos.• Asigna una tablet a un nodo si tiene espacio disponible.• Monitoriza cada directorio para determinar si los servidores están y responden.• Si el servidor no responde (o ha perdido el cerrojo), dicho cerrojo lo captura el nodo maestro

que reasignará las tablets.

• GFS:• Encargado de replicar los datos.

28



Big DataData Storage (Mejoras de Rendimiento)

Date post:	09-Feb-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

Modelización de Sistemas...

Documents