UNIVERSIDAD PRIVADA

ANTENOR ORREGO

FACULTAD DE INGENIERÍA
ESCUELA PROFESIONAL DE
INGENIERÍA DE COMPUTACION Y SISTEMAS

CURSO : Base de Datos

DOCENTE : Piminchumo Flores, Jorge

ALUMNOS : Bustamante Fernandez Carlos

Lizárraga Chimbor Henry
Oruna Cabrera Diego
2
Parimango Pereda Angye

0
1
7
 Índice

1. INTRODUCCION
2. Estado del arte
2.1. ¿Qué es Big Data?
2.2. ¿Para qué sirve el Big Data?
2.3. Características del Big Data: las 3 V’s
2.4. Sistemas Tradicionales de Almacenamiento de Información
2.4.1. Base de Datos Relacionales
2.4.2. Base de datos NoSQL
3. NoSQL
3.1. El movimiento NoSQL
3.1.1. Motivaciones principales del movimiento NOSQL
3.1.2. Escepticismo desde el punto de vista del negocio
3.1.3. EL NOSQL como un producto con mucho “Hype”
3.1.4. El NoSQL entendido como un rechazo al SQL
3.1.5. Necesidad de administradores de sistemas y operadores de
hardware
3.2. Base de Datos No SQL
3.2.1. ¿Qué son las bases de datos NoSQL
3.2.2. Consistencia
3.2.2.1. El Teorema CAP
3.2.2.2. ACID vs BASE
3.2.3. Almacenamiento
3.2.3.1. Almacenamiento basado en filas
3.2.3.2. Almacenamiento basado en columnas
3.2.3.3. Arboles LSM(Log Structured Merge)
3.2.4. Consultas
3.2.5. Procesamiento con MapReduce
3.2.6. Ventajas
3.2.7. Diferencias con las bases de datos SQL
3.2.8. Tipos
3.2.8.1. Bases de datos clave – valor
3.2.8.2. Base de datos documentales

–
 3.2.8.3. Bases de datos en grafo
3.2.8.4. Base de datos orientadas a objetos
3.2.9. Ejemplos
3.2.9.1. DynamoDB
3.2.9.2. Redis
3.2.9.3. HBase
3.2.9.4. Cassandra
3.2.9.5. Mongo DB
3.2.9.6. Neo4j
4. Conclusiones
5. Bibliografía
1. INTRODUCCION
En los últimos años, la cantidad de datos digitales que se genera el mundo se
ha multiplicado. Las redes sociales y el cada vez más fácil acceso a Internet
del que disponemos las personas hacen que el volumen de tráfico y de datos
que se generan sea cada vez mayor. Con el surgimiento de las bases de datos
relacionales las empresas encontraron el aliado perfecto para cubrir sus
necesidades de almacenamiento, disponibilidad, copiado de seguridad y
gestión de sus datos. Pero debido a las tendencias actuales de uso de Internet,
este tipo de sistemas han comenzado a experimentar dificultades técnicas, en
algunos casos bloqueantes, que impiden el buen funcionamiento de los
sistemas de algunas de las empresas más importantes de Internet. Este tipo de
datos que son masivamente generados reciben un nombre: BigData, y un tipo
de tecnología ha surgido para tratar de poner solución a muchos de los
problemas de los que adolecen los sistemas de almacenamiento tradicionales
cuando intentan manejar este tipo de datos masivos. Esta tecnología se
conoce como NoSQL.
Son muchas las aplicaciones web que utilizan algún tipo de bases de datos
para funcionar. Hasta ahora estábamos acostumbrados a utilizar bases de
datos SQL como son MySQL, Oracle o MS SQL, pero desde hace ya algún
tiempo han aparecido otras que reciben el nombre de NoSQL (Not only SQL –
No sólo SQL) y que han llegado con la intención de hacer frente a las bases
relacionales utilizadas por la mayoría de los usuarios.
2. Estado del arte
En el estado del arte se analizará qué es el Big Data, cómo surge, y qué
características tiene. Además, se verá qué bases de datos existían hasta ahora
para hacer frente a las necesidades de almacenamiento actuales, y si estas
bases de datos, unidas al Big Data, presentan algún problema. Finalmente, se
hará un repaso general de las distintas soluciones NoSQL que han surgido en
los últimos años para tratar de cubrir los distintos tipos de necesidades.
2.1.¿Qué es Big Data?
Diversas personalidades con autoridad en el mundo de Internet han
plasmado su opinión respecto a este tema.
Ed Dumbill forma parte del staff de O’Really Media, la conocida marca
editorial que publica multitud de libros técnicos al año, y dice esto en el libro
Big Data Now:
“Big data is data that exceeds the processing capacity of conventional
database systems. The data is too big, moves too fast, or doesn’t fit the
 strictures of your database architectures. To gain value from this data, you
must choose an alternative way to process it.” (O'Really 2012)
En el blog oficial de Microsoft Enterprise se puede leer:
“Big data is the term increasingly used to describe the process of applying
serious computing power – the latest in machine learning and artificial
intelligence – to seriously massive and often highly complex sets of
information” (HowieT 2013)
Adrian Merv, de la revista Teradata expone la siguiente definición:
“Big data exceeds the reach of commonly used hardware environments
and software tools to capture, manage and process it within a tolerable
elapsed time for its user population” (Merv 2011)
Esto es tan solo una pequeña parte de la cantidad de definiciones y de
autores que se puede encontrar en la red.
Atendiendo a estas definiciones, se podría hacer un resumen, a grandes
rasgos y proponer nuestra propia definición sobre lo que el Big Data
significa:
Big Data es la ingente cantidad de información, en su mayor parte
desestructurada, que hoy en día generamos toda la sociedad como
consecuencia de nuestra actividad tanto en Internet como fuera de ella.
Además, debido a cantidad de datos de los que se está tratando, se
necesita un nuevo y diferente enfoque a los que existen hasta ahora en lo
que a la captura, almacenamiento y procesado de toda esta información se
refiere. Esta es la única manera de que se pueda gestionar eficientemente
toda esta información. Las bases de datos tradicionales existentes se
quedan cortas, se necesitan nuevas herramientas que ayuden a llevar a
cabo todo lo expuesto
anteriormente

1 Figura extraída de https://www.academia.edu/6033574/BIG_DATA_GOOD_DATA.

2.2.¿Para qué sirve el Big Data?
El valor que el Big Data proporciona tiene que ver con los datos que se
pueden extraer de esta gran cantidad de información.
A continuación se exponen algunos ejemplos prácticos sobre donde se
podría aplicar métodos y técnicas de recolección y procesamiento de
grandes cantidades de datos (BBVA 2013):
• Más de 5.000 millones de personas poseen teléfonos móviles.
• Facebook tiene más de 900 millones de usuarios que acceden
activamente a la aplicación.
• Cada día se mandan 340 millones de tweets, lo que corresponde a una
media de 4.000 por segundo.
• Al día se generan 2,5 trillones de datos. El 90% de los datos que existen
se han generado en los últimos 2 años.
• En el mundo se efectúan 10.000 pagos con tarjeta de crédito por segundo
Por minuto…:
•…se envían 204 millones de emails.
•…se suben 3.000 fotos nuevas y se visualizan 20 millones.
•…se escuchan 61.141 horas de música
•…se descargan 47.000 aplicaciones móviles.
•…se visitan 6 millones de perfiles de Facebook.
•…se suben 30 horas de vídeo y se generan 1,3 millones de
visualizaciones.
En líneas generales, el objetivo que persiguen las tecnologías Big Data es
el de tratar de sacar el verdadero valor que guardan los datos. Esto debe
lograrse tanto a través del análisis de los datos, como con la creación de
nuevos modelos de negocio válidos para mantener viva este tipo de
tecnología.
Aunque actualmente la comunidad se está centrando mucho en la
tecnología, hay que tener presente que es necesario encontrar la forma de
dar valor a los datos en forma de nuevos modelos de negocio, o de
modelos de negocio adaptando los ya existentes
2.3.Características del Big Data: las 3 V’s
Las 3 Vs se han tomado en el universo del Big Data como unas
propiedades características de esta tecnología. Las 3 Vs hacen referencia a
la cantidad de información, la variedad de fuentes y formatos, y la velocidad
que se necesita para manipular, almacenar y procesar la información
(Soubra 2012).
La imagen que se muestra a continuación expone datos y medidas
alrededor de estas definiciones que se han tomado ya como parte de la
tecnología y de las características básicas del movimiento.
- Volumen
La cantidad de datos que procesan ciertas empresas ha crecido
enormemente. Los sistemas tradicionales de bases de datos comienzan a
tener problemas de rendimiento debido al alto volumen de información.
Por ejemplo, Google procesa 20 petabytes diariamente, y Twitter genera 8
terabytes al día.
- Variedad
Uno de los principales problemas que tiene almacenar toda la actividad que
se genera es que toda esa información se encuentra principalmente
desestructurada. Audio, vídeo, XML… datos de sensores, cotizaciones
bursátiles, datos en streaming… Toda esta variedad en las fuentes “obliga”
en cierta forma el hecho de que haya que almacenar la información sin
ningún tipo de preprocesado o estructura, complicando en gran medida el
posterior procesamiento y análisis general de los datos.
- Velocidad La velocidad de procesamiento se torna de vital importancia.
La captura, almacenamiento y procesado de información puede llegar a
tardar días en muchos modelos de información antiguos. El Big Data intenta
ser una solución a estos tiempos tan altos, mejorando los tiempos de
almacenamiento y procesado para conseguir un sistema que responda
“casi” en tiempo real a la demanda.
 Imagen extraída del artículo
http://www.datasciencecentral.com/forum/topics/the-3vsthat-define-big-data

Si algo se repite cada vez que alguien realiza un ejercicio comparativo entre
las nuevas tendencias (Big Data, NoSQL) y los sistemas y bases de datos
más tradicionales, y que es importante tener en cuenta, es que las
tecnologías relacionadas con el Big Data son unas soluciones que atienden
a una serie de problemas muy concretos, y por lo tanto, sería un error
pretender generalizar en ellas.
Cada problema ha de ser analizado y comprendido antes de poder darle
una solución. Dar el salto automáticamente y proponer una tecnología de
este tipo para abordar cualquier tipo de problema puede costarnos muy
caro el día de mañana.
Hay que tener claro que el Big Data es una tecnología en constante cambio
y crecimiento. De igual forma, el mercado y sus necesidades también se
encuentran en continuo cambio, por lo que es necesario mantener un
proceso de actualización para no quedarse atrás.
2.4. Sistemas Tradicionales de Almacenamiento de Información
A lo largo de la historia han surgido multitud de sistemas de
almacenamiento de información (bases de datos, ficheros, etc.) para cubrir
necesidades que se iban presentando en materia de almacenamiento. Así,
se pueden encontrar las bases de datos jerárquicas, que estructuran su
información en forma de árbol, y sirven por ejemplo para mantener el
espacio de nombres que manejan los servidores de nombres de dominio o
DNSs (Domain Name Servers). O bien las bases de datos en red, que son
un modelo de base de datos ampliado de las bases de datos jerárquicas,
formadas por un conjunto de datos que están interconectados entre sí
mediante conexiones de red.
Se hará especial hincapié en este apartado en las bases de datos
relacionales, una de las opciones más utilizadas hoy en día, con la finalidad
de comprobar si éstas son útiles para el almacenamiento eficiente de Big
Data.
2.4.1. Base de Datos Relacionales
El modelo relacional ha sido desde principios de los 70 y aun hoy en
día continúa siendo la forma habitual de estructurar y almacenar la
información en cualquier tipo de aplicación informática, sobre todo
 en las transaccionales (aquellas aplicaciones con numerosos
usuarios que permiten actualizaciones de la BBDD de forma
continuada y consultas pocos complejas).
Las bases de datos relacionales son aquellas bases de datos que
cumplen con el modelo relacional, que se fundamenta en el uso de
relaciones. Una relación no es más que un vínculo entre dos
entidades de la base de datos. La información contenida en las
bases de datos relacionales y las relaciones de dependencia que se
establecen entre sí, interpretados, persiguen describir el mundo real

2.4.2. Base de datos NoSQL

En los últimos años, una gran variedad de bases de datos NoSQL
han salido a la luz, creadas por compañías principalmente para
cubrir sus propias necesidades. Temas como escalabilidad,
rendimiento, mantenimiento, etc. que no encontraban en ninguna
solución que existía en el mercado.
Debido a la variedad de enfoques que existe entre requisitos y
funcionalidades que debe cumplir una base de datos NoSQL, es
bastante difícil mantener una visión general de la situación actual de
las bases de datos no relacionales.
Se puede decir que las bases de datos NoSQL son una categoría
independiente dentro del conjunto de bases de datos. Más adelante
se expondrán diversos conceptos y características comunes de las
bases de datos NoSQL. Ahora se hará una clasificación general de
las bases de datos NoSQL más importantes atendiendo a su
modelo de datos.
3. NoSQL
Como ya se ha visto en apartados anteriores, los sistemas de bases de datos
relacionales llevan mucho tiempo siendo el modelo informático más empleado
del mundo para almacenar y recuperar la información.
La famosa frase “one size fits all” tiene que ver con el diseño de estas bases de
datos relacionales porque a su vez tiene que ver con las necesidades de las
empresas y las comunidades de usuarios para con las bases de datos. Desde
hace unos años esto ha cambiado. Ahora las necesidades son diferentes, y el
BigData tiene buena parte de culpa. Revisando detenidamente los puntos que
se han ido comentando a lo largo del trabajo, hay que darse cuenta de que los
datos no son los mismos, ni están estructurados de igual manera. También ha
cambiado la manera de almacenar la información, así como la de consumirla.
Esta sección pretende centrarse en estos nuevos conceptos y razones que han
motivado un cambio de dirección enorme en el tratamiento de las bases de
datos, dando lugar a multitud de nuevas formas de almacenamiento, con partes
y estructuras comunes, y características propias y únicas que las diferencia de
las demás. En este apartado se esbozarán las características generales de las
bases de datos NoSQL.

3.1. El movimiento NoSQL

El término NoSQL fue inicialmente utilizado en el año 1998, y fue para
denominar una base de datos relacional que no utilizaba el lenguaje SQL
para funcionar. A partir de aquí, el término fue rescatado en 2009 en unas
charlas por defensores de las bases de datos no relacionales.
3.1.1. Motivaciones principales del movimiento NOSQL
Los principales motivos con los que un proyecto debe encontrarse
para que se pueda comenzar a valorar la posibilidad de dejar atrás
las bases de datos relacionales y comenzar a fijarse en las
soluciones que se tratarán más adelante en este documento son las
siguientes (Strauch 2011):
Evitar la complejidad innecesaria. Las bases de datos
relacionales proporcionan gran cantidad de funcionalidades y
restricciones para mantener la consistencia de los datos, en ciertos
casos, mucho más de lo necesario. Esto hace que, a nivel global,
las operaciones en base de datos tarden más tiempo en ayudarían a
incrementar el rendimiento.
Alto rendimiento. Muchas bases de datos NoSQL proporcionan un
rendimiento superior al que ofrecen los sistemas RDBS
convencionales. Para ilustrar esto, tan solo hay que ver ejemplos
sobre los tiempos que tardan las grandes compañías en insertar
información en sus bases de datos NoSQL. Por ejemplo, en el caso
de Google y su Bigtable. Es capaz de procesar hasta 20 petabytes
diarios (Lai 2009).
Escalabilidad horizontal y hardware de bajo coste. Al contrario
que las bases de datos relacionales, los sistemas NoSQL han sido
diseñados para escalar horizontalmente. El software está pensado
 para poder agregar o eliminar máquinas de forma sencilla sin tener
un coste operacional realmente elevado.
Complejidad y coste de levantar un clúster de base de datos.
Tiene que ver con el punto anterior, en el se exponía la facilidad y
sencillez con la que estos sistemas son capaces de añadir y quitar
nodos del sistema.
Comprometer la fiabilidad a cambio del rendimiento. La
fiabilidad en los datos es un tema muy importante, pero existen
ciertos momentos en los que se puede demandar un aumento del
rendimiento a cambio de un nivel menos de fiabilidad.
3.1.2. Escepticismo desde el punto de vista del negocio
La mayoría de las tecnologías NoSQL tiene su base en el software
open source, tan apreciado por muchos desarrolladores, que no
tienen que preocuparse por temas relacionados con licencias o
cuestiones de soporte. Sin embargo, la gente de negocio no suele
compartir esta opinión, especialmente en caso de posible catástrofe,
donde no existiría ningún tipo de soporte al que acudir.
3.1.3. El NoSQL entendido como un rechazo al SQL
En los primeros años, el NoSQL ha sido entendido de muy
diferentes maneras, especialmente con Internet como medio de
difusión. Algunos blogs anunciaban y vaticinaban el fin de las bases
de datos tan y como se conocen, criticando duramente en modelo
de bases de datos relacional. Algunos incluso cambiaron las siglas
de NoSQL, que significa “Not Only SQL” por la expresión “Not To
SQL”.
El rechazo frontal que debe existir ante este tipo de actitudes y
pensamientos por cualquier profesional, unido al sector más
defensor de las bases de datos tradicionales y del modelo
relacional, hizo que el movimiento NoSQL estuviese mal viso por un
sector importante de la industria informática en sus inicios.
3.1.4. Necesidad de administradores de sistemas y operadores de hardware
Cuando se habla de NoSQL normalmente es desde el punto de vista de la
funcionalidad, de las capacidades y de las ventajas e inconvenientes
cuando lo comparas con otro tipo de bases de datos. Normalmente es la
gente de desarrollo la que se dedica a inventar y explorar nuevas opciones
NoSQL, y a hablar sobre ellas con otros desarrolladores, pero existe otro
 tipo de perfil que también es importante cuando se habla de un desarrollo
NoSQL. Este es el operador de sistema.
Este rol, a veces dejado de lado en compañías dedicadas a computación en
la nube, es cierto que cada vez va quedando poco a poco más relegado a
un segundo plano (al menos así ocurre con el rol de administrador de
sistemas clásico), pero es importante en este caso.
Estas personas serán las encargadas de solucionar problemas que puedan
suceder con las colecciones de datos, así como diagnosticar el estado del
clúster, preparar planes de sharding, particionado, migraciones de datos, y
otro tipo de tareas diferentes a las que un desarrollador está
acostumbrado.
3.2.Base de Datos No SQL
3.2.1. ¿Qué son las bases de datos NoSQL
Hablar de bases de datos NoSQL es hablar de estructuras que nos
permiten almacenar información en aquellas situaciones en las que
las bases de datos relacionales generan ciertos problemas debido
principalmente a problemas de escalabilidad y rendimiento de las
bases de datos relacionales donde se dan cita miles de usuarios
concurrentes y con millones de consultas diarias. Además las bases
de datos NoSQL son sistemas de almacenamiento de información
que no cumplen con el esquema entidad–relación. Tampoco utilizan
una estructura de datos en forma de tabla donde se van
almacenando los datos sino que para el almacenamiento hacen uso
de otros formatos como clave–valor, mapeo de columnas o grafos.
3.2.2. Consistencia
3.2.2.1. El Teorema CAP
El teorema CAP ha sido ampliamente adoptado por las grandes
compañías de internet, al igual que por la comunidad NoSQL.
Las siglas CAP hacen referencia a:
- Coherencia. En sistema distribuido, habitualmente se dice
que se encuentra en un estado consistente si, después de una
operación de escritura, todas las operaciones de lectura
posteriores son capaces de ver las actualizaciones desde la
parte del sistema desde la que están leyendo.
- Disponibilidad (Availability). La alta disponibilidad se
produce cuando el sistema ha sido diseñado e implementado de
 modo que se pueda continuar operando (lecturas, escrituras),
incluso después de que un nodo quede indispuesto, o que
algunas partes de hardware tengan que ser retiradas, debido a
errores o actualizaciones.
- Tolerancia a Particiones (Partition Tolerance). Entendido
como la habilidad de un sistema de tener diferentes regiones o
divisiones lógicas en la red, y de ser capaz de seguir
funcionando aunque una de estas partes quede inaccesible
durante un tiempo.
La teoría CAP (también se conoce como teorema de Bewer
(Bewer 2012)) expone que es imposible que un sistema
distribuido pueda garantizar simultáneamente estas 3
características. Sin embargo, el teorema de CAP también dice
que sí puedes garantizar 2 de estas 3 propiedades.
Los SGBD NoSQL cumplen dos de estas 3 características, y por
tanto, se puede realizar una clasificación de dichos SGBDs en
función de esto.

3.2.2.2. ACID vs
BASE
El mundo de las bases de datos relacionales está familiarizado
con las transacciones ACID.
Las transacciones que se producen en el lenguaje SQL, sea
cual sea el sistema gestor de base de datos cumplen siempre
las propiedades ACID. Este tipo de transacciones se llaman así
porque garantizan la Atomicidad, la Consistencia, el aislamiento
(Isolation) y la Durabilidad.
- Atomicity (Atomicidad). Las transacciones han de ejecutarse
por completo o no ejecutarse, pero la transacción no puede
quedar a medias.
- Consistency (Consistencia o Integridad). Los datos que se
guardan tras la transacción han de ser siempre datos validos.
- Isolation (Aislamiento). Las transacciones son
independientes y no se afectan entre sí.
- Durability (Durabilidad). Una vez finalizada una operación,
esta perdurará en el tiempo.

El modelo BASE es un enfoque similar al ACID, aunque

perdiendo la consistencia y al aislamiento, a favor de la
disponibilidad, la degradación y el rendimiento.
El modelo BASE toma su nombre de:
- Basic Availability. El sistema funciona incluso cuando alguna
parte falla, debido a que el almacenamiento sigue los principios
de distribución y replicación.
- Soft State. Los nodos no tienen porque ser consistentes entre
si todo el tiempo.
- Eventual Consistency. La consistencia se produce de forma
eventual.
Para que un sistema gestor de bases de datos relacional pueda
ser considerado tal, debe cumplir el modelo ACID
 Por otro lado, el modelo no relacional se ciñe más al enfoque
BASE aquí expuesto, basándose en que las aplicaciones debe
funcionar la mayoría del tiempo (disponibilidad, no tienen que
ser siempre consistentes (soft state) y ser eventualmente
coherentes (consistencia eventual).

3.2.3. Almacenamiento
La capa de almacenamiento depende en gran medida del tipo de
base de datos que se esté tratando
3.2.3.1. Almacenamiento basado en filas
Este almacenamiento se basa en juntar de forma secuencial
todas las filas de una tabla y escribirlas juntas a disco. La
ventaja de este tipo de almacenamiento es que si se están
realizando operaciones de lectura / escritura de varias filas
seguidas, la operación se realiza en un solo acceso a disco.
3.2.3.2. Almacenamiento basado en columnas
Almacenamiento basado en la serialización de las columnas, y
la escritura conjunta a disco. Por consiguiente, las operaciones
que involucran accesos completos a los datos de las columnas
quedan favorecidos. Por otro lado, se penalizan los accesos a
información que se encuentra consecutiva dentro de una misma
fila.
3.2.3.3. Arboles LSM(Log Structured Merge)
Los Arboles LSM son un tipo de estructuras que facilitan la
organización y el almacenamiento de los sistemas de bases de
datos, especialmente de aquellos que poseen una tasa muy alta
de inserciones.
En los árboles LSM existen dos tipos de estructuras en forma de
árbol. El primer componente, más pequeño, reside
exclusivamente en memoria, mientras que el segundo persiste
directamente a disco. El proceso consiste en que cada vez que
hay que escribir un nuevo registro, este se escribe primero en el
memoria, en el primer componente, de tal forma que cuando
este primer componente alcanza un tamaño determinado, se
realiza un volcado de una parte de los registros aquí contenidos
 a disco, al segundo componente, y se liberará la memoria que
estos estaban ocupando.
Este tipo de almacenamiento de la información presenta
ventajas muy interesantes, como el uso muy eficiente que hace
de la memoria principal, por lo que es capaz de responder
peticiones muy rápidamente, además de optimizar el uso del
disco de la máquina, haciendo volcados a disco sólo cuando es
necesario para volcar una cantidad importante de información.
Por todo ello, es utilizado por sistemas gestores de bases de
datos tan importantes como son SQLite, HBase o Cassandra.
3.2.4. Consultas
Existen varias diferencias con respecto a cómo los distintos tipos de
bases de datos permiten a los usuarios / aplicaciones realizar
consultas. Desde las consultas más básicas por clave primaria,
como por ejemplo, los almacenes clave – valor, pasando por otros
que ofrecen un acceso a la información algo más complejo. En este
terreno se encontrarían las bases de datos documentales.
En general, la flexibilidad y la riqueza de las querys no son
demasiado elevadas, puesto que lo que se prima por encima de las
consultas es el rendimiento y la escalabilidad, por lo que es habitual
que se delegue a la aplicación el implementar opciones más
avanzadas en este terreno.
Un método de consulta llamado Companion SQL database consiste
en tener una base de datos auxiliar (que puede ser una base de
datos SQL o una TextDB) de forma que se utilice esta secundaria
para almacenar ciertos metadatos importantes para realizar la
búsqueda, y se empleen para facilitar la búsqueda posterior en el
contenedor NoSQL.
Búsqueda local dispersa. Otra forma de realizar consultas
consiste en, puesto que se tiene el conjunto de datos repartido entre
los distintos servidores, repartir de igual modo la consulta, de forma
que cada servidor ejecute localmente cada consulta y reenvíe los
resultados a un nodo maestro, que sería el encargado de juntar
todos los resultados y presentárselos a la aplicación.
Arboles B+ Distribuidos.
 Una forma eficiente de acelerar las búsquedas consiste en
mantener un árbol B+ que forme un índice de entradas a la base de
datos NoSQL (Aquilera, Golab and Shah 2008).
El procedimiento consistiría en sacar los valores hash de los
atributos que nos interese indexar, y construir con ellos el árbol B+.
Cuando se quiera realizar una consulta, se comenzará desde la raíz
y se irá descendiendo en orden hasta llegar a la hoja
correspondiente, que nos dará la entrada concreta donde se
encuentra el registro que se está buscando.
Al tratarse de un árbol B+, se debe tener en cuenta las
particularidades de este tipo de estructura de datos a la hora de
realizar los mantenimientos necesarios, las inserciones y borrados
que puedan hacer redimensiones en el árbol, etc.
3.2.5. Procesamiento con MapReduce
En secciones anteriores se ha hecho una introducción al framework
de programación y procesamiento en paralelo, Hadoop. Se ha
expuesto también que, entre otras cosas, una de las principales
características que posee este sistema de almacenamiento y
procesado de grandes cantidades de información es que ha
adoptado MapReduce como modelo de programación para la
plataforma, para dar soporte a la computación en paralelo de los
datos almacenados en el sistema.
Pues bien, uno de los motivos por los que este modelo de
programación cuadra tan bien con el modelo de Hadoop es porque
está especialmente pensado para grandes cantidades de
información. Las bases de datos NoSQL también comparten parte
de este modelo de datos, por lo que el procesamiento con un
framework basado en MapReduce.
Además, tanto la función map como la función reduce han de ser
entendidas de una manera realmente funcional e independiente de
la máquina donde se ejecuten, por tanto, ante la misma entrada, en
el mismo entorno de ejecución, se producirá exactamente la misma
salida. Esto significa que el particionado de la entrada en trozos más
pequeños y el reparto de éstos a través del clúster, no afectará al
resultado.
Por último, juntando algunos conceptos vistos anteriormente, se
puede utilizar el Consistent Hashing como forma de orquestación
 para el paradigma
MapReduce.
Así, se puede
repartir el
conjunto de
datos de la entrada
de igual modo
que se hace con el Consistent Hashing, por lo que los nodos
comenzarán a procesar los datos en sentido horario. Después, la
muestra de información intermedia volverá a ser consistentemente
hasheada para que los nodos finalicen con la segunda parte del
proceso, el reduce, y produzcan el resultado final.

3.2.6. Ventajas
Esta forma de almacenar la información ofrece ciertas ventajas
sobre los modelos relacionales. Entre las ventajas más significativas
podemos destacar:
- Se ejecutan en máquinas con pocos recursos: Estos
sistemas, a diferencia de los sistemas basados en SQL, no
requieren de apenas computación, por lo que se pueden montar
en máquinas de un coste más reducido. 
- Escalabilidad horizontal: Para mejorar el rendimiento de estos
sistemas simplemente se consigue añadiendo más nodos, con
la única operación de indicar al sistema cuáles son los nodos
que están disponibles. 
- Pueden manejar gran cantidad de datos: Esto es debido a
que utiliza una estructura distribuida, en muchos casos mediante
tablas Hash. 
- No genera cuellos de botella: El principal problema de los
sistemas SQL es que necesitan transcribir cada sentencia para
poder ser ejecutada, y cada sentencia compleja requiere
 además de un nivel de ejecución aún más complejo, lo que
constituye un punto de entrada en común, que ante muchas
peticiones puede ralentizar el sistema.
3.2.7. Diferencias con las bases de datos SQL
Algunas de las diferencias más destacables que nos podemos
encontrar entre los sistemas NoSQL y los sistemas SQL están:
- No utilizan SQL como lenguaje de consultas. La mayoría de
las bases de datos NoSQL evitan utilizar este tipo de lenguaje o
lo utilizan como un lenguaje de apoyo. Por poner algunos
ejemplos, Cassandra utiliza el lenguaje CQL, MongoDB utiliza
JSON o BigTable hace uso de GQL. 
- No utilizan estructuras fijas como tablas para el
almacenamiento de los datos. Permiten hacer uso de otros
tipos de modelos de almacenamiento de información como
sistemas de clave–valor, objetos o grafos. 
- No suelen permitir operaciones JOIN. Al disponer de un
volumen de datos tan extremadamente grande suele resultar
deseable evitar los JOIN. Esto se debe a que, cuando la
operación no es la búsqueda de una clave, la sobrecarga puede
llegar a ser muy costosa. Las soluciones más directas consisten
en desnormalizar los datos, o bien realizar el JOIN mediante
software, en la capa de aplicación. 
- Arquitectura distribuida. Las bases de datos relacionales
suelen estar centralizadas en una única máquina o bien en una
estructura máster–esclavo, sin embargo en los casos NoSQL la
información puede estar compartida en varias máquinas
mediante mecanismos de tablas Hash distribuidas.
3.2.8. Tipos
Dependiendo de la forma en la que almacenen la información, nos
podemos encontrar varios tipos distintos de bases de datos NoSQL.
Veamos los tipos más utilizados.
3.2.8.1. Bases de datos clave – valor
Son el modelo de base de datos NoSQL más popular, además
de ser la más sencilla en cuanto a funcionalidad. En este tipo de
sistema, cada elemento está identificado por una llave única, lo
que permite la recuperación de la información de forma muy
rápida, información que habitualmente está almacenada como
 un objeto binario (BLOB). Se caracterizan por ser muy eficientes
tanto para las lecturas como para las escrituras.
Algunos ejemplos de este tipo son Cassandra, BigTable o
HBase.

3.2.8.2. Base de datos documentales

Este tipo almacena la información como un documento,
generalmente utilizando para ello una estructura simple como
JSON o XML y donde se utiliza una clave única para cada
registro. Este tipo de implementación permite, además de
realizar búsquedas por clave–valor, realizar consultas más
avanzadas sobre el contenido del documento.
Son las bases de datos NoSQL más versátiles. Se pueden
utilizar en gran cantidad de proyectos, incluyendo muchos que
tradicionalmente funcionarían sobre bases de datos
relacionales.
Algunos ejemplos de este tipo son MongoDB o CouchDB.
3.2.8.3. Bases de datos en grafo
En este tipo de bases de datos, la información se representa
como nodos de un grafo y sus relaciones con las aristas del
mismo, de manera que se puede hacer uso de la teoría de
grafos para recorrerla. Para sacar el máximo rendimiento a este
tipo de bases de datos, su estructura debe estar totalmente
normalizada, de forma que cada tabla tenga una sola columna y
cada relación dos.
Este tipo de bases de datos ofrece una navegación más
eficiente entre relaciones que en un modelo relacional.
Algunos ejemplos de este tipo son Neo4j, InfoGrid o Virtuoso.
 3.2.8.4. Base de datos orientadas a objetos
En este tipo, la información se representa mediante objetos, de
la misma forma que son representados en los lenguajes de
programación orientada a objetos (POO) como ocurre en JAVA,
C# o Visual Basic .NET.
Algunos ejemplos de este tipo de bases de datos son Zope,
Gemstone o Db4o.
3.2.9. Ejemplos
3.2.9.1. DynamoDB
Es un SGBD propietaria desarrollada internamente por Amazon
y lanzada allá por 2007, que se incluye dentro de la oferta de
servicios que se ofrecen como parte de los AWS (Amazon Web
Services).
El servicio de Amazon permite únicamente crear nuevas tablas
en las que alojar los datos, e interactuar con ellas mediante tus
aplicaciones a través de APIs (interfaces de programación que
proporciona Amazon para poder añadir, actualizar, borrar y
consultar información de la base de datos). Es decir, no se tiene
acceso al código fuente, ni al hardware ni a los servicios que
hacen funcionar a la base de datos.
Interfaces: DynamoDB proporciona una serie de operaciones
hacia el exterior (Amazon Web Services 2012), entre las cuales
están las correspondientes a recuperar e insertar o actualizar
nuevos elementos:
• GetItem ( clave )
La operación get sirve para, dada una clave, obtener el valor
asociado a la misma. Puede devolver más de un resultado si
existieran varias versiones de la misma información. En ese
caso, en lugar de devolver un único resultado devolvería una
lista de objetos, que se corresponderían con los valores
asociados a esa clave.
Otro dato importante que devuelve es el contexto, que será
necesario después en la operación de escritura.
• PutItem ( clave, valor )
El método putItem determina, en función de la clave, donde
alojar el valor pasado por parámetro.
Todas estas invocaciones al API de DynamoDB viajan por
http(s) y están codificadas en formato JSON.
Modelo de Datos:
El modelo de datos propio de DynamoDB el siguiente: 5.4.1
Tablas
Las tablas son, al igual que en muchos SGBDs, los elementos
donde se almacenan las filas o elementos donde se guardan los
datos propiamente dichos de la base de datos.
Las tablas en DynamoDB son libres de esquema, esto es, que
dos datos de una misma tabla no tienen por qué tener los
mismos atributos, ni siquiera el mismo número de atributos.
Lo que sí deben tener todos los elementos de una tabla es un
atributo obligatorio que haga las funciones de clave primaria,
puesto que esta clave identifica unívocamente a cada elemento
dentro de los elementos de la tabla. Cada tabla puede contener
un número infinito de elementos.
Elementos
Un elemento es información con una estructura que se
almacena en la base de datos. Los elementos son los
homónimos de las filas en el modelo relacional.
Cada elemento en DynamoDB es el resultado de proporcionar
valores a un conjunto de atributos que se definen en el momento
de la inserción. Cada elemento, en conjunto con sus atributos,
tiene una restricción de tamaño máximo de 64KB.
Atributos
Los atributos son pares clave – valor o asociaciones de clave –
conjunto de valores. Estos atributos no tienen restricción de
tamaño máximo.
3.2.9.2. Redis

Se trata de una base de datos creada por Salvatore Sanfilippo y

Pieter Noordhuis y está apoyado por VMWare. Se trata de una
base de datos del tipo clave–valor. Se puede imaginar como un
array gigante en memoria para almacenar datos, datos que
pueden ser cadenas, hashes, conjuntos de datos o listas.

Tiene la ventaja de que sus operaciones son atómicas y

persistentes. Por ponerle una pega, Redis no permite realizar
consultas, sólo se puede insertar y obtener datos, además de las
operaciones comunes sobre conjuntos (diferencia, unión e
inserción).

Creado en ANSI C, por lo tanto es compatible y funciona sin

problemas en sistemas Unix, Linux y sus derivados, Solaris,
OS/X sin embargo no existe soporte oficial para plataformas
Windows.

Tipo de Datos
Redis es capaz de reconocer y manejar cinco tipos de datos
diferentes, lo cual es una ventaja con respecto a otras bases de
datos que únicamente trabajan con cadenas de caracteres
(String). Esto le da ventaja en lo que a manejo de los datos y
almacenamiento de los mismos se refiere. Los tipos de datos
son:
• String
• Set
• Hash
• List
• Sorted Set
 En la sección Modelo de Datos en la que se describe el modelo
de datos con mayor profundidad, se expondrán distintos
ejemplos de utilización de estos tipos de datos.
Poder manejar varios tipos de datos de forma nativa otorga al
sistema diversas ventajas. Cada uno de ellos ofrece una serie
de métodos para acceder y manipular la información que
almacena. Dependiendo del tipo de uso que se le vaya a hacer a
esos datos. Redis da la opción de elegir que estructura se
adapta mejor a las necesidades
3.2.9.3. HBase
HBase es un SGBD, la base de datos NoSQL de Hadoop.
HBase fue concebida inicialmente a partir de los artículos que
liberó Google sobre BigTable allá por 2004. Se podría decir que
HBase es la implementación Open Source del proyecto Bigtable
de Google.
HBase es un software construido sobre Hadoop, sin el cual no
podría funcionar a día de hoy. Hadoop confiere a HBase una
característica indispensable en su modelo de datos: la capa de
almacenamiento que proporciona disponibilidad y fiabilidad
(HDFS), mientras que la otra capacidad de Hadoop, el entorno
de computación de alto rendimiento (MapReduce)
frecuentemente es utilizado junto con HBase para acceder a la
base de datos y tratar datos en ella.

3.2.9.4.
Cassandra
Es un almacén clave valor, altamente escalable, distribuido y
eventualmente consistente.
 Cassandra es similar a DynamoDB con respecto a la
consistencia eventual que implementa en su sistema, y a la vez,
toma prestados de Google y de su proyecto BigTable el modelo
de datos estilo columnar.
Cassandra ha sido concebido e inicialmente desarrollado por
Facebook hasta que su código fue liberado en el año 2008.
Desde 2010 forma parte de los proyectos de primer nivel de
Apache. Cassandra fue inicialmente ideado para mejorar la
barra de búsqueda de la popular red social Facebook, y uno de
sus creadores originales, Avinash Lakshman, llegó de trabajar
directamente con Amazon, formando parte del grupo de
ingenieros que dio forma a DynamoDB. Actualmente Cassandra
se utiliza en varios de los sitios más conocidos y con más
necesidades en cuanto a tráfico y almacenamiento tienen en el
mundo, como por ejemplo, Netflix, Ebay, Spotify, Twitter, Reddit,
SoundCloud o Digg entre otros.
Características Principales
Cassandra, al tener un modelo de datos tan similar al
presentado por Google en BigTable, comparte muchas de las
características con las que se han expuesto en el apartado
anterior de HBase. Aunque como se verá, a nivel arquitectónico
son dos sistemas muy diferentes, por lo que resulta interesante
analizarlas por separado (Lakshman and Malik 2009). Se puede
afirmar que Cassandra y HBase son las dos bases de datos
orientado a columnas que más se utilizan de todas las
existentes.
3.2.9.5. Mongo DB

Se trata de una base de datos

creada por 10gen del tipo orientada a documentos, de esquema
libre, es decir, que cada entrada puede tener un esquema de
datos diferente que nada tenga que ver con el resto de registros
almacenados. Es bastante rápido a la hora de ejecutar sus
operaciones ya que está escrito en lenguaje C++.
 Para el almacenamiento de la información, utiliza un sistema
propio de documento conocido con el nombre BSON, que es
una evolución del conocido JSON pero con la peculiaridad de
que puede almacenar datos binarios.
En poco tiempo, MongoDB se ha convertido en una de las bases
de datos NoSQL favoritas por los desarrolladores.
4. Conclusiones
Las bases de datos NoSQL son una tecnología muy potente y variada que, si
se sabe emplear de forma correcta, resulta ser una herramienta valiosísima
que permitirá almacenar grandes cantidades de datos y extraer conocimiento
de ellos de forma eficiente, tan necesario hoy en día debido al fenómeno
BigData. No en vano, los puestos profesionales de informáticos que poseen
conocimientos sobre alguna de estas tecnologías se están comenzando a
demandar ampliamente.
Estas tecnologías son muy flexibles y versátiles, proponiendo soluciones a
problemas que de otra manera han resultado ser difíciles de abordar. Pero esta
tecnología no ha llegado para reemplazar a las bases de datos relacionales.
Los sistemas relacionales poseen una serie de características y cumplen una
serie de requisitos indispensables para muchos sectores de la informática,
como la banca o el comercio electrónico.
Las bases de datos NoSQL han llegado para complementar la oferta de bases
de datos de la que se dispone a la hora de abordar los problemas, y en ningún
caso es recomendable alcanzar una posición extrema con respecto a las
decisiones que se toman en este ámbito. Cada problema debe ser analizado
en su conjunto, con sus necesidades particulares para cada caso, y una vez se
tiene un esquema claro de esto, se debe buscar la solución de almacenamiento
de entre todas las disponibles que mejor cubra las necesidades del problema.
5. Bibliografía
o Big Data. La Revolución de los datos masivos. Viktor Mayer-Schönberger, Kenneth
Cukier. Turner Publicaciones. 2013.
o Big Data Now. O'Reilly. 2012.  MongoDB: The Definitive Guide, 2nd Edition. Powerful
and Scalable Data Storage. Kristina Chodorrow. O’Reilly. 2013. 
o Mastering Apache Cassandra – Second Edition. Nishant Neeraj. Pack Publishing. 2015.
 Beginning Neo4j. Chris Kemper. Apress. 2016. 
o MongoDB: https://docs.mongodb.com/. Acceso 12 de julio de 2016.  Cloudant:
https://cloudant.com/. Acceso 12 de julio de 2016.
o Cassandra: http://cassandra.apache.org/. Acceso 12 de julio de 2016.  Neo4j:
https://neo4j.com/. Acceso 12 de julio de 2016.