将etcd用作主要存储/数据库？

Question

将etcd用作主要存储/数据库？

76

etcd 可以用作可靠的数据库替代品吗？由于它是分布式的，并以持久化方式存储键/值对，因此它将是一个很好的替代nosql数据库的选择。另外，它还有一个很棒的API。有人能解释一下为什么这不是一个事情吗？

- Plus Ultra

1

我正在尝试使用etcd（k8s CRDs）作为数据库替代品，您能分享一下您对etcd的经验吗？请参见https://stackoverflow.com/questions/52565131/can-i-store-my-application-data-in-kubernetes-configuration-resources。 - Jay Rajput

5

我发现etcd对于存储需要全时可用的配置文件/静态文件特别有用（就像Kubernetes所做的那样，而且名称意味着一个分布式'/etc'文件夹 => etc + d(istributed) = etcd）。通过运行多节点的etcd集群，人们可以确保文件一直可用。我认为这高度取决于您的使用情况和要存储的数据。基准测试显示etcd最多可达到每秒约30,000次查询。 - Plus Ultra

2

我长期以来一直使用etcd来处理各种配置数据。它不是通用数据库，而是键值数据库。对于需要基于按键或键范围检索值的模型进行高速分布式访问的数据存储，可能带有命名空间和细粒度访问控制，它是一个很好的选择。但对于频繁搜索包含字符串值的记录的模型，例如，它并不是很好。根据数据的使用方式选择数据存储。 :) - dannysauer

5个回答

8

来自ETCD.IO网站：

etcd是一个强一致的分布式键值存储，提供了一种可靠的方式来存储需要被分布式系统或机群访问的数据。它在网络分区期间优雅地处理领导者选举，并能容忍机器故障，即使在领导节点中也是如此。

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

你是对的，它应该成为一种事物。一个好用的、可靠的数据存储，有一种易于使用的API并且可以使用raft协议告诉您何时发生变化。这对于特性切换和其他需要所有内容都知道的项目非常有用，比如将触发器放入SQL数据库中并让其向外部应用程序发送事件，或者使用非常糟糕的轮询。

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

如果您正在编写与kubernetes用例非常不同的东西，那么您正在与所有其他NoSQL数据库进行比较。但它与mongodb之类的东西非常不同，因此如果mongodb或类似软件无法满足您的需求，则可能更好。

其他示例用户

M3是由Uber创建的大型Prometheus指标平台，使用etcd存储规则和其他功能

一致性 Jepson进行了NOSQL数据库一致性的良好比较，请参见https：//jepsen.io/analyses

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

- Ronald Duncan

3

请查看以下有关etcd与更全面的数据库相比的限制清单，看看它是否适合您：

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

拥有一把锤子，所有东西都可能看起来像一个潜在的钉子。您需要确保它确实是一个。

- pratyahara

3

我所看到的唯一答案是我们脑海中的答案。我猜我们需要首先展示它可以做到，并且好处是什么。

我的同事似乎对此有些避讳，因为“它是用来存储秘密和共同真相的”。etcd v3修订使etcd变得更加强大，但这个消息还没有传开。

让我们展示一些案例和成功故事。就我个人而言，我喜欢etcd，因为你提到的原因，以及它专注于可信赖的性能。

- akauppi

2

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

假设您有一些（配置）数据，大部分是静态的，但可能会在运行时更改。也许您的前端需要根据客户的国家获取后端端点以遵守法律，并且您知道全球范围内的推出是分阶段完成的。

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

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

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

另一个应用程序可能是功能切换。它们不会经常更改，但是当它们更改时，每个应用程序都需要快速知道，而轮询则很糟糕。

- Hannes

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Lakshman Diwaakar · Accepted Answer

etcd

etcd是一个高可用的键值存储，Kubernetes使用它来持久化存储所有对象，例如部署、Pod、服务信息。
etcd具有高访问控制，只能通过主节点上的API进行访问。集群中除主节点外的其他节点无法访问etcd存储。

nosql数据库

目前有超过255个NoSQL数据库，可以广泛分类为基于键值、列、文档和图形的。将etcd视为键值存储，让我们看看可用的NoSQL键值数据存储。
Redis、memcached和memcacheDB是流行的键值存储。这些是通用的分布式内存缓存系统，通常用于通过在内存中缓存数据和对象来加速动态数据库驱动的网站。

为什么etcd不是替代方案

etcd无法存储在内存(ram)中，只能持久化到磁盘存储，而Redis可以在内存中缓存，也可以持久化到磁盘。
etcd没有各种数据类型。它只能用于存储Kubernetes对象。但是Redis和其他键值存储具有数据类型的灵活性。
etcd仅保证高可用性，但不提供快速查询和索引。所有NoSQL键值存储都是为了快速查询和搜索而构建的。

尽管很明显etcd不能作为替代NoSQL数据库的选择，但我认为上述解释将证明它不能成为合适的替代品。