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

61–70 of 89 posts

Re: HyperDex: A Searchable Distributed Key-Value Store

#61

Post by ypcx »

rescrv wrote: post #7
snewman wrote: post #6

Earlier quoted context omitted.

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 b…

Well first Thank you for providing another data storage possibility, and a great one at that.

I'd just like to ask - the benchmarks where HyperDex beats even Redis - these are strictly clustered benchmarks - is that true?

Or is the way HyperDex stores data so efficient, that it beats Redis even on a single core / single thread?

Thanks!

Re: HyperDex: A Searchable Distributed Key-Value Store

#62

Post by ypcx »

jandrewrogers wrote: post #12
simonw wrote: post #8

Is it open source? I browses around the site and FAQ and didn't spot a mention of the license.

The code is open source. However, they applied for patents on the algorithm: http://www.wipo.int/patentscope/search/en/WO2011137189

While waiting for the answer, what does this generally means if the patent is granted? Since the code is open-sourced under BSD, can the algorithm be used in other open-source BSD-licensed products, and can corporations then use these products to store data, without needing to pay the royalties on the patent?

Re: HyperDex: A Searchable Distributed Key-Value Store

#63

Post by bryanlarsen »

ypcx wrote: post #62
jandrewrogers wrote: post #12

Earlier quoted context omitted.

The code is open source. However, they applied for patents on the algorithm: http://www.wipo.int/patentscope/search/en/WO2011137189

While waiting for the answer, what does this generally means if the patent is granted? Since the code is open-sourced under BSD, can the algorithm be used in other open-source BSD-licensed products, and can corporations then use these products to store data, without needing to pay the royalties on the patent?

The BSD license does not contain a patent grant, so it's technically possible that you'll have to pay to use this software in the future even though it's under the BSD license. I'd really like to see a switch to the Apache license, which does contain a patent grant.

Re: HyperDex: A Searchable Distributed Key-Value Store

#64

Post by ypcx »

bryanlarsen wrote: post #63
ypcx wrote: post #62

Earlier quoted context omitted.

While waiting for the answer, what does this generally means if the patent is granted? Since the code is open-sourced under BSD, can the algorithm be used in other open-source BSD-licensed products, and can corporations then use these products to store data, without needing to pay the royalties on the patent?

The BSD license does not contain a patent grant, so it's technically possible that you'll have to pay to use this software in the future even though it's under the BSD license. I'd really like to see a switch to the Apache license, which does contain a patent grant.

So if I release my code under Apache license, and later it is found that it happens to infringe on a patent, am I liable to pay the damages on behalf of anyone using my code and getting sued based on the patent infringement?

Or, to put it another way - what is the best "free" license for a developer to release his/her code under? I don't really even care about mentioning my name in derivative works.

Re: HyperDex: A Searchable Distributed Key-Value Store

#65

Post by nicktelford »

rbranson wrote: post #58
snewman wrote: post #35

Earlier quoted context omitted.

To be precise, I would argue this is actually a CA system. "C" because there are consistency guarantees, which are upheld even in the face of failures / partition. "A" because the system will continue making progress even after a node failure. What I called a "hiccup" can be made arbitrarily short, in principle at least. The system can work around failed nodes, it does not need to wait for them to be repaired. Not "P…

There is no CA. You cannot guarantee consistency and availability simultaneously in the face of network partitions. Once the line of communications is cut or overloaded (slow enough = a partition), you have to pick one or the other. It's basic physics. If two entities can't communicate, they can't synchronize state, so one (or both) of them have to quit acting like they have a consistent view of the data.

> If two entities can't communicate, they can't synchronize state, so one (or both) of them have to quit acting like they have a consistent view of the data.

With the exception of quantum entanglement, of course.

Re: HyperDex: A Searchable Distributed Key-Value Store

#66

Post by gizzlon »

ypcx wrote: post #61
rescrv wrote: post #7

Earlier quoted context omitted.

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 b…

Well first Thank you for providing another data storage possibility, and a great one at that. I'd just like to ask - the benchmarks where HyperDex beats even Redis - these are strictly clustered benchmarks - is that true? Or is the way HyperDex stores data so efficient, that it beats Redis even on a single core / single thread? Thanks!

Without more context graphs like that is pretty useless.. For all we know they just invented those numbers. I'm not saying they did, but you get my point..

Those numbers seem way to low for running on the same machine, and if not shouldn't the network be the bottleneck and show similar results for both?

I'm sure there's a reasonable explanation, just as I'm sure they picket benchmarks that makes themselves look good.

Re: HyperDex: A Searchable Distributed Key-Value Store

#67

Post by bryanlarsen »

ypcx wrote: post #64
bryanlarsen wrote: post #63

Earlier quoted context omitted.

The BSD license does not contain a patent grant, so it's technically possible that you'll have to pay to use this software in the future even though it's under the BSD license. I'd really like to see a switch to the Apache license, which does contain a patent grant.

So if I release my code under Apache license, and later it is found that it happens to infringe on a patent, am I liable to pay the damages on behalf of anyone using my code and getting sued based on the patent infringement? Or, to put it another way - what is the best "free" license for a developer to release his/her code under? I don't really even care about mentioning my name in derivative works.

I'm no expert, but as far as I'm aware the Apache grants the user a license for your relevant patents. The GPL3 goes a step further and grants the user a license for any patents you have a license for whether its your own or one you licensed from somebody else. Since neither situation likely applies in your case, the BSD and Apache licenses are basically functionally identical. However, by choosing the Apache license you are telling potential users that you don't have any "sleeper" patents, so you might get better uptake.

If somebody later asserts a patent against your code, both you and your users are screwed no matter what license you choose. But the choice of license might influence who might help you out if that happens...

Re: HyperDex: A Searchable Distributed Key-Value Store

#68

Post by otterley »

rescrv wrote: post #50
xxqs wrote: post #36

the FAQ mentions that you target x86_64 architecture. Does the server work on i386? also, I hope it's doing proper memory alignment and endiannes independence? (because Mongo sucks on that)

We use many lock-free datastructures which rely heavily upon the x86_64 architecture. Further, the expanded virtual address space enables us to mmap everything. All network traffic is packed, and in network byte order.

> the expanded virtual address space enables us to mmap everything

This sounds like a disaster waiting to happen when a node's working set is larger than RAM. Have you considered the impact on performance due to excessive I/O resulting from this kind of overcommit?

Redis performance, for example, suffers tremendously when its database size exceeds the available RAM, which is why the authors advise implementors to cap its database size. The only real difference I can see here is that Redis allocates its storage anonymously, while Hyperdex uses file-backed pages; in either case, performance under memory pressure will largely be governed by how the VM chooses to move pages in and out of its backing store -- behavior the application has no control over.

Optimizing the performance of working sets larger than RAM is hard. Redis had a (thankfully) aborted attempt to do so (the VM is gone in the most recent stable release); and the InnoDB buffer pool in MySQL has been refined for many years and is subject to quite a bit of tuning for specific workloads. (See also http://blog.kennejima.com/post/1226487020/thoughts-on-redis for some thoughtful discussion on the subject.)

You claim on the one hand that Hyperdex was designed to work on data sets larger than RAM, but on the other hand you admit that all the benchmarks were performed with a working set smaller than RAM. I'd like to see comparative benchmarks where the working set is larger than RAM to be convinced.

Re: HyperDex: A Searchable Distributed Key-Value Store

#69

Post by reitblatt »

cstejerean wrote: post #46
snewman wrote: post #35

Earlier quoted context omitted.

To be precise, I would argue this is actually a CA system. "C" because there are consistency guarantees, which are upheld even in the face of failures / partition. "A" because the system will continue making progress even after a node failure. What I called a "hiccup" can be made arbitrarily short, in principle at least. The system can work around failed nodes, it does not need to wait for them to be repaired. Not "P…

You don't get to sacrifice the P. http://codahale.com/you-cant-sacrifice-partition-tolerance/

That blog is quite wrong about partition tolerance. First, the definition is just bizarre:

"Handling a crashed machine counts as partition-tolerance. (Update: I was wrong about this part."

He then goes on to give Stonebraker crap about claiming that "failures" never happen, simply because he doesn't understand the difference between failures and partitions.

Look, the point of "CAP" is this: if you assume nothing about the network, then you can not guarantee CA in the presence of ARBITRARY network partitions. It doesn't say that you can't provide CA under some or even many network partition scenarios. So, the question you should be asking is "what kinds of network partitions happen in practice?". Stonebraker's point was that network partitions are such rare and wholly catastrophic events that worrying about them pulls focus away from much more practical concerns. Hyperdex' point on partition tolerance (admittedly not clearly spelled out) is much more subtle. They offer tolerance of a specific class of partitions. To simply say they are "AP" or "CP" ignores the very important fact that they do in fact tolerate partitions and maintain the CA. This whole "CAP" pick any two is a gross over-simplification that obscures very real distinctions like this.

Re: HyperDex: A Searchable Distributed Key-Value Store

#70

Post by reitblatt »

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…

"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."

They offer f-fault tolerance. They can have f nodes go down in a single "zone" and keep chugging as long as no more nodes in the same zone go down before the master reconfigures. Note that the f faults are per-zone, not per-system, so in fact many more than f nodes can be down in a single system without a problem.

But, more importantly, you seem to be confusing partition tolerance and fault tolerance. CAP is about partition tolerance: offering "CA" in the presence of arbitrary partitions. They offer a specific form of fault tolerance: "CA" in the presence of any failure or partition that affects less than f nodes.

Post reply on HN