Antes de entrar en profundidad en la parte más teórica sobre bases de datos NoSQL, vamos a recordar que existen otros tipos de bases de datos.

En primer lugar las BBDD relacionales que yo diría que son las más utilizadas hoy en día. Este tipo de BBDD son con las que, si os dedicáis al mundo del desarrollo, ya habréis trabajado. Un ejemplo de este tipo de BBDD son Oracle o MySQL. Estas BBDD basan su funcionamiento en un modelo relacional que permite establecer relaciones entre los datos alojados en las diferentes tablas. Estas BBDD se componen de tablas con campos definidos a la hora de la creación de la tabla, y utilizan claves primarias o ajenas para las relaciones. Además, poseen un lenguaje relacional para la manipulación de la información. Uno de los lenguajes relacionales más extendido es SQL.

Luego, aunque menos utilizadas o menos conocidas, están:

• Jerárquicas: Donde la información se almacena en forma de nodos de un árbol
• Transaccionales: Muy poco usadas, se centrar en el envío y recepción de grandes cantidades de datos, en ellas no importa la duplicidad de datos, sino que las operaciones se hagan a la mayor velocidad posible.

En algunos sitios hacen más separaciones y añaden más tipos, pero no creo que sea necesario entrar más en detalle aquí ya que el artículo no trata e BBDD en general, sino de BBDD NoSQL.

Ahora bien, ¿por qué las BBDD NoSQL? ¿De donde nace la necesidad de un nuevo paradigma para BBDD? Hasta hoy el mundo, en mayor o menor medida, a funcionado muy bien con BBDD relacionales, estas son las más utilizadas y nos ofrecen multitud de herramientas para trabajar con ellas y asegurar que todas las operaciones han ido correctamente o advertirnos de que han fallado para que podamos poner remedio o tomar medidas en consecuencia.

Entonces, ¿de donde ha salido todo esto? Pues bien la respuesta corta es de Internet. La respuesta larga, sería la proliferación y expansión de Internet que ha hecho que hoy en día haya compañías que exclusivamente tienen sus negocios en la nube, y que poseen millones y millones de usuarios que generan billones y billones de datos e información que necesita ser procesada. Véase como ejemplo Google, Facebook, Amazon, Twitter o simplemente cualquier startup que tenga éxito en Internet. Todas estas compañías tiene una necesidad de procesamiento de datos que una BBDD relacional no puede aportar o al menos no lo puede hacer de una forma sencilla. En el caso de estás compañías necesitan realizar un tratamiento de cantidades ingentes de datos en tiempo real y a una velocidad que no les permitían las BBDD relacionales. En este caso, la mayoría de las BBDD NoSQL están altamente optimizadas para el almacenamiento y recuperación de datos.

Como supongo que ya habréis ido perfilando a partir de las lineas anteriores las BBDD NoSQL se caracterizan por:

• Ausencia de esquema: Los datos no se definen con una estructura de atributos fija, o lo que viene siendo lo mismo, cada registro o documento almacenado en una tabla puede contener diferente información según su necesidad.
• Escalabilidad: Cada vez más usuarios, cada vez más información a procesar, si algo está claro es que la infraestructura inicial ha tenido que ir creciendo a la vez que estás dos cosas lo hacían. Las BBDD NoSQL tienen mecanismos para facilitar la escalabilidad horizontal (mucho más fácil y barata que la vertical) haciendo así posible aumentar el número de nodos de que disponemos para procesar la información según aumenten nuestras necesidades. Dos de estos mecanismos son Map-Reduce y Sharding, que veremos más adelante o quizás en una serie dedicada a Big Data y Web Intelligence (está por decidir aún).
• Velocidad: Como ya hemos dicho, mucha de esta información es procesada en tiempo real, con lo cual una de las cosas más importante es la velocidad, velocidad que nos aporta este tipo de BBDD. Muchas de estas BBDD incluso almacenan información únicamente en memoria y simplemente la vuelcan cada cierto tiempo en el disco duro, dandonos unas tasas de velocidad inimaginables para una BBDD relacional.

Con todo esto, tenemos unas BBDD capaces de manejar enormes cantidades de información, que podemos escalar fácilmente ejecutándolas en clusters de servidores de PCs baratos y que además, no tienen problemas de rendimiento ni cuellos de botellas como las BBDD relacionales.

Entonces, ¿estamos antes la BBDD definitiva? Aquella que va a desplazar y a hacer desaparecer las BBDD relacionales. Ni muchísimo menos. Como hemos podido observar a lo largo del artículo, este tipo de BBDD se crearon para resolver un tipo de necesidades muy específicas, pero para poder enfrentarse a estas necesidades, hubo que dejar de lado otras cosas que nos aportan las BBDD relacionales.

Este tipo de BBDD no permite sin ayuda externa el control de transacciones de datos únicos, la información es más volátil que en sistemas relacionales, no permite la realización de operaciones complejas entre tablas como el producto cartesiano (JOIN). En definitiva, sacrifican algo de fiabilidad y operatividad en beneficio de la velocidad. Por poner un ejemplo para que se vea esto claramente, imaginemos un banco, que al día tiene cientos de transferencias de dinero, para un banco la velocidad no es necesaria, recordemos que las transferencias suelen tardar entre uno y dos días, pero perder una sola de estas transferencias sería un gran problema. El banco necesita un sistema relacional, con sus transacciones, con su control de errores y con su persistencia de datos.

Como siempre, hay que decidir las herramientas que vamos a utilizar en función de las necesidades concretas de nuestro proyecto y no porque algo esté de moda o parezca muy bueno. Puede ser lo mejor, pero no para nuestro escenario.

Hasta aquí hemos llegado por hoy, en el próximo artículo de la serie veremos los tipos de BBDD NoSQL que existen y como trabajan. Nos vemos.