InfluxDB 1.0 GA发布：回顾与展望
作者：Paul Dix / 产品，用例
2016年9月8日
导航至
今天，我们激动地宣布开源时间序列数据库 InfluxDB 1.0 的发布以及我们的商业产品 InfluxDB Enterprise，它支持高可用性部署和横向扩展集群以增加吞吐量。这使得今天成为我们公司历史上最大的一天。这个发布已经酝酿了近3年，在这个场合，我想回顾一下 项目的历史，让用户了解1.x版本将提供哪些兼容性保证，并讨论 InfluxDB的未来发展方向。
今天我们宣布发布的同时，全球有成千上万家组织正在使用InfluxDB。他们用它来监控自己的网络基础设施、安全、容器基础设施、太阳能板、农业、科学实验、用户分析、商业智能、家庭自动化以及无数其他特定用例。想了解更多关于大小公司如何使用InfluxDB来管理他们的时间序列数据，请访问我们的 客户评价页面，目前已有超过100家公司列出。 你的故事是什么？
为什么需要时间序列数据库？
2013年9月，Todd Persen、John Shahid和我正在开发Errplane，这是一个用于实时指标和监控的SaaS应用程序。我和Todd于2012年创立了这个公司，尽管通过2013年冬季Y Combinator的批次获得了优势，但它并没有像我们预期的那样运作。我们筹集了一笔适度的种子轮融资，所以并没有面临立即崩溃的危险，但我们并没有成功地获得真实客户的关注。
我们一直在思考2013年8月应该做什么，并计划在9月下旬的柏林Monitorama会议上展示另一个想法。这个会议是关于监控的，我想这将是一个寻找对新产品感兴趣受众的好地方。但我发现，并没有验证这个新产品，而是验证了我们长期以来一直在讨论的另一个想法：一个开源时间序列数据库。
这个想法的根源早于Errplane。2011年，我和John在一家计划实时追踪数十万金融工具的FinTech初创公司工作时相识。一开始，我们使用了一个名为OneTick的商业时间序列数据库。然而，它并不是用来追踪数十万个独特时间序列的，所以我们开始寻找替代方案。
在开源世界中，我们发现了OpenTSDB、Graphite、RRD，以及其他不多。这些项目都有局限性，不适合我们的用例。我们有一个具体的需求是存储不规则的时间序列。也就是说，由特定事件创建的序列，比如市场上的交易。因此，我们着手构建一个“时间序列数据库”，这是一个基于Cassandra构建的Scala网络服务集，并使用Redis进行一些实时索引。
后来，我在2012年为Errplane构建了最初的API时，使用了相同的技术。我两次解决了相同的问题，但却是针对两种完全不同的用例。在两次事件中，我不得不编写大量的后端代码，以使时间序列“正常工作”。
这是关于如何在现有技术下与时间序列数据打交道有多么困难的一次宝贵经验。因此，在2012年秋季，当我与Todd一起申请Y Combinator时，我们将“开源时间序列数据库”作为我们的备选方案，以防Errplane未能成功。
回到2013年9月的Monitorama，我与其他监控和服务器分析公司以及大型组织的DevOps工程师进行了交谈。我一次又一次听到的是，他们都希望解决如何在规模上存储和查询他们的时间序列数据的问题。他们都在重复发明相同的轮子。
这足以让我坚信，我们应该尝试开源时间序列数据库的想法，于是InfluxDB诞生了。它迅速获得了关注，所以我们决定完全专注于它。在2014年底，我们从Mayfield和Trinity那里筹集了810万美元的A轮融资，以加速项目发展。
在过去的三年间，我们学到了许多关于如何扩展时间序列数据的存储、构建用于时间序列工作负载的分布式系统，以及如何构建并创建一个可持续创新的开源公司的重要教训。
我们为时间序列数据编写了自己的开源存储引擎，称为TSM树。我们创建了一个名为InfluxDB Enterprise的商业产品，它为InfluxDB添加了高可用性和集群功能，使我们能够继续开发开源软件。我们还通过InfluxDB Cloud在AWS上提供可扩展的InfluxDB集群作为托管服务。
在过去的一年里，我们创建了两个新的开源项目。Telegraf，一个用于时间序列数据和度量标准的数据收集器，以及Kapacitor，一个用于时间序列数据处理、监控和警报的引擎。这些项目使InfluxData成为处理时间序列数据的开源平台，而不仅仅是InfluxDB提供的存储和查询功能。
最后，我们计划在今年晚些时候通过一个重新构想并完全开源的Chronograf版本来扩大我们的开源影响力。它不仅仅关于仪表板，而是关于监控容器、Kubernetes和Docker Swarm的开箱即用用户体验。如果您感兴趣并希望参与早期功能迭代，请联系我们。
1.x API 兼容性和稳定性
1.0 版本的一个重要方面是标志着我们API和存储格式的稳定。在过去三年中，我们进行了积极的迭代，经常在这个过程中破坏API。随着1.0的发布以及整个1.x系列版本的发布，我们致力于以下内容：
没有破坏性的HTTP API更改：在HTTP API方面，如果一个命令在1.0中工作，它将在所有1.x版本中不变地工作……但有一个例外。我们将向查询语言中添加关键词。如果您将所有标识符用双引号括起来，所有字符串字面量用单引号括起来，新关键词不会破坏您的查询。这通常被认为是最佳实践，因此应该遵循。对于遵循该指南的用户，查询和摄取API在所有1.x版本中将不会有破坏性更改。请注意，这不包括项目中的Go代码。InfluxDB中底层的Go API在1.x开发过程中可能会改变。用户应通过HTTP API访问InfluxDB。
存储引擎稳定性：TSM存储引擎的文件格式现在是版本1。虽然我们可能会在1.x版本中引入新版本的格式，但这些新版本将与旧版本并行运行。这意味着对于用户来说，在升级到1.x版本的另一个版本时不会有漫长的迁移。
增量更改：查询引擎在新版本中将进行增量更改。我们将引入新的查询函数和新功能到语言中，而不会破坏向后兼容性。我们可能会引入新的协议端点（如二进制格式）和行协议以及查询API的版本，以改善性能和/或功能，但它们必须与现有版本并行运行。现有版本将在整个1.x版本线中得到支持。
持续支持：我们将继续修复行协议、查询API和TSM存储格式的1.x版本中的错误。用户应预期升级到最新的1.x.x版本以修复错误，但这些版本将与1.0 API兼容，无需数据迁移。例如，如果用户正在运行1.1，并在1.2中发布了错误修复，他们应升级到1.2版本。在1.3发布之前，修补修复将进入1.2.x。由于所有未来的1.x版本都是前一个1.x版本的直接替代品，用户应升级到1.x线中的最新版本以获得所有错误修复。
接下来是什么？
我们为1.x系列版本带来了许多改进，我们已经开始了其中的一些。通常，您可以期待开源和商业版本将继续得到改进。作为一个项目，我们以迭代速度著称，我们打算保持这种速度。唯一的区别是，现在我们致力于维护API合同，就像您期望的语义版本控制（Semantic Versioning）一样。
我们正在努力解决数据库的“高基数”限制问题，使用户能够在不消耗无限内存的情况下，对数以亿计的系列在标签中进行索引。我们还正在开发智能规则，用于自动汇总和查询低精度数据，使从短期到数月或数年的可视化性能更加出色和敏捷。
我们还将添加查询语言功能，如跨多个测量值进行计算、通过不同的计算将系列结合起来、子查询、排名查询等。
关于InfluxDB的发布周期，我们将根据实际情况不断调整最佳策略。用户可以期待在出现任何严重错误时发布补丁更新到1.0版本。我们预计1.1版本将在2到3个月后发布。用户可以通过查看1.1里程碑已关闭和合并的内容来了解将包含哪些内容。我们不会承诺里程碑中所有开放的功能，因为我们更希望有一个可预测的发布时间表，但您可以了解正在开发中的内容。
经过3年的努力，InfluxDB 1.0是我从开始到结束参与的最大和最长的项目。我为我们所取得的成就感到无比自豪，并期待着未来即将到来的更多精彩功能和开发。这是一个令人兴奋的时间序列类别时代，感觉它才刚刚开始！
致贡献者
我想通过强调几位对帮助我们达到1.0版本起到关键作用的社区成员的贡献来结束这次讲话。
- John Shahid: 他与Todd和我一起开启了这一切，并在项目的前一年里不知疲倦地工作。
- Philip O'Toole: 他参与了整个0.9重写/重新设计，并帮助构建了TSM的初始版本。
- Paulo Pires: 在过去一年中进行了多次错误修复和功能开发。
- Kun Oiooj: 0.10中的修复、多个0.9版本以及即将在1.1版本中出现的功能
- Adarsha Mvadu: 对InfluxDB在Windows上运行进行了许多修复。
- Jon Seymour: 对TSM和其他方面的修复。
还有很多人我们应该表示感谢，但我们必须在某处结束。在过去三年中，我们有超过200位贡献者。感谢所有曾经修复错误、更新文档、编写功能或帮助我们达到现在位置的人。
接下来是什么
- 下载：1.0 GA 下载，TICK-stack的下载页面已上线
- 云上部署：通过InfluxDB Cloud的免费试用开始使用，该云服务包括完全管理的集群、Kapacitor和Grafana。
- 在您的服务器上部署：想在您的服务器上运行InfluxDB集群吗？试试免费的14天试用版InfluxDB Enterprise，它具有直观的用户界面，可以部署、监控和重新平衡集群，以及管理备份和恢复。
- 分享您的故事：超过100家公司分享了InfluxDB如何帮助他们成功的经验。提交您的评价并获得限量版InfluxDB卫衣作为感谢。
