1
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Big DataData Storage (Mejoras de Rendimiento)
2
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
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
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Bases de datos en memoriaTema 2: Data Storage
4
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
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
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
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
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
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
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Aspectos diferenciales en el diseño
• 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
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Aspectos diferenciales en el diseño
• 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
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
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
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
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
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
APIs de desarrollo Redis
• C / C++ / C#
• Java
• Perl
• Python
• Ruby
• PHP
• Objective-C
• …
12
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
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
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
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
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Bases de datos dispersasTema 2: Data Storage
15
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
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
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
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
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
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
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
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.
19
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
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
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
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
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
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
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
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
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
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
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
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
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
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
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
• 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
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
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 Data – Data Storage
© Jesús Montes & Jose M. Peña
Big DataData Storage (Mejoras de Rendimiento)
Top Related