Hibernate Object/Grid Mapper (OGM) is a persistence engine providing Java Persistence (JPA) support for NoSQL datastores. It reuses Hibernate ORM’s object life cycle management and (de)hydration engine but persists entities into a NoSQL store (key/value, document, column-oriented, etc) instead of a relational database. It reuses the Java Persistence Query Language (JP-QL) as an interface to querying stored data.
The project is still very young and very ambitious at the same time. Many things are on the roadmap (more NoSQL, query, denormalization engine, etc). If you wish to help, please check Chapter 1, How to get help and contribute on Hibernate OGM.
Hibernate OGM is released under the LGPL open source license.
Warning
This documentation and this project are work in progress. Please give us feedback on
- what you like
- what you don’t like
- what is confusing
Check Section 1.2, “How to contribute” on how to contact us.
Hibernate OGM:
- offers a familiar programming paradigm to deal with NoSQL stores
- moves model denormalization from a manual imperative work to a declarative approach handled by the engine
- encourages new data usage patterns and NoSQL exploration in more "traditional" enterprises
- helps scale existing applications with a NoSQL front end to a traditional database
NoSQL can be very disconcerting as it is composed of many disparate solutions with different benefits and drawbacks. Speaking only of the main ones, NoSQL is at least categorized in four families:
- graph oriented databases
- key/value stores: essentially Maps but with different behaviors and ideas behind various products (data grids, persistent with strong or eventual consistency, etc)
- document based datastores: contains as value semi-structured documents (think JSON)
- column based datastores
Each have different benefits and drawbacks and one solution might fit a use case better than an other. However access patterns and APIs are different from one product to the other.
Hibernate OGM is not expected to be the Rosetta stone used to interact with all NoSQL solution in all use cases. But for people modeling their data as a domain model, it provides distinctive advantages over raw APIs and has the benefit of providing an API and semantic known to Java developers. Reusing the same programmatic model and trying different (No)SQL engines will hopefully help people to explore alternative datastores.
Hibernate OGM also aims at helping people scale traditional relational databases by providing a NoSQL front-end and keeping the same JPA APIs and domain model.
Today, Hibernate OGM does not support all of these goals. Here is a list of what we have:
- store data in key/value stores (Infinispan’s datagrid and Ehcache)
- store data in document stores (MongoDB)
- Create, Read, Update and Delete operations (CRUD) for entities
- polymorphic entities (support for superclasses, subclasses etc).
- embeddable objects (aka components)
- support for basic types (numbers, String, URL, Date, enums, etc)
- support for associations
- support for collections (Set, List, Map, etc)
- support for Hibernate Search’s full-text queries
- JPA and native Hibernate ORM API support
Here are a few areas where Hibernate OGM can be beneficial:
- need to scale your data store up and down rapidly (via the underlying NoSQL datastore capability)
- keep your domain model independent of the underlying datastore technology (RDBMS, Infinispan, NoSQL)
- explore the best tool for the use case while using a familiar programming model
- use a familiar JPA front end to datagrids (in particular Infinispan)
- use Hibernate Search full-text search / text analysis capabilities and store the data set in an elastic grid
These are a few ideas and the list will grow as we add more capabilities to Hibernate OGM.