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