集群、标签和 0.9.0 版本即将推出的增强功能

作者：Paul Dix / 产品
2014 年 12 月 08 日

导航至

我们一直在埋头开发 InfluxDB v0.9.0 一段时间了，我想向社区更新我们正在进行的工作以及即将发布的版本的目标。最初，它只是一个完全重写集群实现的版本，但现在已经变得更大了。我们不仅显著改进了 Influx 的集群功能，还添加了对标签的支持，清理了 API，重写了大量底层实现，更换了存储引擎，并迁移到纯 Go 代码库。

简而言之，这是自一年多前我们启动该项目以来，InfluxDB 的最大版本发布。请继续阅读以了解详细信息，或点击此处注册参与早期测试。

集群

0.9.0 版本具有新的集群设计。其核心是新的流式 Raft 实现，针对我们的用例进行了优化。机器集群将分为两种角色：代理节点和数据节点。代理节点代表流式 Raft 共识组。数据节点复制所有原始数据，并保持所有内容索引化以响应查询。

在最简单的高可用集群中，您将拥有三台服务器，所有服务器都充当代理节点和数据节点。在该设置中，如果您的复制因子为 3，您将能够承受单台服务器故障，并保持读取和写入都正常运行。

在更大的设置中，您将拥有 3-7 个专用代理节点，其余为数据节点。您拥有的代理节点数量受您希望能够在代理节点中承受的故障数量的影响。在具有 3 个代理节点的设置中，您可以承受 1 个代理节点故障，并且您的集群仍然可用于写入。拥有 5 个代理节点，您可以承受 2 个代理节点故障；拥有 7 个代理节点，您可以承受 3 个故障。

您可以承受的数据节点故障数量取决于您设置的复制因子。原始时间序列数据将在数据节点中的复制组之间进行拆分。因此，如果您有 10 个数据节点，复制因子为 2，则每个序列的副本将存在于集群中的 2 个数据节点上。

我们在此集群版本发布中的目标包括

  • 创建可以处理每秒 1-2 百万个值写入的集群
  • 让用户能够向集群添加服务器以扩展存储容量和负载（高达 2 百万的上限）
  • 让用户能够快速更换发生故障的服务器
  • 从服务器重启和临时中断中自动恢复


最大吞吐量 1-2 百万的上限仅适用于此版本。后续版本将解除该上限，并使整个系统在水平方向上扩展到该上限之上。

标签

在了解人们如何使用 InfluxDB 后，我们意识到人们期望字符串列作为标签。他们希望将关于其测量的元数据放入列中。因此，我们决定添加对标签的支持。

标签基本上就像索引列。每个名称和标签集都将是一个唯一的序列。您将能够动态地合并和连接这些序列。我们还将索引标签值，并添加新的查询类型来访问关于哪些序列具有哪些标签的信息。

向 InfluxDB 添加标签支持有两个主要目标：辅助发现，以及在数据库中拥有数百万个唯一序列时仍具有出色的性能。

关于发现，我们希望回答如下查询

  • 我的数据中心中有哪些主机？
  • 哪些主机正在运行 MySQL？
  • 这栋建筑物中有哪些传感器？
  • 我正在进行哪些测量？

在性能方面，当前的 InfluxDB 实际上可以存储数百万个唯一序列。棘手的部分在于，当您尝试将它们的模式合并在一起或仅列出它们的子组时。为了使这些操作快速，我们需要一个用于描述序列的元数据的索引结构，而这正是标签为我们提供的。

API 清理

0.9.0 版本将对 API 进行一些清理，其中一部分将是一些破坏性更改。其中一些是次要的，例如将一些 HTTP 端点移动到数据库下，而不是集群下。我想在这里专门讨论两个更改：保留策略和连续查询。

当前版本的 InfluxDB 具有一个名为Shard Spaces的功能。此功能的目的是让用户能够设置保留策略，以确定某些数据位将保留多长时间。这在当前版本中有效。不幸的是，许多用户发现它令人困惑，并且很容易进入不确定数据去向的状态。

这就是为什么在 0.9.0 版本的 Influx 中，Shard Spaces 将被移除，我们将拥有一个简单的更高级别的概念，即保留策略。每个数据库都将具有一个默认保留策略，数据将写入或从该策略中查询。在任何写入或查询时，用户都可以覆盖默认值，并指定要访问的保留策略。

这是从隐式分配到保留策略转变为更明确的方式。您仍然可以拥有高精度区域，并使连续查询从该高精度保留策略聚合和向下采样到更长期的保留策略中。

对连续查询的更新将包括一些内容。首先，我们将更改定义连续查询的语法。它看起来有点像您在 SQL 中定义触发器的方式。

第二部分是，连续查询现在将实际连续运行。以前，连续查询在每个时间间隔运行，用于上一段时间。这意味着，如果您的数据收集滞后，或者您正在加载历史数据，则不会将其包含在连续查询的输出中。0.9.0 版本将修复此问题。

存储引擎

在夏季，我写了关于我们使用不同存储引擎进行测试的文章。我们发布了 0.8.x 版本，支持 4 个引擎：LevelDB、RocksDB、HyperLevelDB 和 LMDB。结果发现，这带来的麻烦远大于其价值。我们在不同的存储引擎中发现了不同的错误，Influx 的构建过程变得更加困难和复杂，并且我们没有看到使用其中一个引擎比另一个引擎有任何实际的性能提升。

通过简单地重构我们自己的代码并针对单个存储引擎进行优化，我们可以获得更好的性能提升。这正是我们在 0.9.0 版本中所做的事情。我们正在转向 BoltDB 作为唯一支持的存储引擎。我们还移除了 Protobufs 作为数据库中数据的额外序列化层，这应该可以降低 CPU 消耗并提高查询性能。

这将使执行热数据库备份、将分片从一台服务器移动到另一台服务器以及利用操作系统缓存等操作更加容易（在某些情况下是可能的）。

另一个巨大的优势是，它将显著减少 InfluxDB 运行所需的打开文件数量。这可能是当前版本中错误报告的最大来源。人们无法提高他们的打开文件限制，并且当 Influx 达到该上限时，会发生糟糕的事情。这将使开箱即用的体验更好。

鉴于 BoltDB 基于针对读取优化的数据结构，它还应该使读取速度显著加快。但是，我们在单台服务器上的写入目标性能仍然至少为每秒 2 万个值（理想情况下，我们可以优化到该值的 2-5 倍）。

纯 #golang

在 0.9.0 版本中，我们已经移除了所有 C 和 C++ 代码。这意味着它是纯 Go 代码。这使得构建更加容易。我们还尝试重构整个代码库，使其更符合语言习惯。我们希望社区成员能够更轻松地为核心做出贡献。

纯 Go 代码库还意味着，为任何 Go 支持的操作系统或架构构建都将是微不足道的。这意味着 ARM 和 Windows 构建将很容易生成。我们可能不会自己发布它们，但任何人应该都能够在几秒钟内在他们选择的平台上进行构建。

测试

对于此版本，我们希望在发布实际的 0.9.0 版本之前进行认真的测试。我们已经安排了早期合作伙伴，他们将对 0.9.0 版本进行广泛的测试。我们将在 1 月份发布候选版本，目标是让尽可能多的人测试它们。一旦我们进行了包括负载、数据库大小和故障场景在内的重大压力测试，我们将发布正式的 0.9.0 版本。

如果您想参与早期测试并与我们密切合作，请发送电子邮件至 [email protected]。

迁移

有了所有这些新功能和一个新的存储引擎，用户将不得不将其数据从 0.8 迁移到 0.9。我们将提供一个工具来执行此操作，该工具能够在新服务器热写入时运行。

迁移工具将为您提供将字符串列转换为标签或将序列名称转换为标签的选项。如果使用后一个选项，它将假定您的序列名称遵循以下形式

<tagName>.<tagValue>.<tagName>.<tagValue>.<measurement>
# for example
az.us-west-1.host.serverA.cpu
# or any number of tags
building.2.temperature

您将能够指定分隔符是 . 还是其他字符，例如 _。

结论

我们对 0.9.0 版本的发布感到非常兴奋。它应该提高稳定性，降低内存消耗，显著加快查询速度，并使 InfluxDB 整体上更加稳固。通过此版本，我们正在为 InfluxDB 1.0 奠定基础。