modelización de sistemas biológicos - laboratorio...

1

Big Data – Data Storage

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

Big DataData Storage

2



Í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



IntroducciónTema 2: Data Storage

4



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



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




• 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




8




• ¿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: 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



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: 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: ¿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: ¿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: ¿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



Alternativas a las bases de datos relacionales

http://blog.monitis.com/index.php/2011/05/22/picking-the-right-nosql-database-tool

16



Modelos de estructuración de datos no relacional (No-SQL)Tema 2: Data Storage

17



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



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



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



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



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




• 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




• 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




• 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




• Ejemplo de consistent hashing: Cluster con 4 nodos y anillo con 32 particiones.

26



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



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



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



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



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



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



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



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



Tecnologías de recuperación y procesamiento masivo

Tema 2: Data Storage

35



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



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



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



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



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



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



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



Un ejemplo de MapReduce distinto: Procesado de grafos

43



Hadoop y HDFS

• Hadoop es la implementación mas popular de MapReduce.• Software libre.


• 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



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



HDFS

46



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



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



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



Modelos de almacenamiento dependientes de los datosTema 2: Data Storage

50



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



Modelos de almacenamiento dependientes de los datosBD de GrafosTema 2: Data Storage

52



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



¿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



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



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



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



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



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



Un ejemplo de BD basada en grafos: Neo4j

• Base de datos No-SQL orientada a grafos.


• Open Source.

• Desarrollada por Neo Technologies.

• Distribuida bajo dos licencias:• Affero General Public License (AGPL) v3

• Licencia comercial

60



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



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



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



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



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



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



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



Escalabilidad de Neo4j a Big Data

• El principal problema es el particionamiento del grafo entre servidores:

© Jim Webber

68




• 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




• 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




• 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



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

http://www.neo4j.org/

http://www.neo4j.org/learn/cypher

http://graphaware.com/assets/bachman-msc-thesis.pdf

http://vimeo.com/83797381

http://osintegrators.com/opensoftwareintegrators%7Cneo4jadevelopersperspective

72



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



Modelos de almacenamiento dependientes de los datosBD de DocumentosTema 2: Data Storage

74



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




• 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




• 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



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



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



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



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



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



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



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



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/

http://www.mongodb.org/

85



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 DataData Storage

modelización de sistemas biológicos - laboratorio...

Documents