Query Performance

查询性能对于任何数据库系统都是至关重要的。此页面列出了一些 OpenTSDB 常见问题以及提高性能的步骤。

Caching

目前，OpenTSDB 没有内置缓存(内置 GUI 会将 PNG 图像文件缓存 60 秒)。因此，我们依赖于基础数据库的缓存。在 HBase(最常见的 OpenTSDB 后端)中，有一个块高速缓存的概念，它将在写和/或读时将行和列的块存储在内存中。一个好的入门书是尼克·迪米达克(Nick Dimiduck)的块缓存 101。设置高速缓存的一种好方法是使用BucketCache并将 L1 高速缓存的大小设置得相当大，以使其充当写高速缓存并将大部分最新数据保留在内存中。然后，L2 缓存可以在用户运行查询时将经常查询的数据保留在内存中。

仔细观察您的区域服务器是否有 GC 暂停。用户通常在堆外模式下运行存储桶缓存，但是在 Java 和 JNI 之间进行序列化以处理堆外缓存命中和写入仍然要付出代价。

另外，请确保在 HBase 表上启用了压缩。使用表上指定的压缩算法将块存储在内存中，因此与未压缩的块相比，您可以在缓存中容纳更多的压缩块。

众多查询中的一项

如果您在某个查询中通常要在基数不同(即许多标记值)不同的 Metrics 中寻找一个或两个时间序列，请确保您使用的是 2.3 或更高版本并在查询中启用了explicitTags。该查询必须列出与您要查找的数据关联的所有标记键，但是它将在 HBase 上启用一个特殊的过滤器，这将有助于减少扫描的行数。有关详情，请参见Query Filters。

或者，如果在度量标准名称中放置高基数标记，则将大大减少查询时扫描的数据量并提高性能。有关更多信息，请参见Writing Data。

高基数查询

对于将多个时间序列聚合在一起的查询，提高性能的最佳方法是在启用盐化的情况下运行 OpenTSDB 2.2 或更高版本，并在 HBase 群集中运行多个区域服务器。这将并行执行查询，从每个区域服务器获取数据子集并合并结果。例如，对于单个区域服务器，查询可能需要 10 秒钟才能完成。将相同的数据写入 5 个区域服务器并加盐时，相同的查询大约需要 2 秒钟，这是最慢的区域服务器响应所花费的时间。合并这些集合通常是不重要的。

宽时 Span 查询

如果在 TSD 和使用应用程序(例如 UI 或 APIClient 端)之间发现了瓶颈，则对时间 Span 很长(例如几个月或几年)的查询可以从 dowmsampling 中受益。使用下采样器将减少由 TSD 序列化并发送给用户的数据量。

但是，如果瓶颈在存储(HBase)和 TSD 之间，那么最好的解决方案是开始使用 OpenTSDB 2.4 或更高版本写入汇总数据。这需要外部系统计算基于时间的汇总并将其写入存储。或者，UI 或 APIClient 端可以针对较小的时间 Span 对多个 TSD 执行多个查询，然后将结果合并在一起。将来，我们计划直接将此类功能添加到 TSD。

General Improvements

要考虑的其他事项：

多个读取的 TSD

运行多个专用于读取数据的 TSD，并在它们前面放置一个负载均衡器。这是在运行 OpenTSDB 时观察到的最常见的设置，并允许在不关闭整个系统的情况下轮流升级 TSD。

Tune Storage

HBase 有许多可以调整的参数，通常，大多数 OpenTSDB 的瓶颈来自 HBase。确保监视服务器，尤其是队列，缓存，响应时间，CPU 和 GC。

Educate Users

任何数据库系统都不能幸免长时间运行或占用资源的查询。要求用户以较小的时间范围(例如 1 小时)开始，然后逐渐增加其时间范围。还可以帮助用户了解基数以及如何要求high_cardinality_tag_key=*可能不是一个好主意。