Contacta con nosotros.

+34 941 123 251

comunicacion@bosonit.com

Bosonit Agile Center

Portales 71, 2º Of. 7,8,9 y 10. LOGROÑO

Isabel la Católica, 6. (Edificio Hiberus). ZARAGOZA

Salvador Granes, 3. MADRID

San Esteban de Etxebarri, 8. BILBAO

Contacta con nosotros.
Back to top

Bosonit

  /  Big Data   /  Análisis de bases de datos NoSQL: características generales.
1. Comparativa de NoSQL vs SQL. El teorema CAP.

Desde que comenzaron a desarrollarse a principios de los 70, las bases de datos SQL se han convertido en un standard en el campo del almacenamiento de datos. Sin embargo, el aumento de los volúmenes almacenados y la necesidad de ejecutar consultas a tiempo real sobre grandes cantidades de datos ha hecho que poco a poco vayan apareciendo nuevos modelos de almacenamiento, denominados NoSQL. Dado que estas bases de datos SQL están altamente extendidas e instauradas en la industria, en este documento vamos a centrarnos en exponer ese otro tipo de bases de datos: los modelos NoSQL.

Antes de entrar en las características de estas, es importante mencionar otro concepto: el teorema CAP. Toda base de datos se basa en 3 pilares: consistencia, disponibilidad y tolerancia a partición

  • Consistencia: toda consulta va a devolver siempre los mismos datos, y en caso de error, antes optará por no devolver datos que por devolver algo erróneo. Importante en bases de datos donde transacciones sean importantes, como bancos.
  • Disponibilidad: toda consulta va a devolver datos, pese a posibles errores en el sistema, aunque estos no tengan por qué ser consistentes (pueden devolver diferentes salidas a dos clientes diferentes)
  • Tolerancia a partición: los datos pueden guardarse de manera distribuida en diferentes nodos

Pese a que son los 3 pilares entre los que se mueve una base de datos, no es posible que los 3 se cumplan a la vez. Siempre van a ser mutuamente excluyentes. Esto significa que en todos los casos se va a tener que priorizar 2 de los pilares sobre el tercero. Es por ello que este teorema se representa sobre el triángulo CAP. Elegir en que vértices nos moveremos dependerá de nuestras necesidades.

Las bases de datos SQL se basan en el segmento CA: proporcionan consistencia y disponibilidad. Sin embargo, esto se consigue teniendo todos los datos en un mismo equipo, lo cual lo hace intolerante a partición y por consiguiente no escalable horizontalmente. Bases de datos que requieren transacciones se moverán habitualmente en este vértice.

Las bases de datos NoSQL van a ser por definición escalables, y por tanto van a poseer la propiedad P. De este modo, si la escalabilidad horizontal es una necesidad, según las propiedades que necesitemos, tendremos que optar por una base de datos CP o una AP.

 

Las BBDD CP priorizan consistencia, de modo que la respuesta va a ser siempre única. Pero esto se consigue a base de bloquear el sistema a consultas en caso de ocurrir dos consultas simultaneas o un fallo (por supuesto, hasta que este fallo haya sido subsanado), lo que da el riesgo de que una consulta no devuelva resultados. Estas soluciones van a ser ideales en los casos de bancos o compañías donde tengan lugar transacciones económicas, ya que priorizarán que la transacción sea correcta aun a riesgo de que en caso de fallo la transacción no se produzca.

Por otro lado, las BBDD AP priorizan disponibilidad. Esto quiere decir que, en caso de fallo (o de estar el nodo primario ocupado), el sistema tirará de una de las réplicas en nodos secundarios. Esto significa que siempre nos van a devolver resultados, pero corremos el riesgo de que ese fallo (u operación simultanea) haya hecho perder información como para que dos consultas den resultados diferentes. Estas soluciones serán ideales cuando busquemos la respuesta en todo momento a una consulta, incluso si esta información no es 100% precisa, por lo que podremos aplicarlas en el uso de redes sociales o sistemas que requieran consultas a tiempo real.

2. Bases de datos NoSQL. Características generales

Como se ha comentado en el apartado anterior, las bases de datos noSQL se crean con el objetivo de cubrir el hueco que dejan las SQL en el triangulo CAP: la posibilidad de particionar los datos y ofrecer una escalabilidad horizontal. Además, el esquema rígido y predefinido de las BBDD SQL, aunque funcionalmente muy útil, supone un problema debido a que a menudo los datos son heterogéneos y no responden a un esquema prestablecido. Como resultado, todas las BBDD noSQL van a basar sus propiedades en torno a este factor de escalabilidad horizontal y a la flexibilidad. Podemos resumir estas propiedades en los siguientes puntos:

  • Esquemas flexibles: se pierde la estructura en tabla, pudiendo establecer diferentes niveles jerárquicos, e incluso pudiendo guardarse diferentes tipos de datos en un mismo campo
  • Sin esquemas predefinidos: no es necesario predefinir el esquema de la base de datos, sino que se pueden añadir nuevos campos a posteriori. Aun así, es recomendable en general tener una estructura predefinida, aunque luego se cambie (esto se conoce como datos semi-estructurados)
  •  Escalabilidad horizontal: Permiten el funcionamiento en clusters. Ya no es necesario tener todos los datos en un mismo equipo, por lo que cuando se requiere más espacio o capacidad de procesamiento, solamente hay que añadir una nueva máquina. Estas bases de datos en general están preparadas para que este proceso sea sencillo y dinámico, sin necesidad de reestructuraciones o migraciones.
  • Replicabilidad y alta disponibilidad: Al funcionar en clusters, es posible tener varias copias de un mismo documento en varios equipos, de modo que si uno de los equipos falla, automáticamente los otros toman el mando sin perdidas de datos ni rendimiento.
  • Particionado: uno de los mayores problemas de almacenar grandes cantidades de datos es que no puede guardarse toda una base de datos en un solo documento debido al gran tamaño de éste. La posibilidad de particionar se basa en que un documento puede distribuirse en varios equipos, eliminando la necesidad de que un solo disco tenga la capacidad de guardar todo un conjunto de datos.
  • Velocidad de consultas: Cuando las bases de datos crecen en tamaño, los tiempos de consulta de una SQL crecen, sobre todo cuando se requieren joins. Diferentes estructuras de datos y las arquitecturas en clusters reducen los tiempos de consulta cuando la cantidad de datos que maneja da es elevada.
  •  Velocidad de procesado: cuando se quieren hacer operaciones sobre toda la base de datos, las BBDD NoSQL llevan incorporados motores de procesamiento en paralelo, que reducen los tiempos de lectura y escritura sobre grandes tablas.

Es importante remarcar que, aunque las bases de datos noSQL giran generalmente en torno a estas propiedades, esto no significa que toda BBDD noSQL vaya a cumplirlas todas, ni que todas las noSQL vayan a ser igual de efectivas en cumplir todas las propiedades. De hecho, las BBDD noSQL se dividen en varios tipos, orientados a satisfacer unas prioridades u otras de acuerdo a diferentes necesidades. Entraremos en más detalle en estos aspectos en las siguientes secciones.

3. Tipos de bases de datos NoSQL. División por grupos
  • Clave-valor.
  • Grafos.
  • Series temporales.
  • Documentales.
  • Columnares.
  • Repostiorios de contenido.

Realizaremos en siguientes post (Bases de datos NoSQL 2 y  NoSQL 3) la conceptualización, comparación y ejemplificación de cada una de estas categorías, para profundizar en la tipología de bases de datos NoSQL. En un último post, analizaremos las nuevas bases de datos en la nube.