Estamos muy habituados a trabajar con bases de datos SQL como MySQL, MariaDB, Oracle, etc. La razón por la cual este tipo de base de datos es el más común es porque son muy versátiles y hasta no hace mucho servían para todo tipo de proyectos. En el post de hoy analizamos el desconocido mundo de las noSQL.
Con la llegada de las redes sociales, Big Data e IoT, el volumen de datos que se deben almacenar y procesar en proyectos de estas características ha empezado a incrementar exponencialmente. Hasta tal punto, que el uso de bases de datos distribuidas fue inevitable. Ante esta situación, con la entrada en juego de las bases de datos distribuidas, se empezaron a buscar soluciones para garantizar consistencia, disponibilidad y partición de datos.
A medida que se se ha ido avanzando en las investigaciones se ha llegado a un punto en que se estableció el teorema CAP. Este teorema concluye que es imposible encontrar una solución que pueda garantizar:
- Consistencia de datos, es decir, que todas las peticiones de lectura en un instante de tiempo concreto obtengan la misma respuesta.
- Disponibilidad de datos, es decir, que todos los datos reciban siempre una respuesta correcta.
- Tolerancia a la partición, es decir, que se permita dividir los datos de forma sencilla con tal de distribuirlos en distintos servidores.
¿Por qué aparecen las noSQL?
Basándonos en el teorema CAP, una base de datos relacional (SQL) garantiza la consistencia y la disponibilidad de datos. Pero cuando llega el momento de distribuir en diferentes servidores es muy costoso mantener la coherencia por lo que cualquier consulta de escritura implica mucho esfuerzo. A raíz de esta problemática, empezaron a surgir bases de datos que garantizaban la tolerancia a la partición a cambio de no asegurar la consistencia o la disponibilidad de datos.
¿Qué opciones tenemos dentro del mundo noSQL?
A partir del teorema CAP surgen varias combinaciones entre consistencia, disponibilidad y tolerancia a la partición. También surgen nuevas soluciones que cambian el paradigma del almacenamiento de datos por lo que las noSQL, en función de cómo se tratan los datos, se organizan en:
Key – Value stores
Una base de datos key-value consiste en almacenar parejas clave-valor con claves únicas. Gracias a esta estructura simple, solo se permiten operaciones simples CRUD (Crear, Leer, Actualizar y Borrar). A este tipo de base de datos se les suele decir que no tienen esquema ya que todo modelo dependerá de la lógica de la aplicación que lo use. La ventaja de este modelo de datos recae en su simplicidad que garantiza la tolerancia a particiones. En cuanto a consistencia y disponibilidad de datos hay ejemplos que garantizan la consistencia como Redis y ejemplos que garantizan la disponibilidad como Riak.
Document stores
Una base de datos basada en documentos es una base de datos key-value que restringe los valores a formatos semiestructurados como los documentos JSON. Esta restricción proporciona flexibilidad cuando se accede a los datos. No solo es posible obtener un documento entero a partir de la clave sino que también se pueden obtener partes del documento o incluso realizar peticiones como agregación, búsqueda de texto, etc. Al tratarse de una evolución de las bases de datos clave-valor también garantiza la tolerancia a la partición en reprimenda de la consistencia o la disponibilidad de datos. Un ejemplo que garantiza la disponibilidad de los datos es Couchbase mientras que uno que garantiza la consistencia es MongoDB.
Column-oriented stores
En el paradigma clásico SQL los datos siempre han sido guardados en filas, es decir, en una fila puedes obtener todos los datos para una cierta clave. En las bases de datos orientadas a columnas, cada fila solo tiene conocimiento de un campo concreto pero conoce el de todos. Es decir, si en SQL tenemos una base de datos de usuarios con los campos «nombre» y «email», en una base de datos orientada a columnas tenemos dos filas, una con los nombres de todos los usuarios y otra con todos los emails. De forma similar a los tipos de bases de datos anteriores, bases de datos orientadas a columnas garantizan la tolerancia a la partición y se dispone de ejemplos que garantizan la consistencia como HBase y de ejemplos que garantizan la disponibilidad como Cassandra.
Graph
Con la llegada de las redes sociales surgen nuevos modelos de bases de datos que pretenden almacenar relaciones más eficientemente que las bases de datos relacionales. El modelo que más ha triunfado ha sido el de base de datos de grafos. En este tipo de bases de datos, la información se guarda en nodos que se relacionan entre sí formando grafos y garantizando lecturas muy rápidas de las relaciones. Un ejemplo de una base de datos de grafos es Neo4j que garantiza la consistencia y la disponibilidad de los datos en reprimenda de la tolerancia a particiones.
Esperamos que después de leer este post, tengáis más claro el mundo de las NoSQL. Si os ha sabido poco, no perdáis la pista a nuestro blog. En breve, os daremos algunos consejos para saber cuándo debéis usar bases NoSQL.
TO BE CONTINUED…
Nuestro Slashboy Iván Martínez, Software Developer, es el autor de este post.
