FAQ

Q: OMG! Yet another ORM tool? Aren’t there many already?

A: There are quite a few ORM tools for NoSQL databases. Some of them only support a particular datastore while others may support more than one. Kundera currently supports Cassandra, HBase, MongoDB and relational databases. Idea behind Kundera is to make working with NoSQL databases drop-dead simple and fun. It achieves this objective by:

• Following JPA 2.0 standards
• Leveraging existing libraries like Pelops, Thrift, mongo-java-driver etc., and builds – on top of them a wrap-around API. This helps developers do away with the unnecessary boiler plate codes, and program a neater, cleaner code that reduces code-complexity and improves quality...and above all, improves productivity.

Q: JPA for NoSQL? Are you kidding me?

A: JPA is very easy to use and most of the people coming from Java EE world are already familiar with it. Another benefit is - code that developers are required to write is the same irrespective of underlying datastore. So switching between datastores is as easy as changing settings in a configuration file. Moreover, Learning JPA-QL is easy which makes it simple to perform operations over NoSQL databases.

Q: I am amazed at the ease of use Kundera provides. But I am clueless whether it will give good performance in my enterprise application. Your thoughts?

A: Kundera performance numbers are pretty close to what Pelops, Hector and other similar libraries provide. We tested Kundera with a million records and it worked well. You can test Kundera yourself (and we would love if you share your performance numbers with us).

Q: What do you mean by "Cross-datastore persistence" or "Polyglot Persistence"?

A: Cross-datastore persistence is a unique and powerful feature added to Kundera. It enables you to perform CRUD operations on related entities to be persisted into different datastores, with a single method call. Take for instance a case of Photographer who has many albums which in turn have many photos.

              (1-M)                  (1-M)
Photographer --------->    Album   --------->   Photo
(MySQL)                 (Cassandra)            (HBase)

With Kundera, all you need to do is create entity classes and define relationships. With entity class, you specify which datastore it is going to be persisted into. And that's it. You call one persist method of EntityManager and it persists all related entities into their corresponding datastores. Find, remove and JPA queries work in a similar way.

Q: Why does Kundera use and provide two different ways of secondary indexing?

A: Kundera depends on secondary indexing in order to give you strong JPA query support. It supports two options (Lucene text based indexing and data store inbuilt secondary indexing) via a property in persistence.xml.

Querying, if used with underlying data store inbuilt secondary indexing, would be faster as compared to Lucene. However, not all query features may be available with this option. Lucene based querying would give you more flexibility and query options.

Q: OK...OK...I understand simplicity, ease of use and all that stuff, but what about flexibility and power that I am accustomed to while using that plain vanilla low level library like thrift?

A: We understand JPA was built for relational databases and may not always provide you ways to perform functions (many times with certain tweaks) that are NoSQL specific. That's the reason we introduced data-store specific configuration in Kundera-2.0.7. For more on this, refer to Data store Specific Configuration.

Home