etcd可以用作可靠的数据库替换吗？由于它是以持久方式分发和存储键/值对，因此它将是一个很好的替代nosql数据库。此外，它有一个很棒的API。有人可以解释为什么这不是一件事吗？
答案 0 :(得分：28)
<强> ETCD
nosql数据库
目前有超过255个nosql数据库，可以大致归类为Key-Value based, Column based, Document based and Graph based。考虑 etcd 作为键值存储，让我们看一下可用的nosql键值数据存储。
Redis, memcached and memcacheDB是受欢迎的键值存储。这些是通用的分布式内存缓存系统，通常用于通过在内存中缓存数据和对象来加速动态数据库驱动的网站。
为什么etcd不是替代
etcd无法存储在内存中（ram）它们只能保存在磁盘存储中，而redis可以缓存在ram中，也可以保存在磁盘中。
etcd没有各种数据类型。它只用于存储kubernetes对象。但redis和其他键值存储具有数据类型的灵活性。
etcd仅保证高可用性，但不会为您提供快速查询和索引。所有的nosql键值存储都是为了快速查询和搜索而构建的。
尽管显然etcd不能用作替代的nosql数据库，但我认为上述解释将证明它不是一个合适的替代方案。
答案 1 :(得分：1)
首先，不。 Etcd不是下一个nosql替代。但是在某些情况下，可以派上用场。
让我们假设您有（配置）数据，该数据大部分是静态的，但可能会在运行时发生变化。也许您的前端需要了解基于客户所在国家/地区的后端端点以遵守法律，并且您知道全球部署是分阶段进行的。
因此，您可以仅使用k8s configMap存储数据数组（国家->端点），然后让您的后端监视此configMap的更改。 更改后，该应用程序仅读取列表并提供一个存储库，以允许从服务层访问数据。 所有操作都需要在存储库中实现（搜索，获取，更新...），但是您的数据将存储在内存中（可能是链接的哈希映射）。因此，它将很快恢复（就像本地缓存一样）。
如果应用程序更改了数据，则只需序列化列表并修补configMap。任何其他监视configMap的应用程序都将更新其内部状态。 但是，没有锁定。因此，快速更改可能会导致比赛状况。
etcd允许存储1Mb。这对于几乎静态的数据就足够了。
另一个应用程序可能是功能切换。它们并没有太大的变化，但是当它们进行了更改时，每个应用程序都需要快速知道并且轮询很糟糕。
答案 2 :(得分：0)
来自 ETCD.IO 站点：
etcd 是一个高度一致的分布式键值存储 提供一种可靠的方式来存储需要被访问者访问的数据 分布式系统或机器集群。它优雅地处理 网络分区期间的领导者选举并且可以容忍机器 失败，即使在领导节点。
它有一个使用 http 和 json 的简单接口。它不仅适用于 Kubernetes。 Kubernetes 只是使用它的关键应用程序的一个示例。
你说得对，应该是一回事。一个不错的可靠数据存储，具有易于使用的 API 和使用 raft 协议告诉您何时发生变化的好方法。这对于功能切换和其他一切都需要了解的项目非常有用，并且比将触发器放入 sql 数据库并让它将事件发送到外部应用程序或非常可怕的轮询等事情要好得多。
因此，如果您正在编写类似 kubernetes 用例的内容 >> 对于分布式应用程序来说，这是一个经过充分验证的完美存储。
如果您正在编写与 kubernetes 用例非常不同的内容，那么您正在与所有其他 no-sql 数据库进行比较。但是与 mongodb 之类的东西非常不同，所以如果 mongodb 或类似的东西不适合你，它可能对你更好。
其他示例用户</p>
Uber 为 Prometheus 创建的大规模指标平台 M3，使用 etcd 进行规则存储等功能
一致性 Jepson 在 https://jepsen.io/analyses
对 NOSQL 数据库一致性进行了很好的比较ETCD 在 https://etcd.io/blog/jepsen-343-results/ 处总结他们的结果
答案 3 :(得分：-1)
我唯一能看到的答案就是那些在我们耳中的答案。我们首先需要先证明它可以完成，以及它带来的好处。
我的同事们似乎对此不以为然，因为“这是为了存储秘密和共同的事实”。 etcd v3的修改使得etcd能够做得更多，但新闻并没有简单地起草，但是。
让我们制作一些展示案例，成功案例。我个人喜欢etcd，因为你提到的原因，以及它对dependable performance的关注。