InfluxDB 一周年以及迈向 1.0 的道路

作者：Paul Dix / 产品
2014 年 9 月 26 日

我写这篇文章时正坐在东京的星巴克里。我在这里是因为 Shuhei Tanuma，GREE 的一名开发者，邀请我参加 GREE 技术活动，谈谈我们在 Golang 中开发 InfluxDB 的经验。Shuhei 也是在过去一年中向 InfluxDB 核心提交 pull request 的 47 位贡献者之一。他正在使用 InfluxDB 在 GREE（一家在东京证券交易所公开交易的移动社交游戏公司）存储服务器和应用程序性能数据。

很难想象这个项目在一年前还不存在。

现在一年过去了，我想借此机会回顾我们的历程，并展望我们为实现 InfluxDB 1.0 版本需要完成的工作。

转型的故事

InfluxDB 的起源可以追溯到第一次提交之前。在 2012 年秋季，Todd Persen 和我申请了 Y Combinator 的 W13 批次。我们被一个名为 Errplane 的实时指标和监控 SaaS 应用程序的项目录取。作为 YC 申请流程的一部分，您需要列出您可能想做的任何其他想法。我们唯一的另一个想法是“一个开源时间序列数据库”。

我们进入了 YC，并将所有时间都花在了 Errplane 上。之后，我们进行了种子轮融资，并继续在 Errplane 上工作，直到第一次 InfluxDB 提交。但是，在构建 Errplane 之前，我们必须构建类似 InfluxDB 的东西。Errplane API 的演变是直接引导我们走向 InfluxDB 的原因之一。

2012 年的第一个 Errplane 版本是基于用 Scala 编写的 Web 服务构建的，使用 Cassandra 存储指标和时间序列数据。这是 Cassandra 的常见用例，而且这也不是我第一次在其之上构建“时间序列数据库”。大约在 2012 年底，我们有了想要进行应用程序的本地部署的想法。我们认为我们需要一个更独立的架构，因此我们开始考虑用 Go 重写它。

Errplane API 的 2.0 版本是用 Go 编写的，使用 LevelDB 作为底层存储引擎（InfluxDB 依赖的两种技术）。

在接下来的 10 个月里，我们改进了 Errplane API 并推出了两个主要版本。在其原始设计中，API 由三个独立的服务组成。一个用于数据收集，带有发布-订阅机制，一个用于计数和聚合（如 StatsD），以及一个用于回答查询的服务。API 在某种程度上是 RESTful 的，可以存储指标和事件数据。

虽然我们认为 API 很酷，但 Errplane 作为一款产品并没有像我们希望的那样流行起来。我们知道还有很多工作要做，还有用户期望的功能，但我们的资源有限，并且试图同时承担太多事情。但是，确实有一些人为我们的服务付费，他们对我们所做的事情非常热情。因此，我们深入研究了他们如何使用该产品。事实证明，他们像使用时间序列数据库一样使用我们的 API。

开源时间序列数据库是一个贫民窟

在 2013 年夏末，我们开始考虑对我们的战略进行重大转变。时间序列数据库的角度看起来很有趣，因此我们查看了其他人在做什么。在闭源世界中，有无数的例子。事实上，几乎所有监控、APM、指标或分析公司都不得不从头开始推出自己的时间序列解决方案。其中大多数都作为 API 公开，客户可以在实际产品之外直接使用，但除了生产这些 API 的公司之外，很少有开发者使用它们。

在开源世界中，我们发现了 Graphite 和 OpenTSDB。虽然每个项目采取的方法略有不同，但两者都有一些很棒的功能。Graphite 看起来也拥有相当大的用户群，并且还在持续增长。

尽管 Graphite 很受欢迎，并且许多组织处理时间序列数据的需求不断增长，但这两个项目的推进程度都无法与其他开源项目（如 Cassandra、Riak、Mongo 或 Hadoop）相提并论。我与 Graphite 的用户交谈过，我听到的两个最常见的抱怨是安装起来很痛苦，而且扩展性不好。我交谈过的少数 OpenTSDB 用户抱怨必须运行 HBase 集群，而且很容易创建热点，从而降低性能。

我们开始认真考虑我们在 YC 申请中提出的开源时间序列数据库的想法。对我来说，最终的顿悟时刻是在 2013 年 9 月在柏林举行的 Monitorama 会议上。我报名参加了会议，甚至让 Errplane 赞助了该活动，以便我可以展示我们正在开发的新产品。我认为这可能是结识潜在客户的好地方。

但我发现，一半的与会者是监控、指标、DevOps 和服务器分析公司的员工和企业家。他们中的大多数人都有关于他们的指标 API 如何成为他们的关键知识产权的故事，他们花费了数年时间才开发出来。另一半的与会者是大型组织的开发者，他们正在从一系列开源工具中推出自己的 DevOps 堆栈。几乎所有人都使用一些 Web 服务代码在其他数据库之上或只是使用 Graphite 创建“时间序列数据库”。

当每个人都在重复相同的工作时，它就不是关键知识产权或差异化因素，而是一个进入壁垒。不仅如此，它还阻碍了该领域的创新，因为每个人都必须花费他们最初的一两年才能达到可以开始构建真正产品的程度。这就像在 1998 年建立一家网络公司。您必须花费数百万美元和一年的时间来构建基础设施、安装服务器并准备好一切，然后才能运行应用程序。监控和分析应用程序不应该这样。

如果这么多人有时间序列用例，那么似乎有机会创建一个标准的开放平台。因此，我从柏林回来，紧张地向 Todd 和 John 宣布，我认为我们应该启动开源项目。他们都担心做出如此剧烈的举动，但我们有一点回旋余地。我们认为我们可以在大约两个月内测试这个想法。我们必须做出选择，要么继续推动 Errplane 这块巨石上山，要么冒险尝试开源时间序列数据库是人们需要的，并且还有另一个参与者的空间。

InfluxDB 向世界宣布

我们决定吸取我们从 Errplane API 中吸取的一些教训，并启动一个新项目。我们在 InfluxDB 上工作了大约 4 周，但实际上没有告诉任何人，除了我们的投资者我们在做什么。在那之后，我认为我们已经取得了足够的进展，可以开始谈论它并获得一些关于 API 的反馈。我安排在 NYC Ruby Meetup 和 NY Open Statistical Programming Meetup 上发表演讲。关于该项目的消息传开了。O’Reilly 在他们的 Radar 博客上发布了一个链接。有人将文档站点发布到 Hacker News，并在首页停留了大部分时间。

从那时起，我收到了关于我们正在构建的东西的大量鼓励。我被邀请在 NY League of Professional Systems Administrators、Boston Ruby、Dropbox、Charlottesville 的一个由 Vivid Cortex 组织的聚会、SF Data Engineers、Pivtol Tech Talks、Square、Data Dog、CloudFlare、Monitorama、GREE、Paris Data Geeks 以及可能还有一些我忘记的其他地方发表演讲。我想在过去的 12 个月里，我已经做了大约 22 场关于 InfluxDB 的演讲。

幸运的是，我并不孤单。不断壮大的 InfluxDB 社区的成员也在世界各地发表演讲，包括 京都、悉尼、科隆和 都柏林。对 InfluxDB 的兴趣是压倒性的，这鼓励我们继续推进该项目。以下是关于该项目的一些有趣的统计数据。

• 在过去 24 小时内，报告运行的 InfluxDB 服务器超过 2,500 台
• Github 上超过 3,000 个 星标
• 47 位核心贡献者
• 外部贡献者为几乎所有语言编写了超过 17 个客户端库
• 4 个 InfluxDB 命令行界面（Node、Perl、Ruby 和 Go）

尽管 InfluxDB 作为一个开源项目还很年轻，但公司和其他开源项目正在勇往直前，将其部署到生产环境中，并将 Influx 集成到他们的堆栈中。一些更值得注意的例子包括 Heroku 为 dyno 构建指标仪表板、Gilt 构建监控堆栈、Dieter Plaetinick 在 Vimeo 工作以取代 Graphite、Google 的 cAdvisor 添加 InfluxDB 支持以及 OpenStack Monasca 项目添加 InfluxDB 支持。

迈向 1.0 的道路

由于对该项目的所有兴趣，我们收到了大量反馈。我们遇到了并修复了错误，并尽力帮助解决问题和功能请求。尽管已经有人在生产环境中运行 Influx，但 1.0 版本将使更多人对将 Influx 作为其堆栈的关键部分运行更有信心。以下是我们为实现这一目标将重点关注的一些优先事项

• 稳健且可扩展的集群实现
• Influx 生产集群上的 DevOps 工具，如热备份和节点替换
• 重新审视 API 以更紧密地匹配指标用例
• 采用一些正在出现的常见模式并将其构建到 API 中

基本上，我们专注于稳定性、生产用途，并确保 API 足够成熟，在一段时间内不会发生重大变化。我们已经开始了许多这项工作，我将在这里和邮件列表中写更多关于我们将对 API 进行的更改。

如果您是 InfluxDB 用户、粉丝，或者只是对我们正在做的事情感兴趣，请感谢您。这是令人难以置信的一年，未来 12 个月将会更好。我们将继续交付代码并努力使 Influx 成为基础设施的核心组成部分，让开发者感到高兴，并在构建任何类型的分析或监控产品时节省时间和精力。