3 ms·

Not an etcd user but my first question was why they chose some new (and now unmaintained) golang key value store as their database instead of something more wid

Not an etcd user but my first question was why they chose some new (and now unmaintained) golang key value store as their database instead of something more widely used (sqlite or bdb seem like the obvious alternatives). I was able to find this analysis they did in 2015: https://github.com/coreos/etcd/issues/2646 https://github.com/coreos/etcd/issues/2646 . On the face of it, it feels like using a more established an well tested database would have been a better choice, even with the facts available to them at the time. Personally I would have been really reluctant to adopt a database whose first commit was in the previous year with only one major contributor. Three years later, they've had to adopt the database code after it was abandoned by the original maintainer.

pokstad 9y ago
The previous maintainer didn’t abandon it, he finalized the API and features. CoreOS wanted additional features. The original maintainer wanted to keep the scope minimal. The reason for adopting a pure Go key value store is to utilize all of the Go tooling, like profiling, to aid with discovering performance bottlenecks. Crossing the language boundary loses visibility into problems.
- philips 9y ago
  As an etcd maintainer the reasoning for using a Go key value is exactly this: we can use all pure Go tooling easing debugging and profiling. Plus, by having a simple Go only build system we reduce the burden for on-boarding developers which I believe is part of the reason for etcd's solid and growing developer base: it is easy to get into. Well, easy relative to other databases, ha!
  - smarterclayton 9y ago
    Etcd has been phenomenal. In terms of solving the simple KV HA story, I can't think of a single technology that I have ever used that is as simple to set up and operate. We run etcd clusters with millions of keys and 500+/sec write rates and I can count on one hand the number of problems / tunings / issues we've had over the last two years. There are lots of reasons why you might not want to use etcd, but if you can live with simple K/V, need HA, and need something that is simple and just works, I can't think of anything else that is comparable except for Consul (which I haven't used much, but has similar design principles).
    - kvz 9y ago
      Not a user but I think Zookeeper is worth a mention.

pokstad 9y ago

The previous maintainer didn’t abandon it, he finalized the API and features. CoreOS wanted additional features. The original maintainer wanted to keep the scope minimal. The reason for adopting a pure Go key value store is to utilize all of the Go tooling, like profiling, to aid with discovering performance bottlenecks. Crossing the language boundary loses visibility into problems.

philips 9y ago
As an etcd maintainer the reasoning for using a Go key value is exactly this: we can use all pure Go tooling easing debugging and profiling. Plus, by having a simple Go only build system we reduce the burden for on-boarding developers which I believe is part of the reason for etcd's solid and growing developer base: it is easy to get into. Well, easy relative to other databases, ha!
- smarterclayton 9y ago
  Etcd has been phenomenal. In terms of solving the simple KV HA story, I can't think of a single technology that I have ever used that is as simple to set up and operate. We run etcd clusters with millions of keys and 500+/sec write rates and I can count on one hand the number of problems / tunings / issues we've had over the last two years. There are lots of reasons why you might not want to use etcd, but if you can live with simple K/V, need HA, and need something that is simple and just works, I can't think of anything else that is comparable except for Consul (which I haven't used much, but has similar design principles).
  - kvz 9y ago
    Not a user but I think Zookeeper is worth a mention.