mongotemplate - ¿Cuál es la diferencia entre Spring Data MongoDB y Hibernate OGM para MongoDB?

spring data mongodb delete by (2)

Descargo de responsabilidad: soy el líder del proyecto Spring Data, así que cubriré principalmente el lado de Spring Data:

Creo que la distinción principal entre los dos proyectos es que el equipo de Hibernate OGM eligió centrar sus esfuerzos en torno a la JPA, mientras que el equipo de Spring Data no lo hizo explícitamente. Las razones son las siguientes:

JPA es una API inherentemente relacional. Las dos primeras frases del estado de especificación, que es una API para el mapeo relacional de objetos. Esto también está incorporado en los temas centrales de la API: habla de tablas, columnas, uniones, transacciones. Conceptos que no son necesariamente transferibles al mundo NoSQL.
Por lo general, elige un almacén NoSQL debido a sus características especiales (por ejemplo, consultas geoespaciales en MongoDB, pudiendo ejecutar recorridos de gráficos para Neo4j). Ninguno de ellos está (y estará) disponible en JPA, por lo que deberá proporcionar extensiones propietarias de todos modos.
Lo que es peor, JPA presenta conceptos que simplemente guiarán a los usuarios en direcciones equivocadas si asumen que funcionan en una tienda NoSQL como se definieron en JPA: ¿cómo debe implementarse una reversión de transacciones razonablemente sobre un MongoDB?

Así que con Spring Data, optamos por proporcionar un modelo de programación consistente para las tiendas compatibles, pero no intentar forzar todo en una única API sobre-abstracta: obtienes las implementaciones de plantillas conocidas, obtienes la abstracción del repositorio, que funciona de manera idéntica para todas las tiendas, pero le permiten aprovechar características y conceptos específicos de la tienda.

No he usado Spring Data anteriormente, pero he usado Hibernate ORM varias veces para aplicaciones basadas en MySQL. Simplemente no entiendo qué marco elegir entre los dos para una aplicación basada en MongoDB.

He intentado buscar la respuesta pero no puedo encontrar la respuesta que hace una comparación entre los dos en un entorno de producción. ¿Alguien ha encontrado problemas al trabajar con estos dos marcos con MongoDB?

Descargo de responsabilidad: soy uno de los desarrolladores de Hibernate OGM, así que intentaré proporcionar algunas de las razones detrás de esto.

Hibernate OGM proporciona soporte de persistencia de Java (JPA) para soluciones NoSQL. Reutiliza el motor de Hibernate ORM pero persiste a las entidades en un almacén de datos NoSQL en lugar de una base de datos relacional. También tiene como objetivo proporcionar acceso a funciones específicas del almacén de datos cuando JPA no tiene un buen ajuste.

Este enfoque es interesante por varias razones:

Conocidos semánticos y APIs. Los desarrolladores de Java ya están familiarizados con JPA, esto significa que uno no tendrá que aprender API de nivel inferior. También es compatible con HQL y consultas de back-end nativas.
Opción backend tarde. Elegir el almacén de datos correcto NoSQL no es trivial. Con Hibernate OGM, no tendrá que comprometerse con una solución NoSQL específica y podrá cambiar y probar diferentes backends fácilmente.
Herramientas y bibliotecas existentes. JPA y Hibernate ORM han existido por un tiempo y podrás reutilizar bibliotecas y herramientas que las utilizan debajo.
La mayor parte del modelo lógico JPA se ajusta. Un ejemplo de una buena adaptación es @Embedded , @EmbeddedCollection y @Entity (que puede ser un nodo, documento o caché basado en el almacén de datos de elección). Es cierto que los nombres de anotación pueden ser extraños porque también tendrá que lidiar con @Table y @Column .
JPA abstrae la persistencia en el nivel del objeto, dejando espacio para muchos trucos y optimizaciones. Tenemos varias ideas planificadas, como la persistencia políglota: almacenar datos en varios almacenes de datos y usar la mejor para un trabajo de lectura específico.

El principal inconveniente es que algunos de los conceptos de JPA no se asignan fácilmente al mundo NoSQL: las transacciones, por ejemplo. Si bien tendrá acceso a los métodos de demarcación de transacciones, no podrá revertir los almacenes de datos que no admiten transacciones de forma nativa (en este caso, las transacciones se utilizarán para agrupar operaciones e intentar optimizar el número de llamadas a la db).

Además, si su conjunto de datos no está centrado en el modelo de dominio por naturaleza, Hibernate OGM no es para usted.