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

ZooKeeper vs. Doozer vs. Etcd

devo.ps

Post reply on HN
Print view View original

41–50 of 91 posts

Re: ZooKeeper vs. Doozer vs. Etcd

#41

Post by lucian1900 »

alanctgardner2 wrote: post #5

They make some cogent points about Zookeeper, but is javaphobia really a valid concern here? Yes, you have to install a JVM, and Oracle doesn't make that as friendly as it could be. But in my experience ZK doesn't bring along "a ton of dependencies". Likewise, I'm skeptical that the performance of Java v. Go in this case makes a huge difference: you're only spinning the JVM once, at startup. Maybe I'm too technically…

Even if you only look at amount of RAM used, with Zookeeper it'll never be lower than 35M and most likely be much higher than 50M. With etcd, you can get away with significantly less than that.

The dependencies and JVM boot time are also annoying if you don't already use Java, though.

Re: ZooKeeper vs. Doozer vs. Etcd

#42

Post by ecopoesis »

darkarmani wrote: post #18
alanctgardner2 wrote: post #7

Earlier quoted context omitted.

Oh! Treat records as key-value pairs, and encode the value into the IP. If your timeout is 10 seconds, add a DNS record timeout.server.yourdomain which resolves to an IPv6 address with value 10. It gets tougher with ASCII strings, but you could support multi-record configs as well. Then your application just uses nslookup to download the config when you reload it. If someone builds this I will be their best friend

You can also use DNS like a distributed cache. This is useful when you have millions of clients because their local DNS server will do caching for you. You can also use it like a bloom filter where cache hits are true positives and anything that misses might or might not be a valid key.

That sounds like the opposite of a Bloom filter. In a Bloom filter, you can have false positives but you always get true negatives.

Re: ZooKeeper vs. Doozer vs. Etcd

#43

Post by Xorlev »

nivertech wrote: post #15
alanctgardner2 wrote: post #5

They make some cogent points about Zookeeper, but is javaphobia really a valid concern here? Yes, you have to install a JVM, and Oracle doesn't make that as friendly as it could be. But in my experience ZK doesn't bring along "a ton of dependencies". Likewise, I'm skeptical that the performance of Java v. Go in this case makes a huge difference: you're only spinning the JVM once, at startup. Maybe I'm too technically…

It's not javaphobia. I think the point is that Go produces a statically-linked native executable, while VM-based languages like Java adding many dependencies and also reduce memory which left for the application itself (assuming z-nodes running on the same nodes as application).

You can run a high performance Java process with a small heap, I would call this a non-issue. I have many heavily-used services with 32-64mb of heap space.

Certainly, Go will end up using less memory but in the day and age of small servers with 1.5GB of RAM, it's really a non-issue.

Re: ZooKeeper vs. Doozer vs. Etcd

#45

Post by philsnow »

russell_h wrote: post #13

One point the article didn't cover is clients. Making a good Zookeeper client is hard, for two reasons: 1. The protocol is difficult to implement. In theory you could just use Jute to codegen this part, but that assumes Jute supports the language you need. Doozer improves on this with a simple text-based protocol, and etcd goes a little further with a HTTP API. 2. The primitives Zookeeper exposes are very primitive.…

re #1, as I said elsewhere, at youtube we use zkocc to proxy readonly connections to zookeeper, and zkocc supports e.g. bson-over-http (and in any case it would be easier to add new client protocol support to zkocc than to zookeeper, I think. maybe I just think that because I don't want to java.)

Re: ZooKeeper vs. Doozer vs. Etcd

#47

Post by Juha »

philsnow wrote: post #44

You can add YouTube to the list of big players that uses ZooKeeper. We use zkocc [0] to scale (readonly) clients. [0] http://godoc.org/code.google.com/p/vitess/go/zk/zkocc

Thank's, didn't know that. Yep, Youtube definitely counts as a big player. Added you to the list.

Re: ZooKeeper vs. Doozer vs. Etcd

#48

Post by philips »

voidmain wrote: post #24
russell_h wrote: post #13

One point the article didn't cover is clients. Making a good Zookeeper client is hard, for two reasons: 1. The protocol is difficult to implement. In theory you could just use Jute to codegen this part, but that assumes Jute supports the language you need. Doozer improves on this with a simple text-based protocol, and etcd goes a little further with a HTTP API. 2. The primitives Zookeeper exposes are very primitive.…

I agree. At FoundationDB, we're writing a coordination tool (working name "beastmaster") that provides service discovery, locking, leader election, etc on top of our transactional key/value store. It is higher level than these tools; our idea is to try to make it useful from a command line or DNS rather than have to be baked into every piece of software that needs service discovery. beast service --lock name=mailserv…

That is cool! How are you doing locking for transactions right now internally?

You can use etcd from the command line with etcdctl or grab environment variables for your process using etcdenv.

I would love to see someone back a DNS server with etcd too.

etcdctl: https://github.com/coreos/etcdctl etcdenv: https://github.com/mattn/etcdenv

Re: ZooKeeper vs. Doozer vs. Etcd

#49

Post by kapilvt »

russell_h wrote: post #13

One point the article didn't cover is clients. Making a good Zookeeper client is hard, for two reasons: 1. The protocol is difficult to implement. In theory you could just use Jute to codegen this part, but that assumes Jute supports the language you need. Doozer improves on this with a simple text-based protocol, and etcd goes a little further with a HTTP API. 2. The primitives Zookeeper exposes are very primitive.…

Another issue with zookeeper, the c bindings which are the basis for alot of language bindings, is both buggy and often out of date, esp wrt to individual language bindings. I've often see internal cpu spiked loads on c lib's internal io thread, ie pathological behavior. The recent support for dynamic quorums or transactions has yet to make it to any of the distributed language bindings. At least for python the folks at mozilla put together a nice from scratch library in the form of kazoo, at the cost of reimplementing the entire protocol. Compare that to the simplicity of etcd's, where you can just curl/wget a request.

Re: ZooKeeper vs. Doozer vs. Etcd

#50

Post by kbd »

Sorry if this is a dumb question but I've never understood the purpose of these configuration stores. If you're not running in the cloud, but have servers in a datacenter that all mount an NFS share, is there any benefit of these over simply reading a json/yaml file off of an NFS mount?
Post reply on HN