乱序/回填数据写入的性能考量

提示

来自deepseek解释

原文链接：https://redis.io/docs/latest/develop/data-types/timeseries/out-of-order_performance_considerations/

当向时间序列中插入一个较旧的时间戳时，该新样本对应时间范围的内存块可能需要从主内存中检索（您可以在此处了解更多关于这些块的信息）。当该块是压缩块时，在插入或更新之前还需要对其进行解码。这些操作对内存消耗较大——而在解码情况下，对计算资源消耗也较大——这会影响整体可达到的写入速率。

写入性能对我们至关重要，这促使我们评估并透明地展示乱序/回填比例对我们整体高性能 TSDB 的影响。

为此，我们创建了一个 Go 基准测试客户端，使我们能够控制决定整体系统性能的关键因素，例如乱序比例、序列的压缩方式、使用的并发客户端数量以及命令流水线。有关完整的基准测试驱动配置详情和参数，请参阅此 GitHub 链接。

此外，所有基准测试变体均在 Amazon Web Services 实例上运行，这些实例通过我们的基准测试基础设施进行配置。基准测试客户端和数据库服务器均运行在独立的 c5.9xlarge 实例上。测试在单分片配置下执行，RedisTimeSeries 版本为 1.4。

下面您可以看到压缩块和非压缩块在可达到的 ops/sec 与乱序比例之间的相关性。

压缩块在乱序/回填下的影响分析

对于压缩块，由于单个乱序数据点意味着需要对整个块进行完整的双增量解压缩，因此在乱序写入时应预期更高的开销。

经验法则是，为了提高乱序压缩性能，应尽可能减小块大小。较小的块意味着双增量解压缩的计算量更少，因此整体影响更小，但代价是压缩比降低。

以下图表和表格说明了以下关键点：

• 如果数据库接收 1% 的乱序样本，且当前默认块大小为 4096 字节，则对写入速率的整体影响应为 10%。

• 在更高的乱序比例下，例如 5%、10% 甚至 25%，整体影响应为 ops/sec 下降 35% 至 75%。在这种乱序比例下，您确实应考虑减小块大小。

• 我们观察到，即使在 99% 的乱序写入下，可达到的 ops/sec 最高下降 95%。（同样，减小块大小可将影响减半。）

非压缩块在乱序/回填下的影响分析

从以下图表和表格可以看出，块大小不会影响乱序对写入的整体影响（这意味着如果块大小为 256 字节和块大小为 4096 字节，乱序写入的预期影响是相同的——正如预期那样）。 除此之外，我们可以观察到以下关键结论：

• 如果数据库接收 1% 的乱序样本，对写入速率的整体影响应该很低甚至无法测量。

• 在更高的乱序比例下，例如 5%、10% 甚至 25%，整体影响应为 ops/sec 下降 5% 至 19%。

• 我们观察到，即使在 99% 的乱序写入下，可达到的 ops/sec 最高下降 45%。