InfluxDB和Kapacitor：增强的数据模型和功能查询语言
作者：Paul Dix / 产品
2017年7月12日
导航至
InfluxDB当前的数据模型，包括度量、标签和字段，是我们于2014年底做出的重大变更。自从2013年11月项目初始引入以来，查询语言基本上保持不变。它看起来有点像SQL，但我们增加了一些语法糖来简化某些操作。基于过去三年中与系统的新用户和高级用户合作所学到的经验，我们将在未来几个月内做一些重大补充。这些变更将作为未来1.x版本的InfluxDB和Kapacitor的附加功能发布，简而言之，我们将简化数据模型，并发布一个新的功能查询语言，该语言可以在InfluxDB和Kapacitor中使用。需要注意的是，我们将继续支持SQL风格的InfluxQL。这些变更将是附加性的。继续阅读以了解这些新方法背后的历史和思考。或跳转到请求合并，以查看关于新查询语言的一些初步想法和概念。
funcA(
argOne: "some thing",
argTwo: ['foo', 'bar'])
.funcB(
arg: /some regex/)
.funcC(
arg: `here "is a" string`)这个提议最具争议的部分是新的查询语言看起来并不像SQL。它看起来更像JQuery或D3中常见的JavaScript风格函数链式语法。在过去4年中，我与用户和时序数据合作，坚信函数风格更适合时序数据的问题领域。事实上，在2014年秋季，当我考虑将数据模型更改为度量、标签和字段时，我也在考虑将查询语言更改为功能性的语言。从社区收到的反馈基本各占一半。一半用户喜欢函数语言的想法，另一半则坚持认为SQL风格让项目变得出色。
然而，我认为许多用户并没有最终编写查询。或者如果他们确实编写了查询，也只是在CLI中进行一些基本任务。大多数用户在Grafana或Chronograf中构建仪表板的查询。我认为，有了合适的语言和用户界面，函数风格的查询接口将赋予我们更多功能和灵活性，同时仍保持InfluxDB易于使用。易用性始终是我们的最高优先级（尽管我们并不总能实现）。我从R的Tidyverse和Python的Pandas等工具中汲取灵感。它们具有清晰的概念，非常适合数据处理。随着时间的推移，我希望在新的查询语言中实现许多分析函数。
我们的目标是将其作为新的端点推出InfluxDB 1.x和Kapacitor 1.x系列。用户将能够同时使用新旧查询语言。我们将发布的初始原型实现将不会在API或查询语言上锁定。我们希望与社区中的成员合作，确保新查询语言在构建应用程序和用户界面时具有意义。一旦我们经过一段时间的迭代并确认它对社区来说是一个真正的胜利，我们将锁定API并将其作为官方支持的版本发布。
我们还将实施一个具有自动补全功能的命令行界面（CLI）和帮助用户构建查询的用户界面（UI）。理想情况下，新用户甚至不需要编写查询。他们只需将网络浏览器指向Chronograf，就可以通过点击来探索和可视化他们的数据。对于想要编写查询的用户，我们将通过自动补全、帮助、详细的文档和示例来使事情变得更加容易。
我们对平台这个新方向感到非常兴奋。我们的重点不仅在于数据库，而且在于整个平台，包括存储、查询、监控、处理以及围绕时间序列数据构建应用程序。我们非常期待您对InfluxQL 2.0拉取请求的反馈。
