查询性能
查询性能对任何数据库系统都至关重要。此页面列出了一些常见的OpenTSDB问题以及提高性能的方法。
高速缓存
此时，OpenTSDB没有内置缓存（除了内置GUI，将缓存PNG图像文件60秒）。因此，我们依赖于底层数据库的缓存。在HBase（最常见的OpenTSDB后端）中，存在块高速缓存的概念，其将在写入和读取时在存储器中存储行和列的块。Nick Dimiduck‘s Block Cache 101是一个很好的入门读物。设置缓存的一个好方法是使用BucketCache，设置尽量大的L1缓存，以便它充当写缓存并将大部分最近的数据保存在内存中。然后，当用户运行查询时，L2缓存可以将经常查询的数据保存在内存中。
仔细观察region server的GC暂停时间。用户通常在堆外内存的模式运行bucket cache，但在Java和JNI之间访问堆外内存，进行序列化时仍然需要付出代价。
此外，请确保在HBase表上启用了压缩。块使用表中指定的压缩算法存储在内存中，因此您可以在缓存中容纳比未压缩更多的压缩块。
高于一切的查询
如果您通常在查询中查找具有不同的基数高（即许多标记值）的metric中的一个或两个时间序列，请确保使用版本2.3或更高版本，并且启用explicitTags。查询必须列出与要查找的数据相关联的所有tag key，它将在HBase上会启用特殊过滤器，这将有助于减少扫描的行数。
或者，如果在metric中放置高基数tag，这将大大减少在查询时扫描的数据量并提高性能。
高基数查询
对于将多个时间序列聚合在一起的查询，提高性能的最佳方法是使用OpenTSDB 2.2或更高版本，启用了salting，并在HBase集群中运行多个region server。这将并行执行查询，从每个region server获取查询结果子集并最终合并结果。例如，对于单个region server，查询可能需要10秒才能完成。当启用salting将相同数据写入5个region server时，相同的查询花费大约2秒，即最慢region server响应所花费的时间。合并结果所花费的时间通常无关紧要。
大时间跨度查询
对于大时间跨度的查询（一个月或者一年），如果性能的瓶颈在TSD和应用之间，那么采样会有效提高性能。使用下采样，将减少TSD发送给用户的数据量。
但是，如果瓶颈在存储（HBase）和TSD之间，那么最好的解决方案是使用OpenTSDB 2.4或更高版本，并启用写挂起。这需要外部系统来计算基于时间的汇总并将其写入存储。或者，UI或API客户端可以针对较小的时间跨度对多个TSD执行多个查询，并将结果合并在一起。在未来，我们计划直接向TSD添加此类功能。
一般改进
需要考虑的其他事项：
多个读TSD
运行专用于读取数据的多个TSD，并在其前面放置负载平衡器。这是运行OpenTSDB时最常见设置，允许在不关闭整个系统的情况下轮换TSD升级。
调整存储
HBase有许多可以调整的参数，一般来说，OpenTSDB的大部分瓶颈都来自HBase。确保监视服务器，尤其是队列，缓存，响应时间，CPU和GC。
教育用户
没有哪个数据库系统可以免受长时间运行或资源占用查询的影响。要求用户以较小的时间范围（例如1小时）开始，逐步增加其时间范围。还可以帮助用户理解高基数查询 high_cardinality_tag_key=*可能是一个坏主意。