优化时间序列应用程序的数据查询
原文作者：Katy Farmer
原文地址：https://dzone.com/articles/optimizing-data-queries-for-time-series-applicatio
现在在了解了时间序列数据是什么以及为什么要将它存储在时间序列数据库之后，我们已经遇到了新的挑战。像任何应用程序一样，我们希望确保我们的数据库查询是智能且高性能的，因此让我们来讨论如何避免一些常见的陷阱。
索引
索引是所有尝试优化的常用推荐和很少被理解的解决方案，适用于大多数数据库。无论您使用的时间序列数据库是基于Cassandra还是MySQL或其独特的体系结构，索引都会影响您的查询。实质上，索引是一个数据结构，它存储来自特定列的值，这意味着当我们通过索引字段进行搜索时，我们有一个方便的快捷方式来访问这些值。当我们通过未加索引的字段进行搜索时，我们必须发现找到该值的完整路径，没有任何捷径。搜索未加索引的字段就像不得不观看《魔戒》中 Frodo走过没有标记的中土世界：这需要很长时间。
虽然索引不是时间序列数据库唯一的，但我们必须记住索引是一个数据结构，如果索引列或字段过多，就会变得过大。一个太大的索引结构最终导致内存紧张和放慢进程，从而抵消其优势。这里的时间序列问题是没有关于哪些片段应该被索引的约定，所以我们需要随时注意我们的模式。
查询范围
当一个查询结果让我失望时，我通常跳入命令行。当我第一次发现时间序列数据库时，我就是这么做的。我跳入我的InfluxDB命令行工具并输入：
SELECT * FROM 'CPU'哈哈，仿佛我的整个人生从我眼前闪过，因为小批量用户数据的回忆让我眼前一亮。我的终端变成了犯罪电视节目中“黑客”显示的那种屏幕，如下图。
时间序列数据的一个显著特点是，它在更大的容量下更有价值——我们存储了数百万个点。使用* (all)运行查询可能会在数据库检索点时锁定数据库。
有几个选项可以限制您的查询，同时改善它。
- 使用时间范围。许多时间序列应用程序查询从一个窗口中汇总数据，因此您可以使用它来获得优势
- 添加一个子查询。这将通过添加参数来限制查询范围，并确保您只获得相关结果。
确定查询范围的关键是对其进行过滤：尽可能具体以避免应用程序，终端和头脑中的数据超载。
保留政策
在时间序列数据的世界里，数据点就像我的保鲜盒里的袋装沙拉：我可能会把它保留得比我应该的时间更长，但最终我需要把它扔掉。大量的数据点使得无限期地存储时间序列数据变得困难，并且即使磁盘空间允许大量数据，查询也必须运行在一个巨大的数据集中。
假设您忽略了我之前的一些建议，您需要运行一个没有时间窗口或子查询的查询。您可以通过设置进程来删除过期数据来控制数据量。这是另一篇文章，其后台依赖于您正在使用的数据库，但这是一个常见的时间序列问题，因此您的数据库选择的解决方案比比皆是。除过期数据，节省一些……时间。
基数
即使我们的查询是完美的，高基数会让我们放慢脚步。一列或一系列中唯一值的数量决定了基数。高基数意味着大量的唯一值。当我们想要跨越越来越多的属性组合查询时，基数往往会增加，这会导致数据库花费的时间：在一系列中找到合适的值，对这些值执行任何必要的功能（比如值的求和），重复每个相关的，独特的系列，然后根据查询要求进行组合。随着索引和基数的增长，运行查询的开销也会增加。
在列式数据库中，我们可以通过确保拥有更多点的序列更少而不是拥有更少点的序列来提高性能。时间序列中的压缩技术可以在长时间运行时效率更高，所以，如果我们想最大限度地利用数据库，我们需要遵循它的规则。
在建立在关系数据库上的时间序列数据库中，基数对索引的影响比其他任何事情都要多，所以我们需要关注索引的大小，以免它占用我们的资源。
结论
你在这里遇到了一些沉重的东西。请记住深呼吸，去一个快乐的地方处理所有的信息。
您的时间系列应用程序在效率和性能水平上应该表现出色 - 您可以实现这一目标。关注索引，查询范围，保留策略和基数可能无法解决您的所有问题，但是您对数据了解得越多，您就能够更好地处理查询。我们离成为时间序列大师又近了一步。