Change Surfers

Perdiendo el miedo a las bases de datos NoSQL

En lo que almacenamiento de datos se refiere, en las últimas 3 décadas, el modelo entidad relación y los sistemas de Bases de Datos relacionales han sido un estándar de uso, y la normalización de bases de datos un estándar de calidad a tener en cuenta, llegando incluso a ser objeto de gobernanza en el ciclo de vida del software de grandes aplicaciones.

En el desarrollo de prácticamente cualquier proyecto, se realiza un gran esfuerzo en fase de diseño para construir un modelo de datos relacional lo más normalizado posible. Sin embargo, en la última década hemos vivido una drástica reducción del coste del almacenamiento, grandes avances en la escalabilidad horizontal de servidores y de aplicaciones,  además de un enorme incremento en la cobertura, velocidad y fiabilidad de las comunicaciones.  Por si fuera poco, la globalización y la puesta en escena de paradigmas como el IoT y el Big Data han creado nuevas necesidades de almacenamiento y de disponibilidad de la información. 

Para dar respuesta a estas necesidades, en los últimos años han surgido nuevos sistemas de Bases de Datos no relacionales, que permiten dar una mejor respuesta a muchas de las nuevas necesidades del mercado, como por ejemplo Cassandra de Apache, Oracle NoSQL o MongoDB. Existen diferentes tipos de bases de datos NoSQL y las solemos clasificar en base a la forma en la que se almacena la información: bases de datos key/value, bases datos orientadas a columnas o tabulares, grafos, documentales, etc. Uno de los modelos que nos permite más potencia y flexibilidad para el almacenamiento de modelos complejos es el modelo de datos documental. Este modelo, en lugar de estar basado en entidades y en sus relaciones, está basado en documentos y sus propiedades. Un documento sería el equivalente a una fila, la propiedad el equivalente a una columna y la colección el equivalente a una tabla. Cada documento es autodeclarativo, es decir, contiene su definición y el dato, normalmente suele representarse y almacenarse físicamente en formato  JSON o BSON. Podéis ampliar más información aquí.

Pero, ¿cómo afecta toda esta revolución en el almacenamiento de datos a nuestro día a día como desarrolladores de aplicaciones bancarias? Si bien es cierto que en nuestro sector llevamos años utilizando bases de datos no relacionales (ficheros indexados, texto plano, o incluso bases de datos relacionales desnormalizadas), la realidad es que a día de hoy disponemos de soluciones diseñadas a tal efecto, tan fiables y robustas como los sistemas de bases de datos relacionales, que nos permiten tratar con datos NoSQL de una forma estandarizada, sencilla y ágil, y que además están orientadas a este nuevo contexto del que antes hablábamos. Gracias a ello podemos dar soluciones sencillas a problemas que normalmente nos requieren de modelos de datos y de lógicas complejas. Por ejemplo, nos permite crear modelos de datos elásticos en las que el dato, la “fila”, es polimórfica, o nos permite anidar datos para disponibilizarlos en su consulta.

Vamos a ver estas ventajas en un caso práctico dentro de nuestro sector, como puede ser la consulta de movimientos de cuentas de nuestros clientes. 

En un modelo relacional, dispondremos de una tabla de contratos, una tabla de movimientos con toda una hilera de columnas que en muchos casos contendrían un valor nulo o por defecto, y con relaciones a otras tablas que contendrían datos relacionados con el movimiento en sí.

Si planteamos el mismo caso en un modelo NoSQL, como por ejemplo en un modelo de base de datos documental, el modelo sería mucho más sencillo. Para este caso tendríamos una colección de documentos, donde cada documento corresponde a un movimiento, y cada movimiento tendría únicamente los campos que le correspondan según su naturaleza, además, en lugar de disponer una relación con la información relacionada a este, este estaría anidada:

Si contrastamos ambas soluciones, veremos que ambas aportan sus ventajas y sus inconvenientes. Por ejemplo, en el modelo de datos relacional no hay redundancia de datos, si por ejemplo, tuviéramos los datos de un recibo asociado a un movimiento, estos estarían almacenados únicamente en la tabla de recibos, para ser consultados desde diferentes aplicaciones, sin embargo, en el modelo NoSQL el recibo debería de estar anidado en aquellos documentos en los que se necesite relacionar. Sin embargo, en el modelo NoSQL, al ser polimórfico no es necesario almacenar todas las columnas posibles, con el consecuente ahorro de espacio, ni es necesario ejecutar la consulta a diferentes entidades, dado que los datos relacionales están anidados, con el consecuente ahorro en tiempo de ejecución de la consulta.

Entonces, ¿cuál de los dos modelos es el que nos aporta más ventajas? Bien, como siempre, la respuesta es: depende. En un nuevo software, o en una refactorización de uno existente, debemos de plantearnos cuál de los dos modelos nos aporta más ventajas, y cuándo utilizar uno u otro, o una combinación de ambos. Deberíamos hacernos preguntas como por ejemplo:

  • – ¿Qué tipo de relaciones hay entre mis datos? Hay que tener en cuenta que los modelos ER permiten relaciones 1-1, 1-n y m-n, sin embargo el en un modelo documental, no se pueden implementar relaciones m-n de forma sencilla.
  • – ¿Mi aplicación está orientada a consulta o a operación? Cuando tratamos con operaciones de consulta, el modelo NoSQL suele aportar ventajas en el consumo de recursos, ya que gracias a la redundancia, se evita el tener que realizar consultas entre diferentes entidades, sin embargo, en operaciones CRUD, la redundancia supone una dificultad y un incremento de consumo de recursos.
  • – ¿Mi modelo de datos es estático, o es elástico? En modelos de datos elásticos es dónde el modelo NoSQL aporta una gran ventaja, al no tener que definir todos los campos posibles para el equivalente a una fila. Por ejemplo, si necesitamos incorporar un nuevo campo a una entidad de datos o necesitamos un campo en un conjunto muy reducido de filas, no es necesario incorporarlo para todos los registros existentes en la entidad.

Además de estos factores, también deberíamos plantearnos otra serie de cuestiones en función de la tecnología utilizada para almacenar los datos. Por ejemplo, si escogemos como modelo documental una base de datos MongoDB, esta permite distribuir los datos en forma de cluster, dándonos incluso la opción de almacenar los datos en el nodo que se encuentra más cercano físicamente a su consumidor para reducir la latencia. 

Como véis, hay mucho que valorar antes de decidirnos por el tipo de modelo de datos a utilizar. En el caso que hemos ejemplificado anteriormente, una solución óptima sería mantener ambos modelos de datos, manteniendo las operaciones CRUD sobre los movimientos de cuentas en una base de datos relacional (por ejemplo en un ecosistema mainframe COBOL/IMS/DB2), y redundar la información de movimientos en una base de datos documental (por ejemplo en un ecosistema J2EE/MongoDB) con un volcado periódico para disponibilizar su consulta. Esto nos permite tener una alta fiabilidad en las operaciones CRUD y una alta disponibilidad en las consultas, además de liberar de carga de recursos a sistemas heredados con un elevado coste por uso.

A partir de aquí, teniendo en cuenta que disponemos de soluciones en nuestro sector que nos permiten trabajar con bases de datos NoSQL de una forma tan fiable como la de los SGBD comerciales, tenemos que perderle el miedo al NoSQL y utilizarlo como una herramienta más que nos permita ofrecer la mejor solución posible a nuestros clientes.