I completely agree that it is time for NoSQL 2.0 - there are more than 100 different NoSQL datatastores and usually developers choose based on MARKETING - there are no good scientific comparisons on which one is better. This is why I founded the NoSQL alliance at http://NoSQL.org - to standardize and offer unbiased advice of which database to use and why. This is an open source project - please contact me if you would like to participate
In every serious development the db architecture gets selected on the use cases specific to the business, so without describing which use cases HyperDex addresses there will be no real interest for it, name it 2.0 or "on steroids".
HyperDex provides strongly consistent GET/PUT operations and fast searches over data. It uses a new object placement technique to facilitate these searches, and as a result, a search may contact a very small subset of hosts in the system.
To tolerate f failures, we need to have f+1 replicas of the data. This implies increased storage, but the f parameter is entirely up to the application.
Record insertion affects all replicas of the data, so latency increases with replication.
The first graph on the performance page (http://hyperdex.org/performance/) shows that a 100% insertion workload will exhibit higher latency (and thus lower throughput for a fixed number of synchronous clients). Write-mostly workloads are slower, but I wouldn't say "extremely slow."
From what I gather skimming through the paper, you should be more concerned comparing HyperDex to Riak, than to Cassandra or MongoDb. The potential use cases seem to be quite different for the last mentioned.
It's a consistent, scalable, high-performance key-value store. If you need the use cases spelled out for you, you should not be using it or anything else related to the web.
Thanks for pointing out the paper. If the paper doesn't cover a question, I'm happy to answer (primary dev/paper author here) it via email, or here on HN.
Can we stop calling it NoSQL? Cassandra has a SQL now and there are other "NoSQL" databases adopting this and the fact that they didn't use SQL wasn't a huge point with how they worked anyway.
Instead of NoSQL 2.0 how about Key Value stores or Document Stores or something else?
22 comments
[ 3.1 ms ] story [ 36.6 ms ] threadEdit: Link to paper and not out-dated slides.
Seriously? Sounds like the PR firm didn't actually take a look at these other DBs.
Redis is in a class of its own; there are lots of niche technologies.
Record insertion affects all replicas of the data, so latency increases with replication.
The first graph on the performance page (http://hyperdex.org/performance/) shows that a 100% insertion workload will exhibit higher latency (and thus lower throughput for a fixed number of synchronous clients). Write-mostly workloads are slower, but I wouldn't say "extremely slow."
Instead of NoSQL 2.0 how about Key Value stores or Document Stores or something else?