Nota técnica #2

NoSQL y Tipos de Procesamiento

1
ÍNDICE

1.- OBJETIVOS DEL BLOQUE 4

2.- ¿QUÉ ES UNA BASE DE DATOS NoSQL? 4

3.- UN POCO DE HISTORIA 16

4.- TIPOS DE BASES DE DATOS NOSQL 21

5.- EJEMPLOS DE USO 33

6.- SQL vs NoSQL: VENTAJAS E INCONVENIENTES 38

7.- BBDD RELACIONALES CON COMPORTAMIENTOS NoSQL 42

8.- TIPOS DE PROCESAMIENTO 46

9.- CASOS DE USO: INTERNET OF THINGS 53

10.- BIBLIOGRAFÍA Y MATERIALES DE CONSULTA 54

2
3
1.- OBJETIVOS DEL BLOQUE
1. Objetivos generales:
En este módulo se expondrá el concepto de NoSQL y cómo han evolucionado
históricamente las bases de datos hasta llegar a nuestros días. Se explicarán los
distintos tipos de bases de datos NoSQL.

2. Objetivos específicos:
- Comprender el concepto de NoSQL.
- Distinguir las tipologías de bases de datos presentes dentro del
paradigma NoSQL.
- Entender que tipología es útil para un problema de procesamiento en
particular.
- Conocer herramientas que dotan de comportamiento NoSQL a bases de
datos SQL.

2.- ¿QUÉ ES UNA BASE DE DATOS NoSQL?

Las primeras bases de datos utilizadas eran las transaccionales y analíticas,
donde la mayoría de los SGBD utilizaban el lenguaje SQL para su
implementación.
NoSQL (o Not Only SQL) es un término propuesto por Strozzi en los 90 que
engloba una amplia variedad de tecnologías relacionadas con bases de datos
que han sido desarrolladas en respuesta a la necesidad de almacenamiento del
gran volumen de datos generados por usuarios, objetos y productos, la
frecuencia con la que dichos datos son accedidos y los requerimientos de
rendimiento y procesamiento. Desde 2009 se utiliza este término para referirse
a los Sistemas de Gestión de Bases de Datos (SGBD) que, por sus características
(desestructuración, distribución, replicación, …) deben prescindir de las
‘pesadas cadenas’ que lastran la eficiencia en los sistemas
relacionales. Los sistemas NoSQL vienen a dar respuesta a los requerimientos
originados por sistemas de la categoría ‘Analíticos’ que pretenden procesar

4
datos masivos (Big Data).
Se presentan en contraposición a las bases de datos tradicionales, que utilizan
la mayor parte de las empresas, que no fueron diseñadas para enfrentarse a los
retos de escalabilidad y agilidad que presentan las aplicaciones modernas, ni
tampoco para aprovechar las ventajas ofrecidas por sistemas de
almacenamiento económico y potencia de procesamiento disponibles
actualmente.
No obstante, las bases de datos relacionales se han ganado esta posición
predominante por buenas razones, no han dejado de ser útiles. Aunque, por
motivaciones técnicas, como puede ser la necesidad de escalado rápido en las
capacidades de sus sistemas de procesamiento y almacenamiento, por
motivaciones económicas, consistentes en buscar alternativas económicas
viables, no sólo en lo que a licencias se refiere, sino también en lo relacionado
con almacenamiento y procesamiento, o bien debido a la necesidad de rápida
adaptación a los requisitos del mercado en forma de desarrollos ágiles que
requieren otro tipo de metodologías, se está tendiendo al empleo de técnicas
NoSQL que permitan lidiar con los datos.
Por regla general, las bases de datos NoSQL se han convertido en la primera
alternativa a las bases de datos relacionales, ya que cumplen requisitos cada
vez más necesarios como son escalabilidad, disponibilidad y tolerancia ante
fallos.

Las principales características de esta tecnología son:

Modelo de datos “schemaless”

Se trata de un modelo de almacenamiento de datos que permite almacenar

cualquier dato que se desee, normalmente en pares clave-valor, sin necesidad
de conocer las claves o los tipos. Puesto que la recuperación de la información
ahí contenida dependerá de las aplicaciones de gestión desarrolladas
explícitamente para ello, se suele considerar que el esquema presente en las

5
bases de datos relacionales ha sido desplazado a las aplicaciones que corren
sobre ellas. En cualquier caso, lo que cumplen este tipo de modelos es que no
requieren esquema, no que necesariamente carezcan de él.
Supongase el ejemplo de una base de datos que almacenase los mismos en un
fichero de texto con la sintaxis clave-valor. Además, dichos elementos son
propiedades de un determinado objeto mayor, que será unívocamente
determinado por un identificador. Así, el fichero seres.txt podría contener algo
como lo siguiente:

Ejemplo de base de datos schemaless

En la figura anterior se observa un ejemplo de base de datos schemaless. Todos

los objetos que forman parte del conjunto seres tienen en común un
identificador, que será el que permita acceder a ellos unívocamente. Sin
embargo, el resto de pares clave-valor, a pesar de que en algunos casos coincida
la clave, no tiene porqué seguir un esquema determinado. Por ejemplo la clave
nombre contiene nombre y apellido en el caso del ser 152000dcf, mientras que
en el ser 845700dht únicamente contiene el nombre. Dicha clave, además,
puede contener números, como es el caso del ser gtr5678hh. También difieren
las claves definidas en cada ser, por ejemplo, la clave episodios sólo tiene
6
sentido si el ser es un personaje de la Guerra de las Galaxias, pero no en el
resto de casos. En este tipo de modelos no es necesario rellenar claves que
carecen de sentido para determinados tipos de objeto.

Arquitectura Distribuida
En una arquitectura distribuida cada componente de la misma se aloja en
diferentes nodos que se comunican a través de una red lo que permite que la
localización de cada nodo puede ser geográficamente distinta. No es necesario
que los nodos de la red sean idénticos, cada uno puede tener diferentes
recursos. En este tipo de arquitecturas cada nodo del conjunto puede llevar a
cabo o bien una subtarea de otra mayor, es decir, procesar paralelamente una
operación concreta, o bien pueden realizar la suya propia, independiente de
las de los demás.

Ventajas:
● Arquitectura redundante, si falla parte del sistema el resto sigue
funcionando (fiable)
● Es escalable, si se necesitan más nodos solo hay que incluirlos
● Mejor rendimiento, ya que la carga de trabajo se puede distribuir mejor
● Se pueden tomar decisiones locales de forma independiente a la lógica
del negocio.
7
 ● El ancho de banda no es tan crítico como en un sistema centralizado
● Rapidez de respuesta ya que los datos están en la red local.
● Es más consistente con la estructura de la organización, dando mayor
flexibilidad. Si un grupo de usuarios quiere modificar parte de su sistema
lo puede hacer sin afectar al resto.

Desventajas:
● Se necesita más personal para mantener los nodos locales. Es más
complicado saber por qué se produce un fallo.
● Problemas para localizar la información, compatibilidad e
interoperabilidad.
● Mayor costo y complejidad del SW.
● Costo en llevar los cambios del SW a cada lugar, en caso de
mantenimiento.
● Integridad de los datos es más difícil de controlar, así como la
redundancia, inconsistencia, seguridad, etc.

Existen diferentes tipos de arquitecturas distribuidas que se diferencian por el

papel que toma cada nodo en la red y la forma de comunicación entre ellos, los
dos tipos principales son:

● Cliente-Servidor: En este caso cada elemento de la red juega un papel

diferente. El servidor se encarga de recibir las peticiones de sus clientes
y enviarles una respuesta a la misma. Se trata de una forma muy
adecuada para proveer de servicios que dependen de un recurso central,
ya sea una base de datos, un procesador, etc.
En la práctica existen sistemas con diferente grado de descentralización.
Por ejemplo en modelos de clientes ligeros, la gestión de datos y el
procesamiento están en el servidor, la presentación en el cliente. La
desventaja en este caso: la carga de procesamiento está en el servidor,

8
 por lo que es un cuello de botella. Además sobrecarga la red al tener
que transmitir más datos.
En modelos de cliente pesados, en cambio, el servidor solo tiene la
gestión de datos. Se emplea en los cajeros automáticos, el servidor lo es
de transacciones (no se comunica con la base de datos, sino con un
intermediario llamado monitor de proceso). Ventaja: distribuye carga de
trabajo y mejora el rendimiento. Desventaja: si hay cambios de software
hay que reinstalar todos los clientes.
También tenemos el Modelo Cliente servidor con tres capas. Se utiliza
en banca electrónica en Web. El servidor realiza la gestión de datos, un
segundo servidor (web) procesa el servicio de cuentas (transferir dinero,
estados de cuenta, pagar facturas, ...) y finalmente está el cliente

● Peer2Peer: Los sistemas P2P son aquellos en los que las tareas se
distribuyen entre todos los componentes del sistema. Todos los
componentes pueden jugar un papel diferente en cada momento de
forma que se comparten los recursos de memoria y procesamiento.
Ventajas: Es redundante, por lo que es tolerante a problemas como
nodos desconectados
Desventajas:
● Sobrecarga porque la misma búsqueda la pueden procesar varios
nodos, alternativa, sistema semicentralizado en que algunos
nodos sirven de servidores (p.e. Servidor buscador de servicios),
o nodos que sirvan de distribución de trabajo y de comprobación.
● Tiene problemas de seguridad y autenticidad, por lo que es mejor
en sistemas de información no críticos o dentro de una
organización
● Flujos de control complicados que pueden llegar a punto muerto.
Se necesita sincronizar las peticiones

9
 Arquitectura distribuida cliente-servidor frente a arquitectura P2P

Escalabilidad horizontal
El concepto de escalado horizontal se entiende con mayor facilidad si se
compara con la escalado vertical. En general, en cualquier conjunto de recursos
disponibles, el escalado vertical implica que, para aumentar el conjunto total
de recursos, se debe aumentar cada uno de ellos individualmente, mientras
que, en el caso del escalado horizontal, el aumento total viene dado por la
adición de recursos individuales.

Sistema de escalado horizontal vs vertical

En esta otra figura se esquematiza un ejemplo de escalado vertical frente a

escalado horizontal. En el primer caso aumenta el tamaño del recurso, en el
segundo el número.

10
Desde el punto de vista de las bases de datos, el escalado horizontal se refiere
al particionamiento de los datos. Cada nodo del conjunto de recursos contiene
únicamente parte de los datos de forma que, en este esquema, al aumentar
recursos los datos quedarán distribuidos entre más nodos. En el caso del
escalado vertical, los datos quedarán en el mismo nodo, sólo que ese nodo
tendrá más capacidad para manejarlos.

El escalado horizontal es más dinámico que el vertical, únicamente consiste en

añadir nodos, no obstante, presenta el problema de la distribución conveniente
de los datos, además, la probabilidad de fallo aumenta. Por su parte, el
escalado vertical tiene límites, cada nodo no es infinitamente ampliables. En
particular, las ventajas del escalado horizontal frente al escalado vertical son
las siguientes:

● Disponibilidad continua: Es necesario asumir que los fallos existen y son

inevitables. En este sentido, los sistemas distribuidos tienen una
probabilidad de fallo mayor, ya que el número de nodos también lo es.
Sin embargo, el tiempo de recuperación en un sistema centralizado suele
ser mayor y la probabilidad de recuperación menor. En los sistemas
distribuidos las técnicas de redundancia, también distribuida,
disminuyen la probabilidad de pérdida de datos. Si se produce un fallo y
se tiene un único nodo, es altamente probable perder información, a
pesar de asegurar un sistema redundante.

● Flexibilidad en coste y rendimiento: La ratio coste/rendimiento es un

factor crítico desde el punto de vista empresarial, sobre todo en el caso
de proveer servicios SaaS, donde el margen de beneficio suele ser bajo.
Es por ello que tener la capacidad de poder adaptarse al mercado, en lo
que a coste de hardware se refiere, supone una
ventaja competitiva. En el caso del escalado horizontal esta adaptación

11
 es posible porque, como se ha comentado, cada nodo de la red puede
disponer de diferentes recursos. Sin embargo, en el caso del escalado
vertical la limitación es mucho mayor, ya que las restricciones en
ampliación de hardware también lo son.

● Actualizaciones continuas: En lo que a las aplicaciones se refiere los

sistemas distribuidos también presentan ciertas ventajas. En este caso
es posible dividir la funcionalidad software en diferentes paquetes que
corran en nodos diferentes, así, en caso de requerir la actualización de
una funcionalidad completa, sería posible reiniciar únicamente una
parte de la misma, sin necesidad de cortar completamente el servicio.

● Distribución geográfica: Los sistemas distribuidos, al comunicarse a

través de la red, permiten disminuir la latencia geográfica ya que es
posible colocar cada nodo de la red en un punto diferente del planeta.
Además, presenta la ventaja de que, al estar situados en lugares
diferentes, los fallos derivados de cortes de luz, desastres
naturales, etc., no suelen producirse en cadena.

Hadoop
Pero es imposible hablar de todas estas ventajas de la escalabilidad horizontal
sin mencionar Hadoop. Y es que sin este software de código abierto resulta
difícil concebir tanto un almacenamiento, como un procesamiento y extracción
de valor de los grandes datos a un bajo coste.

No en vano, la arquitectura de Hadoop tiene unas características que se

adaptan a la perfección a las necesidades del universo Big Data, tanto para su
almacenamiento como para permitir el intercambio de archivos y la posibilidad
de llevar a cabo análisis de datos heterogéneos de forma rápida, flexible,
escalable, a bajo coste y resistente a fallos.

12
La arquitectura de Hadoop permite llevar a cabo un análisis eficaz de grandes
datos no estructurados, añadiéndoles un valor que puede ayudar a tomar
decisiones estratégicas, a mejorar los procesos de producción, ahorrar costes,
etc. Lo hacen posible su tecnología escalable, su velocidad (no en tiempo real,
al menos no sin ayuda, como la que proporciona Spark), flexibilidad, entre otros
puntos fuertes. Si tenemos que señalar sus cinco principales ventajas, serían
las siguientes:
● Tecnología altamente escalable: Un clúster de Hadoop puede crecer
simplemente añadiendo nuevos nodos. No es necesario hacer ajustes que
modifiquen la estructura inicial. Por lo tanto, nos permite un
crecimiento fácil, sin estar atados a las características iniciales del
diseño, haciendo uso de decenas de servidores de bajo coste que, a
diferencia de la base de datos relacional, no puede escalar. Gracias al
procesamiento distribuido de MapReduce, los archivos se dividen en
bloques de forma sencilla.
● Almacenamiento a bajo coste: La información no se almacena de forma
predefinida, en filas y columnas, como ocurre con las bases de datos
tradicionales, sino que Hadoop asigna datos categorizados a través de
miles de computadoras baratas, y ello supone un gran ahorro. Sólo así se
convierte en factible. De otro modo, no podríamos trabajar con grandes
volúmenes de datos, pues el coste sería altísimo, inasumible para la gran
mayoría de las empresas.
● Flexibilidad: Al incrementar el número de nodos del sistema también
ganamos en capacidad de almacenamiento y procesamiento. A su vez,
es posible agregar o acceder a nuevas y diferentes fuentes de datos
(estructurados, semiestructurados y no estructurados), al tiempo que
existe la posibilidad de adaptar herramientas accesorias que funcionan
en el entorno Hadoop y ayudan en el diseño de procesos, la integración
o mejorar otros aspectos.
● Velocidad: De poco nos servirán su bajo coste, escalabilidad y
flexibilidad si el resultado no es razonablemente rápido.

13
 Afortunadamente, Hadoop también permite ejecutar procesamientos y
realizar análisis muy rápidos.
● Tolerancia a fallos: Hadoop es una tecnología que facilita almacenar
grandes volúmenes de información, lo que a su vez permite recuperar
datos de forma segura. Si un equipo se cae, siempre hay otra copia
disponible, con lo que es posible la recuperación de datos en caso de
producirse fallos.

En relación con el sistema de archivos, decir que el sistema distribuido de

ficheros HDFS (Hadoop Distributed File System) está diseñado para ofrecer
una alta disponibilidad incluso ejecutándose en sistemas con prestaciones
comunes. Teniendo en cuenta que este sistema tiene que manejar un alto
volumen de datos y el tipo de hardware sobre el que se ejecuta, HDFS
proporciona mecanismos para la recuperación ante fallos de hardware.
Además, también el sistema está diseñado para aplicaciones donde los datos se
escriben una vez y se leen muchas veces, siendo el soporte adecuado para
Apache Hadoop.

Tal y como se indica en la figura anterior, un clúster HDFS está compuesto de

múltiples DataNodes y de un NameNode que se relacionan entre sí según una
arquitectura maestro/esclavo. El NameNode se encarga de gestionar el espacio
14
de nombrado de los ficheros y gestionar el acceso de los usuarios a los ficheros.
Los DataNodes se encargan de almacenar los diferentes bloques en los que se
divide un fichero. Para mejorar la disponibilidad ante fallos teniendo en cuenta
el ancho de banda utilizado, cada uno de los bloques se almacena en tres
máquinas diferentes, de forma que si una de ellas deja de funcionar aún hay
otras dos que contienen la misma información.

Capacidades transaccionales

Actualmente el concepto de operación transaccional está cambiando debido a

Internet, y ha quedado demostrado que las transacciones ACID (Atomicidad,
Consistencia, Aislamiento y Durabilidad) son un requerimiento en los sistemas
de gestión de bases de datos.

Se trata de una afirmación que puede resultar excesiva, teniendo en cuenta

que la mayor parte de los sistemas de bases de datos implementados en la
actualidad han seguido fielmente los requisitos ACID. Sin embargo, no se refiere
a que no sea fundamental asegurar dichos requisitos, sino que más bien algunos
de ellos dejan de tener sentido. Por ejemplo, la Consistencia en las bases de
datos relacionales se consigue a través del uso de claves externas y
restricciones de integridad referencial. Sin embargo, en las bases de
datos NoSQL este requerimiento no aplica, ya que no existen las operaciones
UNION. La Consistencia proporcionada en las bases de datos NoSQL sigue el
Teorema de CAP (o Teorema de Brewer), que enuncia lo siguiente:

Teorema de CAP
En un sistema distribuido, no es posible proveer simultáneamente las siguientes
garantías:

1. Consistencia. De forma que todos los nodos dispongan de la misma

información. en el mismo momento.

15
 2. Disponibilidad: Garantía de que cada petición a un nodo reciba una
respuesta sobre su correcta resolución o fracaso.
3. Tolerancia al particionamiento: Garantía de que el sistema completo
pueda continuar funcionando en condiciones normales a pesar de que se
produzca un fallo que implique la desconexión de una parte de la red de
nodos.

Así pues, aunque las bases de datos NoSQL cumplen con las siglas AID de ACID,
la consistencia se asegura en un sentido diferente debido a la propia naturaleza
de un sistema distribuido.

3.- UN POCO DE HISTORIA

Un dato (Del lat. datum, lo que se da) es una representación simbólica de un
atributo o variable cuantitativa o cualitativa. Así, desde que comenzaron a
representarse simbólicamente los atributos o variables de este tipo existen los

16
datos. No obstante, esta visión se relaciona más con la Historia que con las
bases de datos.

Las primeras bibliotecas de los templos mesopotámicos podrían considerarse

las primeras bases de datos de la historia, no obstante, tradicionalmente han
estado siempre relacionadas con el mundo informático, de hecho, la primera
vez que se habló del término base de datos fue en 1963 en un simposio
organizado por la System Development Corporation de Santa Mónica en
California. Se define como un conjunto de datos que mantienen una cierta
estructura regular y que se organizan según dicha estructura de forma que un
ordenador pueda encontrar con facilidad la información deseada. Nótese que
esta definición remarca la regularidad en la estructura, la cual no siempre tiene
que estar presente.

El comienzo de lo que actualmente se entiende por base de datos se puede

situar en 1884 cuando Herman Hollerith, considerado el padre de las máquinas
de procesamiento de datos o computadores, inventó un sistema basado en
tarjetas perforadas que permitía realizar estadísticas automáticas.
No fue hasta 1950 cuando se desarrollaron las primeras cintas magnéticas en
las que se grababan los datos en pistas sobre una banda plástica con un metal
magnetizado. Se trata del origen de los sistemas de almacenamiento de acceso
secuencial que marcarían el inicio del desarrollo de soportes capaces de
almacenar una gran cantidad de datos.

Desde entonces, cada década hasta la actualidad se ha visto caracterizada por

desarrollos que han permitido llegar al estado del arte actual.

1960
En los años 60 el precio de los ordenadores disminuyó de tal forma que hizo
posible que las empresas pudiesen adquirir este tipo de dispositivos. Además,
se popularizó el uso de discos que, además de ser capaces almacenar

17
información como las cintas magnéticas, permitían el acceso aleatorio a la
información contenida, resultando mucho más adecuados para tareas de
búsqueda que requerían acceso rápido a los datos sin necesidad de conocer la
ubicación exacta de su grabación en el dispositivo.

Fue en esta década también cuando aparecieron las primeras bases de datos
jerárquicas, que relacionaban las entidades que formaban el modelo de datos
en una estructura de árbol padre-hijos. También surgieron las bases de datos
de red, muy similares a las jerárquicas con la salvedad de que permitían
relacionar las entidades con un mayor número de enlaces, es decir, un hijo
podía tener muchos padres, de manera que se podían crear estructuras de grafo
más complejas. No obstante, a pesar de que el segundo tipo fue ampliamente
utilizado, su popularidad descendió debido a que IBM eligió el modelo
jerárquico para su Information Management System (IMS).

También fue en esta época cuando IBM junto con la American Airlines,
desarrolló SABRE (Semi-Automatic Business Research Environment). Se trataba
de un sistema central de gestión de vuelos pionero en las transacciones online.
Los ordenadores que componían el sistema fueron conectados a través de una
red que permitía que usuarios de todo el mundo accediesen a la información
sobre los vuelos y realizasen peticiones de información sentando las bases del
comercio electrónico.

También fue en 1963 cuando Charles W. Bachman desarrolló el Integrated Data

Store (IDS), uno de los primeros sistemas de gestión de bases de datos, como
parte del producto Manufacturing Information And Control System (MIACS).
Además, desarrolló el primer sistema de acceso concurrente a IDS en lo que se
denominó WEYCOS en 1965.

Bachman perteneció a la Conference on Data Systems Languages (CODASYL),

fundada en 1959, cuyo objetivo consistía en desarrollar un lenguaje de

18
programación estándar. De sus esfuerzos surgió, entre otras cosas, el lenguaje
COBOL.

1970
En la década de los 70 el hito más relevante lo proporcionó Edgar Frank Codd
definiendo el modelo de datos relacional (RDBMS - Relational Data Base Model
System). Publicó sus estudios en el paper "A Relational Model of Data for Large
Shared Data Banks", pilar de las bases de datos relacionales.

Posteriormente publicó 12 reglas, conocidas como las 12 reglas de Codd que

permitían, mediante su cumplimiento, determinar si un sistema de base de
datos era o no relacional.

No obstante, inicialmente, el modelo relacional no podía competir con el

rendimiento de las bases de datos jerárquicas, más extendidas en la época. Fue
el proyecto de IBM System R, basado en los trabajos de Codd, el que impulsó la
extensión del nuevo modelo.

Fue en esta misma época cuando Larry Ellison fundó la Oracle System
Corporation, debido al nombre de su producto principal, la base de datos
Oracle. Ellison había oído hablar System R y quiso compatibilizar ambos
sistemas, pero no le fue posible debido al rechazo de IBM de proporcionarle el
código de System R.

1980
El modelo relacional conoció en esta época su principal crecimiento, debido a
la comercialización de sistemas relacionales y, en 1986, la publicación del
lenguaje Structured Query Language (SQL) se convirtió en el estándar de la
industria.

Además, en esta década, se iniciaron grandes investigaciones que dieron lugar

19
al Sistema de Gestión de Bases de Datos Orientadas Objetos o System
Management Object Oriented Databases (SGBDOO). En estas bases de datos la
información se representa siguiendo el paradigma de programación orientada a
objetos.

Timeline de la evolución de las bases de datos

1990
Como consecuencia de la investigación de las bases de datos orientadas a
objetos surgieron distintos softwares de gestión de datos como Excel y Acces
de la empresa Microsoft. Es lo que se considera la tercera generación de
sistemas de gestión de bases de datos. Además, el lenguaje SQL evolucionó en
su estándar para permitir el uso de nuevas expresiones regulares, consultas
recursivas y triggers.

En cualquier caso, el suceso que caracterizó la década de los 90 fue la aparición

de la World Wide Web (WWW), un sistema de distribución de documentos
conectados entre sí por hiperenlaces accesibles vía Internet. Su disponibilidad
20
continua y la facilidad de acceso a las bases de datos descentralizadas supuso
el punto de partida de los nuevos caminos de investigación que siguen presentes
en la actualidad.

4.- TIPOS DE BASES DE DATOS NOSQL

En los últimos años se han desarrollado numerosas bases de datos que

responden al esquema NoSQL. Cada una tiene una serie de características que
las hacen más adecuadas para una determinada tarea. En esta sección se
detallan los diferentes tipos existentes, qué características tienen y algunos
ejemplos de cada una de ellas.

Clave-valor
Este tipo de base de datos provee modelo más simple de modelado consistente
en una clave y un valor asociado a dicha clave. Las consultas de búsqueda sobre
los datos así almacenados se deben hacer por medio de su clave, los valores
aparecen opacos frente al motor de búsqueda. Si se compara con el modelo
relacional, cada clave se corresponde con una columna, pero en este caso sólo
existen registros independientes, no hay estructura. En la Figura 7 se muestra
un ejemplo de modelado del conjunto de datos seres. En este caso, cada uno
de los seres sólo podría ser accedido mediante su clave y el motor de la base
de datos no entendería qué significa cada valor, así no sería posible, por
ejemplo, obtener los nombres o las edades de los seres sin recuperar el registro
completo.

21
Esquema de registros en una base de datos NoSQL de tipo clave-valor

La ventaja que presentan estas bases de datos es que son muy rápidas en lo que
a lectura/escritura se refiere, únicamente supone un acceso a disco.
Por otra parte, existen tipos de bases de datos clave-valor diferenciadas por la
forma en la que almacenan los datos y mantienen su consistencia, en particular:

● Almacenamiento en memoria: Se trata de bases de datos que

almacenan los registros en memoria principal, no en disco y son, por
tanto, muy rápidas ya que se elimina el tiempo de latencia de búsqueda
en disco. En esta categoría se incluyen memcached, Repcached, Oracle
Coherence, Infinispan, Websphere eXtreme scale, JBoss cache y
Terracotta Ehcache, entre otras.

● Almacenamiento clave-valor regular: En este caso los registros sí son

almacenados en disco. Algunos ejemplos son: Amazon SimpleDB, Flare,
Schema-free, RAMCLoud, Twisted Storage, Redis, Tokyo Cabinet,
Lightcloud, NMDB y Lux IO entre otros.

● Almacenamiento clave-valor eventualmente consistente: Un sistema

de base de datos eventualmente consistente es aquel que cumple el

22
 Teorema de CAP definido en la sección ¿Qué es NoSQL?. Una definición
informal sobre su significado es la proporcionada por Doug Terry et. al.*
Algunos ejemplos de bases de datos NoSQL eventualmente consistentes
son Amazon Dynamo, Voldemort y Dynomite, entre otras.

*Base de datos eventualmente consistentes: "All replicas eventually receive all writes (assuming sufficient
network connectivity and reasonable reconciliation schedules), and any two replicas that have received
the same set of writes have identical databases." (Doug Terry et. al.)

Orientadas a documento

Las bases de datos orientadas a documento son una extensión del modelo
anterior. Los datos se almacenan en un formato estructurado más complejo,
denominado documento, cuyos elementos son entendidos por el software que
compone la base de datos. Debido a ello no existe una limitación tan estricta
sobre la forma de búsqueda, en estos casos es posible analizar los datos
almacenados haciendo queries sobre más campos, no únicamente la clave.
Gracias a esta característica se trata de bases de datos adecuadas para
aplicaciones orientadas a contenido (Facebook, blogs, etc.).

Esquema de registros en una base de datos NoSQL orientada a documento

23
El elemento central de este tipo de bases de datos es el documento. Se trata
de una estructura, más o menos compleja, que encapsula información siguiendo
un determinado formato estandarizado. No obstante, este estándar puede
variar notablemente entre implementaciones. Cada documento se almacena en
disco codificado siguiendo un formato que, de nuevo, depende de la
implementación. Los más comunes son JSON/BSON, XML y YAML. Algunos de
estos formatos serán estudiados en secciones posteriores.

A su vez, los documentos se suelen agrupar en colecciones. Se trata de

estructuras que aglutinan documentos relacionados en concepto y que,
generalmente, quedan unívocamente determinados por un ID que puede ser
generado automáticamente por la base de datos. En el ejemplo de la Figura la
colección podría ser seres y la información de cada ser de la colección aparece
codificada en documentos. Debido al hecho de que en este tipo de bases de
datos la información es transparente para el motor de búsqueda, sí sería posible
buscar seres por nombre, edad, estatura, etc., además de por ID.

La generación automática de IDs de nuevo depende de la estrategia de

distribución de los datos que siga la base de datos. Normalmente son los IDs los
que determinan en qué nodo de la red distribuida se almacenará un
determinado documento, de manera que la correcta generación de dichos IDs
es fundamental para asegurar, en la medida de los posible, la distribución
uniforme de la información. Algunos ejemplos de bases de datos orientadas a
documento son CouchDB, MongoDB, Apache JackRabbit, ThruDB, CloudKit,
Lotus Domino y Terrastore, entre otras.

El ejemplo clásico de base de datos orientada a documento es MongoDB

MongoDB es una base de datos no relacional orientada a documento. No soporta
joins ni transacciones como en caso de las bases de datos relacionales, pero sí
implementa índices secundarios y un lenguaje de consulta propio completo. La
atomicidad de las escrituras se asegura a nivel de documento y las lecturas son

24
plenamente consistentes.
Operacionalmente MongoDB funciona con replicación maesto-esclavo e
implementa un sistema de recuperación ante fallos automático y escalado
horizontal vía particionamiento basado en rango.
Como otros noRel, se orienta a un almacenamiento no estructurado:
● Cada ocurrencia (individuo) se almacena en un documento BSON
(correspondiente al concepto de fila de una base relacional)
● Las generalidades de objetos son colecciones de documentos
(correspondiente al concepto de relación o tabla)
● Al ser no estructurado, carece de diseño previo:
○ La colección no se define: sus documentos pueden tener cualquier
conjunto de campos (incluso el mismo nombre de campo con
distintos tipos de datos)
○ El esquema global (diseño de BD) no se define: se crea la colección
al ingresar el primer elemento en ella.

Recordemos que un documento es un conjunto de datos referidos a un

individuo.
MongoDB utiliza para el almacenamiento y transferencia de datos la
representación documental BSON (Binary JSON), que es una versión de JSON
(JavaScript Object Notation: formato ligero para el intercambio de datos -es un
subconjunto de la notación de Javascript-) de mayor eficiencia en ciertos
aspectos. Tiene como ventaja su simplicidad (y eficiencia en grandes volúmenes
de datos) y, como inconveniente, que es poco seguro.
Para procesar ambos, se utiliza el lenguaje de programación JavaScript (JS)

Otra base de datos orientada a documento, pero en este caso orientada

completamente a la Web, es CouchDB
CouchDB es una base de datos orientada completamente a la Web en la que la
estructura de almacenamiento de datos es, como en el caso de MongoDB,
documentos JSON que son accedidos vía HTTP o bien mediante un navegador,

25
consola de administración o cualquier aplicación que permita realizar este tipo
de peticiones.
Soporta índices, combinación y transformación de documentos vía JavaScript y
se adapta a las características actuales de la Web así como de las aplicaciones
móviles.
Implementa además replicación incremental y comunicaciones maestro-
maestro con detección automática de conflictos en la modificación de datos.
Se trata de una base de datos altamente escalable y tolerante a particiones y,
a pesar de ser sólo eventualmente consistente, es una base de datos
comprometida con la seguridad y veracidad de la información.

Orientadas a columna

Las bases de datos relacionales almacenan la información en forma de filas, es

decir, cada nuevo registro insertado en la misma es una nueva fila y las
búsquedas se realizan, en consecuencia, por filas. Sin embargo, en este tipo de
bases de datos los registros se relacionan con las columnas (aunque no
necesariamente en una relación 1-1), y las búsquedas se realizan por columnas.
Esta diferencia reside en la forma de almacenar los registros en disco: Mientras
que en el caso relacional dos registros contiguos se corresponden con filas, en
el modelo NoSQL orientado a columna dos registros continuos se refieren a la
misma columna.

26
Esquema de registros en una base de datos NoSQL orientada a columna

A su vez, estas columnas, también denominadas tuplas, se agrupan dentro de

estructuras superiores en la jerarquía que permiten identificarlas. En
particular:
● ColumnFamily: Es la estructura inmediatamente superior a la columna
y su cometido es agruparlas de forma que se identifique qué grupo de
columnas contiene.
● Key: Es el identificador del registro, a su vez puede contener diferente
número de columnas.
● Keyspace: Se trata del nivel superior en la jerarquía, identifica el
conjunto total de datos, puede ser, por ejemplo, el nombre de la
aplicación cuyos datos se estén
almacenando.

En la figura anterior se muestra el ejemplo de los datos de seres almacenados

en una base de datos orientada a columna. Se ha añadido la raza a los registros
152000dcf y 845700dht para apreciar la potencia de este tipo de estructura.
Mientras que en otro tipo de base de datos el campo humano se almacenaría
repetidamente, en este caso sólo se guardan referencias a los IDs que se
corresponden con esa raza. Además, de esta forma, se agilizan las tareas de
análisis que implican el recorrido de todos los registros, puesto que se
almacenan contiguos y se relacionan por índices de acceso rápido. En secciones
posteriores se estudiará esta característica más en detalle.
Algunos ejemplos de bases de datos orientadas a columna son Google
BigTable[2], HBase, Cassandra e HyperTable, entre otras.

27
Cassandra es una base de datos altamente escalable, eventualmente
consistente, distribuida y de almacenamiento tipo clave-valor. Surge como el
producto de la fusión de las tecnologías distribuidas de Dynamo y el modelo de
datos Big Table de Google.
Debido a que está basada en Big Table, el modelo de datos que presenta es
orientado a familias de columnas (ColumnFamilies) lo que proporciona mayor
flexibilidad que el tipo clave-valor exclusivo.
El código fuente de Cassandra fue liberado por Facebook en 2008 y es la base
de datos que esta empresa utiliza en producción. Sus principales características
son:
● Alta disponibilidad.
● Escalado horizontal.
● Consistencia eventual (es un ejemplo de que sacrificar consistencia
permite ganar rendimiento)
● Configuración del equilibrio entre consistencia y latencia.
● Modelo de distribución P2P, lo que evita puntos de fallo únicos.

Por tanto, según sus principales características, se trata de una base de datos
pensada para funcionar en un sistema distribuido. Cada nodo del sistema juega
el mismo papel, no hay arquitectura maestro-esclavo sino P2P. La arquitectura
distribuida de Cassandra se presenta como un anillo en el que cada nodo del
cluster almacena cierta parte de los datos automáticamente, sin necesidad de
configuración.
Al igual que otras bases de datos, Cassandra proporciona un mecanismo de
replicación en el que la información se almacena de forma redundante
distribuida en distintos nodos de la red. De esta forma es como se proporciona
alta disponibilidad, ya que si un nodo falla la información persiste en otros
nodos del anillo.
Por otra parte, como consecuencia de la sencillez en la arquitectura, la
escalabilidad que se proporciona es lineal, es decir, crece linealmente con la
adhesión de nodos al anillo.

28
El modelo de datos de Cassandra tiene su origen en las BigTable de Google. El
esquema se estructura de la siguiente forma, por orden de jerarquía:
● Espacio de claves (Keyspace): Primer nivel de contenido, almacena
familias de columnas. Es una práctica habitual que contenga todos los
datos de una aplicación. Se podría equiparar a una base de datos en un
modelo relacional.
● Familia de columnas (Column Family): Segundo nivel de la jerarquía,
contiene claves de filas y otras familias de columnas. Este nivel sería
equiparable a las tablas del modelo relacional.
● Clave de fila (Row Key): Identificador único de un dato almacenado
dentro de una Column Family.
● Súper columna (Super Column): Estructura tipo diccionario de columnas
identificadas por una Row Key.
● Columna (Column): Par nombre-valor con un campo adicional que
contiene el timestamp del dato.

29
En la figura anterior se muestra un diagrama con la estructura general de
almacenamiento en Cassandra. En primer lugar, se encuentra el keyspace que,
a su vez, aglutina varias column families. Estas a su vez enlazan con una serie
de claves, las row keys, que apuntan a grupos de columnas, que contienen el
propio valor del dato identificado por un nombre y un timestamp.
La arquitectura de Cassandra está orientada a solventar problemas debidos a
fallos hardware. Este tipo de fallos son mitigados empleando un sistema P2P
distribuido a través de nodos homogéneos donde todos ellos se encargan de
almacenar los datos. Por otra parte se realiza un proceso de escritura
secuencial en unos ficheros denominados commitlogs presentes en cada nodo
que almacenan toda la información sobre la actividad local asegurando así la
durabilidad de las acciones. Tras ser escritos en los commitlogs los datos son
indexados y almacenados en memoria en unas tablas denominadas memtables.
Una vez que la memoria dedicada a dichas tablas está llena, esta información
es almacenada en disco en lo que se denominan Sorted String Tables (SSTables).

Orientadas a grafo

Las bases de datos orientadas a grafos son aquellas que emplean estructuras de
tipo grafo para almacenar la información. Los elementos que la componen son
nodos, propiedades y enlaces:

● Nodos: Son los elementos centrales del grafo, cada uno de ellos se
corresponde con un objeto determinado, por ejemplo un usuario, una
Web, una empresa, etc.
● Propiedades: Son atributos que caracterizan permanentemente a los
nodos.
● Enlace: Los enlaces definen las relaciones entre nodos, dos nodos
pueden o no estar conectados por un enlace, de forma bidireccional o
no y con unos determinados atributos.

30
Esquema de registros en una base de datos NoSQL orientada a grafo

Generalmente se emplean para almacenar información sobre redes o relaciones

sociales ya que en este tipo de bases de datos los elementos cambiantes son las
conexiones entre los nodos del grafo, tanto su forma como sus atributos.
Gracias a su estructura es posible utilizar teoría de grafos para realizar
búsquedas sobre las mismas, esto las convierte en bases de datos muy
adecuadas para almacenar datos en los que la información requerida dependa
de los enlaces que conexionan los nodos.

El ejemplo de seres no sería muy adecuado para almacenarlo en bases de datos

de este tipo, ya que constan más de características permanentes que de
relaciones. En cualquier caso, por motivos de continuidad, en la figura anterior
se representa una idea de cómo podrían almacenarse los datos de seres en una
base de datos orientada a grafo. Algunos ejemplos de bases de datos orientadas
a grafo son Neo4J e HyperGraphDB, entre otras.

31
Una de las más conocidas es Neo4j, un servicio implementado en Java que
utiliza este último tipo de grafos que acabamos de describir.

Neo4J es un software libre de Base de datos orientada a grafos, implementado

en Java. Los desarrolladores describen a Neo4j como un motor de persistencia
embebido, basado en disco, implementado en Java, completamente
transaccional, que almacena datos estructurados en grafos en lugar de en
tablas. La versión 1.0 de Neo4j fue lanzada en febrero de 2010. La base de
datos está licenciada en un modelo dual, tanto bajo Affero General Public
License (AGPL) v3 como bajo licencia comercial.
Neo4j fue desarrollado por Neo Technology, una startup sueca con base en
Malmö y San Francisco Bay Area en Estados Unidos.

Empresas como eBay, Walmart, Telenor, UBS, Cisco, Hewlett-Packard o

Lufthansa han confiado en las cualidades de Neo4j para mejorar sus servicios:
eBay la usa para planificar las rutas del servicio de comercio electrónico;
Walmart analiza cada venta de un producto para “entender qué tipo de
artículos te gusta comprar y qué tipo de productos te puede recomendar”; Cisco
utiliza Neo4j para ofrecer soluciones personalizadas a sus clientes “sin que
tengan que levantar el teléfono y hablar”.

Neo4j usa grafos para representar datos y las relaciones entre ellos. En
concreto, utiliza grafos de propiedad para extraer valor añadido de los datos
de cualquier empresa con gran rendimiento y de una forma ágil, flexible y
escalable. Sus principales ventajas son:

Rendimiento: Las bases de datos orientadas a grafos como Neo4j tienen mejor
rendimiento que las relacionales (SQL) y las no relacionales (NoSQL). La clave
es que, aunque las consultas de datos aumenten exponencialmente, el
rendimiento de Neo4j no desciende, frente a lo que sí sucede con las BD
relacionales como MySQL.

32
Las BDOG responden a las consultas actualizando el nodo y las relaciones de esa
búsqueda y no todo el grafo completo. Eso optimiza mucho el proceso.

Agilidad: Neo4J tiene muchas ventajas, pero una es su agilidad en la gestión de

datos. Si nosotros quisiéramos llevar al límite sus capacidades, tendríamos que
superar un volumen total de 34.000 millones de nodos (datos), 34.000 millones
de relaciones entre esos datos, 68.000 millones de propiedades y 32.000 tipos
de relaciones.

Flexibilidad y escalabilidad: Cuando los desarrolladores de una empresa

trabajan con grandes datos, buscan flexibilidad y escalabilidad. Las bases de
datos orientadas a grafos aportan mucho en este sentido porque cuando
aumentan las necesidades, las posibilidades de añadir más nodos y relaciones a
un grafo ya existente son enormes.

En la Web NoSQL Databases, es posible encontrar un listado actualizado con las

bases de datos NoSQL disponibles en la actualidad clasificadas por categorías.
Como se puede observar existen otros tipos de bases de datos NoSQL, como son
las orientadas a objeto o las bases de datos XML. Sin embargo, aquí se han
tratado los tipos principales.

5.- EJEMPLOS DE USO

Como se ha visto, no existe un tipo de sistema de almacenamiento que encaje
en las necesidades de todos los usuarios. Dependiendo de la aplicación, la
priorización de los requerimientos puede ser distinta, una aplicación que se
fundamente en la estabilidad de los datos quedará mejor gestionada con una
base de datos SQL, mientras que en una aplicación que deba escalar
rápidamente será más conveniente el uso de tecnologías NoSQL.

En esta sección se describen para qué aplicaciones será más conveniente

emplear cada tipo de almacenamiento.
33
Almacenamiento NoSQL tipo clave-valor

Este tipo de almacenamiento suele ser una buena solución cuando la aplicación
únicamente requiere o genera un tipo concreto de objeto y las búsquedas sobre
esos objetos se realizan mediante un único atributo. En ese caso el uso de bases
de datos tipo clave-valor resultan muy convenientes por simplicidad y rapidez.

Supóngase, por ejemplo, una web que se adapta según el usuario conectado y,
para ello, se deben realizar un gran número de consultas a una base de datos
RDBMS. Supongamos, además, que la información de un mismo usuario cambia
en pocas ocasiones, y que, cuando lo hace, el cambio se refiere directamente
a ese mismo usuario, es decir, es un cambio controlado. En ese caso, el sistema
se puede modelar tomando el identificador de usuario como clave y el resto de
información contenida como valor, de forma que se pueda agilizar la etapa de
recuperación de datos.

Un ejemplo de este caso podría ser una aplicación similar a una parte de
Facebook, la parte en la que el usuario actualiza su propio estado y,
posiblemente, incluso en relación con actualizaciones de otros usuarios.

Almacenamiento NoSQL tipo documento

Una aplicación que encajaría en un sistema de base de datos orientada a

documento sería aquella en la que se necesitase almacenar diferentes tipos de
objetos y, además, realizar búsquedas empleando como clave cualquiera de
ellos. Por ejemplo, una aplicación de gestión de vehículos, en la que se integren
vehículos y conductores. En este caso es un requisito de la aplicación almacenar
información de naturaleza muy variada (vehículos, conductores, seguros,
piezas, mecánicos, citas, etc.) y, además, realizar consultas
sobre cualquier campo.

34
No obstante, es necesario plantearse las restricciones en la consistencia de los
datos, es decir, la importancia del factor concurrencia. Si la aplicación puede
tolerar consistencia eventual en los datos, con atomicidad y aislamiento
limitados, entonces las bases de datos orientadas a documento son una buena
opción. Sin embargo, si los datos deben cumplir completa atomicidad y
consistencia, por ejemplo si se desean bloquear usuarios en función de los
intentos de acceso fallido, entonces la alternativa del modelo relacional resulta
más adecuada.
En aplicaciones de este tipo, por tanto, puede ser conveniente implementar un
sistema mixto que incluya ambas opciones.

Almacenamiento NoSQL orientado a columna

Los casos de uso de este tipo de base de datos son similares a los orientados a
documento, es decir, muchos tipos de objetos con requerimientos de búsquedas
variadas y flexibles.
Sin embargo, en estos casos, debido a la forma de almacenar la información en
disco, son bases de datos más orientadas a proyectos con un alto flujo de datos
que, además, pueden proporcionar garantías más fuertes en lo que a
consistencia se refiere a cambio de una mayor complejidad.

Supóngase el caso de una aplicación tipo eBay, en la que se requiere un

particionamiento de los datos tanto horizontal como vertical:
Búsqueda de clientes por país, de forma que se requiera eficiencia en las
búsquedas en un rango de un tamaño considerable y altamente cambiante.
Independencia de la información que cambia en pocas ocasiones, como por
ejemplo direcciones de usuario, o raramente, como el número de pujas en curso
para un usuario.

Aunque este tipo de particionamiento se puede conseguir en un sistema

35
orientado a documento, mediante el uso de múltiples colecciones de diferentes
dimensiones, el particionamiento es más sencillo en el caso orientado a
columna.

Almacenamiento NoSQL orientado a grafo.

Debido a las características de estas bases datos su uso es muy concreto y fácil
de determinar. En este caso los elementos cambiantes son las relaciones entre
nodos, no los nodos en sí mismos y por eso suelen ser muy adecuadas para
caracterizar redes de comunicaciones.

Las bases de datos orientadas a grafos (BDOG) ayudan a encontrar relaciones y

dar sentido al puzzle completo de datos no estructurados de una empresa o
negocio. Entre sus aplicaciones están las siguientes:
● Detección del fraude: En sectores como la banca, los seguros o el
comercio electrónico. Esta base de datos puede descubrir patrones que
con otro tipo de BD sería difícil de detectar.
Las redes de fraude tienen mecanismos para delinquir que no son
detectables con el análisis lineal de los datos. Pero con un análisis
escalable de las múltiples relaciones entre los datos, esto es mucho más
fácil. Un fraude habitual es la apertura de líneas de crédito con
identidades falsas con la idea no pagar: en la actualidad, entre el 10% y
el 20% de la deuda sin respaldo en los bancos líderes tanto en EEUU como
en Europa se debe a este fraude.
● Recomendaciones en tiempo real y redes sociales: Permiten conectar
de forma eficaz a las personas con nuestros productos y servicios, en
función de la información personal, sus perfiles en redes sociales y su
actividad online reciente. En este sentido, las bases de datos orientadas
a grafos son interesantes porque son capaces de conectar personas e
intereses.
Con esa información, una empresa puede ajustar sus productos y

36
 servicios a su público objetivo y personalizar las recomendaciones en
función de los perfiles. Eso es lo que permite que se aumente la precisión
comercial y el compromiso del cliente.
● Gestión de centros de datos: Las bases de datos gráficas son el antídoto
perfecto ante el crecimiento desbordante de los datos. La gran cantidad
de información, dispositivos y usuarios hacen que las tecnologías
tradicionales no puedan gestionar tantos datos. La flexibilidad,
rendimiento y escalabilidad de Neo4j permite gestionar, monitorizar y
optimizar todo tipo de redes físicas y virtuales pese a la gran cantidad
de datos.
● Gestión de sistemas de datos maestros: La gestión de datos maestros
(Master Data Management) es un auténtico quebradero de cabeza en las
empresas. La creación de un sistema de información centralizado y fiable
siempre es una cuestión compleja. El objetivo final es que cada miembro
de una organización use los mismos formatos y aplicaciones para los
datos. Eso genera un protocolo de trabajo que es aprovechable por el
resto. Este tipo de bases de datos ayudan a crear sistemas de ese tipo
con velocidad, agilidad, rendimiento y todo eso sin perder flexibilidad y
escalabilidad con los datos. Tendríamos un sistema de creación de
insights en 360º: empleados, clientes y productos.

Modelo RDBMS

Si se requieren altos niveles de consistencia y fiabilidad, entonces las ventajas

del modelo relacional son bien conocidas. Si la aplicación requiere un gran
número de tablas con diferentes tipos de datos, un sistema centralizado, un
lenguaje de consultas altamente extendido y soporte, entonces, siempre que
el volumen de datos generado lo permita, un sistema relacional es el más
conveniente.

Un buen ejemplo puede ser la aplicación de gestión de vehículos anterior en la

37
que, además, se deban realizar búsquedas sobre cumplimiento de leyes,
matrículas, fechas concretas, números de licencias, etc. Dichas búsquedas son
más susceptibles del cumplimiento de ACID, de forma que la elección de una
base de datos RDBMS es más adecuada.

No obstante, estas ventajas son dependientes de las necesidades de

escalabilidad. Aunque actualmente la escalabilidad de las bases de datos no
relacionales se está viendo mejorada en gran medida, se suele asumir que la
aplicación no demanda actualizaciones o joins que incluyan muchos nodos ya
que la coordinación de las transacciones y el movimiento de datos entre nodos
distribuidos en un esquema relacional puede ser prohibitivo e incluso, en la
mayor parte de los casos, inexistente.

6.- SQL vs NoSQL: VENTAJAS E INCONVENIENTES

Como se ha comentado anteriormente NoSQL no es un sustituto absoluto de

SQL. En esta sección se comentarán las principales diferencias entre ambos
modelos de forma que se facilite la elección en función de las necesidades.
Las principales diferencias que se pueden encontrar son las que marcan las
claves de elección. No es posible afirmar categóricamente si un tipo de base de
datos, digamos relacional, es mejor que otra NoSQL en cualquier caso, todo
depende del uso que se le vaya a dar a la base de datos y lo que se espere de
ella. A continuación se listan una serie de diferencias que ayudan en la decisión:

Protección de la estructura y el tipo de dato (1:1)

Las bases de datos SQL requieren una estructura que implica atributos bien
definidos que deben cumplir los datos. Las bases de datos NoSQL son más
flexibles en lo que a estructura se refiere y, por tanto, aceptan una amplia
variedad de tipos almacenados en cada registro.
38
Así, las bases de datos SQL resultan más adecuadas cuando la aplicación sigue
la máxima “Structure First”, es decir, no se puede esperar que cada registro
contenga cualquier cosa y los datos siempre deben ser correctos. NoSQL, por
su parte, sigue la máxima “Store First”, se trata de casos en los que lo que
prime sea la velocidad y la capacidad de almacenamiento más que el
mantenimiento de la estructura.

En cualquier caso, siempre existe algún tipo de lógica en la estructura, tanto

en SQL como en NoSQL, la principal diferencia es dónde se localiza dicha lógica,
en el caso de SQL la proporciona la propia base de datos y en el caso de NoSQL
se encuentra en la aplicación que hace uso de la base de datos.
En este sentido, un esquema típico es utilizar SQL como base de datos maestra,
que almacena la información de gestión y NoSQL para el almacenamiento de
datos en bruto.

Lenguaje de consulta (1:0)

A pesar de las licencias que rijan cada base de datos SQL, todas ellas siguen en
mayor o menor medida el estándar Structured Query Language (SQL), de forma
que es muy sencillo adaptar la sintaxis de una determinada aplicación que pase
a consultar de una base de datos a otra.

Las bases de datos NoSQL no siguen un estándar común en lo que al lenguaje

de consulta se refiere y, por tanto, la adaptación entre bases de datos
diferentes es mucho más costosa. Se hace necesario aprender una sintaxis
diferente para cada base de datos NoSQL que se quiera utilizar.

SQL NoSQL
Almacenamiento Modelo relacional (filas y Modelo no relacional, diferente
columnas) según la BBDD.

39
 Flexibilidad Esquema fijo, cada columna Esquema dinámico, los datos se
tiene establecido qué puede pueden añadir al vuelo y cada
almacenar y cada fila debe entrada no necesariamente
cumplir las restricciones. cumple los mismos requisitos.

Escalabilidad Escalan verticalmente Escalan horizontalmente

ACID Cumplen ACID, Sacrifican,
en ocasiones, consistencia por
rendimiento y escalabilidad.

Principales diferencias entre SQL y NoSQL para la toma de decisiones

Las bases de datos NoSQL no siguen un estándar común en lo que al lenguaje

de consulta se refiere y, por tanto, la adaptación entre bases de datos
diferentes es mucho más costosa. Se hace necesario aprender una sintaxis
diferente para cada base de datos NoSQL que se quiera utilizar.

Escalabilidad (0:1)

La escalabilidad vertical es posible en ambos casos, tanto una base de datos

SQL como un NoSQL puede escalar aumentando los recursos de cada nodo del
sistema. Sin embargo las bases de datos NoSQL escalan mucho mejor
horizontalmente que las SQL debido a que suelen seguir modelos de
arquitectura distribuida.

Fiabilidad (1:0)

Debido a los requerimientos de velocidad e incluso a la propia naturaleza de los

sistemas distribuidos, las bases de datos NoSQL no garantizan la fiabilidad de
los datos en las operaciones transaccionales, en este sentido SQL es mucho más
fiable, ya que asegura la integridad y atomicidad de las operaciones realizadas
sobre la base de datos.

40
Soporte (1:0)

Como se ha visto en la sección “Un poco de historia”, las bases de datos

relacionales tienen décadas de historia, su difusión es absoluta, de forma que
es muy sencillo encontrar soporte tanto gratuito como de pago. Así, si se
requiere soporte en la solución de algún problema complejo, es mucho más
sencillo disponer del mismo en el caso SQL, a pesar de que la documentación
de algunas bases de datos NoSQL extendidas, como MongoDB, esté en un punto
de madurez adecuado.

Necesidades de consulta y análisis (1:1)

Las bases de datos SQL encajan bien en un esquema en el que se requiera

realizar consultas muy complejas debido, entre otras cosas, a la fuerte
estructura de los datos. Sin embargo, en este sentido, existen frameworks sobre
NoSQL dedicados al análisis complejo de los datos. Además, es importante
destacar en este punto que la gestión del almacenamiento y manejo de datos
en SQL puede imposibilitar la realización de determinados análisis.

ACID (1:0)

La mayor parte de las bases de datos SQL cumplen las propiedades ACID
(Atomicidad, Consistencia, Aislamiento, Durabilidad) mientras que las NoSQL
únicamente siguen el Teorema de CAP. En este sentido, las bases de datos SQL,
de nuevo, aseguran integridad y fiabilidad de los datos almacenados, mientras
que las NoSQL proporcionan velocidad.

Así pues, si se contabilizan los “puntos” que cumple cada tipo de base de datos,
SQL gana 6 a 3. No obstante, en función de que lo que se requiera de cada base
de datos, será conveniente emplear una u otra o, incluso, ambas.

41
7.- BBDD RELACIONALES CON COMPORTAMIENTOS
NoSQL
Como se ha comentado el término NoSQL no se refiere únicamente a bases de
datos no relacionales, aunque es posible que en algún momento se haya
empleado una relación directa. De hecho, el término NoSQL se define, en
muchas ocasiones como “Not Only SQL”.

En el ámbito NoSQL también se encuentran las bases de datos relacionales, en

la era del Big Data seguirán existiendo, no se trata de una sustitución. De hecho,
la pérdida de ACID en las bases de datos no relacionales no supone una ventaja
en ningún caso, se sacrifica a consta de ganar en otros sentidos antes
comentados.

No obstante, algunas bases de datos relacionales están evolucionando hacia

comportamientos NoSQL en el sentido de que van incorporando características
que las hacen más rápidas y escalables. A este tipo de bases de datos se las
conoce como NewSQL, y se pueden definir como una clase de sistemas
modernos de gestión de bases de datos relacionales que tratan de conseguir el
mismo rendimiento escalable de sistemas NoSQL para el procesamiento de
transacciones en línea, pero manteniendo durante las cargas de trabajo las
garantías ACID de un sistema de base de datos tradicional. Dos de los casos más
conocidos y evolucionados, que coinciden con las bases de datos relacionales
más extendidas, son PostgreSQL y MySQL.

En este capítulo se desarrollan las características que van incorporando ambas

bases de datos y que las están haciendo evolucionar hacia comportamientos
NoSQL.

42
PostgreSQL: JSON y HSTORE

En la versión 9.4 de PostgreSQL se han introducido nuevas características

orientadas hacia el mercado de las aplicaciones web. Se trata de aplicaciones
que tienen unos altos requerimientos de velocidad en lo que a almacenamiento
y recuperación
de un gran volúmen de datos se refiere.

Originariamente Postgres fue diseñada como una base de datos relacional

orientada a objetos extensible. Soporta objetos, clases, tipos de datos definidos
por el usuario y métodos. En los últimos años los desarrolladores de Postgres
han expandido las capacidades de la base de datos para soportar mayor
flexibilidad que encaje con los modelos de datos emergentes. Los cambios más
relevantes que han permitido esta evolución son JSON y HSTORE.

A continuación se describe cómo ambas tecnologías permiten a PostgreSQL

adentrarse en el mundo NoSQL.

JSON: (Java Script Object Notation) es una de las notaciones para el

intercambio de datos más empleada en la Web. De hecho, muchas bases de
datos eminentemente NoSQL utilizan JSON (o BSON, en formato binario) como
formato nativo de intercambio de información. La principal ventaja que
presenta es que se trata de un formato fácil de leer por humanos y fácilmente
parseable por máquinas, además de que, a pesar de ser independiente de
cualquier lenguaje, resulta familiar para los desarrolladores de los
lenguajes C (C, C++, C#, Java, JavaScript, Perl, Python, etc.), familia de
lenguajes más empleados en la actualidad.

43
Postgres proporciona un soporte robusto para JSON, contiene un tipo de dato
JSON que valida y almacena datos en formato JSON y que permite extraer
elementos de un objeto JSON, de forma que las aplicaciones que trabajan de
forma nativa en JSON (la mayoría en Web) puede utilizar Postgres para obtener
datos directamente formateados en su propio lenguaje.

Por otra parte, además del tipo de dato nativo JSON, Postgres incorpora un
parseador JSON y funciones JSON. Este hecho implica que los desarrolladores
web no necesitan implementar capas de traducción entre la base se datos y la
aplicación ya que hablan el mismo lenguaje. Además, en el caso de trabajar
nativamente con datos JSON y prescindir así de la capa de traducción, permite
acelerar los procesos de lectura/escritura a la base de datos.

HSTROE: Es la forma que Postgres tiene de almacenar pares clave/valor dentro

de una misma columna, de forma que es posible crear modelos schemaless en
una base de datos Postgres, manteniendo además el cumplimiento de ACID.
Esta forma de almacenamiento fue introducida en la versión 8.2 de Postgres
con el objetivo de adecuarse a la demanda de trabajo con datos semi
estructurados, sobre todo en aplicaciones Web.

Mediante el uso de este tipo de columnas es posible almacenar atributos

dispersos en una misma columna, así, datos que pueden aparecer sólo
ocasionalmente, pueden ser almacenados con su clave correspondiente o no sin
necesidad de completar numerosas columnas con valores nulos.

Este tipo de arquitectura es especialmente útil, por ejemplo, para almacenar

varios tipos de productos presentes en una tienda online en una única tabla.
Dichos productos puede compartir algunos atributos comunes (nombre, precio,
peso, etc.) y muchos otros particulares de cada uno.

44
MySQL: Memcached

Una caché es un tipo de memoria que mantiene duplicados algunos o todos los
datos almacenados en una o más bases de datos que permite que las
aplicaciones accedan de forma escalable y rápida a los mismos. Resulta, por
tanto, particularmente útil cuando el acceso a una determinada parte de la
base de datos resulta complicado por limitaciones producidas por los recursos
del sistema. En bases de datos distribuidas dichas limitaciones pueden
centrarse en los recursos de red.

Así, introducir una capa de cacheo de datos hace más accesible el sistema
completo, disminuyendo el tiempo de acceso y mejorando la capacidad de la
base de datos de escalar en el sentido de cumplir los requerimientos de
consistencia cuando se sufren picos de carga. Normalmente esta forma de
caché se implementa de manera distribuida, haciendo más eficiente la
disponibilidad de memoria, red y otros recursos necesarios para el acceso a la
misma. MySQL implementa este tipo de arquitectura de memoria de forma
distribuida en lo que denomina Memcached, de código abierto.

45
Además de las ventajas de acceso rápido, Memcached ha sido diseñado para
poder escalar hasta cientos de servidores, de forma que se adquiere la
característica de escalado horizontal, al menos en esta tecnología, para una
base de datos MySQL distribuida. La forma de localizar la información en las
memorias distribuidas es mediante tablas hash. Una transformación hash es un
procedimiento en el que transforma un determinado dato a un entero que
utilizan los servidores como índice de un array.

El sistema Memcached de MySQL realiza el procedimiento de transformación

hash en dos etapas, en las que se involucran los nodos y los servidores de una
red distribuida. En primer lugar, el cliente obtiene el hash de lo que quiere
buscar y busca en una tabla hash que la relaciona con la lista de servidores.
Cuando identifica el servidor en cuestión le hace la petición que requiere y
este, su vez, realiza de nuevo una transformación hash para recuperar el dato
real. Estas tablas hash son ampliables, de forma que añadir más
servidores implica únicamente, teniendo en cuenta sólo este proceso, añadir
más entradas a la tabla. No obstante, la escalabilidad horizontal completa no
está contemplada, la ampliación de los recursos del sistema completo implica
la ampliación de cada nodo individualmente.
No obstante, no incorpora ningún mecanismo de protección ante fallos, de
forma que no se cumplen los requisitos de disponibilidad en caso de que un
nodo caiga.

8.- TIPOS DE PROCESAMIENTO

Las principales características de los sistemas Big Data son la velocidad con la
que se reciben nuevos datos, la variedad de los mismos y el alto volumen de
datos tanto a incorporar o almacenar como a procesar (2). Estos datos se
obtienen desde múltiples fuentes heterogéneas (por ejemplo: temperatura de
cada una de las habitaciones de un edificio, logs de los servidores hospedados
en un CPD o el movimiento del ratón en una pantalla), por lo que es necesario
46
transformarlos o procesarlos para poder extraer información de ellos o
simplemente almacenarlos de una estructurada (RDBMS) o semi-estructurada
(NoSQL) para su análisis posterior. Actualmente se han definido varias
estrategias de procesamiento de este gran volumen de datos: batch processing
y streaming processing. Ambas estrategias se combinan en la denominada
Arquitectura Lambda para poder ofrecer un soporte integral para sistemas Big
Data.

Batch Processing

Este procesamiento descompone los datos a analizar en grupos y los procesa de

forma independiente, generalmente en diferentes máquinas. Posteriormente,
agrupa los resultados obtenidos construyendo el resultado requerido por la
aplicación o por el usuario. Este tipo procesamiento es especialmente útil para
un gran volumen de datos estáticos (es decir, que no varían, al menos, durante
el tiempo de procesamiento) y distribuidos. Sin embargo, el principal
inconveniente de este tipo de procesamiento es el retraso que puede existir
entre la solicitud de procesamiento y la obtención de la información solicitada.
Es por ello que el procesamiento en batch resulta de gran interés para el análisis
de datos históricos sobre los que, por ejemplo, basar decisiones estratégicas de
la empresa.

Apache Hadoop implementa el modelo MapReduce para el procesamiento de

los datos en paralelo utilizando el sistema distribuido de ficheros HDFS. Este
modelo se basa en descomponer el procesamiento de los datos en operaciones
map y reduce, ejecutándose cada operación en diferentes nodos de forma
simultánea. La operación map se encarga de asignar una clave a cada uno de
los datos de entrada y agruparlos según la clave asignada. La operación reduce
agrega los resultados de las operaciones map, produciendo el resultado final.
Al ser cada operación asignada al nodo donde están almacenados los datos, se

47
reduce significativamente el tiempo de procesamiento (al reducirse el uso de
la red de datos), ofreciendo fiabilidad ante fallos.

El modelo de MapReduce simplifica el procesamiento en paralelo, abstrayendo

la complejidad que hay en los sistemas distribuidos.

Streaming Processing

El objetivo de este tipo de procesamiento es reducir el retraso introducido en

el procesamiento en batch y, por tanto, soportar procesamiento en tiempo real
(o, al menos, casi tiempo real). Para ello, este tipo se basa en el procesamiento
de cada uno de los datos tan pronto como se incorporan al sistema (true stream
processing) y así ofrecer los resultados correspondientes en la menor cantidad
de tiempo posible. Los sistemas denominados “microbatch” procesan una
pequeña cantidad de datos en vez de un dato cada vez para conseguir un
análisis en tiempo real.

El procesamiento en streaming es adecuado para la extracción de anomalías o

tendencias en datos de entrada para que así reaccionar ante ellos en el menor
tiempo posible, en caso de que sea necesario.

48
Apache Storm es una plataforma de procesamiento streaming que se basa en
los siguientes elementos: spouts, bolts y topologies. Un spout representa la
entrada de datos directamente de la fuente (por ejemplo, Twitter streaming
API o bróker de mensajes como Apache Kafka o RabbitMQ). Un bolt se encarga
de procesar (filtrar, agregar…) la información de uno o varios flujos de entrada
y producir un flujo de salida. Ambos, spouts y bolts se conectan entre sí
construyendo una red que se denomina topology.

Apache Spark es una plataforma de procesamiento streaming, y en concreto,

del subtipo micro-bacth. Este sistema se basa la abstracción RDD (Resilient
Distributed Datasets) que representa una colección de sólo lectura, tolerante a
fallos y distribuida de elementos. Sobre estos elementos se pueden realizar dos
operaciones: acciones y transformaciones. Las acciones realizan una operación
sobre el dataset sin generar un dataset nuevo, como por ejemplo iterar sobre
cada uno de los miembros o contar elementos. Sin embargo, las
transformaciones manipulan el dataset de forma que se obtenga uno nuevo
como por ejemplo filtrar elementos.

49
Para conseguir reducir la latencia del procesamiento, este sistema trabaja
directamente en memoria (sin necesidad de operaciones de escritura y lectura
en el disco excepto para la carga inicial de datos y el almacenamiento de los
resultados) y se basa en DAGs (Directed Acyclic Graphs) para reducir el tiempo
de procesamiento y por tanto garantizar un uso eficiente de los recursos de
computación.

Arquitectura Lambda

La arquitectura Lambda propone un sistema de tres capas para soportar

aplicaciones de Big Data. La Batch Layer se encarga del almacenamiento de los
datos originales y de procesar vistas predefinidas (Batch Views) para que, en el
caso de ser consultadas, la latencia sea menor. La Serving Layer es la encargada
de recoger las vistas predefinidas (Batch Views y Realtime Views) y permitir al
usuario acceder a las mismas. Finalmente, la Speed Layer es la encargada de
procesar sólo los datos más recientes e incorporándolos de forma incremental
a los ya obtenidos anteriormente (Realtime Views). Adicionalmente, una vez
que la Batch Layer produce nuevos resultados, los datos manejados en la Speed
Layer se reducen, eliminándose aquellos que ya se ofrecen en la Batch Layer.
Esta propiedad se conoce como Complexity isolation ya que aísla toda la
complejidad de procesamiento en aquella capa donde los resultados son
temporales y volátiles.

50
Arquitectura Kappa

Una de las motivaciones más importantes para crear la arquitectura Kappa, fue
el evitar dar mantenimiento a dos sistemas separados (la capa batch y la capa
de velocidad). La idea principal es administrar ambos, el procesamiento de
datos y el procesamiento continuo de datos usando un único motor de
procesamiento en línea.
Partiendo de ese objetivo, la arquitectura Kappa, sólo cuenta con dos capas:
capa de tiempo real y capa de servicios. La capa de procesamiento en línea
ejecuta las actividades de procesamiento en línea y las actualizaciones de
código que permiten reprocesar los datos y visualizar los cambios en los
resultados. Normalmente, una tarea de procesamiento en línea es ejecutada
para habilitar el procesamiento de información en tiempo real. Una tarea de
procesamiento de datos en línea en particular, es la encargada de replicar toda
la información previa una vez ejecutados los códigos que modifican
información. Estas tareas son creadas bajo demanda, es decir, las instancias de
streaming que deberán reprocesar información son ejecutadas

51
simultáneamente con las instancias que ejecuta la capa de streaming con
regularidad, posteriormente, deben replicar su ejecución sobre toda la
información previa, para conservar la integridad de la misma y mantener las
reglas de procesamiento actualizadas para cada instancia.
Cuando se desea reprocesar, se inicia una segunda instancia de la tarea que se
encuentra ejecutando el procesamiento en línea (streaming processing)
comenzando a procesar en el inicio de la información ya “retenida” pero
enviando su resultado a una nueva tabla de salida. Cuando la segunda instancia
de la tarea haya terminado de procesar la información se debe cambiar la
aplicación para leer la información de la nueva tabla de salida.

Ventajas:
● Es una simplificación de la arquitectura Lambda, ya que se suprime el
uso de la capa de batch.
● La información es almacenada utilizando un log inmutable de sólo
almacenamiento, del cual se envía a almacenamientos auxiliares para la
capa de serving.
● La arquitectura Kappa permite que la migración y la reorganización de
la información a partir de diversas fuentes de información se ejecuten
de manera eficiente proporcionando la información de manera rápida a
través de la capa de streaming.
● Dada la ausencia de la capa de batch, sólo un código debe de ser
actualizado en caso de necesitar mantenimiento.
● No utiliza un esquema de base de datos relacional o un almacenamiento
basado en valores clave, como SQL o Cassandra, respectivamente.
52
Desventajas:
● Requiere del doble de espacio de almacenamiento en el sistema de base
de datos de salida temporalmente, mientras exista la posibilidad de
reprocesar la información.
● Los sistemas de bases de datos deben de soportar escritura de grandes
volúmenes de registros para el reprocesamiento.
● Las características del hardware requerido para realizar el
reprocesamiento de la información deben considerar un pequeño
porcentaje adicional para los jobs que estarán reprocesando
activamente la información en cualquier momento dado.

9.- CASOS DE USO: INTERNET OF THINGS

Internet of Things (IoT) incluye tanto sensores con recursos computacionales
limitados, objetos a los que se les ha añadido una capacidad limitada de
computación y comunicación (por ejemplo: smart TVs o smart fridges) como
dispositivos móviles de usuario como smartphones, tablets o wearables.
Centrándonos en estos últimos, la mayoría de estos dispositivos ofrecen una
capacidad de computación razonable junto con una amplia variedad de sensores
desde acelerómetros, cámaras o módulos GPS. Además, estos dispositivos
también ofrecen múltiples interfaces de comunicación inalámbricas tanto para
la conexión con Internet como para el transporte de los datos producidos por
otros dispositivos como por ejemplo relojes inteligentes o sistemas de
monitorización de constantes vitales.

De acuerdo con algunos estudios recientes, el 70% de la población mundial usará

al menos uno de los 6,1 billones de smartphones conectados a Internet. Cifra
que se incrementa hasta los 9,2 billones si incluimos otros dispositivos como
tablets. Hoy en día, cada uno de los usuarios utiliza de forma habitual una
media de 3,64 dispositivos conectados a Internet como ordenadores,
smartphones o televisiones inteligentes. Teniendo en cuenta la cantidad de
53
datos que se generan, las bases de datos NoSQL son el sistema de
almacenamiento más adecuado para su almacenamiento.

El procesamiento de los datos generados en el ámbito de Internet of Things

ofrece múltiples beneficios en diferentes campos. Por ejemplo, su aplicación
al control de los sistemas de ventilación y climatización puede suponer un
ahorro del 18% de la energía consumida. Además, su aplicación a la
monitorización del transporte puede proporcionar una reducción de hasta el
10% del combustible. Es por ello que el procesamiento de los datos (batch y/o
streaming) es muy útil para poder extraer información de ellos, y así trasladar
estos beneficios a las aplicaciones correspondientes.

10.- BIBLIOGRAFÍA Y MATERIALES DE CONSULTA

LIBROS:

1. Top 5 Considerations when evaluating NoSQL Databases. MongoDB, Julio 2014.

2. Comparación del coste total de propiedad de MongoDB y Oracle. 10gen,
Diciembre 2012.
3. The Transaction Concept: Virtues and Limitations. Jim Gray, Tandem Computers
Incorporated. Junio 1981.
4. Big Data Glossary. Pete Warden. O'Reilly, 2011.
5. Terry, D. B., Petersen, K., Spreitzer, M. J., Theimer, M. M. 1998. The case fornon-
transparent replication: examples from Bayou. IEEE Data Engineering
Bulletin21(4): 12-20
6. Eventually Consistent:Not What You Were Expecting?. Wojciech Golab,
University of Waterloo, Muntasir R. Rahman, University of Illinois at Urbana-
Champaign, Alvin AuYoung, HP Labs, Palo Alto, Kimberly Keeton, HP Labs, Palo
Alto, Xiaozhou (Steve) Li, Google. ACM, 2014.
7. Scalable SQL and NoSQL Data Stores. Rick Cattell, ACM SIGMOD Record. 2010.
54
8. Using the NoSQL Capabilities in Postgres. EnterpriseDB, 2014.
9. Big Data - Nathan Marz, James Warren – ISBN: 978-1617290343
10. Spark in Action - Petar Zecevic, Marko Bonaci – ISBN: 978-1617292606
11. Codd, E. F. (1970). "A relational model of data for large shared data banks".
Communications of the ACM 13 (6): 377. doi:10.1145/362384.362685
12. Michael Stonebraker, Samuel Madden, Daniel J. Abadi, Stavros Harizopoulos,
Nabil Hachem, and Pat Helland. 2007. The end of an architectural era: (it's time
for a complete rewrite). InProceedings of the 33rd international conference on
Very large data bases (VLDB '07). VLDB Endowment 1150-1160.
13. Werner Vogels. 2008. Eventually Consistent. Queue 6, 6 (October 2008), 14-19.
DOI=10.1145 /1466443.1466448
14. Dan Pritchett. 2008. BASE: An Acid Alternative. Queue 6, 3 (May 2008), 48-55.
DOI=10.1145 /1394127.1394128
15. Seth Gilbert and Nancy Lynch. 2002. Brewer's conjecture and the feasibility of
consistent, available, partition-tolerant web services. SIGACT News 33, 2 (June
2002), 51-59. DOI=10.1145/564585.564601
16. Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A.
Wallach, Mike Burrows, Tushar Chandra, Andrew Fikes, and Robert E. Gruber.
2006. Bigtable: a distributed storage system for structured data. In Proceedings
of the 7th USENIX Symposium on Operating Systems Design and 20/01/2015
Implementation Volume 7 (OSDI '06), Vol. 7. USENIX Association, Berkeley, CA,
USA, 15-15.
17. Avinash Lakshman and Prashant Malik. 2010. Cassandra: a decentralized
structured storage system. SIGOPS Oper. Syst. Rev. 44, 2 (April 2010), 35-40.
DOI=10.1145/1773912.1773922
18. Big Data - Nathan Marz, James Warren – ISBN: 978-1617290343
Lambda Architecture with Apache Spark.
19. Programming Hive - Jason Rutherglen, Dean Wampler, Edward Capriolo – ISBN:
9781449326944

55
 20. Use MySQL to store NoSQL and SQL data in the same database using memcached
and InnoDB. ScriptingMySQL.
21. PostgreSQL 9.4beta2 Documentation. The PostgreSQL Global Development
Group, 2014.

LISTADO DE BLOGS Y SITIOS WEBS DE INTERÉS.

1. https://blogs.gartner.com/doug-laney/files/2012/01/ad949-3D-Data-
Management-Controlling-Data-Volume-Velocity-and-Variety.pdf
2. Ericsson, “Ericsson Mobility Report.” http://www.ericsson.com/news/ 1925907
(visited March 2016).
3. https://www.digitalocean.com/community/tutorials/hadoop-storm-samza-
spark-and-flink-big-data-frameworks-compared
4. https://www.digitalocean.com/community/tutorials/an-introduction-to-big-
data-concepts-and-terminology
5. NoSQL Databases Explained. http://www.mongodb.com/nosql-explained
6. NoSQL Databases Defined and Explained. http://planetcassandra.org/what-is-
nosql/#nosql-explained
7. https://dzone.com/articles/lambda-architecture-with-apache-spark
8. Apache Spark: spark.apache.org
9. Apache Hadoop: hadoop.apache.org
10. Apache Storm: storm.apache.org
11. MySQL and Memcached. MySQL: http://www.mysql.com/why-
mysql/memcached/
12. HDFS Architecture Guide.
https://hadoop.apache.org/docs/r1.2.1/hdfs_design.html
13. Controlling Data Volume, Velocity and Variety. https://blogs.gartner.com/doug-
laney/files/2012/01/ad949-3D-Data-Management-Controlling-Data-Volume-
Velocity-and-Variety.pdf

56
14. An Introduction to Big Data Concepts and Terminology.
https://www.digitalocean.com/community/tutorials/an-introduction-to-big-
data-concepts-and-terminology
15. Apache Hadoop. http://hadoop.apache.org
16. Apache Storm. http://storm.apache.org
17. Apache Spark. http://spark.apache.org
18. Spark in Action - Petar Zecevic, Marko Bonaci – ISBN: 978-1617292606
19. Apache Spark - An Engine for Large-Scale Data Processing.
https://dzone.com/refcardz/apache-spark
20. Hadoop, Storm, Samza, Spark, and Flink: Big Data Frameworks Compared.
https://www.digitalocean.com/community/tutorials/hadoop-storm-samza-
spark-and-flink-big-data-frameworks-compared
21. https://dzone.com/articles/lambda-architecture-with-apache-spark
22. Ericsson Mobility Report. http://www.ericsson.com/news/1925907
23. Traffic Data Monitoring Using IoT, Kafka and Spark Streaming.
https://www.infoq.com/articles/traffic-data-monitoring-iot-kafka-and-spark-
streaming
24. IoT Use Case: https://www.infoq.com/articles/traffic-data-monitoring-iot-
kafka-and-spark-streaming
25. Couch DB - The Definitive Guide, http://guide.couchdb.org/index.html
26. Long list of NoSQL papers: http://nosqlsummer.org/papers

57