无序/回填的摄入性能考虑¶

当一个较旧的时间戳插入到一个时间序列时，与新示例的时间框架相对应的内存块可能必须从主内存中检索(您可以阅读更多关于这些块的信息在这里)。当这个块是一个压缩块时，在插入/更新它之前，它也必须被解码。这些是内存密集型(在解码的情况下是计算密集型)操作，将影响总体可实现的摄入速率。

吸收性能对我们来说至关重要，这促使我们评估无序回填比例对我们整体高性能TSDB的影响并保持透明。

为此，我们创建了一个Go基准测试客户端，它使我们能够控制决定系统整体性能的关键因素，如无序比率、序列的压缩、使用的并发客户端数量和命令管道。有关完整的基准测试驱动程序配置细节和参数，请参阅此文档GitHub链接．

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

下面你可以看到压缩块和未压缩块的可实现操作/秒和无序比率之间的相关性。

压缩块无序/回填冲击分析¶

对于压缩的数据块，假设一个无序数据点意味着对整个数据块的双增量进行完整的解压缩，那么无序写操作将带来更高的开销。

根据经验，要提高无序压缩性能，就要尽可能地减少块大小。更小的块意味着双增量解压缩的计算量更少，因此整体影响更小，缺点是压缩比更小。

下面的图表说明了这些要点:

• 如果数据库接收到1%的无序样本(当前默认块大小为字节(4096))，则对摄取率的总体影响应该是10%。

• 在更大的无序百分比中，如5%，10%，甚至25%，总体影响应该在35%到75%的操作/秒之间。在这种无序百分比级别上，您应该真正考虑减少块大小。

• 我们观察到，即使在99%的误食情况下，可达到的ops/秒也会下降95%。(同样，减少块大小可以减少一半的影响。)

未压缩块无序/回填冲击分析¶

从下面的图表和表中可以看出，块大小并不影响摄入的总体无序影响(这意味着如果我的块大小为256字节，块大小为4096字节，那么无序摄入的预期影响是相同的——它应该是这样的)。除此之外，我们可以观察到以下主要结论:

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

• 在较高的无序百分比(如5%、10%甚至25%)下，整体影响应该会减少5%到19%的操作/秒。

• 我们观察到，即使在99%的误食情况下，可达到的ops/秒也会下降45%。