Big Data Data Storage. Big Data. Data Storage (Mejoras de Rendimiento) Jesús Montes & Jose M. Peña

Transcripción

1 Big Data Data Storage (Mejoras de Rendimiento) 1

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). 2

3 Bases de datos en memoria Tema 2: Data Storage 3

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? Memoria Disco 4

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. 5

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). 6

7 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. 7

8 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. 8

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 9

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: Redis Sorted Set Campo Campo Campo Campo Valor Valor Valor Valor HEAD Valor 1 Valor 2 Valor 3 Valor 4 TAIL Valor 1 Valor 2 Valor 3 Valor 4 Score 4 Valor 1 Score 6 Valor 2 V Sc Va 10

11 APIs de desarrollo Redis C / C++ / C# Java Perl Python Ruby PHP Objective-C 11

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. 12

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. 13 Wikipedia

14 Bases de datos dispersas Tema 2: Data Storage 14

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). 15

16 Alternativa: BigTable 16 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 17 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. Columna: Nombrado de la estructura a dos niveles: family: qualifier La familia de columnas es la unidad de control de acceso. Por cuestiones de localidad se invierte el orden de la entrada ( com.cnn.www) 18

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. 19

20 Tablet X Tablet Y Big Data Data Storage Tablets Una tabla se particiona horizontalmente (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). 20

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. 21

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 22

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. 23

24 Despliegue 24 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 MB 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. 25

26 Localización de las tablets 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. 26

27 Asignación de tablets 27 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 (Mejoras de Rendimiento) 28