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