8

We are in the process of getting our feet wet with Cassandra. None of us have any experience with this particular platform, but are experienced developers with JavaEE, JPA, etc. I came across the Kundera library that provides a JPA implementation compatible with several NoSQL datastores, including Cassandra.

It's tempting to go down this route, as we will be able to get up and running MUCH faster. However, is it the right idea? What are the tradeoffs of using a library like this? How does it affect performance? Is there a huge difference?

I'm curious to know what experiences others have had using this library. And, if there is something else we should look at instead I'd love to hear about it.

Shadowman
  • 11,150
  • 19
  • 100
  • 198
  • 5
    Please recheck the [faq], especially the "what _not_ to ask" section. This isn't a discussion board. – Mat May 01 '13 at 15:27
  • 1
    Another related question you can explore is http://stackoverflow.com/questions/15983190/cassandra-client-java-apis/15990877#15990877 – Easility May 02 '13 at 13:35
  • shame that more people don't actually close such questions as "primarily opinion based" since that is what this is – Neil Stockton Jan 13 '16 at 11:01

3 Answers3

10

Taking Jonathan's (jbellis) to the next level, IMHO, the purpose of ORMs like hibernate or JPA specs is to hide the complexities of SQL since Application developers deal best in objects and not SQL. Similarly, kundera hides the complexities of NoSQL but in an intelligent way that allows it to use the power of NoSQL but still make it easy for developers to use the traditional RDBMS paradigm. However, as Jonathan mentions, you should still understand Cassandra data modeling concepts, otherwise, you will end up creating another SQL like monster even over Cassandra. Kundera does help in this NoSQL modeling by using optimization techniques such as Embedded or One-to-Many relationships automatically converted into multiple Columns rather than creating new Columnfamilies (RDBMS tables equivalents) thus circumventing creating a physical relational model. "A tool is only as good as the skills of the craftsman/woman using it!"

indoos
  • 179
  • 2
  • So, that said, do the benefits of using something like Kundera (transaction support, Lucene indexing, etc.) outweigh any performance impacts or other downsides? I recognize the need to reimagine the data model to be less SQL-like and more inline with what the datasources are designed to handle. Is there still a benefit in going down this route? – Shadowman May 02 '13 at 17:02
  • 2
    Lucene based indexing is optional. You may want to use Cassandra's secondary indexing. With current 2.5 release performance overhead is very minimal in comparison to raw thrift etc apis. – vivek mishra May 02 '13 at 17:12
8

Use the native CQL driver and read the documentation on data modeling. Pretending that Cassandra is a relational database the way Kundera does is a great way to paint yourself into a corner without quite understanding how you got there.

jbellis
  • 19,347
  • 2
  • 38
  • 47
  • 4
    I would say it depends on use case to use case. Kundera does not Cassandra as a relational schema, but offers a JPA way of accessing it. With current CQL development, Cassandra itself recommends some sort of schema to be available for use. So, Kundera comes very handy and it allows you: 1. Handles implicitly Cassandra schema management 2. Do CRUD over Cassandra in JPA way. 3. Of-course Cassandra is non relational distributed database, but still we have seen instances where people are looking for such JPA like use cases, polyglot persistence. There Kundera comes very handy, – vivek mishra May 02 '13 at 15:52
2

PlayOrm is a noSql mapping layer and is NOT JPA compliant on purpose following many of the patterns of noSQL. noSQL is not relational. In fact, it probably should not have the R in PlayORM as it is not really relational completely either. You still have relationships in noSQL though. It is not just an RDBMS.

Dean Hiller
  • 19,235
  • 25
  • 129
  • 212