无状态——Elasticsearch 的全新查找状态

借助无状态 Elasticsearch，我们正在投资构建一个全新的完全云原生架构，以突破规模和速度的界限。在本博客中，我们将探讨我们的起点、引入无状态架构后 Elasticsearch 的未来以及该架构的详细信息。

我们的起点

Elasticsearch 的第一个版本于 2010 年发布，它是一个分布式可扩展搜索引擎，允许用户快速搜索和呈现关键见解。十二年过去了，超过 65,000 次提交之后，Elasticsearch 继续为用户提供经过实战检验的解决方案，以解决各种搜索问题。由于 1,500 多位贡献者（包括数百名 Elastic 全职员工）的努力，Elasticsearch 不断发展以应对搜索领域中出现的新挑战。

在 Elasticsearch 的早期，当出现数据丢失问题时，Elastic 团队进行了多年努力，重写了集群协调系统，以保证已确认的数据安全存储。当管理大型集群中的索引变得麻烦时，团队致力于实施广泛的ILM 解决方案，通过允许用户预定义索引模式和生命周期操作来自动化这项工作。当用户发现需要存储大量指标和时间序列数据时，添加了各种功能（例如更好的压缩）以减小数据大小。随着搜索大量冷数据的存储成本增加，我们投资创建了可搜索快照，作为直接在低成本对象存储中搜索用户数据的一种方式。

这些投资为 Elasticsearch 的下一次发展奠定了基础。随着云原生服务的增长和新的编排系统出现，我们认为现在是时候让 Elasticsearch 发展以改善与云原生系统一起工作时的体验。我们相信，这些变化为在Elastic Cloud上运行 Elasticsearch 时提供操作、性能和成本改进的机会。

我们的目标——采用无状态架构

操作或编排 Elasticsearch 时面临的主要挑战之一是它依赖于大量持久性状态，因此它是一个有状态系统。三个主要部分是事务日志、索引存储和集群元数据。这种状态意味着存储必须是持久性的，并且在节点重启或替换期间不能丢失。

Elastic Cloud 上现有的 Elasticsearch 架构必须跨多个可用区复制索引，以便在出现中断时提供冗余。我们打算将此数据的持久性从本地磁盘转移到对象存储，例如 AWS S3。通过依赖外部服务来存储此数据，我们将消除对索引复制的需求，从而显著减少与摄取相关的硬件。由于 AWS S3、GCP 云存储和 Azure Blob 存储等云对象存储跨可用区复制数据的方式，此架构还提供了非常高的持久性保证。

将索引存储卸载到外部服务还将允许我们通过分离索引和搜索职责来重新设计 Elasticsearch。我们打算拥有一个索引层和一个搜索层，而不是让主实例和副本实例处理这两个工作负载。分离这些工作负载将允许它们独立扩展，并使硬件选择更适合各自的用例。它还有助于解决长期存在的挑战，即搜索和索引负载会相互影响。

在进行了为期数月的概念验证和实验阶段后，我们相信这些对象存储服务满足我们设想的索引存储和集群元数据的需求。我们的测试和基准测试表明，这些存储服务可以满足我们在 Elastic Cloud 中看到的最大集群的高索引需求。此外，支持对象存储中的数据降低了索引成本，并允许轻松调整搜索的性能。为了搜索数据，Elasticsearch 将使用经过实战检验的可搜索快照模型，其中数据永久持久存储在云原生对象存储中，本地磁盘用作常用数据的缓存。

为了便于区分，我们将现有模型描述为“节点到节点”复制。在此模型的热层中，主分片和副本分片都执行相同的繁重工作以处理摄取和提供搜索请求。这些节点是“有状态的”，因为它们依赖于本地磁盘来安全地持久存储它们托管的分片的数据。此外，主分片和副本分片会不断通信以保持同步。它们通过将对主分片执行的操作复制到副本分片来做到这一点，这意味着每个指定的副本都会产生这些操作（主要是 CPU）的成本。执行摄取工作的相同分片和节点也提供搜索请求，因此必须同时考虑这两个工作负载来进行配置和扩展。

除了搜索和摄取之外，“节点到节点”复制模型中的分片还处理其他密集型职责，例如合并 Lucene 段。虽然此设计有其优点，但基于多年来从客户那里学到的经验以及更广泛的云生态系统的演变，我们看到了很多机会。

新架构使许多当前和未来的改进成为可能，包括

您可以使用相同的硬件显着提高摄取吞吐量，或者换句话说，针对相同的摄取工作负载显着提高效率。这种提高来自于消除了为每个副本复制索引操作的需求。CPU 密集型索引操作只需要在索引层执行一次，然后将生成的分段发送到对象存储。从那里，数据就可以被搜索层按原样使用。
您可以将计算与存储分离，从而简化集群拓扑。如今，Elasticsearch 具有多个数据层（内容、热、温、冷和冻结），以使数据与硬件配置文件匹配。热层用于近实时搜索，冻结层用于较少搜索的数据。虽然这些层提供了价值，但它们也增加了复杂性。在新架构中，将不再需要数据层，从而简化了 Elasticsearch 的配置和操作。我们还将索引与搜索分开，这进一步降低了复杂性，并允许我们独立扩展这两个工作负载。
您可以通过减少必须存储在本地磁盘上的数据量来提高索引层的存储成本。目前，Elasticsearch 必须出于索引目的在热节点（主节点和副本节点）上存储完整的分片副本。通过直接将索引到对象存储的无状态方法，只需要一部分本地数据。对于仅追加用例，只需要存储某些元数据即可进行索引。这将大大减少索引所需的本地存储。
您可以降低与搜索查询相关的存储成本。通过使可搜索快照模型成为搜索数据的原生模式，与搜索查询相关的存储成本将显着降低。根据用户的搜索延迟需求，Elasticsearch 将允许调整以增加对频繁请求数据的本地缓存。

基准测试——索引吞吐量提高 75%

为了验证这种方法，我们实施了一个广泛的概念验证，其中数据仅在一个节点上索引，并且复制是通过云对象存储实现的。我们发现，通过消除将硬件专用于索引复制的需要，我们可以实现 **索引吞吐量提高 75%**。此外，仅从对象存储中提取数据的 CPU 成本远低于索引数据并将其写入本地，就像当今热层所必需的那样。这意味着搜索节点将能够充分利用其 CPU 来进行搜索。

这些性能测试在一个双节点集群上针对三大主要的公共云提供商（AWS、GCP和Azure）进行。随着我们推进生产环境无状态实施，我们计划继续构建更大的基准测试。

索引吞吐量