使用 etcd 作为主存储/数据库？

Posted 2023-03-15

【中文标题】使用 etcd 作为主存储/数据库？

【英文标题】：Using etcd as primary store/database?

【发布时间】：2017-04-25 02:22:02

【问题描述】：

etcd 可以用作可靠的数据库替换吗？由于它是分布式的并以持久的方式存储键/值对，因此它将是一个很好的替代 nosql 数据库。此外，它还有一个很棒的 AP​​I。有人可以解释为什么这不是一件事吗？

【问题讨论】：

我正在尝试看看是否可以使用 etcd (k8s CRDs) 作为数据库替换，您能否分享您使用 etcd 的经验。见***.com/questions/52565131/…

我发现 etcd 对于存储需要随时可用的配置文件/静态文件特别有用（就像 Kubernetes 一样，名称暗示了一个分布式 /etc 文件夹 => etc + d(istributed) =等）。通过运行多节点 etcd 集群，可以确保文件可用。我会说这在很大程度上取决于您的用例和您要存储的数据。基准测试显示 etcd 上每秒最多查询 30k 次。

我使用 etcd 处理各种配置数据，并且使用了很长时间。它不是通用数据库，而是键值数据库。对于需要使用基于键或键范围检索值的模型（可能具有命名空间和精细访问控制）的数据存储需要高速分布式访问，这是一个不错的选择。例如，对于经常搜索记录以查找包含字符串的值的模型，它并不是那么好。根据数据的使用方式选择数据存储。 :)

【参考方案1】：

etcd

etcd 是一个高度可用的键值对存储，Kubernetes 使用它来持久存储其所有对象，例如

部署、pod、服务

信息。 etcd 具有高度的访问控制，只能在主节点使用 API 访问。集群中除 master 以外的节点

无权

访问 etcd 存储。

nosql 数据库

目前有超过255的nosql数据库，大致可以归为Key-Value based, Column based, Document based and Graph based。将 etcd 视为键值存储，让我们看看可用的 nosql 键值数据存储。

Redis, memcached and memcacheDB 是流行的键值对存储。这些是通用分布式内存缓存系统，通常用于通过在内存中缓存数据和对象来加速动态数据库驱动的网站。

为什么 etcd 不是替代品

etcd不能存储在内存中（ram）只能持久化在磁盘存储中，而redis可以缓存在内存中，也可以持久化在磁盘中。

etcd 没有各种数据类型。它仅用于存储 kubernetes 对象。但是 redis 和其他键值存储具有数据类型的灵活性。

etcd 只保证高可用性，但不提供快速查询和索引。所有的 nosql 键值存储都是以快速查询和搜索为目标而构建的。

虽然 etcd 显然不能作为 nosql 数据库的替代品，但我认为上面的解释将证明它不是一个合适的替代品。

【讨论】：

"它只用于存储 kubernetes 对象" --> 这不是真的。虽然 Kubernetes 是 etcd 的主要客户之一，但这并不意味着只有 kubernetes 对象可以存储在 etcd 中。 etcd 更倾向于在分布式环境中存储数据。

为什么说“etcd的访问控制很高，只能在master节点使用API​​访问。集群中除master以外的节点无权访问etcd store”。部署您自己的 etcd 就像部署您自己的数据库一样简单，并且可以为您想要的任何实体提供访问权限？

这里的cons都是错误的，可能是因为作者只在Kubernetes的上下文中使用过etcd。 etcd 从内存中工作，并且只将日志存储在磁盘上。 etcd 将数据（键和值）存储为二进制数组；最终用户可以应用他们想要的任何类型（通常通过将值存储为 JSON）。 etcd 使用 btree 来索引键，这与大多数其他数据库在通用数据上使用的索引相同。我想它不使用 SQL，但适用于键值数据库中数据的“查询和搜索”在 etcd 中非常快。

这个答案不应该被任何人关注。第二部分完全错误。

我不认为结论尊重整个讨论，我认为 etcd 可以用作非 SQL 数据库的替代品，真正的答案是它取决于您的用例和权衡取舍你愿意做

【参考方案2】：

来自ETCD.IO 网站：

etcd 是一个高度一致的分布式键值存储 提供了一种可靠的方式来存储需要由 分布式系统或机器集群。它优雅地处理 网络分区期间的领导者选举并且可以容忍机器 失败，即使在领导节点。

它有一个使用 http 和 json 的简单接口。它不仅适用于 Kubernetes。 Kubernetes 只是使用它的关键应用程序的一个示例。

你是对的，它应该是一件事。一个很好的可靠数据存储，具有易于使用的 API 以及使用 raft 协议告诉您何时发生变化的好方法。这对于功能切换和其他一切都需要知道的项目非常有用，并且比在 sql 数据库中放置触发器并将事件发送到外部应用程序或非常糟糕的轮询等事情要好得多。

因此，如果您正在编写类似 kubernetes 用例的东西 >> 它是一个经过充分验证的分布式应用程序存储。

如果您正在编写与 Kubernetes 用例非常不同的东西，那么您就是在与所有其他无 SQL 数据库进行比较。但是与 mongodb 之类的东西非常不同，所以如果 mongodb 或类似的东西不适合你，它可能对你更好。

其他示例用户

Uber为Prometheus打造的大规模指标平台M3，使用etcd进行规则存储等功能

一致性 Jepson 在https://jepsen.io/analyses 上对 NOSQL 数据库一致性进行了很好的比较

ETCD 在https://etcd.io/blog/jepsen-343-results/ 总结他们的结果

【参考方案3】：

我看到的唯一答案是我们耳朵之间的答案。猜猜我们需要首先证明它是可以做到的，以及有什么好处。

我的同事们似乎回避它，因为“它是用来存储秘密和共同真理的”。 etcd v3 的修订使 etcd 功能更强大，但消息还没有简单地传开。

让我们制作一些展示案例和成功案例。就我个人而言，我喜欢 etcd，因为你提到的原因，因为它专注于dependable performance。

【参考方案4】：

首先，不。 Etcd 不是下一个 nosql 替代品。但在某些情况下，它可以派上用场。

假设您有（配置）数据，这些数据大部分是静态的，但可能会在运行时发生变化。也许您的前端需要了解基于客户国家/地区的后端端点以遵守法律，并且您知道全球范围内的部署是分阶段完成的。

因此，您可以只使用 k8s configMap 来存储数据数组（国家 -> 端点）并让您的后端监视此 configMap 的更改。 在更改时，应用程序只读取列表并提供一个存储库以允许从您的服务层访问数据。 所有操作都需要在存储库中实现（搜索、获取、更新……），但您的数据将在内存中（可能是链接的哈希映射）。所以检索起来会非常快（就像本地缓存一样）。

如果应用程序更改了数据，只需序列化列表并修补 configMap。任何其他观察 configMap 的应用程序都会更新它们的内部状态。 但是没有锁定。如此快速的更改可能会导致竞争条件。

etcd 允许存储 1Mb。这对于几乎是静态的数据来说已经足够了。

另一个应用程序可能是功能切换。它们并没有发生太大变化，但是当它们发生变化时，每个应用程序都需要快速知道并且轮询很糟糕。

【参考方案5】：

看看etcd 的限制清单与功能更全的数据库相比是否适合您：

您的数据库大小将在 2 GB 以内（可扩展到最大 8 GB） NoSQL 数据库集群（Mongo、Redis 等）提供的无分片和数据可扩展性 适用于有效负载限制为 1.5 MB 的简单值存储。可以增加，但会影响其他查询。大多数数据库可以存储大型 BLOB。 Redis 可以存储 512 MB 的值。 没有查询语言可用于键前缀之外的更复杂的搜索。其他数据库提供更复杂的数据类型，如文档、带有查询和索引的图形存储。甚至键值数据库 Redis 通过模块以及查询和搜索功能支持更复杂的类型 没有 ACID 事务

有了锤子，一切都可能看起来像潜在的钉子。您需要确保它确实是一个。