使用Zstandard压缩以优化Amazon OpenSearch Service的存储成本

文章重点

在本篇文章中，我们将探讨如何透过引入Zstandard压缩算法来优化Amazon OpenSearch Service的存储成本。Zstandard作为一种高效的压缩算法，不仅能减少存储需求，还能提升查询效率，对于处理大量数据的环境来说具有重要意义。

这篇文章由Praveen Nischal、Mulugeta Mammo和Akash Shankaran来自Intel共同撰写。

Amazon OpenSearch Service 是一个管理服务，能够轻松地在AWS云端中安全、部署与运营OpenSearch集群。在OpenSearch Service领域中，数据以索引的形式进行管理。根据使用模式，一个OpenSearch集群可能有一个或多个索引，其片段会分布在集群的数据节点上。每个数据节点有固定的磁碟大小，磁碟的使用情况取决于存储在该节点上的索引片段数量。每个索引片段的大小可能根据其文件数量而有所不同。此外，确定索引片段大小的一个重要因素是用于索引的压缩策略。

在索引操作中，摄取的文件会被存储为不可变的段。每个段是各种数据结构的集合，例如倒排索引、块K维树BKD、术语字典或存储字段，这些数据结构在搜索操作时负责更快地检索文件。在这些数据结构中，存储字段是段中较大的字段，当存储到磁碟上时会进行压缩，根据使用的压缩策略，压缩速度和索引存储大小会有所不同。

本文将讨论Zstandard算法的性能，该算法在OpenSearch v29中引入，与OpenSearch中其他可用的压缩算法进行比较。

压缩在OpenSearch中的重要性

压缩在OpenSearch中扮演著重要角色，因为它显著影响了性能、存储效率和整体可用性。以下是几个突显压缩在OpenSearch中重要性的关键原因：

重要性描述存储效率与成本节省OpenSearch通常处理大量数据，包括日志文件、文档和分析数据集。压缩技术可以减少磁碟上的数据大小，带来可观的成本节省，特别是在云端或分布式环境中。减少I/O操作压缩减少了读取或写入数据所需的I/O操作次数，较少的I/O操作意味著减少磁碟I/O，这对整体系统性能和资源利用率至关重要。环境影响通过最小化存储需求和减少I/O操作，压缩有助于降低能耗和碳足迹，这符合可持续性和环境目标。

在配置OpenSearch时，必须仔细考虑压缩设置，以便在存储效率和查询性能之间取得平衡，根据具体用例和资源约束进行调整。

核心概念

在深入了解OpenSearch提供的各种压缩算法之前，先看三个在比较压缩算法时经常使用的标准指标：

压缩比：输入的原始大小与压缩后数据的比率，表达为10或更高的比率压缩速度：压缩数据的速度，以MB/s表示所消耗的输入数据解压缩速度：从压缩数据重建原始数据的速度，以MB/s表示

索引编解码器

OpenSearch支持用于压缩存储字段的编解码器。在OpenSearch 27之前，OpenSearch提供了两种编解码器或压缩策略：LZ4和Zlib。LZ4相当于bestspeed，因为它提供更快的压缩速度，但与Zlib相比压缩比率较低占用更多磁盘空间。如果在索引创建时未显式指定编解码器，则默认使用LZ4压缩算法。大多数情况下，由于LZ4能提供较快的索引和搜索速度而受到青睐，尽管相比Zlib占用的空间相对较多。Zlib则相当于bestcompression，因为它提供更好的压缩比占用更少的磁盘空间，但需要更长的时间进行压缩和解压，因此在索引和搜索操作中具有更高的延迟。LZ4和Zlib编解码器都是Lucene核心编解码器的一部分。

Zstandard编解码器

在OpenSearch中引入的Zstandard编解码器作为实验性功能在版本27中提供，它提供基于Zstandard的压缩和解压API。Zstandard编解码器基于JNI绑定到Zstd原生库。

Zstandard是一种快速、无损的压缩算法，旨在提供与Zlib相媲美的压缩比，但具有与LZ4相当的更快的压缩和解压缩速度。Zstandard压缩算法在OpenSearch中有两种不同的模式：zstd和zstdnodict。更多细节见索引编解码器。

这两种编解码器模式旨在平衡压缩比、索引和搜索吞吐量。zstdnodict选项在占用略大索引体积的代价下排除字典以进行压缩。

随著最新的OpenSearch 29版本，Zstandard编解码器已从实验阶段升级为主流，适合生产级用例。

使用Zstd编解码器创建索引

您可以在索引创建时使用indexcodec设置，以使用Zstd编解码器创建索引。以下是使用curl命令的范例此命令要求用户具备创建索引的必要权限：

bash

创建索引

curl XPUT http//localhost9200/yourindex H ContentType application/json d{ settings { indexcodec zstd }}

Zstandard压缩级别

使用Zstandard编解码器，您可以选择性地使用indexcodeccompressionlevel设置指定压缩级别，如下代码所示。该设置接受范围为[1 6]的整数。较高的压缩级别可带来更高的压缩比更小的存储大小，但会影响速度较慢的压缩和解压速度会导致较高的索引和搜索延迟。有关更多细节，请参见选择编解码器。

bash

创建索引

curl XPUT http//localhost9200/yourindex H ContentType application/json d{ settings { indexcodec zstd indexcodeccompressionlevel 2 }}

更新索引编解码器设置

您可以在创建索引后随时更新indexcodec和indexcodeccompressionlevel设置。为使新配置生效，需关闭并重新打开该索引。

以下是使用curl命令更新索引设置的范例：

云梯加速器最新版

关闭索引：

bash

关闭索引

curl XPOST http//localhost9200/yourindex/close

更新索引设置：

bash

更新indexcodec和codeccompressionlevel设置

curl XPUT http//localhost9200/yourindex/settings H ContentType application/json d { index { codec zstdnodict codeccompressionlevel 3 } }

重新打开索引：

bash

重新打开索引

curl XPOST http//localhost9200/yourindex/open

更改索引编解码器设置不会立即影响现有段的大小。只有在更新后创建的新段才会反映新的编解码器设置。为了使段大小和压缩比保持一致，可能需要进行重新索引或其他索引过程，如合并。

OpenSearch中压缩性能的基准测试

为了理解Zstandard编解码器的性能优势，我们进行了基准测试。

设置

伺服器设置如下：

基准测试在一个OpenSearch集群上进行，该集群有单个数据节点，既作为数据节点又作为协调节点，并有一个专用的clustermanager节点。数据节点的实例类型为r52xlarge，clustermanager节点为r5xlarge，均以Amazon弹性块存储Amazon EBS类型GP3和大小100GB支援。

基准测试的设置如下：

基准测试运行在单个c54xlarge节点上大小足以避免客户端资源限制以GP3类型和500GB大小的EBS卷作为支援。客户端数量为16，批次大小为1024工作负载为nyctaxis

索引设置如下：

分片数：1副本数：0

结果

从实验中可见，zstd的压缩比优于Zlibbestcompression，在写入吞吐量上略有提升，并且其读取延迟与LZ4bestspeed相似。zstdnodict则提供了比LZ4bestspeed高出14的写入吞吐量，但压缩比率略低于Zlibbestcompression。

以下表格总结了基准测试的结果。

压缩算法压缩比写入吞吐量读取延迟Zlib (最佳压缩)最高N/AN/ALZ4 (最佳速度)N/AN/A最低Zstandard最优略高于LZ4与LZ4相同Zstandard无字典次优高于LZ4略低于Zlib

限制

尽管Zstd提供了压缩比和压缩速度的最佳平衡，但仍存在以下限制：

某些查询在检索所有匹配文档的整个存储字段时可能会观察到延迟增加。更多信息请参见更改索引编解码器。您无法将zstd和zstdnodict压缩编解码器用于kNN或安全分析索引。

结论

Zstandard压缩为存储大小和压缩速度提供了良好的平衡，并能根据用例调整压缩级别。Intel和OpenSearch Service团队合作引入Zstandard作为OpenSearch中的压缩算法之一。Intel通过设计和实现初始版本的压缩插件来做出贡献，该插件在OpenSearch v27中作为实验性功能发布。OpenSearch Service团队进一步改进了它，验证了性能结果，并将其整合进OpenSearch伺服器代码库，在OpenSearch v29中发布为常规可用功能。

如果你希望贡献OpenSearch，请创建一个GitHub问题并与我们分享你的想法。我们也希望了解您在OpenSearch Service中使用Zstandard的经验。欢迎在评论区提出更多问题。

关于作者

PraveenNischal 是一名云端软件工程师，并负责Intel的云端工作负载性能框架。

Mulugeta Mammo 是一名高级软件工程师，当前负责Intel的OpenSearch优化团队。

AkashShankaran 是Intel Xeon软件团队的软件架构师和技术负责人，专注于寻找新机会，并为数据服务如OpenSearch开启优化可能性。

SarthakAggarwal 是Amazon OpenSearch Service的软件工程师，主要对开源开发与索引和存储性能作贡献。

PrabhakarSithanandam 是Amazon OpenSearch Service的首席工程师，主要负责OpenSearch的可扩展性和性能方面。

载入评论中