Hola, yo soy Andrés y me incorporo en este curso de Big Data con estos dos videos donde, como veréis en la primera parte, voy a explicar un poquito el origen y la necesidad de las tecnologías de bases de datos no relacionales o NoSQL. Haremos un pequeño repaso del contexto actual y os explicaré los tipos de aproximación, en cuanto a los modelos de datos que han dado lugar a las tecnologías actuales. Finalmente, os presentaré brevemente las tres tecnologías que estudiaremos en el siguiente video. El origen y la necesidad, como ya hemos visto en anteriores videos, 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 miles de millones de registros, 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". Pero, 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 que utilicemos de gestión de base de datos, 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, simplemente, 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. Estos son uno de los tipos de modelo de datos más utilizados en las bases de datos no relacionales, pero, existen algunos otros en los que haremos mención durante el curso. En esta gráfica podemos ver, de las más de 300 tecnologías de sistemas de base de datos, la tendencia en cuanto a popularidad que tienen, 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 relacional "de toda la vida", podemos decir, 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 en el siguiente video. 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 en anteriores videos, 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 Hadoop, 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, también tenemos clientes muy importantes como son 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. Hasta aquí hemos llegado con este primer capítulo introductorio. En el siguiente capítulo analizaremos un poquito más en profundidad estas tres tecnologías. Hasta pronto.
