4 ms·

Off-topic, but does Zookeeper have features that etcd doesn't provide? etcd seems to be simpler to operate at a glance.

pram 4y ago
Running ZK was pretty easy with Exhibitor (not that I’d recommend it over etcd) but it’s defunct now. Otherwise manually managing it is crufty and ancient feeling. The API for “dynamic reconfiguration” is like something I’d expect from Oracle software in the 90s. It sucks.
maxmcd 4y ago
My understanding is that they have different consistency models and different APIs. I think etcd might be better suited for more use-cases, but I don't think migration of existing systems is straightforward. Some previous discussion here: https://news.ycombinator.com/item?id=18687516 https://news.ycombinator.com/item?id=18687516 I also enjoyed this lecture about zookeeper: https://www.youtube.com/watch?v=pbmyrNjzdDk https://www.youtube.com/watch?v=pbmyrNjzdDk
cogman10 4y ago
Not much they have pretty compatible feature overlap. Zookeeper pushes pretty heavily on a smart client rather than handling a lot of stuff server side. If I were to pick I'd go with etcd in a heartbeat. Every con they list on their comparison website is stuff I've personally dealt with in ZK. https://etcd.io/docs/v3.3/learning/why/#zookeeper https://etcd.io/docs/v3.3/learning/why/#zookeeper
- kbumsik 4y ago
  Actually I was asking the question looking at the etcd doc you linked. The etcd doc explains like it is just better than Zookeeper. Then why there are so many projects still rely on Zookeeper and spend so much time on re-writing its features instead of switching to etcd like what OP, ClickHouse (in the discussion), and Kafka (KRaft) are doing? It there something that etcd won't fit?
  - hodgesrm 4y ago
    ClickHouse chose an API compatible rewrite because it allowed the project to banish issues like Zookeeper transaction ID rollover and eliminate an external dependency while allowing a gentle migration to the new "ClickHouse Keeper" implemention. Existing prod deployments of ClickHouse are mostly still on Zookeeper, though new deployments are beginning to use ClickHouse Keeper from the start. There's a good talk by ClickHouse committer Alexander Sapin that explains the design considerations: https://www.youtube.com/watch?v=abhcCRW09Ac https://www.youtube.com/watch?v=abhcCRW09Ac
  - dikei 4y ago
    Very few new projects use Zookeeper now. For older projects, most of them have no issue using Zookeeper, so it's simply not worth the time to rewrite them for etcd.

pram 4y ago

Running ZK was pretty easy with Exhibitor (not that I’d recommend it over etcd) but it’s defunct now. Otherwise manually managing it is crufty and ancient feeling. The API for “dynamic reconfiguration” is like something I’d expect from Oracle software in the 90s. It sucks.

maxmcd 4y ago

My understanding is that they have different consistency models and different APIs. I think etcd might be better suited for more use-cases, but I don't think migration of existing systems is straightforward. Some previous discussion here: https://news.ycombinator.com/item?id=18687516 https://news.ycombinator.com/item?id=18687516 I also enjoyed this lecture about zookeeper: https://www.youtube.com/watch?v=pbmyrNjzdDk https://www.youtube.com/watch?v=pbmyrNjzdDk

cogman10 4y ago

Not much they have pretty compatible feature overlap. Zookeeper pushes pretty heavily on a smart client rather than handling a lot of stuff server side. If I were to pick I'd go with etcd in a heartbeat. Every con they list on their comparison website is stuff I've personally dealt with in ZK. https://etcd.io/docs/v3.3/learning/why/#zookeeper https://etcd.io/docs/v3.3/learning/why/#zookeeper

kbumsik 4y ago
Actually I was asking the question looking at the etcd doc you linked. The etcd doc explains like it is just better than Zookeeper. Then why there are so many projects still rely on Zookeeper and spend so much time on re-writing its features instead of switching to etcd like what OP, ClickHouse (in the discussion), and Kafka (KRaft) are doing? It there something that etcd won't fit?
- hodgesrm 4y ago
  ClickHouse chose an API compatible rewrite because it allowed the project to banish issues like Zookeeper transaction ID rollover and eliminate an external dependency while allowing a gentle migration to the new "ClickHouse Keeper" implemention. Existing prod deployments of ClickHouse are mostly still on Zookeeper, though new deployments are beginning to use ClickHouse Keeper from the start. There's a good talk by ClickHouse committer Alexander Sapin that explains the design considerations: https://www.youtube.com/watch?v=abhcCRW09Ac https://www.youtube.com/watch?v=abhcCRW09Ac
- dikei 4y ago
  Very few new projects use Zookeeper now. For older projects, most of them have no issue using Zookeeper, so it's simply not worth the time to rewrite them for etcd.