Skip to main content
Spring Data

MongoDB, Cassandra, Oracle y Spring Data: Juntos, pero no muy revueltos

Con este post pretendo dar a conocer nuestra experiencia aplicando Spring Data para hacer uso de distintos stores de datos, en concreto, MongoDB, Oracle Database y Cassandra.

Hoy en día existen multitud de bases de datos: relacionales, de tipo key-value, orientadas a documento, orientadas a fila, orientadas a grafos, etc. Y es totalmente lógico dado que la naturaleza de nuestros datos no es siempre la misma, entonces tendremos que aplicar la solución que mejor se adapta a nuestros datos y no al revés.

Lo primero, explicar el contexto del proyecto: Proporcionar una solución que permitiera explotar datos almacenados en distintos tipos de stores (MongoDB, Oracle y Cassandra) de manera que de cara al desarrollo de aplicaciones fuera lo más simplificado y transparente posible, por lo que partimos de los siguientes requerimientos:

  • Minimizar el código requerido por las aplicaciones para acceder a los datos: A menos código, mayor facilidad de mantenimiento y menor acoplamiento.
  • Homogeneizar la capa de acceso a los datos para así abstraer detalles específicos de los stores, de las aplicaciones cliente: De esta manera se reduce el impacto por mover los datos de un store a otro; y también facilita la labor de los desarrolladores porque siempre van a manejar el mismo API independientemente del store al que tengan que acceder.

​Sondeando posibles alternativas, finalmente nos decantamos por Spring Data por las siguientes razones:

  • Es un proyecto de Spring basado en Spring, y esto en sí es un punto a favor dado que podemos aprovechar todos los beneficios que nos ofrece este maravilloso framework.
  • Soporta un gran número de stores: Redis, Hadoop, GemFire, Neo4J, …
  • Posibilidad de exponer los stores​ a través de servicios REST.
  • Y, sobre todo, la enorme sencillez con la que se accede a los stores: Basta con definir un interfaz de tipo Repository indicando los datos y métodos a exponer y Spring Data automáticamente se encarga de generar el resto; más limpio y sencillo, imposible.

Spring Data simplifica el acceso a los stores, pero internamente utiliza mecanismos existentes: JDBC en el caso de Oracle; driver Java de MongoDB en MongoDB; y CQL en Cassandra.

Pero como se dice habitualmente “nada es perfecto” y no podíamos obviar el hecho de que Cassandra no está soportado oficialmente por Spring Data, sino que es un proyecto mantenido por la comunidad y en estado incubation con muchas de sus librerías en versión SNAPSHOT cuya frecuencia de actualización fue bastante alta, al menos durante el tiempo que estuvimos trabajando con ellas.

Después de hacer algunas pruebas con Spring Data en los tres stores, nos decidimos a utilizarlo porque en el mejor de los casos nos cubriría el 100% de los stores y en el supuesto más pesimista nos resolvería 2 stores de 3 (MongoDB y Oracle quedaban cubiertos, Cassandra no estaría cubierto en su totalidad).

El desenlace fue el siguiente. Tanto para MongoDB como Oracle a través de JPA, Spring Data funciona perfectamente, pero en caso de Cassandra no fuimos capaces de que funcionara en todos los escenarios que teníamos que cubrir.

Lo que funciona en Spring Data Cassandra:

  • Creación de la tabla en Cassandra: Spring Data Cassandra permite crear directamente la tabla (aka column family en terminología Cassandra) aunque, en nuestro caso, necesitábamos obtener la sentencia CREATE TABLE para que pudiera ser ejecutada por un administrador de Cassandra, en lugar de que fuera directamente ejecutada por una aplicación que no tiene por qué tener credenciales para la creación de column families. Tuvimos que realizar una pequeña modificación en el código del proyecto para poder recuperar la sentencia CREATE TABLE.
  • Inserciones de filas a través del método save.
  • Consultas del tipo findAll sin paginación.

Lo que no funciona (o que nosotros no conseguimos que funcionase, aunque seguro que con el tiempo estará perfectamente resuelto):

  • Búsquedas paginadas y búsquedas por columna (métodos findByXXX).

Finalmente, decidimos implementar nuestro propio repositorio de Cassandra basándonos en CQL e inspirándonos en Spring Data para la parte de paginación (clases Page y Pageable pero sin poder hacer uso de ellas porque no están pensadas para Cassandra dado que hacen uso del tipo int y Cassandra requiere un rango mayor de tipo long).

Las conclusiones:

  • No hemos apreciado un impacto en el rendimiento por el hecho de introducir una capa más como es la de Spring Data.
  • MongoDB con Spring Data ofrece un rendimiento increíble al menos en las pruebas que hemos realizado y con un volumen de datos razonable; el mejor de todos.
  • Cassandra ofrece algo de menor rendimiento, pero con la ventaja de que el performance no se ve afectado por el volumen de los datos.

Temas pendientes a tratar en futuros posts:

  • Consideración de la naturaleza y tratamiento de los datos a la hora de elegir el store en el que almacenarlos.
  • Cómo resolver la paginación en Cassandra a través de CQL.

 

 

Alberto Rodríguez Berzal

Alberto Rodríguez Berzal

Arquitecto software, especialista SOA&BPM, programador multilenguaje, experto J2E, administrador Weblogic y más. Con más de 15 años de experiencia profesional y 25 como programador, pero solo uno haciendo cerveza casera.

Alberto Rodríguez Berzal ha escrito 2 entradas


Alberto Rodríguez Berzal

Alberto Rodríguez Berzal

Arquitecto software, especialista SOA&BPM, programador multilenguaje, experto J2E, administrador Weblogic y más. Con más de 15 años de experiencia profesional y 25 como programador, pero solo uno haciendo cerveza casera.

3 comentarios en “MongoDB, Cassandra, Oracle y Spring Data: Juntos, pero no muy revueltos

  1. Hola Alberto. Muy bueno tu artículo y el siguiente sobre las consultas paginadas en Casandra. Estoy planteando una arquitectura con un WSO2 ESB que invoque a una aplicación Spring y después de leer tu artículo será Spring Data seguramente. Pero estaba dudando entre usar Cassandra como Store de un volumen de datos muy heterogéneo de 6 aplicaciones diferentes que pueden tener registros de la misma persona, pero con datos comunes o disjuntos, que de alguna forma tengo que reprocesar y consolidar en un repositorio único Oracle. La duda es, para este Store temporal que debe tener un rendimiento óptimo, había pensado en Hadoop con HBASE y hacer uso de los nuevos frameworks de Apache (Spark, flume, Storm), ¿qué me aportaría usar Cassandra o MongoDB en lugar de HBASE? Decías que SpringData tenía conector con Hadoop, pero no mencionas si lo usabas para consultas contra Cassandra o MongoDB (si es que se puede… que hablo desde el desconocimiento).

    Gracias y enhorabuena de nuevo.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *