简化 InfluxDB：分片和保留策略
作者：Margo Schaedel / 产品, 使用案例, 开发者
2018年6月5日
导航至
我最近做了一个关于 InfluxDB 和 Telegraf 入门的网络研讨会，在准备过程中，我悲哀地意识到，关于 InfluxDB 仍然有很多概念对我来说仍然很神秘。现在，如果你和我一样，数据库和数据存储并非自然而然。 （如果对你来说是自然的，回顾一下也无妨）。我原以为我对 InfluxDB 作为时间序列数据存储有了相当透彻的理解，但现在我发现它比表面看起来要复杂得多。巧合的是，InfluxDB 的内部运作机制对我们社区中的一些人来说也很神秘，因此有了这篇博文。在本指南（某种程度上）中，我们将尝试理解围绕 InfluxDB 的一些更神秘的概念——特别是关于保留策略、分片组和分片。我们将了解它们是什么以及它们是如何相互关联的。
在我们深入之前
如果您是时间序列数据库世界的新手，或者这是您第一次阅读关于 InfluxDB 的内容，您可能需要轻松阅读一些资料，以获得一些背景知识。这里有一些有用的资源可以帮助您快速入门
保留策略
让我们首先讨论保留策略。时间序列数据本质上会很快堆积起来，在旧数据不再有用后将其丢弃会很有帮助。保留策略提供了一种简单有效的方法来实现这一点。这相当于为您的数据设置了一个有效期。一旦数据“过期”，它将自动从数据库中删除，这种操作通常被称为保留策略执行。然而，当需要删除数据时，InfluxDB 不会一次只删除一个数据点；它会删除整个分片组。
分片组
分片组是分片的容器，而分片又包含实际的时间序列数据（稍后会详细介绍）。每个分片组都有一个对应的保留策略，并且单个分片组内的任何分片都遵循相同的保留策略。此外，每个分片组都有一个分片组持续时间，它决定了每个分片组跨越的时间窗口（时间间隔）。时间间隔可以在配置保留策略时指定。如果未指定任何内容，则分片组持续时间默认为 7 天。
分片
当我们想到典型的时间序列数据库时，存储和查询的时间序列数据的庞大数量值得采用另一种方法来对数据进行分类。这就是分片发挥作用的地方。分片是时间序列数据的理想容器。在 InfluxDB 中对数据进行分片可以实现高度可扩展的方法，以提高吞吐量和整体性能，特别是考虑到时间序列数据库中的数据很可能会随着时间推移而增长。
分片包含数据的时间块，并映射到基础存储引擎数据库。 InfluxDB 存储引擎称为 TSM 或时间结构合并树，与 LSM 树非常相似。 TSM 文件包含编码和压缩的时间序列数据，这些数据在分片中组织。
所有分片都属于单个分片组，并且它们的时间间隔都落在分片组的时间间隔内。每个分片组都有一个分片是非常可能的，就像我们在 InfluxDB 的开源版本中看到的那样，或者每个分片组有多个分片，这在多节点集群中经常发生。
回到保留策略 (RP)
让我们回到保留策略一会儿，更仔细地看看它们是如何组合在一起的。当您在 InfluxDB 中创建数据库时，您会自动为该数据库创建一个名为 autogen 的默认保留策略。如果您选择不修改默认策略，则该值设置为无限。在这种情况下，分片组持续时间将默认为 7 天。这意味着您的数据将存储在 1 周的时间窗口中。如果您的保留策略设置为 autogen（或无限），则数据实际上不会无限期存储 - 这只是意味着保留策略与分片组持续时间匹配，因此保留策略实际上被禁用了。另一方面，您可以将保留策略设置的最小时间为一小时。
另一种思考方式是，保留策略就像分片组的存储桶。一旦保留策略到期日生效，您将丢弃时间间隔未通过保留策略到期日的分片组。因此，即使时间流逝，您仍然可以使用相同数量的数据 - 它只是在时间上发生偏移。例如，如果我将保留策略设置为一年，我将始终拥有一年的数据（一旦我达到第一个年标记）。
如您所见，分片组（以及相关的分片）与保留策略密切相关；如果保留策略有数据，它将至少有一个分片组。每个数据点（这是一个测量值，由与特定时间点相关的任意数量的值和标签组成）都必须与数据库和保留策略相关联。这里重要的是要记住，一个数据库可以有多个保留策略，并且所有保留策略对于每个数据库都是唯一的。
OSS 与企业版
当我们开始查看 InfluxDB 企业版中的分片、分片组和保留策略与 InfluxDB 的开源版本相比时，事情变得有点复杂。如果我们使用的是开源版本，我们只有一个 InfluxDB 的单节点实例，这意味着我们不必担心复制我们的数据，因为该功能不可用。因此，分片组最终只有一个分片，实际上使它们成为同一事物（另一种思考方式是分片变得冗余）。这是因为您不需要将数据均匀地分布在多个节点上 - 您只有一个节点！当保留策略生效时，您将删除整个分片组。
另一方面，使用 InfluxDB 企业版，您可以拥有多个 InfluxDB 的节点实例。如果您想了解有关此集群功能的更多信息，我建议阅读这篇博客，其中介绍了基础知识。在一个集群中拥有多个节点是分片组存在的原因。我们需要一种方法将数据均匀地分布在多个节点上，同时仍然属于适当的数据库、保留策略和时间间隔。在企业版中，一个分片组可以（并且通常确实）包含一组共享相同时间跨度的分片。分片组中的每个分片都将包含不同的时间序列子集。
我们还看到复制因子在 InfluxDB 企业版中发挥作用。复制因子表示您要制作的数据副本数。您可以在数据库保留策略中指定复制因子。同一数据的两个副本不能最终出现在同一个分片组中。理想情况下，它们会位于单独的分片组和单独的节点上。这样，如果一个节点发生故障，您仍然可以在另一个节点上进行备份。
实际应用
为了帮助您理解，让我们通过一些示例来考虑所有这些
对于开源版本，请记住我们只有一个节点实例，因此一个分片组将只有一个分片，如下所示
Data Points
---------------
series_a t0
series_a t4
series_b t2
series_b t6
series_c t3
series_c t8
series_d t7
series_d t9
Shard Group Z (t0 - t10)
-------------
Shard 1 (series_a, series_b, series_c, series_d)从上面的简化示例中，您可以看到我们有一个分片组 (Z)，其时间跨度为 t0 到 t10，以及几个系列子集（a、b、c 和 d）。因为我们不必担心此处的分布（将数据均匀地分布在各个节点上），所以所有系列都包含在一个分片（分片 1）中。
对于企业版，我们可以有多个节点，因此事情变得有点复杂。例如，如果我们有一个双节点集群，复制因子为 1
Data Points
---------------
series_a t0
series_a t4
series_b t2
series_b t6
series_c t3
series_c t8
series_d t7
series_d t9
Shard Group Z (t0 - t10)
-------------
Shard 1 (series_a, series_c) (Node A)
Shard 2 (series_b, series_d) (Node B)您可以看到我们仍然有分片组 Z，其时间跨度为 t0 到 t10，但此分片组包含两个分片。由于复制因子仅为 1（即只有 1 个数据副本），因此分布优先，因此一半数据存储在节点 A 上，另一半数据存储在节点 B 上。这会将数据均匀地分布在两个节点上，并减少性能问题的可能性。但是，如果我们将复制因子增加到 2，则复制优先于分布，并且结果看起来与开源示例非常相似。见下文
Data Points
---------------
series_a t0
series_a t4
series_b t2
series_b t6
series_c t3
series_c t8
series_d t7
series_d t9
Shard Group Z (t0 - t10)
-------------
Shard 1 (series_a, series_b, series_c, series_d) (Node A, Node B)现在我们又回到了一个分片组 (Z) 内的一个分片，但由于复制因子，它存在于两个节点上。现在让我们将保留策略添加到组合中。
假设我们已将数据库全部设置为保留策略为 1 天（24 小时），并且我们的分片组持续时间设置为推荐的 1 小时时间间隔。如果这是 InfluxDB 的 OSS 版本，则分片组将包含一个分片。该分片将容纳 1 小时时间跨度的所有系列，类似于我们在第一个示例中看到的。
Shard Group Z (t0 - t60)
-------------
Shard 1 (series_a, series_b, series_c, series_d)当然，在一天中的每个小时，都会创建一个新的分片组，跨度为 60 分钟，并且分片组的数量将继续增加，直到我们达到第 25 小时（在完整的一天过去之后）。当保留策略被强制执行时，我们将看到初始分片组已超过到期点，因此整个分片组将被删除。这将每小时持续进行。因此，在任何给定时间，我们将精确地拥有 1 天的数据。
理解所有内容
总结
- 一个 InfluxDB 实例可以有一个或多个数据库。
- 这些数据库中的每一个都可以有一个或多个保留策略。
- 您可以在保留策略中指定保留间隔、分片组持续时间和复制因子。
- 每个保留策略可以有一个或多个分片组（只要有数据）。
- 每个分片组可以有一个或多个分片（OSS 版本始终为 1 个分片）。
- 分片包含实际数据。
我希望这篇文章有助于澄清一些事情，但如果您仍然感到困惑（相信我，我非常了解这种感觉），请在 Twitter 上联系我们 @influxDB 和 @mschae16，我们可以尝试回答您的所有问题。或者访问我们出色的社区网站，每个人都聚集在一起互相帮助进行调试，并理解神奇且时常神秘的 InfluxData 平台。
