索引编解码器
索引编解码器决定了索引存储字段的压缩方式以及它们在磁盘上的存储方式。索引编解码器由index.codec指定压缩算法的静态设置控制。该设置会影响索引分片大小和索引操作性能。
支持的编解码器
UDB-SX支持四种可用于压缩存储字段的编解码器。每种编解码器在压缩比（存储空间）和索引性能（速度）之间各有优劣:
default—此编解码器采用LZ4算法并配备预设字典，其侧重于性能而非压缩比。与best_compression相比，它在索引和搜索操作方面速度更快，但可能会导致索引/分片的大小更大。如果在索引设置中未提供任何编解码器，则将使用LZ4作为默认的压缩算法。best_compression—此编解码器使用 zlib 作为压缩的底层算法。它能够实现极高的压缩比，从而使得索引文件的大小更小。然而，这可能会在索引操作期间增加额外的 CPU 使用量，并可能因此导致较高的索引和搜索延迟。
UDB-SX 25.0.0.0版本开始，新增了两种基于Zstandard 压缩算法的编解码器。该算法在压缩比和速度之间取得了良好的平衡。
更改现有索引的编解码器设置可能比较困难（请参阅更改索引编解码器），因此在使用新的编解码器设置之前，在非生产环境中测试具有代表性的工作负载非常重要。
zstd– 此编解码器提供与编解码器相当的显著压缩，best_compression同时 CPU 使用率合理，并且与编解码器相比，索引和搜索性能有所提高default。zstd_no_dict—此编解码器与字典压缩功能类似zstd，但不具备此功能。与字典压缩功能相比，它能提供更快的索引和搜索速度，但zstd代价是索引大小略大。
对于zstd和zstd_no_dict编解码器，您可以选择在设置中指定压缩级别index.codec.compression_level。此设置接受 [1, 6] 范围内的整数。更高的压缩级别会带来更高的压缩比（更小的存储空间），但速度会有所降低（较慢的压缩和解压缩速度会导致更大的索引和搜索延迟）。
创建索引段时，它会使用当前索引编解码器进行压缩。如果更新索引编解码器，则更新后创建的任何段都将使用新的压缩算法。有关具体操作注意事项，请参阅索引操作的索引编解码器注意事项。
从UDB-SX早期版本开始，已提供硬件加速的压缩编解码器，支持多种DEFLATE压缩LZ4算法。这些硬件加速编解码器适用于运行 Linux 内核 3.10 及更高版本的最新第四代和第五代 Intel® 至强® 处理器。对于所有其他系统和平台，编解码器将使用相应平台的软件实现。
可以通过设置以下值之一来使用新的硬件加速编解码器index.codec：
qat_lz4（UDB-SX 25.0.0.0版本）：硬件加速LZ4qat_deflate（UDB-SX 25.0.0.0版本）：硬件加速DEFLATE
qat_deflate与相比，压缩比要好得多qat_lz4，压缩和解压缩速度略有下降。
该index.codec.compression_level设置可用于指定 和qat_lz4的压缩级别qat_deflate。
该index.codec.qatmode设置控制硬件加速器的行为，并使用以下值之一：
auto如果硬件加速失败，则算法切换到软件加速。hardware：保证仅使用硬件进行压缩。如果硬件不可用，则会抛出异常，直到硬件可用为止。
有关此index.codec.qatmode设置对快照的影响的信息，请参阅快照部分。
有关Intel 硬件加速的更多信息，请参阅Intel (R) QAT 加速器概述。
选择编解码器
索引编解码器的选择会影响存储索引数据所需的磁盘空间量。像 best_compression、zstd 和 zstd_no_dict 这样的编解码器能够实现更高的压缩比，从而生成更小的索引大小。相反，default 编解码器并不优先考虑压缩比，因此生成的索引大小更大，但比 best_compression 的搜索操作更快。
索引操作的索引编解码器考虑因素
以下的索引编码器相关考虑因素适用于各种索引操作。
写操作
每个索引都由多个分片组成，每个分片又进一步被划分为 Lucene 段。在索引写入过程中，会根据索引设置中指定的编码器创建新的段。如果您为某个索引更新编码器，那么新的段将使用新的编码器算法。
合并操作
在段合并过程中，UDB-SX会将较小的索引段合并为较大的段，以实现最佳的资源利用并提高性能。索引编解码器设置会影响合并操作的速度和效率。一个索引上发生的合并次数取决于段的大小，段的大小越小，合并的大小也就越小。如果您更新index.codec设置，新的合并操作在创建合并段时将使用新的编解码器。合并后的段将具有新编解码器的压缩特性。
分裂与收缩
[拆分 API]（{{site.url}}{{site.baseurl}}/api-reference/index-apis/split/）会将原始索引拆分为一个新的索引，在这个新索引中，每个原始主分片都会被拆分为两个或更多的主分片。收缩 API会将现有索引收缩为具有较少主分片的新索引。在拆分或收缩操作过程中，任何新创建的段都将使用最新的编码器设置。
快照
在创建快照时，索引编码器设置会影响快照的大小以及其创建所需的时间。如果索引的编码器发生更新，新创建的快照将采用最新的编码器设置。生成的快照大小将反映最新编码器设置的压缩特性。快照中包含的现有段将保持其原有的压缩特性。
当您将一个集群的快照中的索引恢复到另一个集群时，务必确认目标集群支持源快照中段落所使用的编解码器。例如，如果源快照包含zstd或zstd_no_dict编解码器的段落，那么您无法将该快照恢复到运行较旧 UDB-SX版本的集群中，因为该集群不支持这些编解码器。
对于UDB-SX 25.0.0.1 及更高版本中提供的硬件加速压缩编解码器，index.codec.qatmode 的值会影响快照和恢复操作的执行方式。如果该值为auto（默认值），那么快照和恢复操作将正常进行。然而，如果该值为hardware，则必须将其重置为auto，以便在缺乏硬件加速器的系统上使恢复过程成功完成。
在恢复过程中，您可以通过将 index.codec.qatmode 的值修改为以下内容来对其进行调整："index_settings": {"index.codec.qatmode": "auto"} 。
重新索引
当您从源索引执行重新索引操作时，目标索引中创建的新段将具有目标索引的编码器设置的属性。
索引汇总与转换操作
当一个索引聚合或转换任务完成时，目标索引中创建的段将具有在创建目标索引时指定的索引编码器的属性，而与源索引的编码器无关。如果目标索引是通过聚合任务动态创建的，那么目标索引的段将使用默认编码器。
更改索引编码器
无法更改已打开索引的编解码器设置。您可以先关闭索引，应用新的索引编解码器设置，然后再重新打开索引。此时，只有新的段才会使用新的编解码器进行写入。这需要暂时停止对索引的所有读写操作一小段时间以完成编解码器的更改，可能会导致段大小和压缩比率不一致。另外，您还可以将所有数据从源索引重新索引到具有不同编解码器设置的新索引中，不过这是一个非常耗费资源的操作。
性能调优与基准测试
根据您的具体使用场景，您可能需要尝试不同的索引编码器设置，以优化您的UDB-SX集群的性能。通过使用不同的编码器进行基准测试，并测量其对索引速度、搜索性能和资源利用率的影响，可以帮助您确定适用于您工作负载的最佳索引编码器设置。对于 zstd 和 zstd_no_dict 编码器，您还可以调整压缩级别，以确定适合您集群的最佳配置。
基准测试
以下表格对best_compression, zstd, 和 zstd_no_dict c编码器与“默认”编码器的性能进行了对比。测试使用了nyc_taxi(https://github.com/topics/nyc-taxi-dataset)数据集进行。结果以百分比变化的形式列出，加粗的结果表示性能有所提升。
| | best_compression | zstd | zstd_no_dict |
|:— |:— |:— |:— |
|写 | | |
|Median Latency |0% |0% |−1% |
|p90 Latency |3% |2% |−5% |
|Throughput |−2% |7% |14% |
|读 | | |
|Median Latency |0% |1% |0% |
|p90 Latency |1% |1% |−2% |
|磁盘 | | |
| Compression ratio |−34% |−35% |−30% |