优化时间序列应用的数据查询
作者：Katy Farmer / 产品, 用例, 开发者
2018 年 3 月 21 日
导航至
既然我们了解了什么是时间序列数据以及为什么我们要将它存储在时间序列数据库中，我们就面临了一个新的挑战。与任何应用程序一样，我们希望确保我们的数据库查询智能且高性能，因此让我们讨论一下如何避免一些常见的陷阱。
索引
索引，通常被推荐但很少被理解的优化所有尝试的解决方案，适用于大多数数据库。无论您使用的时间序列数据库是构建在 Cassandra 还是 MySQL 之上，还是其自己独特的架构，索引都会影响您的查询。本质上，索引是一种数据结构，用于存储来自特定列的值，这意味着当我们按索引字段搜索时，我们有一个方便的快捷方式来获取值。当我们按未索引字段搜索时，我们必须发现值的完整路径，没有捷径或魔术。搜索未索引字段就像不得不观看弗罗多未经编辑地走遍中土世界一样——这需要很长时间。
虽然索引并非时间序列数据库所独有，但我们必须记住，如果我们索引的列或字段过多，索引是一种会变得过大的数据结构。索引结构太大最终会消耗内存并减慢进程，从而抵消其优势。这里的时间序列问题是，没有关于应该索引哪些部分的约定，因此我们需要始终了解我们的模式。
查询范围
当查询让我沮丧时，我通常会跳入命令行。我在那里很高兴。当我第一次发现时间序列数据库时，我就这样做了。我跳进了我的InfluxDB命令行工具并输入了
SELECT * FROM 'cpu'我的生活在我眼前闪过。少量用户数据的记忆让我热泪盈眶。我的终端变成了犯罪电视剧中“黑客”展示的那种屏幕。
时间序列数据的一个显着特点是，它的数据量越大，价值越高——我们存储数百万个数据点。使用 *（全部）运行查询可能会锁定您的数据库，因为它会检索数据点。
有一些选项可以限制您的查询，同时还可以改进它。
- 使用时间范围。许多时间序列应用程序查询聚合来自窗口的数据，因此利用这一优势。
- 添加子查询。这将通过添加参数来限制您的查询范围，并确保您只获得相关的结果。
限定查询范围的关键是过滤它们——尽可能具体，以避免应用程序、终端和您的大脑中的数据过载。
保留策略
在时间序列数据的世界中，数据点的老化就像我保鲜抽屉里的袋装沙拉：我可能会比应该的时间更久地保存它，但最终我需要扔掉它。大量的数据点使得无限期存储时间序列数据变得困难，即使磁盘空间允许存储大量数据，查询也必须通过庞大的数据集运行。
假设您忽略了我之前的一些建议，并且您需要运行一个没有时间窗口或子查询的查询。您只需设置流程删除过期数据即可控制数据量。这是另一个部分，其后勤取决于您使用的数据库，但这是一个常见的时间序列问题，因此互联网上有大量针对您选择的数据库的解决方案。删除过期数据，节省一些...时间。
基数
即使我们的查询是完美的，高基数也会减慢我们的速度。列或系列中唯一值的数量决定了基数——高基数意味着大量唯一值。当我们想要跨越来越多属性组合进行查询时，基数往往会增加，这会导致数据库花费时间：在系列中查找适当的值，对这些值执行任何必要的功能（即，对值求和），为每个相关的唯一系列重复，然后根据查询要求将它们组合起来。随着索引和基数的增长，运行查询的开销也会增加。
在列式数据库中，我们可以通过确保我们拥有更少系列和更多数据点，而不是更多系列和更少数据点来提高性能。时间序列中的压缩技术在长运行值上更有效率，因此如果我们想充分利用我们的数据库，我们需要遵循其规则。
在构建在关系数据库之上的时间序列数据库中，基数对索引的影响大于其他任何因素，因此我们需要密切关注索引的大小，以免它耗尽我们的资源。
结论
您在这里经历了一些沉重的东西。记住深呼吸，去一个快乐的地方处理所有信息。
您的时间序列应用程序应该在效率和性能水平方面表现出色——您可以实现它。关注索引、查询范围、保留策略和基数可能无法解决您的所有问题，但您对数据了解得越多，就越能更好地编写查询。我们离成为时间序列大师更近一步了。
