Data Storage PDF

Big Data Data Storage
Big Data
Data Storage
Jess Montes &

Jose M. Pea
ndice general del tema

Introduccin
Modelos de estructuracin de datos no relacional (No-SQL)
Tecnologas de recuperacin y procesamiento masivo
Modelos especficos para tipologas de datos
Tecnologas para la mejora de rendimiento en el almacenamiento de
datos
Tecnologas de servicios de datos corporativos
Prcticas
Jess Montes &

Jose M. Pea
Introduccin
Tema 2: Data Storage
Jess Montes &

Jose M. Pea
Introduccin
El primer problema al que se enfrenta el Big Data es el almacenamiento y
la organizacin de los datos que se pretende analizar.
Big Data implica volmenes gigantescos de datos, por lo que
probablemente necesitemos mecanismos especiales para almacenarlos.
Jess Montes &

Jose M. Pea
Volumen gigante de datos

2008 (wired.com):
20 TB (fotos subidas a Facebook cada mes, 2008).
120 TB (todos los datos e imgenes recogidos por el telescopio espacial Hubble).
460 TB (todos los datos del tiempo climtico en EEUU compilados por el National
Climatic Data Center).
530 TB (Todos los vdeos de YouTube).
600 TB (base de datos de genealoga, incluye todos los censos de EEUU 17902000).
Jess Montes &

Jose M. Pea

2013:
Tamao total de datos actual: 2,8 ZB. IDC (International Data Corporation)
proyecta que, para el 2020, el Universo Digital alcanzar 40 ZB (Amrica
Economia).
400 millones de tuits (tweets) diarios que representan 54 Terabytes.
Un vuelo transocenico de un jumbo puede generar 640 Terabytes (Boeing).
1 milln de transacciones por hora en Wal-Mart. Base de datos de 2.5 PB.
Google procesa al da 20 PB de informacin.
Jess Montes &

Jose M. Pea
Jess Montes &

Jose M. Pea

Cunto 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 pudiramos guardar los 40 ZB en los discos Blue-ray de la actualidad, el peso de
dichos discos (sin fundas ni estuches) sera equivalente a 424 portaaviones Nimitz.
En 2020, 40 ZB sern 5,247 GB por persona a nivel mundial.
Fuente :http://itusersmagazine.com/tag/universo-digital-de-idc/
Jess Montes &

Jose M. Pea
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
automticos
Condiciones:
Grandes volmenes de datos
Alta velocidad de transferencia (en
entornos cada vez ms distribuidos)
Mucha variedad de datos
9
Jess Montes &

Jose M. Pea
3 Vs de Big Data
Volumen: crece ms deprisa que los recursos de cmputo:
El volumen crece 10 veces cada 5 aos.
La capacidad de almacenamiento/procesamiento se dobla cada 18 meses (Ley de Moore).
Es indispensable poder gestionar mayores volmenes en los recursos disponibles.
Velocidad
Los recursos de red no crecen en proporcin a los datos que fluyen por ella.
Necesidad de optimizar la comunicacin: 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.
10
Se necesitan modelos de representacin flexibles. Herramientas de almacenamiento y

consulta optimizadas para estos tipos de datos.
Jess Montes &
Jose M. Pea
Big Data: Soluciones de almacenamiento

Tecnologa escalable
Baja latencia de lectura/actualizacin
Generalidad y extensibilidad
Infraestructura para la distribucin, anlisis y comparticin

Modelos flexibles de representacin.
Determinar la calidad de los datos: incongruencias, ausencias...
Acondicionar los datos mediante estndares que faciliten su procesamiento; ej.
XML o RDF.
Gestin de privacidad y seguridad

Mantenimiento mnimo.
Robustez y tolerancia a fallos. Datos inmutables.
11
Jess Montes &

Jose M. Pea
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:
12
Atomicity
Consistency
Isolation
Durability
Jess Montes &

Jose M. Pea

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 volmenes 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.
13
Jess Montes &

Jose M. Pea

relacionales?
Si las bases de datos tradicionales no son suficientes qu alternativas
hay?
Modelos genricos No-SQL
Bases de datos con modelo clave-valor.
Bases de datos orientadas a columnas.
Modelos especficos para tipologas de datos

Bases de datos orientadas a grafos.
Bases de datos orientadas a documentos.
14
Jess Montes &

Jose M. Pea
Alternativas a las bases de datos relacionales
15
http://blog.monitis.com/index.php/2011/05/22/picking-the-right-nosql-database-tool
Jess Montes &

Jose M. Pea
Modelos de estructuracin de
datos no relacional (No-SQL)
16
Jess Montes &

Jose M. Pea
Modelos de estructuracin 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.
17
Jess Montes &

Jose M. Pea

relacional (No-SQL)
Sin esquema fijo.
Fcilmente replicables.
APIs simples.
Requisitos de coherencia menos estrictos (eventual consistency).
Los datos son inmutables:
Almacenamiento en bruto de los datos (sin ningn tipo de transformacin).
Nos permite hacer seguimiento de todo lo que hay almacenado.
18
Jess Montes &

Jose M. Pea

relacional (No-SQL)
Teorema de Brewer (o principio de CAP): Es imposible que un sistema
distribuido cumpla con las siguientes tres caractersticas:
Consistency (coherencia entre nodos).
Availability (disponibilidad).
Partition tolerance (tolerancia ante prdida de una parte del sistema).
Las bases de datos NoSQL relajan estas condiciones, presentando

propiedades BASE:
Basically Available (disponible en la prctica).
Soft state (estado variable).
Eventual consistency (coherencia final).
19
Jess Montes &

Jose M. Pea
Bases de datos con modelo clave-valor

Modelo de almacenamiento ms sencillo: pares (clave, valor).
Se conoce habitualmente como key-value store.
Fcil 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.
20
Jess Montes &

Jose M. Pea
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.
21
Jess Montes &

Jose M. Pea

Desplegable sobre un cluster.
Organizacin 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.
22
Jess Montes &

Jose M. Pea

Disponibilidad y tolerancia a fallos.
Informacin replicada en los nodos del cluster.
En caso de fallo o particin de la red, se puede seguir operando, y la informacin
se propagar y/o balancear cuando sea posible.
Replicacin entre mltiples clusters (1 cluster primario + n secundarios).

fullsync: Replicacin peridica.
realtime: Propagacin en tiempo real.
23
Jess Montes &

Jose M. Pea

Los datos se distribuyen usando consistent hashing:
24
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 particin 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.
Jess Montes &

Jose M. Pea

Ejemplo de consistent hashing: Cluster con 4 nodos y
anillo con 32 particiones.
25
Jess Montes &

Jose M. Pea
Bases de datos orientadas a columnas

Organizan la informacin 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 agregacin (COUNT, SUM, MIN...) ms eficientes.
Insercin en lote ms eficiente.
Mejora las posibilidades de compresin y distribucin.
Contras:
Recuperar una tupla completa es ms costoso (consulta a varias columnas).
Insertar una tupla completa es ms costoso (insercin en varias columnas).
26
Ejemplos: BigTable, HBase, Cassandra.
Jess Montes &

Jose M. Pea
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 bsica de las BD orientadas a columnas.
27
Jess Montes &

Jose M. Pea
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.
28
Jess Montes &

Jose M. Pea

Cassandra
Desplegable sobre un cluster.
Descentralizada: sin SPOF (punto nico de fallo).
Con replicacin local (dentro del cluster) y entre clusters.
Altamente escalable.
Coherencia ajustable (tunable consistency).
Las escrituras nunca fallan.
Qurum entre nodos.
Bloqueante hasta que se hayan escrito todas las rplicas.
29
Jess Montes &

Jose M. Pea

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
30
Jess Montes &

Jose M. Pea

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.
31
Jess Montes &

Jose M. Pea

Cassandra
Ejemplo: servicio de msica
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.
32
Jess Montes &

Jose M. Pea

Cassandra
Canciones
CREATE TABLE songs (
Listas
CREATE TABLE playlists (
id uuid PRIMARY KEY,
id uuid,
title text,
song_order int,
album text,
song_id uuid,
artist text,
title text,
data blob
album text,
);
artist text,
PRIMARY KEY (id, song_order)
);
33
Jess Montes &

Jose M. Pea
Tecnologas de recuperacin y
procesamiento masivo
34
Jess Montes &

Jose M. Pea
MapReduce
Framework para el procesamiento de grandes problemas paralelizables.
Pensado para grandes volmenes de datos.
Hace uso de grandes clusteres o grids (muchos nodos).
Hace uso de tcnicas de bajo nivel para mejorar el rendimiento, como la
localizacin de los datos.
Inspirado por el modelo map/reduce de la programacin funcional, pero
con diferentes objetivos.
La base de muchas iniciativas de Big Data.
35
Jess Montes &

Jose M. Pea
MapReduce vs. map/reduce

map/reduce es una tcnica clsica de programacin funcional:
map(f, X) = [f(x1), f(x2), f(x3), ]: aplica la funcin 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 funcin f. Tambin llamado fold o accumulate.
36
Jess Montes &

Jose M. Pea
MapReduce vs. map/reduce

MapReduce es un framework de computacin distribuida, inspirado en
map/reduce pero con el objetivo de hacer posible el procesado de
grandes volmenes de datos.
Fase Map: Los datos de entrada del problema se dividen en bloques (subproblemas), que se distribuyen entre los nodos. Cada nodo procesa su subproblema.
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

combinacin de resultados (Reduce()).
37
Jess Montes &

Jose M. Pea
MapReduce
Lo cinco pasos de MapReduce:
1. Se prepara la entrada del Map(): Particin y diseminacin 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.
38
Ejemplos tpicos: wordcount, grep,

Jess Montes &
Jose M. Pea
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 funcin de su estado actual y el estado de sus vecinos.
Evoluciona de manera iterativa.
Cmo calcular la evolucin del grafo usando MapReduce?
39
Jess Montes &

Jose M. Pea

de grafos
Solucin:
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 funcin de los mensajes
recibidos: Reduce([(B:B), (B:A),(B:D), (B:E)]) = Estado de B en funcin de B, A, D y E.
Se ejecuta MapReduce de forma iterativa.
40
Jess Montes &

Jose M. Pea

de grafos
Map
Reduce
method Map(id n, object N)
method Reduce(id m, [s1, s2,...])
Emit(id n, object N)
M = null
for all id m in N.OutgoingRelations do
messages = []
Emit(id m, message getMessage(N))
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)
41
Jess Montes &

Jose M. Pea

de grafos
42
Jess Montes &

Jose M. Pea
Hadoop y HDFS
Hadoop es la implementacin 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 ejecucin de aplicaciones MapReduce.
Escalable y tolerante a fallo.
43
Jess Montes &

Jose M. Pea
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:

Localizacin de los datos en nodos donde se ejecutan los Map asociados.
No completamente POSIX
44
Jess Montes &

Jose M. Pea
HDFS
45
Jess Montes &

Jose M. Pea
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 programacin de alto nivel para definir trareas map
y reduce.
46
Jess Montes &

Jose M. Pea
Wordcount en Pig Latin

input_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;
47
Fuente: Wikipeda
Jess Montes &

Jose M. Pea
Hive
Solucin de data warehousing basada en Hadoop.
Desarrollada por Facebook. Ahora parte del proyecto Apache.
Permite estructura la informacin almacenada en HDFS y acceder a ella
mediante HiveQL, similar a SQL.
Las queries en HiveQL se implementan como trabajos MapReduce en
Hadoop.
48
Jess Montes &

Jose M. Pea
Modelos de almacenamiento
dependientes de los datos
49
Jess Montes &

Jose M. Pea
Estructuras de datos particulares

Hay dominios de aplicacin que generan y gestionan informacin basada
en unas estructuras especficas: 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 clsico
pero es la estructura ms apropiada?
Hasta hace unos aos, la respuesta era s (casi siempre), los SGBD eran
comparativamente ms eficientes con una alternativa programada ad-hoc.
Ahora existe tecnologa especfica mucho ms adecuada.
50
Jess Montes &

Jose M. Pea
BD de Grafos
51
Jess Montes &

Jose M. Pea
Concepto de BD orientadas a grafos

Adecuadas para modelar se caracteriza por una
serie (ms o menos estructurada) de entidades que
establecen relaciones entre ellas:
E.g., La Web, usuarios de Facebook, autores-libros,
pelculas-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.
52
Jess Montes &

Jose M. Pea
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.
53
neo4j.org
Jess Montes &
Jose M. Pea
Elementos de una BD orientada a grafos

Nodos: Anlogo a cada fina en una tabla asociada a una entidad en un
modelo E/R.
Estn identificadas con un nombre (semntica 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
54
Jess Montes &

Jose M. Pea
Elementos de una BD orientada a grafos

Relaciones: Tan importantes (o ms) que los nodos.
Estn identificadas con un nombre (semntica de la relacin).
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
since: 12 years
name: Trinity
since: 3 days
since: 3 days
55
name: Neo
real_name: Thomas Andersson
is_the_chosen: true
Jess Montes &

Jose M. Pea
BD sin esquema
No implica que no haya un diseo por debajo.
Implica que la tipologa de entidades(nodos) que se pueden incluir no hay
que definirla explcitamente:
Se hace de forma dinmica.
En cualquier caso, en el ejemplo, tienes que definir cmo representar personajes,
enemigos, escenarios,
No existe el concepto de normalizacin:

En un BD relacional necesitas normalizar.
y hay veces, que en la implementacin de-normalizas.
56
Jess Montes &

Jose M. Pea
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 operacin de recorrido.
El indexado se realiza mediante propiedades concretas.

Requiere la construccin 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.
57
Jess Montes &

Jose M. Pea
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 clsicos.
La eficiencia se mide en recorridos de relaciones (trasversals) por segundo.
Inconvenientes:
Reparticin (sharding) horizontal de datos:
A pesar de que la escalabilidad de las soluciones tecnolgicas actuales es buena.
La interrelacin entre los datos dificulta la creacin de particiones (shards).
Depende de los dominios o naturaleza de los datos (en algunos casos hay una fuerte localidad
que se puede aprovechar).
58
Jess Montes &

Jose M. Pea
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
59
Jess Montes &

Jose M. Pea
Ejemplo comparativo
http://java.dzone.com/articles/mysql-vs-neo4j-large-scale
Grafo artificial generado sintticamente en

base a estadsticas muestreadas:
1 milln de nodos y 4 millones de arcos.
Comparativa frente
a MySQL:
Recorrido desde un
nodo raz a lo largo
de N pasos.
Neo4J tard la
mitad de tiempo.
60
Jess Montes &

Jose M. Pea
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.
Jim Webber
Diferencia con el anterior:

Calentamiento de las caches.
61
Jess Montes &

Jose M. Pea
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
proyeccin en memoria (Java NIO).
Gestin de caches (separadas para
nodos, relaciones, propiedades y
optimizaciones).
Traversal framework:
62
Motor de queries.
Diferentes implementaciones.
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.
REST API
Java
Ruby
Clojure
JVM Language Bindings
Traversal Framework
Graph Matching
Core API
Caches
Memory-Mapped (N)IO
Filesystem
Jess Montes &

Jose M. Pea
Creacin de nodos y relaciones

Creacin de Nodos
GraphDatabaseService db =
new EmbeddedGraphDatabase("data");
Transaction tx = db.beginTx();
try
{
Node morpheus = db.createNode();
morpheus.setProperty("name",
"Morpheus");
tx.success();
}
finally
{
tx.finish();
}
63
Creacin de Relaciones
Transaction tx = db.beginTx();
try
{
Node trinity = db.createNode();
trinity.setProperty("name",
"Trinity");
trinity.createRelationshipTo(morpheus,
DynamicRelationshipType.withName("KNOWS"));
tx.success();
}
finally
{
tx.finish();
}
Jess Montes &

Jose M. Pea
Mecanismo de indexado en Neo4j

Subclase que implementan IndexManager.
Lucene (implementacin por defecto):
Indexa nodos y relaciones.
Permite bsqueda 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");
64
Jess Montes &

Jose M. Pea
Mecanismo de consulta en Neo4j

El acceso a una BD suele ser programtico:
Gestin por el usuario del nodo o relacin usado.
Los elementos de partida para la consulta se recuperan del indexado.
Se proporcionan funciones eficientes para:
Recorrido (traversal).
Bsqueda de rutas (path finding).
Bsqueda 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");
65
Jess Montes &

Jose M. Pea
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).
Traverser t = smith.traverse(Order.DEPTH_FIRST,
StopEvaluator.DEPTH_ONE,
ReturnableEvaluator.ALL_BUT_START_NODE,
relacionesMatrix.KNOWS,
Direction.OUTGOING);
Adems existen lenguajes de consulta (a-la SQL): Cypher

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
66
Jess Montes &

Jose M. Pea
Escalabilidad de Neo4j a Big Data

El principal problema es el particionamiento del grafo entre servidores:
67
Jim Webber
Jess Montes &

Jose M. Pea

El problema del particionado se
resuelve con:
Un reparto bien balanceado de los
nodos.
La bsqueda del nmero mnimo de
cortes.
Es un problema terico complejo,

sobre todo cuando el grafo
evoluciona y se modifica.
68
Jim Webber
Jess Montes &

Jose M. Pea

El segundo aspecto es la paralelizacin 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 reparticin 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.
69
Jess Montes &

Jose M. Pea

La asignacin de los contenidos
de las caches se puede:
Asociar al usuario que hace la
consulta.
Utilizar informacin del dominio
de datos.
Puede sugerir particionamientos
razonables.
Se puede elaborar en fase de diseo.
70
Jim Webber
Jess Montes &

Jose M. Pea
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 Developers Perspective

http://osintegrators.com/opensoftwareintegrators%7Cneo4jadevelopersperspective
71
Jess Montes &

Jose M. Pea
Otras alternativas
OrientDB (Orient
Technologies)
Java
Soporta SQL,
RESTful/HTTP y JSON
Transacciones ACID y
soporte documental
Licencia Apache 2.
72
DEX / Sparksee
(Sparsity-Technologies)
C++
Multilenguaje API
para desarrollo.
Transacciones aCiD
parcial.
Licencia dual
comercial/personal
TinkerGraph (TinkerPop)
Java
Todo un ecosistema
de herramientas
(Gremlin, Blueprints,
Pipes, ).
Licencia Open Source
Jess Montes &

Jose M. Pea
BD de Documentos
73
Jess Montes &

Jose M. Pea
BD orientadas a documentos
Concepto natural para el almacenamiento de registros electrnicos.
El elemento central almacenado es el documento:
Su concepto concreto depende de la implementacin especfica de la BD en
concreto, por lo general asociado con una codificacin:
Para el caso de documentos de texto: Formato de almacenamiento (PDF, MSWord, )
Para el caso de objetos: Serializacin en formato texto o binario (XML, YAML, JSON o BSON).
A los documento se les puede asociar informacin adicional:

Organizacin de grupos de objetos: Colecciones y Jerarquas.
Anotacin individual: Etiquetas y metadatos adicionales.
El concepto tampoco era nuevo (Mumps), pero su generalizacin fuera de mbitos

concretos ha hecho que sea su momento.
74
Jess Montes &

Jose M. Pea
Similitudes con otros modelos:
BD relacional:
Las colecciones seran 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.
Adems de la recuperacin de los documentos por esa clave, se pueden realizar bsquedas
por contenido de los documentos (que no se pueden hacer en BD de tipo clave-valor).
75
Jess Montes &

Jose M. Pea
Almacenamiento de objetos:
Traduccin a un formato compacto y genrico:
MongoDB usa BSON (Binary JSON).
Optimizado por cuestiones de rendimiento y navegacin.
Admite compresin.
La traduccin de formatos se hace en los drivers de las APIs de los lenguajes de

uso de la BD.
76
Jess Montes &

Jose M. Pea
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
77
Jess Montes &

Jose M. Pea
Representacin de documentos en MongoDB

MongoDB usa JSON como formato de representacin de objetos
(internamente lo traduce a BSON):
{
"_id"
: "5349aff52",
"first"
: "John",
"last"
: "Doe",
"age"
: 39,
"interests" : [
"Reading",
"Mountain Biking ]
"favorites" : {
"color": "Blue",
"sport": "Soccer"}
}
78
Identificador nico (cualquier tipo

(excepto un array).
De no existir, el sistema le
asignar uno interno.
Jess Montes &

Jose M. Pea
MongoDB: Operaciones bsicas (CRUD)

Creacin:
db.collection.insert( <document> )
db.collection.save( <document> )
Lectura:
db.collection.find( <query>, <projection> )
db.collection.findOne( <query>, <projection> )
Actualizacin:
db.collection.update( <query>, <update>, <option> )
Borrado:
db.collection.remove( <query>, <justOne> )
79
Jess Montes &

Jose M. Pea
Recuperacin y bsqueda
Los mecanismos de bsqueda se basan en ndices y etiquetas:
location1 = {
name
:
address:
city
:
zip
:
tags
"10gen HQ",
"17 West 18th Street 8th Floor",
"New York",
"10011",
: ["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]}})
80
Generacin de un ndice
por parte del usuario
Jess Montes &
Jose M. Pea
Recuperacin y bsqueda
Los documentos se pueden referenciar entre s:
location1 = {
name
:
address:
city
:
zip
:
tags
"10gen HQ",
"17 West 18th Street 8th Floor",
"New York",
"10011",
Referencias a ObjectId
dentro del sistema.
: ["business", "cool place"],
latlong: [40.0,72.0],
contact: [4b97e62bf1d8c7152c9ccb74,
5a20e62bf1d8c736ab]
contactos= db.locations.find({..},
{contact:true}).contact
db.persons.find({_id:{$in: contactos}})
81
Jess Montes &

Jose M. Pea
MongoDB para Big Data

MongoDB permite un esquema de
particionamiento (sharding) automtico de
los datos:
Los Mongo Config Servers se encargan de la
distribucin 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 va load sharing.
http://www.polyvision.org/
82
Jess Montes &

Jose M. Pea
Soporte nativo Map/Reduce

db.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); };
83
http://docs.mongodb.org/manual/reference/method/db.collection.mapReduce
Jess Montes &

Jose M. Pea
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/
84
Jess Montes &

Jose M. Pea
Alternativa (CoachDB)
CoachDB (Damien Katz):
Desarrollado en Erlang
Interfaz de acceso REST
Consulta va JavaScript + Map/Reduce
Licencia: Apache v2.
Hay otras, pero de menor relevancia.
85
Jess Montes &

Jose M. Pea
Big Data
Data Storage
86
Jess Montes &

Jose M. Pea

Data Storage PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Data Storage PDF

Transféré par

Droits d'auteur :

Formats disponibles

Big Data Data Storage

Jess Montes &

Big Data Data Storage

ndice general del tema

Jess Montes &

Big Data Data Storage

Jess Montes &

Big Data Data Storage

Jess Montes &

Big Data Data Storage

Volumen gigante de datos

Jess Montes &

Big Data Data Storage

Volumen gigante de datos

Jess Montes &

Big Data Data Storage

Volumen gigante de datos

Jess Montes &

Big Data Data Storage

Volumen gigante de datos

Jess Montes &

Big Data Data Storage

Big Data: Necesidades y condiciones de

Jess Montes &

Big Data Data Storage

Variedad: mucha variedad de datos

Se necesitan modelos de representacin flexibles. Herramientas de almacenamiento y

Big Data Data Storage

Big Data: Soluciones de almacenamiento

Infraestructura para la distribucin, anlisis y comparticin

Gestin de privacidad y seguridad

Jess Montes &

Big Data Data Storage

Big Data: Por qu no usar bases de datos

Jess Montes &

Big Data Data Storage

Big Data: Por qu no usar bases de datos

Los principales defensores de las bases de datos tradicionales cuestionan

Jess Montes &

Big Data Data Storage

Big Data: Por qu no usar bases de datos

Modelos especficos para tipologas de datos

Jess Montes &

Big Data Data Storage

Alternativas a las bases de datos relacionales

Jess Montes &

Big Data Data Storage

Jess Montes &

Big Data Data Storage

Modelos de estructuracin de datos no

Jess Montes &

Big Data Data Storage

Modelos de estructuracin de datos no

Jess Montes &

Big Data Data Storage

Modelos de estructuracin de datos no

Las bases de datos NoSQL relajan estas condiciones, presentando

Jess Montes &

Big Data Data Storage

Bases de datos con modelo clave-valor

Similar a una tabla hash distribuida (DHT).

Jess Montes &

Big Data Data Storage