4 ms·

NoSQL: Comparing the Different Solutions

19 points by Garbage 16y ago

chapel 16y ago
The title is a bit misleading. No comparison has been made yet, in actuality the author is requesting developers from each NoSQL solution to describe how their solution handles some problems he lists. I would love to see the resulting article though once more have replied.
- uggedal 16y ago
  The Cassandra and MongoDB articles are already available.
khingebjerg 16y ago
Why link to readwriteweb instead of the real comparison? http://perfcap.blogspot.com/2010/10/comparing-nosql-availability-models.html http://perfcap.blogspot.com/2010/10/comparing-nosql-availabi...
ekidd 16y ago
I applaud this effort to compare NoSQL databases, but I'd like to inject a word of caution. The various NoSQL databases are _amazingly_ different, and it's hard to compare them properly using a single scenario. Adrian Cockcroft's scenario, for example, favors a simple key/value store with good partition tolerance. (It also contains some design decisions that fit together poorly: He asks about partition tolerance, but his application is designed to write to one availability zone and immediately read consistent data from another availability zone. He should either combine these two operations into a single operation, give up partition tolerance, or look for better load-balancing options.) I could easily describe other scenarios which favored S3, MongoDB, CouchDB, or offline Hadoop/Hive queries of S3 buckets. And that's just the systems I've used. We need much better NoSQL comparisons, but we won't get there without investigating a wide mix of use cases. Otherwise, we're going to wind up with the equivalent of a comparison of Clojure, Haskell, Mozart and F# written by a "Blub" programmer: All the genuinely interesting questions will fall outside the basis of comparison.
- kbutler 16y ago
  > I could easily describe other scenarios which favored S3, MongoDB, CouchDB, or offline Hadoop/Hive queries of S3 buckets. And that's just the systems I've used. We need much better NoSQL comparisons, ... Please do - that would be VERY useful. kb

19 points by Garbage 16y ago

The title is a bit misleading. No comparison has been made yet, in actuality the author is requesting developers from each NoSQL solution to describe how their solution handles some problems he lists. I would love to see the resulting article though once more have replied.

uggedal 16y ago
The Cassandra and MongoDB articles are already available.

khingebjerg 16y ago

Why link to readwriteweb instead of the real comparison? http://perfcap.blogspot.com/2010/10/comparing-nosql-availability-models.html http://perfcap.blogspot.com/2010/10/comparing-nosql-availabi...

ekidd 16y ago

I applaud this effort to compare NoSQL databases, but I'd like to inject a word of caution. The various NoSQL databases are _amazingly_ different, and it's hard to compare them properly using a single scenario. Adrian Cockcroft's scenario, for example, favors a simple key/value store with good partition tolerance. (It also contains some design decisions that fit together poorly: He asks about partition tolerance, but his application is designed to write to one availability zone and immediately read consistent data from another availability zone. He should either combine these two operations into a single operation, give up partition tolerance, or look for better load-balancing options.) I could easily describe other scenarios which favored S3, MongoDB, CouchDB, or offline Hadoop/Hive queries of S3 buckets. And that's just the systems I've used. We need much better NoSQL comparisons, but we won't get there without investigating a wide mix of use cases. Otherwise, we're going to wind up with the equivalent of a comparison of Clojure, Haskell, Mozart and F# written by a "Blub" programmer: All the genuinely interesting questions will fall outside the basis of comparison.

kbutler 16y ago
> I could easily describe other scenarios which favored S3, MongoDB, CouchDB, or offline Hadoop/Hive queries of S3 buckets. And that's just the systems I've used. We need much better NoSQL comparisons, ... Please do - that would be VERY useful. kb