TECNOLOGÍAS SQL Y NOSQL.

En esta ocasión, vamos a introducir una serie de conceptos sobre los tipos de datos y sobre la diferencia
entre las bases de datos relacionales y las no SQL. Sería muy importante analizar el contexto de la
consistencia dentro de estas diferencias de datos, y luego, repasaremos varias tecnologías de bases de datos
no SQL, en el contexto de consistencia, de bases de datos analíticas y de análisis de grafos.

TIPOS DE DATOS

Existen diferentes tipos de clasificación de los datos,

según diferentes características, y lo que nos aborda
hoy, según su estructura.
Entendiendo esa estructura de datos, podemos
encontrar tres tipos de datos. Los datos
estructurados, datos semiestructurados y datos no
estructurados.

Como se puede ver en la imagen, clasificamos los

datos en función del formato que tienen.
Los datos estructurados forman parte de SQL. Los
datos semiestructurados tienen una estructura
ligera, flexible que, básicamente, se utilizan en
formatos ampliamente usados como XML o JSON.
Y luego, finalmente, tenemos la gran cantidad de
datos en Internet, que son los datos no estructurados,
que son de tipo texto sin ningún formato.

Ahora vamos a entrar en detalle con cada uno de

ellos.
Primero, vamos a hablar de los datos no
estructurados. Debemos entender que los datos no
estructurados suponen el gran volumen de datos que
existe en Internet. La gran mayoría de depósitos de
datos de información empresarial o de negocio son
datos no estructurados, y en estos datos no existe un
modelo predefinido. Hay un gran volumen de
información, básicamente en texto, que no tiene una
estructura. No conocemos las relaciones semánticas
entre los elementos que la componen.
A veces existe la duda, cuando tenemos un documento que conocemos muy bien, tenemos esta idea de: "No
pues, yo conozco la estructura de mi documento", pero eso, aunque se conozca, no existe una forma general
ni formalizada de extraer aquellas entidades semánticas de ese dato, de ese depositorio, con lo cual hace falta
la ayuda de un experto. Queremos superar ese nivel a partir de definiciones de metadefiniciones de datos.

Hay muchísimos ejemplos de este tipo de datos.

La gran mayoría de datos que existen en Internet son
de este tipo. Podemos hablar, por ejemplo, de
imágenes, vídeos, imágenes satelitales, datos
científicos provenientes de la simulación o de la
estación, por ejemplo, de datos meteorológicos, los
datos sobre circulación de vehículos en el tránsito.
En general, los volcados de documentación
empresarial, ya sean estadísticas, memorándums,
encuestas, correos.
Todos esos son datos no estructurados.

Y lo que cada vez tiene más importancia son los datos provenientes de las aplicaciones web y las aplicaciones
móviles, datos que reflejan las operaciones y los usuarios que han realizado sobre esas aplicaciones. En
general, como caso, son los logs que obtenemos de las aplicaciones web.

Los datos semiestructurados van un paso más allá en

esta estructuración de la información y suponen una
cierta información que se establece a partir de
categorías y etiquetas. En ese sentido, se utilizan
formatos muy flexibles, como JSON o XML, donde el
programador, el diseñador del proyecto, puede
cambiarlas en cualquier momento, para que estos
tengan más riqueza. Y entonces, la definición
semántica de los datos va basada en estas pequeñas
categorías. Estos datos se almacenan en el registro y
son fácilmente identificables por el programador o
por el desarrollador pero esta flexibilidad, la
penalización que tienen, es que puede existir
ambigüedad en los datos.
 Este es un ejemplo de datos en un formato JSON,
donde vemos que el esquema es flexible, y en
cualquier momento se pueden cambiar estas cuatro
categorías, nombre, apellido, identificador y total.
Puede cambiar en cualquier momento el formato,
cambiar los datos, añadir nuevos campos, y hacer
que la aplicación sea más rica, pero no estamos libres
de que, en alguna aplicación, en un volcado, el
número, por ejemplo, que tenga que ver con el total,
aparezca una letra.
Entonces, eso es un error, y el formato en sí no nos
corrige ese error. No quedamos libres de
incoherencia.
En ese sentido, se plantean los datos estructurados,
que pertenecen a un modelo de dos abstractos donde
se organizan los elementos, básicamente, en
entidades, donde son objetos que tienen propiedades,
y las relaciones con las demás entidades. Cada
elemento de este conjunto tiene un contenido
semántico, tiene una interpretación semántica en
función de su definición y la relación con el resto, y si
lo ha realizado algún experto en generación de bases
de datos, ha creado un modelo de datos donde se
reflejan estas relaciones. Estos modelos de datos
estructurados forman parte de bases de datos
estructuradas, como puede ser MySQL o mariaDB, y
que son ejemplos de sistemas de gestión de bases de
datos.

Un ejemplo de una estructura de información podría

ser esta tabla donde tenemos una serie de pedidos.
Tenemos unos nombres de usuario, el apellido, el
identificador del pedido y el importe de este pedido, y
esto está almacenado en una tabla, de forma que
almacenamos estas entidades, y los datos, y los
valores que identifican cada una de estas
transacciones.

Finalmente, cuando vayamos a publicar datos

masivos o de una cierta cantidad, es importante
conocer el proceso de anonimización. Este proceso
consiste en la eliminación de las referencias de
cualquier identificador personal de un conjunto de
datos, lo que se conoce como el PII, información de
identificación personal. Debemos intentar que en la
publicación de estos datos desaparezca cualquier
referencia al individuo, y este proceso se aplica sobre
un conjunto de datos con el objetivo de preservar la
privacidad de los individuos que forman parte del
conjunto.
Es necesario aplicar este proceso de anonimización para cuando se hacen públicos elementos que pueden
identificar al individuo, como puede ser su nombre, datos sobre su vivienda, o, por ejemplo, como puede ser
un código postal o una dirección.

Los métodos para permitir esa anonimización son

varios, y vamos a destacar los tres principales.
El primero es la eliminación completa de estos datos,
de forma que nuestro depositorio no contenga
ninguna referencia a las personas de las cuales
estamos obteniendo datos.
La segunda es el cifrado. En esta segunda, lo que
hacemos es conservar los campos originales de
nuestra base de datos, pero creamos un algoritmo de
cifrado donde se obtiene una clave cifrada de los
datos originales. Este proceso de cifrado es costoso, y
también, es tan robusto como la robustez de la clave
utilizada.
Finalmente, se puede utilizar técnicas de enmascaramiento, donde se conserva la estructura de datos
originales, de forma que el procesamiento de los datos se hace como si fuera de la propia fuente original, pero
se cambian todos los datos que tienen que ver con los campos sensibles de identificación del usuario. Los
tipos se conservan, los valores no.
 Es importante conocer que este proceso de
anonimización no asegura la protección, puesto que,
cualquier conjunto de datos suficientemente extenso
añadido a una información contextual de la geografía
o del entorno donde se han obtenido, puede derivar a
la obtención aproximada de los individuos, con lo
cual, es necesario, sobre todo en datos sensibles,
dependiendo de la legislación del país donde se esté
trabajando. Hay ciertos datos, como por ejemplo, los
datos de salud, que son del máximo nivel de
protección, y debemos aplicar las técnicas de
anonimización más complejas posible para evitar, en
toda posibilidad, que las personas con esos datos no
se publiquen.

TECNOLOGÍAS SQL Y NOSQL

Vamos a hablar primero del contexto de necesidad de trabajar con grandes conjuntos de datos a escala y qué
limitaciones tienen las bases de datos relacionales en ese ámbito, cuáles son los problemas que nos
encontramos al trabajar con bases de datos no relacionales y qué tenemos que hacer para superar esos
problemas y luego, en ese contexto, hablaremos de la técnica de sharding o participación horizontal como
una técnica que intenta avanzar las bases de datos SQL.
Y luego discutiremos cuáles son las dificultades que proporciona al desarrollador este tipo de cambios. Luego,
presentaremos las bases de datos NoSQL como una alternativa a esta tecnología e intentando mejorar estas
dificultades que hemos visto.

Inicialmente es necesario establecer un contexto de

aquellos proyectos que agregan datos de los usuarios
que es uno de los ejemplos que se crean en el siglo
XXI a partir de la gran explosión de datos que se
dispone de los usuarios.
Inicialmente, la gran cantidad de datos que tenemos
son sobre productos de analítica web y aplicaciones
móviles, es decir que, somos capaces de medir cada
una de las operaciones que realiza el usuario y las
tenemos a nuestra disposición.
En ese sentido, podemos predecir el crecimiento de ciertos efectos de la vida real. Por ejemplo, Google puede
predecir el crecimiento de la gripe a partir de la cantidad de páginas vistas por los usuarios donde se buscan
remedios contra la gripe. Ese tipo de ejemplos muestra la gran necesidad de analizar muchos datos.

En este sentido, al trabajar con datos a escala, el

volumen de esos datos representa una gran parte del
problema. Analizar el gran volumen de datos ya es
una parte del problema. Vamos a trabajar en estos
datos que están almacenados en un volumen
especial, están guardados en bloque. El objetivo es
tanto interpretar como explorar qué tendencias
guardan esos datos. Estos datos pueden tener
cualquier formato, el esquema de los datos no es
estricto, puede ir cambiando a partir de que la
aplicación, o ciertas medidas nos dan más y otras
menos, por lo tanto, tenemos un empuje a ir más allá
del modelo relacional.

En ese sentido, el modelo relacional tiene el gran

problema de la falta de eficiencia a gran escala. Ese
es el gran problema que vamos a tener que gestionar
en este capítulo. Es muy complejo. Otros problemas
derivados de ahí es la complejidad de evolucionar el
modelo de datos. Una vez tenemos un modelo de
datos es muy complicado modificarlo.

Los nuevos servidores de datos, que son

descendientes de las tablas de Google BigTable y
Amazon Dynamo, son tecnologías que, por sí mismas,
están diseñadas desde cero para ser fáciles de
distribuir en múltiples nodos, proporcionan una
consistencia parcial, por lo tanto, permiten esquemas
de datos flexibles, más flexibles que las bases de
datos relacionales, y, a partir de esa creación de estos
proyectos, ha existido una explosión de una gran
cantidad de proyectos open source, como Cassandra,
Hbase, CouchDB, mongoDB, que permiten utilizar
estas tecnologías en diferentes tipos de datos. Nuestro
ejemplo de partida es la escalabilidad con MySQL.
 Nuestro ejemplo es muy sencillo. Consiste en:
tenemos una aplicación de analítica web que consiste
en analizar el número de visitas que tenemos en una
página web. Cada vez que tenemos una visita,
tendremos que modificar la base de datos y añadir un
nuevo elemento, conforme se ha hecho una nueva
visita a una web particular. El objetivo de todo esto es
hacer un Top, es decir, una lista de las cien webs con
más visitas de todos nuestros registros.

Por lo tanto, vamos a diseñar nuestra pequeña base

de datos. En este caso, es una simplificación, y vamos
a hablar de una tabla donde tenemos el número de
visitas, el número del usuario y la página web, la URL
que hemos visitado. Esta tabla habrá que
incrementarla cada vez que haya una nueva visita.

Entonces, en ese sentido vamos incrementando

nuestra tabla y lo que ocurre es que de pronto
tenemos muchísimas visitas y tenemos un mensaje
de la base de datos que nos dice que hay un error de
time out al insertar datos porque la base de datos no
es capaz de asumir la gran cantidad de peticiones que
está recibiendo. Por lo tanto, para eso lo que hacemos
es crear un buffer, es decir, una cola de peticiones
que guarda esas peticiones y va proporcionando a la
base de datos, de cien en cien, para que esta pueda
insertarlas.

Pero este problema, a medida que tenemos más peticiones, se convierte en un problema general muy
importante que es cómo actualizo de forma eficiente cuando tengo muchísimas peticiones en una base de
datos relacional.

Una de las maneras de hacerlo es dividir la base de

datos en trozos, lo que se llama partir la base de datos
de forma horizontal. Cada base de datos, cada
partición ahora está en un servidor distinto y esa
partición puede recibir el triple de peticiones.
Esta manera de particionar los datos se llama
también sharding. Y esta técnica, en el fondo, lo que
está haciendo es distribuir la carga de peticiones en
diferentes servidores de forma simultánea.

En este ejemplo, vemos un esquema muy sencillo de

partición donde se tiene la base de datos original y
ahora se hacen tres particiones de los mismos datos
y en las tres tablas se contienen los mismos tipos de
datos. Simplemente cada una de ellas tiene un
conjunto de página web distinta y a cada una le llega
un conjunto de peticiones, de forma que nuestro
servidor ahora es el triple, acepta el triple de
peticiones y es el triple de eficiente.

Esto tiene implicaciones y estas son implicaciones de

tareas de ingeniería.
La primera que vemos es que se necesita un buen
método para partir la base de datos original en tres
segmentos horizontales que contengan
aproximadamente la misma cantidad de datos de
forma que reciban la misma cantidad de peticiones.
Por lo tanto, necesitamos un método propio para
distribuir esos valores a la partición correspondiente.
Normalmente, se utiliza una función.
Y luego necesitamos también adaptar nuestra manera de encontrar el Top 100. Antes teníamos una manera:
buscábamos en la base de datos y teníamos los 100. Ahora tenemos tres pequeños, tres listas de 100 que
habrá que agregar para obtener la lista de 100 páginas web global.

El problema grave viene cuando tenemos que tolerar,

gestionar la tolerancia de fallos, es decir, si uno de
nuestros segmentos falla, no podemos insertar datos
en ese segmento y nos tenemos que esperar.
Luego la complejidad de la gestión cae sobre la
aplicación que tiene que calcular a qué lugar, a que
share, a qué partición tiene que insertar cada dato
Eso, esa decisión la tiene que tomar la aplicación.

Por lo tanto, cualquier error que se produzca de asignación de partición equivocada va a ser muy difícil de
resolver puesto que tendremos que extraerlos de uno en uno todos esos datos. Y, por ejemplo, si también
tenemos un problema que hemos calculado mal y resulta que una de las particiones de golpe crece mucho
más que el resto tendríamos que resegmentarlo y esa resegmentación implica volver a diseñar toda la política
de partición de claves.

Por lo tanto, qué les pedimos a las bases de datos

NoSQL desde ese punto de vista. Necesitamos una
tecnología de base de datos que gestione
automáticamente la naturaleza distribuida de los
repositorios de datos, que se gestionen las particiones
de forma automática, que permita una inserción
escalable de datos de forma masiva y que las
preguntas que yo haga a la base de datos tengan una
licencia pequeña, pese a que estén distribuidas. Una
buena gestión de tolerancia de errores y una buena
gestión de robustez, y también, por supuesto, que sea
de propósito general, es decir, que cualquier
aplicación pueda adaptarse a su uso.

Como ejemplo para ilustrar un poco esta tecnología

HBase como base de datos no relacional, NoSQL. Es
una base de datos persistente, distribuida, los datos
están ordenados por la clave, es multidimensional y
es capaz de almacenar datos con baja intensidad.
Los primeros beneficios que tenemos de utilizarla es
que, por ejemplo, está colocada por encima de un
sistema de datos un sistema de ficheros distribuidos
que ya conocemos, que es HDFS.

Este sistema de ficheros distribuidos permite, por

ejemplo, tener tres instancias de los datos de forma
replicada, es decir, cada registro, cada tabla, está
copiada tres veces, de forma que, si pierdo un nodo,
no estoy perdiendo información, tengo maneras de
recuperar esa información.
Y también es multidimensional. Los datos se
almacenan en familias. Es un poco la diferencia de
las bases de datos relacionales y cada familia puede
contener cualquier número de columnas.
En este ejemplo se almacenan un nombre y dos
familias: la familia Nombre y la familia contactinfo
para cada fila, para cada elemento. La familia Nombre
tiene lo que se llaman dos cualificadores que son
NOM y AP1. Estos dos cualificadores guardan valores.
Entonces, la familia Nombre tiene dos cualificadores
y la familia contactinfo tiene uno. A partir de aquí
podemos guardar la información en estos
cualificadores y podemos preguntar por la
información de contacto de un usuario a partir de su
cualificador EMAIL. Tendremos, por tanto, como
referencia como dato de vuelta su email.
 Si queremos comparar cómo se guardaba esto en una
tabla relacional y cuál es la estructura final dentro de
una base de datos NoSQL veremos que la
organización por las familias rompe esa estructura
lineal de un registro por línea y ahora aquí tenemos
que cada clave apunta a un conjunto que puede tener
diferentes valores por familia y diferentes valores
donde podemos tener familias en diferente NOM.
Vemos que, por ejemplo, que la clave 3 tiene datos en
cada familia, pero la clave 1 y la clave 2 solo tiene un
dato en cada familia. Por lo tanto, vemos que nuestro
esquema está simplificado, es flexible.
La gran ganancia que tenemos de estos sistemas es
la escalabilidad automática. Se establece el concepto
de región, que es un conjunto de filas de datos
contiguas que se almacenan juntas. Esta región
forma una unidad mínima de balanceo de carga, es
decir, si de golpe empezamos a tener inserciones en
la base de datos, y una región crece mucho ésta
automáticamente se dividirá en dos y cada una de las
regiones irá a parar a un servidor distinto, de modo
que yo no me tengo que preocupar del balanceo. Cada
servidor almacenará un número equivalente de
regiones, por lo tanto, cada pregunta que yo haga está
distribuida de forma uniforme.

Aquí vemos, finalmente, un esquema de cómo

quedarían estas regiones en un buen balanceo.
Tenemos que en cada recuadro azul es un servidor de
regiones, es un servidor distinto, por lo tanto,
estamos paralelizando, multiplicando la cantidad de
procesamiento que podemos hacer.
Tenemos tres servidores que están atendiendo
peticiones y cada uno de ellos almacena una cantidad
equivalente de carga, es decir, una cantidad
equivalente de regiones.

Eso permite que las búsquedas sean muy fáciles porque están ordenadas alfabéticamente, es muy fácil
encontrar cuál es la región, simplemente colocando la clave ordenada alfabéticamente y se sabrá a dónde se
tiene que ir, y también es muy fácil balancear porque, automáticamente, cuando crece una región se va a
partir de dos y se va a asignar automáticamente.

CONSISTENCIA, FIABILIDAD Y ESCALABILIDAD

Hablaremos primero de qué significa la consistencia de datos, y luego introduciremos qué impacto tiene a la
hora de gestionar los sistemas distribuidos de datos de gran tamaño. Introduciremos el teorema CAP en este
entorno y hablaremos de la necesidad de decidir entre consistencia o disponibilidad en grandes sistemas de
datos. Finalmente, daremos un par de ejemplos de qué sistemas existen para adaptarlos a las necesidades
de nuestros proyectos.

Principalmente la consistencia de datos la vamos a

analizar, la vamos a trabajar en el contexto de
grandes sistemas de datos distribuidos donde
tenemos nuestro repositor de datos en el que vamos
a trabajar. En ese sentido también es donde tiene
validez el teorema CAP.

La consistencia de datos en este entorno, lo que

permite y el objetivo que tiene es garantizar que los
datos almacenados en las bases de datos muerden
siempre unos valores veraces. Es decir, que siempre
que vayamos a acudir a esos datos, a esos
repositorios, a esas bases de datos, tengamos un
resultado fiable. Por lo tanto, cada vez que se realice
una operación en la base de datos, el resultado tiene
que ser consistente, es decir, no se puede invalidar el
resultado que hay previamente.
Para asegurar este tipo de operación, se realizan dos
aproximaciones.
La primera es que se asegura que cada cambio que se
realizó en la base de datos mantiene la consistencia
previa. Si es así dejamos pasar el dato y si no es así
lo que hacemos es invalidar esa operación y pasamos
al estado previo de consistencia que tenía el sistema.
 Existen varios modelos de consistencia que permiten
perseguir este objetivo, que el sistema almacene en
cada uno de los nodos donde se almacenan datos una
consistencia.
La primera es la estricta, es decir, todos los cambios
que se producen en la base de datos tienen que llegar
a todos los servidores, a todos los nodos, de forma
atómica y de forma instantánea. Es decir, no se puede
dar una operación como acabada hasta que todos los
servidores tengan la última versión.
En sistemas muy grandes eso tiene un coste muy
alto, por lo tanto, se plantean otros modelos de
consistencia como por ejemplo la secuencial donde
cada cliente ve los cambios en el orden en el que
aparecieron, la causal, de forma que los cambios
aparecen según el orden causal.
También la consistencia eventual es importante, ya que permite que los cambios se propaguen de forma
local. Y, finalmente, tenemos los de consistencia débil, donde no se hace ningún esfuerzo en asegurar la
consistencia global y podemos tener datos en diferentes estados, en diferentes nodos del sistema.

La consistencia es relevante cuando tratamos los

errores. Es decir, hay un momento en nuestro
sistema de datos distribuido que tenemos dos
versiones, dos documentos, dos variables tienen
diferentes valores en dos servidores.
¿Qué hacemos en ese momento? Bueno, en ese
momento, como diseñadores de sistemas, tenemos
que decidir entre dos opciones, mantener la
consistencia, es decir, no dejamos ningún cambio
más, no dejamos acceder a nuestras variables o
nuestros documentos hasta que ese cambio se haya
propagado a todas las instancias de esos datos, o bien
nos orientamos a la disponibilidad, es decir,
permitimos que se siga leyendo los datos, aunque
estos no tengan la última versión de los mismos.
Es importante decir que mientras no se produzcan errores, mantener la consistencia y la disponibilidad no
tiene ningún problema, porque mientras solo sea de lectura no se produce ningún problema.

En este sentido de cómo gestionamos los errores, es

cuando se plantea el teorema CAP, que básicamente
nos viene a decir que los sistemas distribuidos de
gestión de datos tienen que elegir dos de tres
propiedades:
la primera es la consistencia, mantener la
consistencia o mantener la disponibilidad o bien
mantener la tolerancia al particionado de datos.
Podemos elegir solo dos de estas tres capacidades.
Como normalmente en los sistemas distribuidos de
datos aceptamos que los datos están distribuidos
geográficamente, ya sea en diferentes oficinas o de
forma global en el planeta, utilizando proveedores en
la nube, lo que tenemos es que elegir entre la
consistencia o la disponibilidad de nuestros datos.

Por lo tanto, tendremos que elegir entre dos opciones.

Elegir consistencia, es decir, en algún momento el
sistema no estará disponible, pueden ser segundos o
milisegundos, hasta que todos los servidores que
tenemos tengan la última versión, o bien nos
orientamos a disponibilidad, es decir, los usuarios y
aplicaciones siempre tienen acceso a los datos, en
ningún momento se interrumpe, pero aquellos en
algún momento no tendrán la última versión de los
datos.
Un servidor puede no reflejar la última versión de un
valor.
 En ese sentido, muchos sistemas distribuidos
plantean la consistencia eventual como una
aproximación a las dos.
Por lo tanto, ¿qué proponen? Un modelo de
consistencia débil, es decir, que los clientes siempre
tienen acceso a los datos en todo momento e intentan
acercarse a la consistencia de forma que cuando los
cambios se hayan producido, estos se propagan de la
manera que se han producido a los demás servicios,
o nodos de nuestro sistema. Por lo tanto,
conservaremos la consistencia de una manera
relajada en un tiempo que se va a llegar a producir.

En este ejemplo vemos un momento en el cual

tenemos tres servidores y uno de los datos, el tercer
servidor a la derecha, tiene una copia que se ha
modificado.
Por lo tanto, en una consistencia eventual los datos
de los servidores que quedan a la izquierda siguen
siendo visibles, las aplicaciones pueden seguir
haciendo consultas y en algún momento el cambio de
ese dato llegará a propagarse a los dos servidores que
vemos a la izquierda.

Como usuarios o como diseñadores de sistemas

distribuidos y de aplicaciones, tenemos que elegir en
algún momento qué tipos de bases de datos vamos a
usar en nuestros sistemas y, por ejemplo, para BD
orientadas a disponibilidad y tolerancia a
particionado tenemos Cassandra y orientadas a
consistencia y disponibilidad tenemos HBASE y
MongoDB.
En nuestro caso, tendremos que elegir en cada
momento qué es lo que nos interesa según nuestros
proyectos.

TECNOLOGÍAS DE BBDD NOSQL I

Haremos un pequeño repaso del contexto actual y les explicaré los tipos de aproximación, en cuanto a los
modelos de datos que han dado lugar a las tecnologías actuales.

El origen y la necesidad, como ya hemos visto

anteriormente, responden a las denominadas "4V del
big data".
Por un lado, tenemos el volumen, cuando hablamos
de "big data" estamos hablando de una cantidad
enorme de datos, de millones de millones de registros,
estamos hablando de que estos datos se transmiten y
se generan a una velocidad enorme también. Estos
datos, a su vez presentan una heterogeneidad muy
importante, por lo tanto, hay que saber gestionar
estos diferentes tipos de datos.

Finalmente, como es obvio, tenemos la veracidad, es decir, estos datos, necesitamos poder extraerlos y
trabajar con ellos de manera fiable, que nos den un grado de confianza alto.
Esto parece bastante evidente ahora, sobre todo con la aparición del denominado "Internet of things".

Las grandes empresas dedicadas al tratamiento de

datos, hace años que evidentemente detectaron la
necesidad de implementar sus propios sistemas de
bases de datos no relacionales.
Cuando hablamos de tratamiento de datos,
seguramente lo primero que nos viene a la cabeza es
Google.
Google, en 2006 introdujo BigTable como una base de
datos distribuida, dispersa y persistente, donde los
registros se indexaban mediante una clave de fila,
una clave de columna, y mediante un "timestamp".
 De manera análoga, Amazon, poco después introdujo
DynamoDB. DynamoDB lo introdujo también para
satisfacer las necesidades de fiabilidad, de velocidad
y de disponibilidad de la gran cantidad de datos que
disponía.
Estas dos aproximaciones trataron los datos de una
manera sutilmente distinta.

Por un lado, en DynamoDB tenemos que los datos se

trataban como parejas de clave-valor, donde teníamos
una clave y el valor asociado. En Google, teníamos
que los datos se trataban como registros donde había
un índice y unas familias de columnas.
De manera que, en DynamoDB, lo que teníamos era
una clave, podía funcionar como índice, y las
entradas asociadas a esta clave eran absolutamente
arbitrarias, es decir, no tenían por qué seguir ni una
estructura predefinida, ni tenían porqué contener los
mismos tipos de datos ni nada parecido.
En Google, BigTable, estos datos se organizaban de manera que las familias de columnas contenían, a su
vez, subcolumnas que tenían algún tipo de relación conceptual, de esta manera, se permitía que cada acceso
a un registro fuera más eficiente en el sentido de obtener sólo la información que necesitábamos en ese
momento.
Por tanto, tenemos que en este tipo de esquema existen tres puntos clave como son las familias de columnas,
las propias claves de columna y las claves de fila o de registro. Esta manera de ver los datos fue precursora
de los distintos modelos de datos que existen en la actualidad.

Nosotros nos vamos a fijar en tres. Por un lado,

tenemos el "key-value store", como hemos explicado
antes, se desprende de la aproximación de
DynamoDB.
En este caso, lo que tenemos son registros clave-valor
donde cada clave tiene asociado un valor y este valor
no tiene por qué tener nada que ver con el resto de
valores en la tabla, ni tiene por qué seguir ningún tipo
de estructura ni ningún tipo de datos en especial.

Por otro lado, tenemos los conocidos como "wide

column store", aquí, como en el caso de Google
BigTable, lo que tenemos es que los registros están
indexados mediante un índice y luego tenemos una
serie de familias de columnas. Estas familias de
columnas se dividen en subcolumnas y cada una de
éstas tienen su clave de columna y su
correspondiente valor. Dependiendo de las
tecnologías de gestión de base de datos que
utilicemos, estos valores dentro de las columnas
tendrán restricciones o no en cuanto al "tipado" y
también se nos ofrecerá distintas operaciones de
indexado o de operaciones entre tablas.
Finalmente, tenemos los "document store".
Los "document store", por cada registro, lo que
tenemos es un índice y el valor asociado a este índice
es lo que se conoce como un "documento".
Un documento es una vasta cantidad de información
que, generalmente, presenta una estructura interna.
Eso sí, esta estructura interna no tiene por qué ser
común entre distintas bases de datos "document
store" e, incluso, tampoco tiene por qué ser común
entre los propios registros de una misma base de
datos.
Lo que sí que se contempla es que dentro tienen una
estructura propia, que luego puede ser analizada.
De hecho, todas estas maneras de ver los modelos de
datos están bastante interrelacionadas, de manera
que podemos observar que a los "wide column store"
se pueden ver como "key-value stores"
bidimensionales, donde cada familia de columna
tiene una serie de claves de columna.
Y, de la misma manera, un "document store" lo podemos ver como un "key-value store" donde el valor es esta
cantidad de información de manera desestructurada completamente. En este caso, la diferencia está en que
las tecnologías "document store" lo que permiten es analizar de manera directa la estructura interna del
documento, mientras que si lo implementásemos dentro de una tecnología "key-value store", necesitaríamos
un "parser" o un procesado posterior para poder interpretar los datos que se incluyen.
 En esta gráfica podemos ver las más de 300
tecnologías de sistemas de base de datos y la
tendencia en cuanto a popularidad que tienen
además que van adoptando las bases de datos no
relacionales.
Este índice está desarrollado por el portal DB-
Engines, se tienen en cuenta distintos aspectos como
menciones en "post" en Internet, menciones en
ofertas de trabajo, proyectos que oficialmente utilizan
esta tecnología de base de datos, etcétera. Como
podemos ver, las tecnologías de base de datos
relacionales "de toda la vida", se mantienen en altos
índices porque las grandes empresas aún son
reticentes, en muchos casos, a migrar sus grandes
bases de datos.
Pero, sí que podemos observar que en los últimos años las tecnologías no relacionales están tomando mucho
protagonismo. Aquí tenemos detalladas, de hecho, las tres que vamos a estudiar, que serán Cassandra,
MongoDB y HBase.

HBase es un proyecto de Apache que nació en 2007.

Se le conoce como la "base de datos de Hadoop", por
lo tanto, es muy conveniente, si lo que se desea es
realizar una integración rápida con el resto de
herramientas de Hadoop, como veremos más
adelante. Por supuesto, también se entiende
perfectamente con el sistema de ficheros HDFS. Es de
tipo "wide column store" y es un proyecto "open
source" escrito en Java, que parte de la
implementación de BigTable.
Refiriéndonos al teorema CAP, que hemos explicado
anteriormente, consideraríamos este sistema como
un "sistema CP", es decir que permite consistencia de
datos y tiene tolerancia a la fragmentación o a la
partición.
Grandes empresas utilizan internamente esta
tecnología, como son por ejemplo Yahoo, Twitter o
Adobe, entre otras.

Por otro lado, tenemos Cassandra.

Cassandra es un proyecto que también lo está

gestionando en la actualidad Apache, pero, en sus
inicios se creó en Facebook, precisamente para
atender a la necesidad de la gestión del "inbox" de
todos los usuarios.
Cassandra está pensado como un sistema orientado
al rendimiento operativo, y con clara vocación a
ofrecer una alta escalabilidad y disponibilidad. Es de
tipo "wide column store", al igual que HBase, y
también está escrita en Java.
Pese a que no se le conoce como la "base de datos de
Hadoop", presenta muy buena integración con este y
es muy fácil integrarlo, así como con otras
herramientas de Big Data.
Respecto al teorema CAP, consideramos que es un
sistema AP, es decir que proporciona una alta
disponibilidad de los datos, y también tiene tolerancia
a la partición.
Clientes que utilizan el sistema de datos Cassandra,
que son clientes muy importantes como eBay, Netflix
o el propio Facebook.

Finalmente, trataremos MongoDB. MongoDB es una

base de datos que nació en 2007 en la empresa
10gen, que actualmente se llama MongoDB
Incorporation, está muy orientada a la simplicidad en
el desarrollo. Así como Cassandra tiene una clara
vocación de simplicidad operativa, en MongoDB la
simplicidad es en el desarrollo, y es por eso que está
adquiriendo altas cuotas de popularidad. Es de tipo
"document store", está escrita en C++, también
presenta muy buena integración con el resto de
herramientas Big Data, y es un sistema CP como
HBase, es decir, permite consistencia de datos y
tolerancia a particiones.
Empresas importantes que utilizan MongoDB:
Electronic Arts, Cisco, Bosch, entre muchas otras.

Analicemos ahora los conceptos en cuanto a modelo

de datos y arquitectura de estas soluciones de Base
de Datos No SQL que presentamos. Y analicemos
cuáles son las ventajas e inconvenientes de cada una
de ellas.

Empezaremos con HBASE. HBASE, como ya vimos,

es un proyecto que actualmente lleva Apache, y que
está fuertemente integrado con el ecosistema Hadoop.
Como también comentamos, es un proyecto que nació
como clon de Google Big Table, y por lo tanto hereda
mucha de sus características, principalmente lo que
es la organización del modelo de datos y el concepto
de familia de columnas. No obstante, obviamente, ha
ido evolucionando con el tiempo, y actualmente
presenta sus características propias.

Si nos fijamos en el modelo de datos, vemos que cada

uno de los registros tiene cuatro componentes muy
importantes. En primer lugar, tenemos la clave de
fila, tenemos un time stamp, y luego vemos que los
datos vienen referenciados de la siguiente manera,
que es, nombre de familia de columna, dos puntos,
nombre de calificador de columna, lo cual nos indica
más concretamente qué tipo de datos tenemos en
cada uno de los registros.
Como podemos ver en este ejemplo, existirían varias
celdas vacías de datos. Esto en la realidad no es así.
Y una representación más aproximada de la realidad
vendría a ser como ésta, tipo JSON, en las que en
realidad las celdas que aparecían vacías no ocupan
espacio de memoria y ni tan siquiera existen. De
hecho, la existencia de datos para cada familia de
columnas, como ya comentamos, no es requerida.
Aquí podemos observar distintos campos que
contienen distintos datos para familias de columnas
y calificadores de columnas, pero físicamente
debemos de tener en cuenta que los datos no están
almacenados de manera que cada fila contiene todas
las columnas de familias, sino que a nivel físico los
datos están almacenados simplemente por clave de
fila, time stamp, y luego, familias de columnas por
separado.

Es decir, cada registro tiene una clave de fila, un time

stamp, y los datos relativos a una sola familia de
columna.

De todos modos, por simplificar, vamos a imaginar

que almacenamos todos los campos de todas las
familias de columnas.
Si tenemos en cuenta esto, podremos observar en este
ejemplo que la arquitectura de HBASE lo que hace es
un particionamiento horizontal de los datos de modo
que cada fragmento viene identificado por una clave
de fila inicial y una clave de fila final.
Una vez tenemos particionados los datos, estos datos
se distribuyen en distintas regiones. Esto
corresponde a una distribución en distintas
ubicaciones lógicas.
 Cada una de estas regiones está gobernada por un
servidor de región, y cada conjunto de regiones que
están gobernadas por un servidor de región pueden
estar distribuidas geográficamente.
En este esquema, hay dos componentes esenciales
para el funcionamiento de HBASE. Por un lado,
tenemos HMaster, que como su nombre indica, será
el elemento principal del sistema, y tenemos Apache
Zookeeper, este será el elemento de coordinación
distribuida, esencial también para el funcionamiento
de toda la arquitectura.

Como podemos ver, estas son las interacciones que

hay entre los distintos componentes.
A partir de estas claves, HBASE distribuye los datos
en distintas ubicaciones lógicas que son
denominadas regiones. Cada una de estas regiones a
su vez están gobernadas por un servidor de región o
región server. A su vez, cada conjunto de regiones
puede estar distribuidas físicamente y en cada
ubicación física disponemos de uno o más servidores
de región que mantendrán el estado de cada una de
estas regiones.

En este esquema, existen dos componentes esenciales para que la arquitectura de HBASE funcione. Estos
son, Zookeeper y HMaster.
HMaster, como su nombre lo indica, es el proceso principal que se encarga de la asignación y reasignación
de las distintas regiones, efectúa las tareas DDL, de la base de datos, estos son las tareas de data definition,
como son la creación y eliminación de tablas, y mantenimiento de la coherencia de los datos. Y también se
ocupa de todo lo relacionado con el balanceo de carga.
El componente Zookeeper es esencial en el sentido de que es el coordinador principal de todo el sistema. Si
nos fijamos, en este esquema de interacciones, un cliente cuando realiza cualquier petición lo primero que
ha de hacer es ponerse en contacto con Zookeeper para obtener la dirección del servidor de región asociado
a los datos a los que desea acceder. Luego, una vez obtenida estas direcciones, el cliente podrá realizar todas
las operaciones de tipo data management, es decir, lectura de registros, actualización, etcétera, directamente
hablando con los servidores de región. A su vez, Zookeeper mantiene la configuración global del sistema y
monitoriza las caídas de todos los componentes de ellos. La relación entre Zookeeper y HMaster a su vez es
muy estrecha, de manera que HMaster y Zookeeper se intercambian continuamente hard bits, y HMaster
informa en todo momento del estado de cada uno de los region servers a Zookeeper.

Bien, una vez vista por encima la arquitectura de

HBASE, pasamos a Cassandra. Cassandra, como ya
comentamos, es un proyecto que nace inicialmente de
Facebook, y muchos expertos lo consideran una
suma de características de Google Big Table y de
Amazon Dinamo. Como vemos en este gráfico,
Facebook lo liberó en modo de Open Source a partir
de 2008, y en 2009 Apache se hizo cargo del proyecto.
En cuanto al modelo de datos, Cassandra es muy
parecido a HBASE. Como ya estuvimos comentando,
Cassandra responde a un modelo de datos de familias
de columnas. Lo que hace especialmente particular al
sistema Cassandra es su arquitectura. Como vemos
en este esquema, podemos ver cómo todos los nodos
que contienen datos se distribuyen topológicamente
en forma de anillo. De manera simplificada, podemos
decir que un cliente cuando tiene una petición se
puede dirigir a cualquiera de estos nodos, y en el
momento en el que se dirige a cualquiera de estos
nodos, este nodo asume la responsabilidad de
coordinador para esta petición exclusiva. Cada nodo
dentro del anillo de Cassandra, conoce el estado y los
datos que contienen el resto de nodos. Por lo tanto, el
nodo coordinador de la petición lo que hará es
redirigir la consulta a los nodos que contienen esta
información. Y una vez obtenida la respuesta,
redirigirá esta al propio cliente.
¿Cómo gestiona todo esto el sistema Cassandra?
Bueno, en primer lugar, tenemos que tener en cuenta
que Cassandra realiza un particionamiento de los
datos basado también en clave, de manera análoga a
como lo hacía HBASE, pero con una sutil diferencia
que es que cada clave de fila le aplica una función
Hash, mediante la cual obtenemos un valor que le
vamos a llamar número de token. Y, por lo tanto, cada
porción de datos lo vamos a denominar token. De este
modo, Cassandra maneja un rango de valores de
token que va de menos dos a la 63, a dos a la 63
menos uno.
Vamos a imaginar, para poder comprenderlo de manera más rápida, que este rango va de cero a 999. Bien,
pues este rango completo se distribuiría uniformemente entre todos los nodos del anillo. De modo, que
tenemos que hay nodos que tienen un rango de cero a 199, de 200 a 399, así hasta llegar hasta 999. Una vez
realizamos la función Hash a la porción de datos indeterminada, si obtenemos por ejemplo un valor 700,
pues este dato o esta porción de datos, iría a parar al nodo que tiene asignado ese rango de valores, el rango
de valores donde cae este valor obtenido por la función Hash.
Además de esto, Cassandra permite o aumenta la disponibilidad de los datos vía un sistema de réplicas. Así
que, además del nodo que contiene la información original, esta información es replicada en n nodos del
mismo anillo. Cassandra tiene un sistema particular de coordinación entre nodos. Como podemos ver, esta
arquitectura de anillo se aleja completamente del esquema tradicional Master-Slave, aquí no hay master ni
slave. Y, de hecho, hemos visto que cada petición puede ser atendida por cualquiera de los nodos.
¿Cómo sabe, por lo tanto, cada nodo qué información tiene el resto de nodos? Bien. Cassandra implementa
lo que se denomina el protocolo gossip, que consiste en una comunicación constante nodo a nodo. Es decir,
cada nodo tiene comunicación constante y frecuente con cada uno de los nodos restantes del anillo. En esta
comunicación, y mediante este protocolo se intercambia la información de estado, de número de tokens, de
tamaño disponible, etcétera.

Esta arquitectura es escalable y la podemos repetir

entre distintas ubicaciones.

De modo que podemos tener lo que se conoce como

distintos data centers que, por ejemplo, podrían estar
compuestos, en este caso cada uno por un solo anillo.
Y los data centers los agruparemos conceptualmente
en clusters.
Los clusters, obviamente, pueden estar distribuidos
también geográficamente.

De este modo, el esquema se repite, pero con la

peculiaridad de que la réplica de datos puede estar
distribuida entre todos o varios data centers. De
manera que el cliente, cuando hace una petición y se
es asignado un nodo coordinador de esta petición,
este nodo, además de preguntar a los nodos que
figuran en su mismo anillo, preguntará a un nodo de
otro data center que a su vez se convertirá en
coordinador de esa petición para ese data center.

De este modo, obtendremos una respuesta de un

determinado nodo y satisfaremos la petición.

Esta arquitectura que ofrece Cassandra está

claramente orientada a disponer de una gran
disponibilidad de los datos y en realidad es mucho
más compleja, con lo que, si se quiere entrar en
detalle, se recomienda encarecidamente consultar la
documentación oficial de Cassandra.

Algo importante que podemos observar dentro de los distintos detalles de configuración es que a pesar de
que Cassandra siempre lo hemos categorizado como un sistema AP dentro del teorema CAP, nosotros
podemos llegar a ofrecer una serie de consistencia más o menos elevada.
 Es decir, esta consistencia es ajustable y
Cassandra implementa distintos métodos para
aumentar la consistencia, básicamente basados
en lo que denominamos quórum.

De modo que, por ejemplo, nosotros para poder dar

una petición por satisfecha, dependiendo del número
de réplicas que existan en cada uno de los anillos de
los data centers, será necesario obtener una
respuesta coherente de n nodos. Y esa n es lo que
constituirá el quórum que podemos configurar de
antemano. De este modo, como vemos, a más
quórum, pues una mayor consistencia. A menor
quórum, menor latencia, pero posibilidad de
conflictos de consistencia.

Pasemos a MongoDB. MongoDB es una base de datos,

como ya comentamos, orientada a documentos, es
decir, el modelo de datos responde al concepto de
documento, donde los datos son mucho más vastos
que los que venimos analizando en los paradigmas de
familias de columnas, y los podemos ver
representados de esta manera. Como se puede
observar, esta manera de representar un cierto
registro es absolutamente análoga a lo que vendría a
ser un objeto tipo JSON.
De hecho, los documentos en MongoDB se codifican mediante un tipo de datos llamado BSON, que es como
un JSON, pero en binario.
Esto se hace porque de este modo MongoDB puede ofrecer el tipado de los datos que contiene cada
documento. De manera que podemos tener campos con valores enteros, campos con valores string, campos
dobles, podemos tener arrays de distintos tipos de datos, etcétera.

Estos documentos BSON conforman la unidad básica

de datos que maneja MongoDB.
Estos documentos, a su vez, se pueden apilar en lo
que se denominan colecciones. Y como veremos, las
bases de datos contienen colecciones de documentos
y estas colecciones además podrán ser subdividas en
chunks o fragmentos.

Algo interesante también a considerar respecto a este

modelo de datos es la relación que se establece entre
los distintos documentos.
De manera que Mongo proporciona una manera de
relacionar los datos que bien puede ser mediante
enlaces, es decir, utilizando los propios
identificadores internos que se generan para cada
documento, o bien con documentos incrustados. Esto
es incrustar directamente un subdocumento como
valor de un determinado campo.

MongoDB ofrece un sistema de réplica de datos muy

consistente. El sistema que ofrece en cuanto a réplica
de datos es denominado replica set y consiste en que
varias instancias corren en distintos nodos y
contienen los mismos datos, siguiendo un esquema
master/slave, a diferencia de lo que acabamos de ver
en Cassandra.
De manera que aquí tenemos en este caso un nodo
primario que actuará de master y dos nodos
secundarios que actuarán de slaves. Solamente el
nodo primario atenderá las peticiones de lectura y
escritura, y cuando se atienda una operación de
lectura, se responderá e inmediatamente después se
realizará una replicación en los componentes
secundarios.
El sistema master/slave se mantiene gracias a que
entre todos los componentes, tanto secundarios como
el componente master, se envían frecuentemente
señales de heartbeat.

De manera que, si tenemos que un nodo primario cae,

automáticamente los nodos secundarios organizan
una votación en la que una cierta cantidad de nodos
se postulan como candidatos, se lleva a cabo una
votación de manera automática para ver quién es el
nuevo master y una vez se ha decidido este master,
pues adquiere el rol y, por lo tanto, atenderá a las
peticiones de lectura y escritura y realizará las
réplicas correspondientes en los nodos secundarios.

Un concepto muy importante en el que los

desarrolladores de MongoDB han puesto mucha
atención es en el concepto de sharding o
particionamiento.
Sharding, ya hemos visto anteriormente que es una
técnica que permite escalar horizontalmente,
dividiendo los datos en varios servidores y, en el caso
de MongoDB, esta división se realiza utilizando lo que
denominan una shard key, que vendría a ser análogo
a las claves de fila que utilizábamos en el esquema de
HBase.
De esta manera, podemos ver que una simple
colección de datos la podemos dividir entre varios
shards, dividiendo de esta manera lo que son los
distintos documentos contenidos en una misma
colección. En un esquema de sharding de MongoDB
existen tres componentes principales, que son el
enrutador, los servers de configuración y los shards
en sí. Los shards en sí serán las particiones lógicas o
físicas que contendrán los datos. El router, que estará
dirigido por el proceso llamado mongos, se encargará
de atender las peticiones y de enrutarlas al shard
correspondiente. Y todos los datos relativos a la
configuración de este sistema se mantendrán en un
conjunto de servidores de configuración.
Una configuración típica en los sistemas de MongoDB
vendría a ser como en la imagen, en la que vemos que
podemos disponer de varios enrutadores, varios
servidores de configuración y varios shards. Aquí
podemos ver que tanto los shards como los servidores
de configuración están contenidos dentro de un
replica set, lo cual aumenta la consistencia y la
disponibilidad. Y la división entre varios enrutadores
lo que nos permite es tener distintos servidores de
aplicación y de este modo balancear la carga de
peticiones que vienen desde el exterior.
Otro aspecto interesante a tener en cuenta es que,
aparte de este esquema de particionado o de sharding
que Mongo puede realizar automáticamente, además
Mongo cada subconjunto que provenía de una
colección y que está ubicado en un determinado
shard, lo puede dividir a su vez en lo que conocemos
como distintos chunks. A partir de esta manera de
fragmentar los datos, lo que nos permite Mongo es
aumentar las prestaciones en cuanto a latencia de
cada una de las operaciones, permite aumentar la
escalabilidad del sistema global y también nos
permite balancear la carga en cuanto a los datos que
contiene cada uno de los shards. De manera que
Mongo puede decidir automáticamente migrar
determinados conjuntos de chunks de un shard a
otro.
 De este modo, tenemos bien equilibrada la carga de
datos que existe en cada una de las particiones.
Obviamente, cada solución presenta muchos más
detalles de los que podemos abordar en un solo
capitulo.

INTRODUCCIÓN A BBDD ANALÍTICAS Y ORIENTADAS A GRAFOS

Hasta hace poco más de una década, las bases de

datos relacionales, tradicionales, eran utilizadas para
resolver los problemas de las empresas en su día a
día, lo que podemos denominar como soluciones
operativas, es decir, mantenimiento de registros,
mantenimiento del stock de productos,
mantenimiento de cuentas de usuario, para dar
acceso o no a usuarios registrados, etcétera.

¿Qué ocurre?
Que, como venimos viendo, el aumento de los datos
está siendo masivo. Y, claro, a raíz de esto se nos
plantea la posibilidad de que, además de todas estas
soluciones operativas, podemos realizar muchas más
acciones con estos datos que nos pueden llegar a dar
un conocimiento muy valioso.
De esta manera, surge una necesidad que es, a partir
de esta inmensa cantidad de datos, cómo vamos a
poder analizarlos de manera que obtengamos
información valiosa.
Está claro que necesitamos un proceso en el que se
depure y se transformen estos datos de manera que,
finalmente, obtengamos un conjunto de datos
elaborado que nos permita tomar decisiones
realmente importantes y que van mucho más allá de
lo que es el mantenimiento del día a día de nuestra
empresa.

En esto es en lo que se basa el concepto de "business

intelligence", este es un concepto que se entiende muy
bien teniendo en cuenta estas dos frases que pongo
como ejemplo.
Por un lado, tenemos a Mister Codd, que es
considerado el padre de las bases de datos
relacionales, que allá por los años 90 dijo que,
"disponer de un sistema de bases de datos
relacionales no significa disponer de un sistema
de soporte a la toma de decisiones".

Por otro lado, hace pocos años, Wayne Calloway, como CEO de PepsiCo dijo en una junta de accionistas,
"hace diez años les pude decir cuántos Doritos vendimos en el oeste en Mississippi". "Hoy no sólo les puedo
decir eso mismo, sino cuántos vendimos en California, en el Condado de Orange, en la ciudad de Irvine, en
el supermercado local Von's, durante una promoción especial, al final del pasillo 4, los jueves".
Como se ver, aquí ha habido una evolución muy clara en cuanto a lo que es el concepto de dato y el concepto
de la información que podemos extraer de los datos que hemos ido almacenando. De esta manera, la
información actualmente está fragmentada y es escudriñada hasta obtener datos de increíble valor para los
negocios.

¿Cómo atendemos a la necesidad de convertir estos

datos en información valiosa?
Mediante un análisis efectivo y eficiente de esta gran
y masiva cantidad de datos.
¿Cuáles son los inconvenientes a los que nos
enfrentamos para realizar este análisis, teniendo en
cuenta que los sistemas operacionales normales
están en continuo funcionamiento y es difícil
interaccionar con ellos?
Tenemos que tener en cuenta que los inconvenientes importantes que nos podemos encontrar son que esta
interferencia con el sistema operacional nos lleva a la ralentización, tanto en lo que son las acciones del día
a día, como en nuestro proceso de adquisición de este conocimiento.
Asimismo, tenemos que saber que los datos normalmente se guardan de una manera desestructurada y,
sobre todo, de una manera muy heterogénea. Es decir, nos podemos encontrar algunas bases de datos
relacionales bien estructuradas, pero lo normal es encontrarse distintos registros que no tienen utilidad,
registros repetidos, registros distribuidos en distintos formatos, como podrían ser bases de datos, ficheros de
texto, etcétera.
Y, a su vez, estos registros, debido también a esta heterogeneidad inherente, carecen de una fiabilidad certera
en el momento en el que los tenemos registrados, y también son volátiles puesto que, como estamos en un
sistema operacional del día a día, estos registros son continuamente actualizados, son borrados, se insertan
nuevos registros, etcétera.

Teniendo en cuenta todos estos inconvenientes y en

aras de intentar resolverlos, se desarrolló el concepto
de "Data Warehouse".
El "Data Warehouse" lo podemos ver como un gran
almacén de datos donde prima la estructura de la
información, es decir, la clave del "Data Warehouse"
que nos va a permitir obtener y extraer un
conocimiento valioso es que la información está bien
estructurada y es muy fiable.
Para resolver estos inconvenientes, un "Data
Warehouse" presenta las siguientes características.
En primer lugar, es un sistema integrado, como he
dicho, tiene una estructura consistente y los datos
bien homogeneizados. Por otro lado, además, los
datos están caracterizados temáticamente, es decir,
tenemos una categorización que nos permite acceder
a distintos tipos de datos de manera efectiva con tal
de poder realizar estudios bien orientados hacia
nuestros intereses.
Otra característica muy importante es que un "Data Warehouse" contiene los datos de manera histórica, es
decir, los datos que contiene un "Data Warehouse" registran la tendencia y evolución de ellos mismos.
Esto está relacionado con la no volatilidad de estos datos, es decir, la información en este "Data Warehouse"
simplemente es introducida y leída, pero jamás se modifica. Esto es lo que permitirá que podamos analizar
toda la tendencia y evolución existente en los datos y de manera categorizada.

Aquí tenemos un esquema simplificado de los

componentes que interactuarían con este "Data
Warehouse".
En este esquema podemos observar que el "Data
Warehouse" recibe una determinada entrada y tiene
varias salidas.

Esta entrada determinada viene de la metodología

conocida como "ETL", que son las siglas de "extract,
transform and load".
El proceso de "extract" consiste en la obtención de
datos de las distintas y heterogéneas fuentes
existentes, es decir, podemos tener en cuenta la base
de datos de facturación de la empresa, el ERP de la
empresa, incluso podemos contar con ficheros en
texto plano.

Esta extracción de datos es lo que se realizaría en una primera fase para luego transformarlos lo que
consistirá en homogeneizarlos, filtrarlos, depurarlos y categorizarlos. De esta manera, tendremos los datos
bien preparados para hacer el volcado de éstos en lo que será nuestro almacén de datos.
A su vez, este volcado de datos vendrá acompañado de distintos metadatos que acompañarán a cada registro.
Finalmente, la salida del "Data Warehouse" será la explotación de estos datos, y esta explotación puede venir
en forma de realización de informes, analítica de resultados o de los propios datos y técnicas de "data
mining" sobre éstos.
Con la evolución de los sistemas Big Data veremos
que este esquema que acabo de presentar es muy
simple y que actualmente pasa a formar parte de otro
más complejo, que es el denominado "Corporate
Information Factory" que está constituido por algunos
componentes más y distintos diagramas de flujo de
información.

Todo esto lo veremos en el siguiente capítulo, de

la misma manera que también haremos un
repaso a las denominadas bases de datos
orientadas a grafos.

Este tipo de bases de datos están adquiriendo mucho

protagonismo en los últimos años y, de hecho, este
paradigma no es nada nuevo y seguro que a muchos
de ustedes les suenan o están familiarizados con los
diagramas UML, o con mapas conceptuales, que
obedecen a estas estructuras.

En esencia, las bases de datos orientadas a grafos

representan entidades individuales y sus relaciones.
Las entidades, como puede ser una persona, un
objeto, una cuenta bancaria, están representadas
mediante nodos o vértices, y las relaciones entre estas
entidades están representadas por arcos o
conexiones.
Como podemos ver, tanto los vértices como los arcos,
contienen a su vez propiedades que nos permitirán
recorrer el grafo y las relaciones existentes entre los
datos que contiene.

De este modo, tenemos que las bases de datos

orientadas a grafos centran su potencial en las
relaciones entre entidades, permitiendo explorar
caminos que las unen o analizar las relaciones
existentes entre las entidades más próximas.
Obviamente, una de las grandes ventajas de este tipo
de bases de datos es que están respaldadas por todos
los métodos propios de la teoría de grafos que tanto
ha evolucionado durante el siglo XX.
Como he dicho, existen varios cálculos típicos y varios
algoritmos que se utilizan actualmente, de entre los
que destacaríamos, por ejemplo, el algoritmo de
"PageRank" de Google, también algoritmos basados
en la determinación de los caminos o las rutas más
cortas, que son muy útiles para empresas o negocios
de transporte, y también tenemos, por ejemplo, los
algoritmos de componentes conectados o de
"clustering" que nos permiten por ejemplo, en
LinkedIn, saber cuál es nuestra red profesional más
cercana, o en aplicaciones de "dating online", saber
con qué entidades, en este caso, con qué personas
compartimos mayor cantidad de intereses.
Mas adelante profundizaremos en todo este tipo de
características y sobre todo en las herramientas
denominadas "Graph processing" que están
centradas en este tipo de bases de datos, como son
"Apache Giraph" o "Titan", que también están
integradas dentro del ecosistema de "Hadoop".