4 ms·
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
by 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