Comparison of NoSQL Databases for Java

I want to find out more about NoSQL databases/data-stores available for use from Java, and so far I tried out Project Voldemort. Except for awfully chosen name, it seems fine so far.

I'd like to find out more about other such database systems. Now, on wikipedia article there is a list of some of them, and there is some documentation on their project pages.

However, instead of comparing technical specs and tutorials provided by authors, what I would like to know is:

What are your experiences with working with these libraries on real projects? Which one would you recommend for use based on that experience, which one you wouldn't and wh开发者_StackOverflow社区y?

I know that only people to be able to answer this question are those who actually used more than one such database, but I hope that someone did do so.

EDIT:

By "real project" I primarily mean a project in production (but in absence of these anything larger than a homework or finished tutorial applies).

I worked with a relational database that had enormous amount of data in it, most of it concentrated in a single table, which was denormalized for performance anyway. But, because of the entire mess with constraints etc, creating a usable cluster had shown horrible results in both stability and performance.

Now, I'm quite sure that most likely any of these NoSQL systems would be a better choice then what I had at disposal. But, there has to be a difference between them, too. Whether it is in documentation, stability between versions, community, ease of use, whatever... And there are many giants. Which ones shoulders to choose? :D

We have been working with HBase for our projects. Our experience is -

• The community is very dynamic and extremely helpful
• The installation procedure for developers is quite easy in either pseudo distributed or standalone mode
• We have been using it for integration test like unit tests
• Installing a cluster is also easy but comparing some other NoSQL it has more components to install than others.
• Administering - is still going on so not able to say much to say about it.
• Do not use it for SQL like SELECT queries, for that we are using Apache Solr
• To make development and testing easier we have come up with a simple object mapper - https://github.com/smart-it/smart-dao
• The reason I chose is HBase, like other NoSQL, solves sharding, scaling by design making it easier in the long run and that seems to hold well.

Maybe the most prominent of Java NoSQL solutions is Cassandra. It has some features beyond Voldemort (Order-Preserving Partitioner which allows range queries; BigTable style structure for values); and is missing others (no alternate storage backends or version clocks for versioning). Its performance is more optimal for fast writes, but its biggest strength is probably ease at which it can be horizontally scaled by adding new nodes (something where V is bit more static).

Compared to, say, MongoDB, its data model is quite simple and often there's no point in using much more than key/value abstraction (that is, handle data mapping on client side, store serialized objects). It has full replication and distribution, unlike some k/v stores (couchdb, from what I understand).

It's pretty difficult to nail down a good choice without knowing exactly what your use case is. Much of it depends on what kind of data model are you comfortable with and fits your need. You have key-value stores, document-oriented, column-oriented, etc. Another huge factor is the products take on scaling and how they choose to deal with availability/consistency trade-offs.

I like MongoDB. I like how it supports queries and I like the document oriented data models. It fits many problems that I seem to run into. There is a Great (with capital G) community as seen at the recent MongoSV event.

Your best bet it to pick 3 different products and evaluate them. I would also see if you can find some companies who have presented at conferences and tell their stories of how they were successful. Videos from MongoSV will be available soon.