transacciones - ejb java

¿Manera fácil de almacenar y recuperar objetos en Java sin usar una base de datos relacional? (9)

¿Conoces una forma "fácil" de almacenar y recuperar objetos en Java sin usar un DB / ORM relacional como Hibernate ?

[ Tenga en cuenta que no estoy considerando la serialización tal como está para este propósito, ya que no permitirá recuperar objetos arbitrarios en el medio de un gráfico de objetos. Tampoco estoy considerando DB4O debido a su licencia restrictiva. Gracias. ]

Significado "fácil": no tener que manejar detalles de bajo nivel como pares de clave / valor para reconstruir un gráfico de objetos (como con BerkeleyDB o cachés tradicionales). Lo mismo se aplica a la reconstrucción de objetos desde un DB orientado a documentos o columnas (CouchDB, HBase, ..., incluso Lucene).

Tal vez haya proyectos interesantes por ahí que proporcionen una capa de integración entre los sistemas de almacenamiento mencionados y el modelo de objetos (como ORM sería para RDBMS) que no conozco.

¿Alguien con éxito usando aquellos en producción, o experimentando con estrategias de persistencia que no sean DB relacionales? ¿Qué hay de las tiendas RDF?

Actualización : me encontré con un artículo muy interesante: una lista de tiendas distribuidas de valores-clave

Hmm ... sin serialización, y sin una solución ORM, me gustaría recurrir a algún tipo de implementación basada en XML. Todavía tendría que diseñarlo con cuidado si desea extraer solo algunos de los objetos del gráfico objeto, quizás un archivo diferente para cada objeto, donde un URI hace referencia a las relaciones de objeto a otro archivo.

Hubiera dicho que no era "fácil" porque siempre me ha costado algo de tiempo diseñar el mapeo de XML en objetos, pero me inspiró mucho una conversación sobre Apache Betwixt que me hace sentir esperanzada de que estoy simplemente desactualizado, y las soluciones más fáciles ya están disponibles.

Me gustaría recomendar XStream, que simplemente toma sus POJO y crea XML de ellos para que pueda almacenarlo en el disco. Es muy fácil de usar y también es de código abierto.

Sigo pensando que deberías considerar pagar por db4o .

Si desea algo más, agregue "con una licencia de estilo MIT" al título.

NeoDatis parece interesante. Está licenciado bajo LGPL, por lo que no es tan restrictivo como el GLP propiamente dicho.

Eche un vistazo a su tutorial de 1 minuto para ver si funciona para sus necesidades.

Serialización de objetos (también conocido como almacenar cosas en un archivo)
Hibernate (utiliza una base de datos relacional pero es bastante transparente para el desarrollador)

Sugeriría Hibernate porque tratará con la mayoría de los detalles desagradables que desaniman a los desarrolladores cuando usan una base de datos y al mismo tiempo permite las optimizaciones que se han realizado con el software de base de datos a lo largo de los años.

Terracotta proporciona una tienda persistente de objetos en disco altamente disponible y altamente escalable. Puede usarlo solo para esta característica sola o puede usar su amplia gama de funciones para implementar una aplicación completamente en clúster: su elección.

Terracota:

no rompe la identidad del objeto dándole la interfaz de programación más natural
no requiere serialización
agrupa (y persiste) casi todas las clases de Java (Maps, Locks, Queues, FutureTask, CyclicBarrier, y más)
persiste objetos en el disco a velocidades de memoria
mueve solo deltas de objetos, dando un rendimiento muy alto

Aquí hay un caso de estudio sobre cómo gnip usa Terracotta para la persistencia en memoria: sin base de datos. Gnip recoge todos los eventos en Facebook, Twitter y similares y los produce para los consumidores de forma normalizada. Su solución actual es procesar más de 50,000 mensajes / segundo.

Es OSS y tiene un alto grado de integración con muchos otros frameworks de terceros, incluidos Spring e Hibernate.

Supongo que encontré un tipo de respuesta a mi pregunta.

Obtener la mentalidad de paradigma orientado a documentos no es una tarea fácil cuando siempre ha pensado sus datos en términos de relaciones, normalización y uniones.

CouchDB parece ajustarse a la factura. Todavía podría actuar como un almacén de clave-valor, pero sus excelentes capacidades de consulta (mapa / reducir, ver intercalaciones), la disponibilidad de concurrencia y el acceso HTTP independiente del idioma hacen que sea mi elección.

El único error es tener que definir y asignar correctamente las estructuras JSON a los objetos, pero estoy seguro de que encontraré una solución simple para el uso con modelos relacionales de Java y Scala (y me preocuparé más adelante por el almacenamiento en caché, ya que la contención se aleja de la base de datos). Terracota aún podría ser útil, pero ciertamente no como en un escenario RDBMS.

Gracias por su aportación a todos ustedes.

Mira los comentarios de Prevayler sobre esta pregunta . Prevayler es un contenedor transaccional alrededor de la serialización de objetos: aproximadamente, usa objetos en Java simple y persiste en el disco a través de la API de Java sin sql, un poco más ordenado que escribir tu propia serialización.

Advertencias: con la serialización como mecanismo de persistencia, usted corre el riesgo de invalidar sus datos guardados cuando actualiza la clase. Incluso con una biblioteca contenedora, probablemente desee personalizar el manejo de serialización / deserialización. También ayuda a incluir serialVersionUID en la clase, por lo que anula la idea de la JVM de cuándo se actualiza la clase (y, por lo tanto, no puede volver a cargar sus datos guardados en serie).

Recomiendo Hibernate (o, más en general, OR-mapping) como Matt, pero también hay un RDBMS en el back-end y no estoy tan seguro de a qué te refieres con

... sin usar una base de datos relacional? ...

También sería interesante saber más acerca de la aplicación, porque el mapeo OR no siempre es una buena idea (rendimiento de desarrollo vs. rendimiento de tiempo de ejecución).

Editar: Pronto aprendí sobre terracota y aquí hay una buena discusión sobre el flujo de acumulación de información sobre cómo reemplazar los DB con esa herramienta. Todavía experimental, pero vale la pena leerlo.