8 ms·

Announcing etcd 3.1

95 points by philips 10y ago

philips 10y ago
Much of the focus on this release is continuing to support Kubernetes with the best possible consistency database. Xiang Li, one of the leads of etcd, included a couple of notes in his email to Kubernetes dev: etcd v3.1 improves the read performance by a factor of 10 for Kuberentes use cases (unless quorum read is disabled). etcd's v3 API will be the default backend in Kubernetes 1.6 release. But now you can also run Kuberentes 1.5 with etcd3 by providing `--storage-backend=etcd3` to the API server. https://groups.google.com/forum/#!topic/kubernetes-dev/wgYXbyHKLEw https://groups.google.com/forum/#!topic/kubernetes-dev/wgYXb...
dsies 10y ago
Congrats to the coreos/etcd team! With that said, I feel really conflicted about v3. I understand why it was introduced and understand why it is objectively better than v2, however the reason I fell in love with etcd was because of v2. It was a simple, highly available, not very fast key store that exposed an easy way to view and traverse the store (via the /v2/keys API endpoint). Likewise, the client api was simple, quick to pickup and very easy to work with. With v3, while the performance has increased dramatically (and many other things), the "ease" of etcd seems to have gone as well. To this point, all of the software I've written that makes use of etcd is tied to etcd v2. Should I make a conscious effort to migrate to etcd v3? How much longer is v2 going to be kept around?
- ideal0227 10y ago
  > the "ease" of etcd seems to have gone Can you explain this more? One of the goals of the new API is to make etcd easier to interact with. Can you provide a few examples where v3 is more difficult than v2 to work with? (etcd-dev or github might be a better place to discuss though) We would love to hear and improve.
  - regecks 10y ago
    grpc clients are disgustingly fat. For that reason I am using v2 API on v3. It's a pity but I need etcd access from many projects and grpc often dwarfs the rest of the project , explodes the binary size.
  - sagichmal 10y ago
    Agree with sibling comment, gRPC is nice as an optimization but terrible as a default or exclusive means to speak to an API.
    - ideal0227 10y ago
      etcd3 provides a HTTP+JSON API as a gateway: https://github.com/coreos/etcd/blob/master/Documentation/dev-guide/api_grpc_gateway.md https://github.com/coreos/etcd/blob/master/Documentation/dev.... There are users we know successfully using it. If users are unhappy about the HTTP API, or it is too hard to use, we might consider to provide a native HTTP API.
lobster_johnson 10y ago
Tangentially, has anyone tried using etcd as a database for content? etcd was obviously designed for consensus, coordination and discovery, but there seems to be nothing to prevent it from being perfectly adequate as a data store for other things. From what I can tell, it's pretty fast, strongly consistent, replicating, and has the building blocks to perform atomic transactions across multiple keys. It might work really well as the primary store of truth with something like Elasticsearch on top.
- niftich 10y ago
  There are a few things preventing it from being an effective database for general-purpose content: - "bespoke" data storage [1] - originally optimized for small amounts of data [2] v3 made progress on both of these fronts but see [3][4] [1] https://github.com/coreos/etcd/issues/2647 https://github.com/coreos/etcd/issues/2647 [2] https://groups.google.com/forum/#!searchin/etcd-dev/store/etcd-dev/ATZm7sRJy60/aqeQcrIB7NcJ https://groups.google.com/forum/#!searchin/etcd-dev/store/et... [3] https://coreos.com/etcd/docs/latest/faq.html#deployment https://coreos.com/etcd/docs/latest/faq.html#deployment [4] https://coreos.com/etcd/docs/latest/op-guide/hardware.html https://coreos.com/etcd/docs/latest/op-guide/hardware.html
  - lobster_johnson 10y ago
    Hm. The first two are pre-3.x, and that issue (#2647) is closed, seemingly because everything has been implemented? Not seeing any huge limitations mentioned in 3 and 4. The "small amounts of data" issue apparently no longer applies to 3.x, which now persists efficiently to disk. Not sure what "bespoke" data storage means? 3.x has pluggable backends.
    - niftich 10y ago
      I thought they might've meant to add pluggable backends but I can't find any reference to them? Do you have a link?
      - 10y ago

95 points by philips 10y ago

Much of the focus on this release is continuing to support Kubernetes with the best possible consistency database. Xiang Li, one of the leads of etcd, included a couple of notes in his email to Kubernetes dev: etcd v3.1 improves the read performance by a factor of 10 for Kuberentes use cases (unless quorum read is disabled). etcd's v3 API will be the default backend in Kubernetes 1.6 release. But now you can also run Kuberentes 1.5 with etcd3 by providing `--storage-backend=etcd3` to the API server. https://groups.google.com/forum/#!topic/kubernetes-dev/wgYXbyHKLEw https://groups.google.com/forum/#!topic/kubernetes-dev/wgYXb...

dsies 10y ago

Congrats to the coreos/etcd team! With that said, I feel really conflicted about v3. I understand why it was introduced and understand why it is objectively better than v2, however the reason I fell in love with etcd was because of v2. It was a simple, highly available, not very fast key store that exposed an easy way to view and traverse the store (via the /v2/keys API endpoint). Likewise, the client api was simple, quick to pickup and very easy to work with. With v3, while the performance has increased dramatically (and many other things), the "ease" of etcd seems to have gone as well. To this point, all of the software I've written that makes use of etcd is tied to etcd v2. Should I make a conscious effort to migrate to etcd v3? How much longer is v2 going to be kept around?

ideal0227 10y ago
> the "ease" of etcd seems to have gone Can you explain this more? One of the goals of the new API is to make etcd easier to interact with. Can you provide a few examples where v3 is more difficult than v2 to work with? (etcd-dev or github might be a better place to discuss though) We would love to hear and improve.
- regecks 10y ago
  grpc clients are disgustingly fat. For that reason I am using v2 API on v3. It's a pity but I need etcd access from many projects and grpc often dwarfs the rest of the project , explodes the binary size.
- sagichmal 10y ago
  Agree with sibling comment, gRPC is nice as an optimization but terrible as a default or exclusive means to speak to an API.
  - ideal0227 10y ago
    etcd3 provides a HTTP+JSON API as a gateway: https://github.com/coreos/etcd/blob/master/Documentation/dev-guide/api_grpc_gateway.md https://github.com/coreos/etcd/blob/master/Documentation/dev.... There are users we know successfully using it. If users are unhappy about the HTTP API, or it is too hard to use, we might consider to provide a native HTTP API.

lobster_johnson 10y ago

Tangentially, has anyone tried using etcd as a database for content? etcd was obviously designed for consensus, coordination and discovery, but there seems to be nothing to prevent it from being perfectly adequate as a data store for other things. From what I can tell, it's pretty fast, strongly consistent, replicating, and has the building blocks to perform atomic transactions across multiple keys. It might work really well as the primary store of truth with something like Elasticsearch on top.

niftich 10y ago
There are a few things preventing it from being an effective database for general-purpose content: - "bespoke" data storage [1] - originally optimized for small amounts of data [2] v3 made progress on both of these fronts but see [3][4] [1] https://github.com/coreos/etcd/issues/2647 https://github.com/coreos/etcd/issues/2647 [2] https://groups.google.com/forum/#!searchin/etcd-dev/store/etcd-dev/ATZm7sRJy60/aqeQcrIB7NcJ https://groups.google.com/forum/#!searchin/etcd-dev/store/et... [3] https://coreos.com/etcd/docs/latest/faq.html#deployment https://coreos.com/etcd/docs/latest/faq.html#deployment [4] https://coreos.com/etcd/docs/latest/op-guide/hardware.html https://coreos.com/etcd/docs/latest/op-guide/hardware.html
- lobster_johnson 10y ago
  Hm. The first two are pre-3.x, and that issue (#2647) is closed, seemingly because everything has been implemented? Not seeing any huge limitations mentioned in 3 and 4. The "small amounts of data" issue apparently no longer applies to 3.x, which now persists efficiently to disk. Not sure what "bespoke" data storage means? 3.x has pluggable backends.
  - niftich 10y ago
    I thought they might've meant to add pluggable backends but I can't find any reference to them? Do you have a link?
    - 10y ago