Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HyperDex: A Searchable Distributed Key-Value Store

hyperdex.org

Post reply on HN
Print view View original

1–10 of 89 posts

Re: HyperDex: A Searchable Distributed Key-Value Store

#3

Post by rescrv »

pixelcort wrote: post #2

This reminds me of http://xanadu.com/zigzag/ .

HyperDex is different. ZigZag focuses on data visualization. HyperDex provides you the same key-value interface of other systems, while also providing an efficient search primitive.

Check out http://hyperdex.org/tutorial/ for examples of the Python API.

Re: HyperDex: A Searchable Distributed Key-Value Store

#4

Post by ericmoritz »

From the FAQ " rel="nofollow">http://hyperdex.org/faq/>:

"So, the CAP Theorem says that you can only have one of C, A, and P. Which are you sacrificing?

HyperDex is designed to operate within a single datacenter. The CAP Theorem holds only for asynchronous environments, and well-administered datacenters enable us to sidestep this tradeoff entirely."

I'd like to see how they pull that off when a node goes down. I guess in "well-administered" data centers, nodes don't go down.

Sounds like they're sacrificing "A" to me because they're doing synchronous replication.

Re: HyperDex: A Searchable Distributed Key-Value Store

#5

Post by rescrv »

ericmoritz wrote: post #4

From the FAQ " rel="nofollow">http://hyperdex.org/faq/> : "So, the CAP Theorem says that you can only have one of C, A, and P. Which are you sacrificing? HyperDex is designed to operate within a single datacenter. The CAP Theorem holds only for asynchronous environments, and well-administered datacenters enable us to sidestep this tradeoff entirely." I'd like to see how they pull that off when a node goes down. I gue…

HyperDex uses value-dependent chaining, which offers fault tolerance properties similar to those provided by chain replication (http://www.cs.cornell.edu/home/rvr/papers/osdi04.pdf).

A single node failure will be recovered from quickly without issue. Multiple concurrent failures are handled the same as the single failure case, so long as our failure assumptions are not violated (e.g., every node in the datacenter fails simultaneously).

Re: HyperDex: A Searchable Distributed Key-Value Store

#6

Post by snewman »

ericmoritz wrote: post #4

From the FAQ " rel="nofollow">http://hyperdex.org/faq/> : "So, the CAP Theorem says that you can only have one of C, A, and P. Which are you sacrificing? HyperDex is designed to operate within a single datacenter. The CAP Theorem holds only for asynchronous environments, and well-administered datacenters enable us to sidestep this tradeoff entirely." I'd like to see how they pull that off when a node goes down. I gue…

It's a bit of a middle ground. Yes, the replication is synchronous, which impacts availability. However, the master can remove a failed replica from the chain fairly quickly. In principle, with proper tuning, a node failure would merely cause a brief hiccup. This would feel more like a period of increased latency than a full-blown outage. So there really needn't be much sacrifice of availability.

However, there's also a sacrifice of partition tolerance. If the master is unable to communicate with any replica, the system can't serve requests. Also, the master is implemented as a collection of Paxos nodes; if these nodes are partitioned from one another, the entire system would grind to a halt.

Since this is intended for intra-datacenter use, one could argue that a full network partition might be unlikely. (Depending on what sort of data center you hang out in.) But in CAP terms, it's possible, of course.

(I base all this on the value-dependent chaining paper cited below.)

Re: HyperDex: A Searchable Distributed Key-Value Store

#7

Post by rescrv »

snewman wrote: post #6
ericmoritz wrote: post #4

From the FAQ " rel="nofollow">http://hyperdex.org/faq/> : "So, the CAP Theorem says that you can only have one of C, A, and P. Which are you sacrificing? HyperDex is designed to operate within a single datacenter. The CAP Theorem holds only for asynchronous environments, and well-administered datacenters enable us to sidestep this tradeoff entirely." I'd like to see how they pull that off when a node goes down. I gue…

It's a bit of a middle ground. Yes, the replication is synchronous, which impacts availability. However, the master can remove a failed replica from the chain fairly quickly. In principle, with proper tuning, a node failure would merely cause a brief hiccup. This would feel more like a period of increased latency than a full-blown outage. So there really needn't be much sacrifice of availability. However, there's als…

What you said was right on. I just wanted to add a few things.

The coordinator is only involved for recovering from failures, so the cluster can still serve requests until server (non-coordinator) nodes start failing too.

I would also add that if there is a intra-datacenter partition so severe as to violate HyperDex's failure assumptions, it will likely impact applications built on top of HyperDex as well. It would be necessary to survive such failures with an inter-datacenter system (which could be built on top of HyperDex).

Re: HyperDex: A Searchable Distributed Key-Value Store

#9

Post by stevelosh »

For those that want to take a quick look at the source code without physically cloning it, there's a GitHub link buried somewhere in the site (I forget where I found it): https://github.com/rescrv/HyperDex

Their Python client seems to be using Cython for extra speed: https://github.com/rescrv/HyperDex/blob/master/hyperclient/p...

Post reply on HN