modelización de sistemas biológicos - laboratorio...
Post on 18-Sep-2018
225 Views
Preview:
TRANSCRIPT
1
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Big DataData Storage
2
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Índice general del tema
• Introducción
• Modelos de estructuración de datos no relacional (No-SQL)
• Tecnologías de recuperación y procesamiento masivo
• Modelos específicos para tipologías de datos
• Tecnologías para la mejora de rendimiento en el almacenamiento de datos
• Tecnologías de servicios de datos corporativos
• Prácticas
3
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
IntroducciónTema 2: Data Storage
4
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Introducción
• El primer problema al que se enfrenta el Big Data es el almacenamiento y la organización de los datos que se pretende analizar.
• Big Data implica volúmenes gigantescos de datos, por lo que probablemente necesitemos mecanismos especiales para almacenarlos.
5
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Volumen gigante de datos
• 2008 (wired.com):• 20 TB (fotos subidas a Facebook cada mes, 2008).
• 120 TB (todos los datos e imágenes recogidos por el telescopio espacial Hubble).
• 460 TB (todos los datos del tiempo climático en EEUU compilados por el NationalClimatic Data Center).
• 530 TB (Todos los vídeos de YouTube).
• 600 TB (base de datos de genealogía, incluye todos los censos de EEUU 1790-2000).
6
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Volumen gigante de datos
• 2013:• Tamaño total de datos actual: 2,8 ZB. IDC (International Data Corporation)
proyecta que, para el 2020, el Universo Digital alcanzará 40 ZB (América Economia).
• 400 millones de tuits (tweets) diarios que representan 54 Terabytes.
• Un vuelo transoceánico de un jumbo puede generar 640 Terabytes (Boeing).
• 1 millón de transacciones por hora en Wal-Mart. Base de datos de 2.5 PB.
• Google procesa al día 20 PB de información.
7
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Volumen gigante de datos
8
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Volumen gigante de datos
• ¿Cuánto son 40ZB?• Existen 700,500,000,000,000,000,000 granos de arena en todas las playas del
mundo (o setecientos trillones quinientos mil billones). Esto significa que 40 ZB equivalen a 57 veces la cantidad de granos de arena de todas las playas del mundo.
• Si pudiéramos guardar los 40 ZB en los discos Blue-ray de la actualidad, el peso de dichos discos (sin fundas ni estuches) sería equivalente a 424 portaaviones Nimitz.
• En 2020, 40 ZB serán 5,247 GB por persona a nivel mundial.
Fuente :http://itusersmagazine.com/tag/universo-digital-de-idc/
9
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Big Data: Necesidades y condiciones de almacenamiento• Necesidades:
• Facilidades de almacenamiento
• Herramientas, procesos y procedimientos para organizar, crear, manipular y gestionar conjuntos de datos en agentes automáticos
• Condiciones:• Grandes volúmenes de datos
• Alta velocidad de transferencia (en entornos cada vez más distribuidos)
• Mucha variedad de datos
10
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
3 Vs de Big Data
• Volumen: crece más deprisa que los recursos de cómputo:• El volumen crece 10 veces cada 5 años.• La capacidad de almacenamiento/procesamiento se dobla cada 18 meses (Ley de Moore).• Es indispensable poder gestionar mayores volúmenes en los recursos disponibles.
• Velocidad• Los recursos de red no crecen en proporción a los datos que fluyen por ella.• Necesidad de optimizar la comunicación: Procesamiento en streaming + Almacenamiento
selectivo.
• Variedad: mucha variedad de datos• Alta heterogeneidad entre las fuentes de datos existentes:
• Colecciones de estructura diversa (generalmente datos semi-estucturados).• El modelo relacional no ajusta bien.
• Se necesitan modelos de representación flexibles. Herramientas de almacenamiento y consulta optimizadas para estos tipos de datos.
11
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Big Data: Soluciones de almacenamiento
• Tecnología escalable• Baja latencia de lectura/actualización
• Generalidad y extensibilidad
• Infraestructura para la distribución, análisis y compartición• Modelos flexibles de representación.
• Determinar la calidad de los datos: incongruencias, ausencias...
• Acondicionar los datos mediante estándares que faciliten su procesamiento; ej. XML o RDF.
• Gestión de privacidad y seguridad• Mantenimiento mínimo.
• Robustez y tolerancia a fallos. Datos inmutables.
12
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Big Data: ¿Por qué no usar bases de datos relacionales?• El uso de bases de datos relacionales está
totalmente extendido.
• Proporcionan alto rendimiento y propiedades ACID:• Atomicity
• Consistency
• Isolation
• Durability
13
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Big Data: ¿Por qué no usar bases de datos relacionales?• Sigue existiendo debate al respecto, aunque en general está aceptado que
las bases de datos tradicionales no son suficientes:• Escalabilidad: No manejan bien enormes volúmenes de datos.
• Flexibilidad: No se adaptan a la complejidad y requisitos de las aplicaciones actuales.
• Los principales defensores de las bases de datos tradicionales cuestionan las condiciones en las que se han evaluado.
14
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Big Data: ¿Por qué no usar bases de datos relacionales?• Si las bases de datos tradicionales no son suficientes ¿qué alternativas
hay?• Modelos genéricos No-SQL
• Bases de datos con modelo clave-valor.
• Bases de datos orientadas a columnas.
• Modelos específicos para tipologías de datos• Bases de datos orientadas a grafos.
• Bases de datos orientadas a documentos.
15
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Alternativas a las bases de datos relacionales
http://blog.monitis.com/index.php/2011/05/22/picking-the-right-nosql-database-tool
16
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Modelos de estructuración de datos no relacional (No-SQL)Tema 2: Data Storage
17
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Modelos de estructuración de datos no relacional (No-SQL)• No-SQL (Not Only SQL): Es una clase amplia de
bases de datos que no tienen porque utilizar SQL como lenguaje de consulta.• No garantizan completamente ACID.
• Optimizadas para las operaciones recuperar y almacenar registros.• Habitualmente no soportan operaciones JOIN.
• Escalan bien • Las soluciones son inherentemente distribuidas.
18
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Modelos de estructuración de datos no relacional (No-SQL)• Sin esquema fijo.
• Fácilmente replicables.
• APIs simples.
• Requisitos de coherencia menos estrictos (eventual consistency).
• Los datos son inmutables:• Almacenamiento en bruto de los datos (sin ningún tipo de transformación).
• Nos permite hacer seguimiento de todo lo que hay almacenado.
19
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Modelos de estructuración de datos no relacional (No-SQL)• Teorema de Brewer (o principio de CAP): Es imposible que un sistema distribuido cumpla con las siguientes tres características:• Consistency (coherencia entre nodos).
• Availability (disponibilidad).
• Partition tolerance (tolerancia ante pérdida de una parte del sistema).
• Las bases de datos NoSQL relajan estas condiciones, presentando propiedades BASE:• Basically Available (disponible en la práctica).
• Soft state (estado variable).
• Eventual consistency (coherencia final).
20
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Bases de datos con modelo clave-valor
• Modelo de almacenamiento más sencillo: pares (clave, valor).
• Se conoce habitualmente como key-value store.
• Fácil de implementar y utilizar.
• Ineficiente cuando se desea consultar o actualizar solo parte de un valor.• Hay que leer el valor entero.
• Hay que actualizar el valor entero.
• Similar a una tabla hash distribuida (DHT).
• Ejemplos: Dynamo, Redis, Riak.
21
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Un ejemplo de key-value store: Riak
• Modelo clave-valor.
• Escrito en Erlang.
• Multiples versiones:• Open source (licencia Apache 2).
• Comercial con soporte (Riak Enterprise).
• Cloud (Riak cs).
• Inspirado en Dynamo (Amazon).
• Desarrollado por Basho Technologies.
22
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Un ejemplo de key-value store: Riak
• Desplegable sobre un cluster.
• Organización peer-to-peer dentro del cluster, sin nodo maestro.
• Acceso:• API RESTful sobre HTTP: PUT, GET, POST, DELETE.
• Drivers para Ruby, Java, Erlang, Python, C/C++, y PHP.
• Compatible con Apache Solr y MapReduce.
23
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Un ejemplo de key-value store: Riak
• Disponibilidad y tolerancia a fallos.• Información replicada en los nodos del cluster.
• En caso de fallo o partición de la red, se puede seguir operando, y la información se propagará y/o balanceará cuando sea posible.
• Replicación entre múltiples clusters (1 cluster primario + n secundarios).• fullsync: Replicación periódica.
• realtime: Propagación en tiempo real.
24
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Un ejemplo de key-value store: Riak
• Los datos se distribuyen usando consistent hashing:• Los pares clave-valor se almacenan en buckets (similares a directorios).
• Se calcula un hash de 160 bits de “bucket+clave”.
• Todo el rango de posibles hash se reparte en un anillo.
• Este anillo se divide en particiones (por defecto 64).
• Cada partición la gestiona un nodo virtual (vnode).
• Los vnodes se reparte de forma equitativa entre los nodos del cluster.
• Las replicas se almacenan en diferentes particiones.
25
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Un ejemplo de key-value store: Riak
• Ejemplo de consistent hashing: Cluster con 4 nodos y anillo con 32 particiones.
26
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Bases de datos orientadas a columnas
• Organizan la información por columnas, de forma independiente, en vez de por tablas y filas.
• Claves a nivel de tupla, que referencian a varias columnas.
• Pros:• Operaciones de agregación (COUNT, SUM, MIN...) más eficientes.
• Inserción en lote más eficiente.
• Mejora las posibilidades de compresión y distribución.
• Contras:• Recuperar una tupla completa es más costoso (consulta a varias columnas).
• Insertar una tupla completa es más costoso (inserción en varias columnas).
• Ejemplos: BigTable, HBase, Cassandra.
27
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Bases de datos orientadas a columnas
• Concepto de columna:• Objeto con tres campos:
• Nombre único.
• Valor.
• Marca de tiempo.
• Distinto a una una columna de una matriz o un atributo de una tabla en una BD relacional.
• Pieza básica de las BD orientadas a columnas.
28
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Un ejemplo de BD orientada a columnas: Cassandra• Orientado a columna.
• Escrito en Java.
• Open Source.
• Parte de proyecto Apache.
• Inicialmente desarrollada por Facebook y posteriormente liberada.
29
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Un ejemplo de BD orientada a columnas: Cassandra• Desplegable sobre un cluster.
• Descentralizada: sin SPOF (punto único de fallo).
• Con replicación local (dentro del cluster) y entre clusters.
• Altamente escalable.
• Coherencia ajustable (tunable consistency).• Las escrituras nunca fallan.
• Quórum entre nodos.
• Bloqueante hasta que se hayan escrito todas las réplicas.
30
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Un ejemplo de BD orientada a columnas: Cassandra• Acceso:
• cqlsh: cliente propio, usando CQL (Cassandra Query Language), similar a SQL.
• Drivers para Ruby, Java, Node.js, Spark, C++, Python, C#...
• Uno de los sistemas No-SQL mas populares del momento.• CERN, Digg, IBM, Netflix, Reddit, Twitter, Facebook…
31
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Un ejemplo de BD orientada a columnas: Cassandra• Modelo de datos:
• Los datos se organizan en familias de columnas, conceptualmente similares a tablas en una BD relacional.
• Cada familia contiene columnas y filas (tuplas).
• Cada fila está identificada por una clave única.
• Cada fila tiene una serie de columnas, cada una con su nombre, valor y marca de tiempo.
• Cada fila de una familia puede tener distintas columnas, a diferencia de lo que ocurre en una BD relacional.
32
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Un ejemplo de BD orientada a columnas: Cassandra• Ejemplo: servicio de música
• Canciones y listas.
• Se puede operar de manera similar a una BD relacional, usando CQL, pero hay que tener en cuenta que el sistema no soporta JOIN.
33
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Un ejemplo de BD orientada a columnas: Cassandra
CREATE TABLE songs (
id uuid PRIMARY KEY,
title text,
album text,
artist text,
data blob
);
• Canciones • ListasCREATE TABLE playlists (
id uuid,
song_order int,
song_id uuid,
title text,
album text,
artist text,
PRIMARY KEY (id, song_order)
);
34
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Tecnologías de recuperación y procesamiento masivo
Tema 2: Data Storage
35
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
MapReduce
• Framework para el procesamiento de grandes problemas paralelizables.
• Pensado para grandes volúmenes de datos.
• Hace uso de grandes clusteres o grids (muchos nodos).
• Hace uso de técnicas de bajo nivel para mejorar el rendimiento, como la localización de los datos.
• Inspirado por el modelo map/reduce de la programación funcional, pero con diferentes objetivos.
• La base de muchas iniciativas de Big Data.
36
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
MapReduce vs. map/reduce
• map/reduce es una técnica clásica de programación funcional:• map(f, X) = [f(x1), f(x2), f(x3), …]: aplica la función f a todos los valores de X.
• reduce(f, X) = f(x1, f(x2, f(x3, …))): Acumula de forma recursiva los valores de X, aplicando la función f. También llamado fold o accumulate.
37
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
MapReduce vs. map/reduce
• MapReduce es un framework de computación distribuida, inspirado en map/reduce pero con el objetivo de hacer posible el procesado de grandes volúmenes de datos.• Fase Map: Los datos de entrada del problema se dividen en bloques (sub-
problemas), que se distribuyen entre los nodos. Cada nodo procesa su sub-problema.
• Fase Reduce: Los resultados de cada sub-problema se combinan en un resultado final.
• Se implementan las funciones de procesado de sub-problemas (Map()) y combinación de resultados (Reduce()).
38
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
MapReduce
• Lo cinco pasos de MapReduce:1. Se prepara la entrada del Map(): Partición y diseminación de los datos.
2. Se ejecuta Map() en cada nodo (mapper). La salida de cada sub-problema se identifica con una clave intermedia.
3. Se baraja y ordena (shuffle and sort) la salida de cada Map(), usando la clave intermedia.
4. Ejecuta Reduce() en cada nodo. Cada reducer procesa los datos asociados a una clave intermedia.
5. Se agrupa la salida de los reducers como resultado final.
• Ejemplos típicos: wordcount, grep, …
39
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Un ejemplo de MapReduce distinto: Procesado de grafos• Dado un grafo dirigido:
• Nodos (con estado).
• Relaciones entre nodos (arcos).
• Estado de un nodo:• Se calcula en función de su estado actual y el estado de sus vecinos.
• Evoluciona de manera iterativa.
• ¿Cómo calcular la evolución del grafo usando MapReduce?
40
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Un ejemplo de MapReduce distinto: Procesado de grafos• Solución:
• El grafo se almacena como un conjunto de pares clave-valor. La clave es el nombre del nodo, y el valor es una lista de nodos adyacentes (A:[B, C]).
• En la fase Map cada nodo genera un mensaje a él y a sus vecinos. La clave de cada mensaje es el ID del nodo de destino: Map(A:[B,C]) = [(A:A), (B:A), (C:A)].
• MapReduce ordena las salidas de los Map() por clave y las asigna a cada Reduce() (shuffle and sort).
• En la fase Reduce se calcula el estado de cada nodo, en función de los mensajes recibidos: Reduce([(B:B), (B:A),(B:D), (B:E)]) = Estado de B en función de B, A, D y E.
• Se ejecuta MapReduce de forma iterativa.
41
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Un ejemplo de MapReduce distinto: Procesado de grafos
method Map(id n, object N)
Emit(id n, object N)
for all id m in N.OutgoingRelations do
Emit(id m, message getMessage(N))
• Map • Reducemethod Reduce(id m, [s1, s2,...])
M = null
messages = []
for all s in [s1, s2,...] do
if IsObject(s) then
M = s
else // s is a message
messages.add(s)
M.State = calculateState(messages)
Emit(id m, item M)
42
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Un ejemplo de MapReduce distinto: Procesado de grafos
43
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Hadoop y HDFS
• Hadoop es la implementación mas popular de MapReduce.• Software libre.
• Escrito en Java.
• Altamente escalable y confiable.
• HDFS (Hadoop Distributed File System) es el sistema de ficheros distribuido de Hadoop.• Pensado para ejecución de aplicaciones MapReduce.
• Escalable y tolerante a fallo.
44
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
HDFS
• Arquitectura: 1 Namenode + n Datanodes.• Namenode: Nodo de metadatos. Puede tener un respaldo (SecondaryNamenode).
• Datanode: Nodo que almacena los bloque que datos.
• Muy orientado a tareas MapReduce:• Localización de los datos en nodos donde se ejecutan los Map asociados.
• No completamente POSIX
45
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
HDFS
46
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Pig
• Plataforma de alto nivel para crear aplicaciones MapReduce basadas en Hadoop.
• Desarrollado inicialmente por Yahoo. Ahora parte del proyecto Apache.
• Pig Latin: Lenguaje de programación de alto nivel para definir trareas mapy reduce.
47
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Wordcount en Pig Latininput_lines = LOAD '/tmp/my-copy-of-all-pages-on-internet' AS (line:chararray);
-- Extract words from each line and put them into a pig bag
-- datatype, then flatten the bag to get one word on each row
words = FOREACH input_lines GENERATE FLATTEN(TOKENIZE(line)) AS word;
-- filter out any words that are just white spaces
filtered_words = FILTER words BY word MATCHES '\\w+';
-- create a group for each word
word_groups = GROUP filtered_words BY word;
-- count the entries in each group
word_count = FOREACH word_groups GENERATE COUNT(filtered_words) AS count, group AS word;
-- order the records by count
ordered_word_count = ORDER word_count BY count DESC;
STORE ordered_word_count INTO '/tmp/number-of-words-on-internet’;
Fuente: Wikipeda
48
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Hive
• Solución de data warehousing basada en Hadoop.
• Desarrollada por Facebook. Ahora parte del proyecto Apache.
• Permite estructura la información almacenada en HDFS y acceder a ella mediante HiveQL, similar a SQL.
• Las queries en HiveQL se implementan como trabajos MapReduce en Hadoop.
49
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Modelos de almacenamiento dependientes de los datosTema 2: Data Storage
50
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Estructuras de datos particulares
• Hay dominios de aplicación que generan y gestionan información basada en unas estructuras específicas: redes y grafos, datos semi-estructurados, datos geo-referenciados, datos dependientes del tiempo, …
• Todas estructuras se pueden (y se ha hecho) almacenar en un modelo relacional clásico …
• … pero ¿es la estructura más apropiada?• Hasta hace unos años, la respuesta era sí (casi siempre), los SGBD eran
comparativamente más eficientes con una alternativa programada ad-hoc.
• Ahora existe tecnología específica mucho más adecuada.
51
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Modelos de almacenamiento dependientes de los datosBD de GrafosTema 2: Data Storage
52
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Concepto de BD orientadas a grafos
• Adecuadas para modelar se caracteriza por una serie (más o menos estructurada) de entidades que establecen relaciones entre ellas:• E.g., La Web, usuarios de Facebook, autores-libros,
películas-actores, …
• En realidad es un modelo muy intuitivo a como se esquematizan las cosas en una pizarra.
• No es una idea nueva (modelo CODASYL), pero “es un modelo que ahora tiene su momento”.
53
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
¿Qué es una BD orientada a grafos?
• Lista de registros (con estructura variable) enlazados entre sí.• Los registros tienen una
serie de propiedades asociadas.
• Al igual que los propios enlaces.
• Los registros se denominan nodos.
• Los enlaces se llaman relaciones.
© neo4j.org
54
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Elementos de una BD orientada a grafos
• Nodos: Análogo a cada fina en una tabla asociada a una entidad en un modelo E/R.• Están identificadas con un nombre (semántica del nodo).
• Se le asocian una serie de propiedades:• Modelo “scheme-free”: No existe una estructura fija de las entidades/nodos, cada elemento
puede tener unas u otras propiedades.
• De forma purista, los nodos no tienes propiedades que son otros nodos con los que se relacionan: Permite “violar” la 1ra forma normal.
• Las propiedades son pares clave-valor.
name = Morpheus
occupation = Total badass
rank = Captain
55
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Elementos de una BD orientada a grafos
• Relaciones: Tan importantes (o más) que los nodos.• Están identificadas con un nombre (semántica de la relación).
• Se le pueden asociar propiedades (no a lo mejor en todas las implementaciones).
• Se les puede dotar de direccionalidad.name: Morpheus
occupation: Total badass
rank: Captain
name: Trinity
name: Neo
real_name: Thomas Andersson
is_the_chosen: true
since: 3 days
since: 3 days
since: 12 years
56
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
BD sin esquema
• No implica que no haya un diseño por debajo.
• Implica que la tipología de entidades(nodos) que se pueden incluir no hay que definirla explícitamente:• Se hace de forma dinámica.
• En cualquier caso, en el ejemplo, tienes que definir cómo representar personajes, enemigos, escenarios, …
• No existe el concepto de normalización:• En un BD relacional necesitas normalizar.
• … y hay veces, que en la implementación de-normalizas.
57
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Indexado
• Tanto los nodos como las relaciones pueden indexarse.• La BD dispone de un mecanismo de indexado interno, pero el usuario puede
incluir el suyo propio:• Está orientado a identificar nodos/relaciones “interesantes”.
• Son los que se usan como comienzo de una operación de recorrido.
• El indexado se realiza mediante propiedades concretas.
• Requiere la construcción de estructuras: BTrees, HTrees, BKTrees, …
• Al igual que en las BD tradicionales el indexado no es gratis:• Se consume espacio.
• Lo que se hace es ganar en velocidad en lecturas a cambio de retardos en escritura.
58
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Ventajas e inconvenientes de las BD de grafos
• Ventajas:• El modelo de datos es muy potente (para las aplicaciones que de forma nativa se
adaptan a él).
• Eficiente: Para operaciones de recorrido de datos conectados la eficiencia es muy superior a las SGBD clásicos.• La eficiencia se mide en recorridos de relaciones (trasversals) por segundo.
• Inconvenientes:• Repartición (sharding) horizontal de datos:
• A pesar de que la escalabilidad de las soluciones tecnológicas actuales es buena.
• La interrelación entre los datos dificulta la creación de particiones (shards).
• Depende de los dominios o naturaleza de los datos (en algunos casos hay una fuerte localidad que se puede aprovechar).
59
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Un ejemplo de BD basada en grafos: Neo4j
• Base de datos No-SQL orientada a grafos.
• Escrito en Java.
• Open Source.
• Desarrollada por Neo Technologies.
• Distribuida bajo dos licencias:• Affero General Public License (AGPL) v3
• Licencia comercial
60
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Ejemplo comparativo
• Grafo artificial generado sintéticamente en base a estadísticas muestreadas:• 1 millón de nodos y 4 millones de arcos.
• Comparativa frente a MySQL:• Recorrido desde un
nodo raíz a lo largo de N pasos.
• Neo4J tardó la mitad de tiempo.
http://java.dzone.com/articles/mysql-vs-neo4j-large-scale
61
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Ejemplo comparativo
• ¿Qué ocurre si eliminamos la sobrecarga de E/S de disco?
• Otro experimento:• 1000 personas
• Una media de 50 amigos por persona.
• Determinar si hay ruta entre X e Y.
Diferencia con el anterior:• Calentamiento de las caches.
© Jim Webber
62
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Un ejemplo de BD basada en grafos: Neo4j
• Despliegue:• En servidor o como BD embebida.
• Acceso a los datos: • Los datos residen en ficheros.
• Recuperados por medio de proyección en memoria (Java NIO).
• Gestión de caches (separadas para nodos, relaciones, propiedades y optimizaciones).
• Traversal framework:• “Motor de queries”.
• Diferentes implementaciones.
Core API
REST APIJVM Language Bindings
Traversal Framework
Caches
Memory-Mapped (N)IO
Filesystem
Java Ruby Clojure…
Graph Matching
• Acceso:• API REST: Descubrible para acceso remoto.
• Bindings de lenguajes sobre la API nativa.
• API de bajo nivel sobre las abstracciones de los elementos del grafo.
63
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Creación de nodos y relaciones
GraphDatabaseService db =
new EmbeddedGraphDatabase("data");
Transaction tx = db.beginTx();
try
{
Node morpheus = db.createNode();
morpheus.setProperty("name",
"Morpheus");
tx.success();
}
finally
{
tx.finish();
}
Transaction tx = db.beginTx();
try
{
Node trinity = db.createNode();
trinity.setProperty("name",
"Trinity");
trinity.createRelationshipTo(morpheus,
DynamicRelationshipType.withName("KNOWS"));
tx.success();
}
finally
{
tx.finish();
}
Creación de Nodos Creación de Relaciones
64
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Mecanismo de indexado en Neo4j
• Subclase que implementan IndexManager.
• Lucene (implementación por defecto):• Indexa nodos y relaciones.
• Permite búsqueda exacta y por expresiones regulares.
• Implementa mecanismo de scoring (para BD de recomendadores).
GraphDatabaseService db = new EmbeddedGraphDatabase("data");
Index <Node> agentes = db.index().forNodes("agents");
Index <Relationships> programado = db.index().forRelationships("CODED_BY");
65
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Mecanismo de consulta en Neo4j
• El acceso a una BD suele ser programático:• Gestión por el usuario del nodo o relación usado.
• Los elementos de partida para la consulta se recuperan del indexado.
• Se proporcionan funciones eficientes para:• Recorrido (traversal).
• Búsqueda de rutas (path finding).
• Búsqueda de patrones (pattern matching).
GraphDatabaseService db = new EmbeddedGraphDatabase("data");
Index <Node> agentes = db.index().forNodes("agents");
Node smith = agents.get("name", "Smith");
IndexHit <Node> smithes = agents.query ("name", "Sm*h");
66
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Mecanismo de consulta en Neo4j (alternativas)
• Neo4j admite un modelo declarativo (no imperativo) de consulta:• El modelo declarativo usa recorrido desde nodo (traversers).
• Hay dos implementaciones de estos modelos de consulta (graphdb y graphdb.traversal).
• Además existen lenguajes de consulta (a-la SQL): Cypher
Traverser t = smith.traverse(Order.DEPTH_FIRST,
StopEvaluator.DEPTH_ONE,
ReturnableEvaluator.ALL_BUT_START_NODE,
relacionesMatrix.KNOWS,
Direction.OUTGOING);
start smith=node:agents(name = 'Smith')
match (smith)<-[:KNOWS]-(personaje)-[:IS_RESPONSIBLE_OF]->(subordinado)
return personaje.name, count(subordinado)
order by count(subordinado) desc
limit 5
67
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Escalabilidad de Neo4j a Big Data
• El principal problema es el particionamiento del grafo entre servidores:
© Jim Webber
68
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Escalabilidad de Neo4j a Big Data
• El problema del particionado se resuelve con:• Un reparto bien balanceado de los
nodos.
• La búsqueda del número mínimo de cortes.
• Es un problema teórico complejo, sobre todo cuando el grafo evoluciona y se modifica.
© Jim Webber
69
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Escalabilidad de Neo4j a Big Data
• El segundo aspecto es la paralelización de las operaciones:• La idea es intentar hacer escalar el sistema de forma que pueda almacenar en
memoria todo el grafo.
• Si no es posible se usa la repartición de caches (cache sharding):• Cada nodo almacena en cache parte del data set que todos tiene almacenado localmente en
disco.
• Asume que si bien los datos son muy grandes para entrar en memoria no lo son para replicarlo en cada nodo.
• El rendimiento de Neo4j es muy dependiente del grado de aprovechamiento de las caches.
70
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Escalabilidad de Neo4j a Big Data
• La asignación de los contenidos de las caches se puede:• Asociar al usuario que hace la
consulta.
• Utilizar información del dominio de datos.• Puede sugerir particionamientos
razonables.
• Se puede elaborar en fase de diseño.
© Jim Webber
71
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Referencias
• Recursos de Neu4j (web site):• http://www.neo4j.org
• http://www.neo4j.org/learn/cypher
• Bachman, Michal (2013). GraphAware: Towards Online Analytical Processing in Graph Databases:• http://graphaware.com/assets/bachman-msc-thesis.pdf
• Hunger, Michael (2012). Cypher and Neo4j:• http://vimeo.com/83797381
• Mistry, Deep (2013). Neo4j: A Developer’s Perspective• http://osintegrators.com/opensoftwareintegrators%7Cneo4jadevelopersperspective
72
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Otras alternativas
• OrientDB (Orient
Technologies)• Java
• Soporta SQL, RESTful/HTTP y JSON
• Transacciones ACID y soporte documental
• Licencia Apache 2.
• DEX / Sparksee(Sparsity-Technologies)• C++
• Multilenguaje API para desarrollo.
• Transacciones aCiDparcial.
• Licencia dual comercial/personal
• TinkerGraph (TinkerPop)• Java
• Todo un ecosistema de herramientas (Gremlin, Blueprints, Pipes, …).
• Licencia Open Source
73
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Modelos de almacenamiento dependientes de los datosBD de DocumentosTema 2: Data Storage
74
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
BD orientadas a documentos
Concepto natural para el almacenamiento de registros electrónicos.
• El elemento central almacenado es el “documento”:• Su concepto concreto depende de la implementación específica de la BD en
concreto, por lo general asociado con una codificación:• Para el caso de documentos de texto: Formato de almacenamiento (PDF, MSWord, …)
• Para el caso de objetos: Serialización en formato texto o binario (XML, YAML, JSON o BSON).
• A los documento se les puede asociar información adicional:• Organización de grupos de objetos: Colecciones y Jerarquías.
• Anotación individual: Etiquetas y metadatos adicionales.
• El concepto tampoco era nuevo (Mumps), pero su generalización fuera de ámbitos concretos ha hecho que sea su momento.
75
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
BD orientadas a documentos
• Similitudes con otros modelos:• BD relacional:
• Las colecciones serían las tablas,
• … pero a diferencia de los registros en una BD relacional, los documentos pueden tener campos y estructura diferente.
• BD clave-valor:• En un BD orientada a documentos, cada documento tiene una clave identificativa única.
• Además de la recuperación de los documentos por esa clave, se pueden realizar búsquedas por contenido de los documentos (que no se pueden hacer en BD de tipo clave-valor).
76
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
BD orientadas a documentos
• Almacenamiento de objetos:• Traducción a un formato compacto y genérico:
• MongoDB usa BSON (Binary JSON).
• Optimizado por cuestiones de rendimiento y navegación.
• Admite compresión.
• La traducción de formatos se hace en los drivers de las APIs de los lenguajes de uso de la BD.
77
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Un ejemplo de BD de documentos: MongoDB
• Base de datos No-SQL orientada documentos.
• Escrito en C++.
• Soporte multiplataforma y APIs multilenguaje.
• Desarrollada (inicialmente)por 10gen.
• Distribuida bajo dos licencias:• Affero General Public License (AGPL) v3
• Drivers bajo Licencia Apache
78
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Representación de documentos en MongoDB
• MongoDB usa JSON como formato de representación de objetos (internamente lo traduce a BSON):
{
"_id" : "5349aff52",
"first" : "John",
"last" : "Doe",
"age" : 39,
"interests" : [
"Reading",
"Mountain Biking ]
"favorites" : {
"color": "Blue",
"sport": "Soccer"}
}
Identificador único (cualquier tipo (excepto un array).De no existir, el sistema le asignará uno interno.
79
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
MongoDB: Operaciones básicas (CRUD)
• Creación:db.collection.insert( <document> )
db.collection.save( <document> )
• Lectura:db.collection.find( <query>, <projection> )
db.collection.findOne( <query>, <projection> )
• Actualización:db.collection.update( <query>, <update>, <option> )
• Borrado:db.collection.remove( <query>, <justOne> )
80
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Recuperación y búsqueda
• Los mecanismos de búsqueda se basan en índices y etiquetas:location1 = {
name : "10gen HQ",
address: "17 West 18th Street 8th Floor",
city : "New York",
zip : "10011",
tags : ["business", "cool place"],
latlong: [40.0,72.0]
}
db.locations.find({zip:"10011"}).limit(10)
db.locations.find({zip:"10011", tags:"business"})
db.locations.ensureIndex({latlong:"2d"})
db.locations.find({latlong:{$near:[40,70]}})
Generación de un índice por parte del usuario
81
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Recuperación y búsqueda
• Los documentos se pueden referenciar entre sí:location1 = {
name : "10gen HQ",
address: "17 West 18th Street 8th Floor",
city : "New York",
zip : "10011",
tags : ["business", "cool place"],
latlong: [40.0,72.0],
contact: [4b97e62bf1d8c7152c9ccb74, 5a20e62bf1d8c736ab]
}
contactos= db.locations.find({..},
{contact:true}).contact
db.persons.find({_id:{$in: contactos}})
Referencias a ObjectIddentro del sistema.
82
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
MongoDB para Big Data
• MongoDB permite un esquema de particionamiento (sharding) automático de los datos:• Los Mongo Config Servers se encargan de la
distribución y del equilibrado de carga.
• El esquema permite replicado de datos.
• Los drivers de las API del lenguaje conocen al servidor primario:• Si no responde pueden encontrar otro.
• Se escribe en el primerio y se replica.
• Las escritura se equilibran vía load sharing.
http://www.polyvision.org/
83
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Soporte nativo Map/Reducedb.collection.mapReduce(
<mapfunction>,
<reducefunction>,
{
out: <collection>,
query: <>,
sort: <>,
limit: <number>,
finalize: <function>,
scope: <>,
jsMode: <boolean>,
verbose: <boolean>
})
var mapFunction1 = function() { emit(this.cust_id, this.price); };
var reduceFunction1 = function(keyCustId, valuesPrices)
{ return sum(valuesPrices); };
http://docs.mongodb.org/manual/reference/method/db.collection.mapReduce
84
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Referencias
• No SQL Distilled by P. Sadalage and M. Fowler
• MongoDB Applied Design Patters by R. Copeland
• The Definitive Guide to MongoDB by Plugge, Membry and Hawkins
• MongoDB (web site):• http://www.mongodb.org/
85
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Alternativa (CoachDB)
• CoachDB (Damien Katz):• Desarrollado en Erlang
• Interfaz de acceso REST
• Consulta vía JavaScript + Map/Reduce
• Licencia: Apache v2.
• Hay otras, pero de menor relevancia.
86
Big Data – Data Storage
© Jesús Montes & Jose M. Peña
Big DataData Storage
top related