HyperDex: A searchable distributed key-value store

FWIW, I find your website suffers the same problem as Riak's, which is to say, it is entirely too focused on the product rather than how _I_ use the product. It's like it's written for people who'd be interested in writing their own data store, rather than someone, like most of us, who just want to CRUD in some shape or another.<p>I feel like I'm reading a white paper.<p>Redis' website is the exact opposite. Similarly, MongoDB's website, while a far cry from Redis', is still much, much better than Riaks.

Was trying to figure out where it lies in the CAP trade-off space. Found this set of slides<p><a href="http://hyperdex.org/slides/2012-04-13-HyperDex.pdf" rel="nofollow">http://hyperdex.org/slides/2012-04-13-HyperDex.pdf</a> :<p>---<p>* Consistent: linearizable. GET returns latest PUT, always<p>* Available: in the presence of  &#60; f failures<p>* Partition-Tolerant: for partitions with  &#60; f nodes<p>---<p>So it seems they have strong C and a tunable trade-off between A and P ?<p>Then they take a jab at the popular interpretation of the CAP theorem and claim they have a work-around:<p>----<p><pre><code> Working around the [CAP] theorem: * Constrain the failure size * Redirect clients to majority partition * Profit: Retain all of C, A, P Realistic for a modern data center CAP misses the point The real tradeoff is between C, A, and Performance. </code></pre> ---<p>Not sure what they meant here. Anyone understood this better?

Look interesting. Is like a mongodb + redis in one?<p>If i understood it well, if the coordinator die then everything die?<p>Any plan in provide pub/sub?<p>And/or capped collections (by number (keep 1000) or TTL (keep 24h))

This looks interesting, but can someone explain the benefits over memcache/Redis?<p>Is "hyperspace hashing" storing multiple copies, so it's like storing records on multiple shards of a database?<p>And "enables lookups of non-primary data attributes": how useful is this, actually? Is this a big step forward for NoSQL?<p>The site doesn't seem to be giving me a real-world case where HyperDex solves existing problems better than other things... maybe I just can't find it?

Ever thought about using some kind of locality sensitive hashing or maybe a neural network to map your properties into the table space? Intuition is telling me your partitioning scheme would still work and similarity search could be improved?

Would be more believable if you gave some examples of the tradeoffs that went into the design, example use-cases, strengths and weaknesses, etc..<p>As it stands, it just reads: "It's faster!! It's better!! It's webscale!"

Additionally, this looks like a repost anyways: <a href="http://news.ycombinator.com/item?id=3622888" rel="nofollow">http://news.ycombinator.com/item?id=3622888</a>

Do you have examples of use in production?<p>Could not find on your site. Adding such info would be beneficial.

How hard is it to add APIs for other languages? (In my case I'm thinking JVM, since I'm getting into Clojure.)

This looks very interesting; however, I do wish they would stop doling out the koolaide on (almost) every page. Instead of telling me why they are "this much faster than xyz" all I see are some graphs and numbers, which isn't particularly helpful because the benchmarks could be flawed!