基数对数据摄取的影响 — 第 1 部分
作者：Ed Bernier / 产品, 开发者, 公司
2017 年 12 月 01 日
导航至
在 InfluxData 担任销售工程师期间，我有很多机会与客户交流他们如何使用 InfluxDB 和 TICK Stack 的其余部分。我们有大量大型客户在他们的 DevOps 领域中使用 InfluxDB Enterprise 进行指标收集、分析、可视化和告警，因此我们为这些客户进行了大量的横向扩展测试。在这些测试中，我们看到随着向 InfluxDB Enterprise 集群添加更多节点，横向扩展非常线性。我将在我的下一篇博客文章中讨论这一点。
在过去的 6 个月里，我看到越来越多的大型制造商、能源公司和公用事业公司找到我们，希望从他们的物联网设备收集指标。很多时候，他们与专门构建物联网解决方案的咨询公司合作，这些公司将 InfluxDB 引入解决方案，因为我们非常适合时间序列应用。
在这些物联网应用中，我注意到几件事：很多时候，需要在工厂本地运行 InfluxDB 实例，并在本地对他们监控的任何内容发出警报。在这些情况下，他们必须运行的设备相当轻量级，因此了解我们如何向下扩展与了解我们如何向上扩展同样重要。另一件事是，与要摄取的数据量相比，数据的基数可能相当大。因此，我想我应该做一些向下扩展测试，并衡量基数对写入吞吐量的影响。这就是这篇博客文章的内容。这是我正在进行的 InfluxDB Enterprise 性能测试系列的第一篇。如果您对此主题感兴趣，请继续关注。
设置
为了进行此测试，我将在 AWS 中使用我们构建的一些实用程序来轻松启动集群。如果您以前没有使用过 InfluxData 的 TICK Stack，您会惊讶于它的安装和设置有多么容易。事实上，我的同事 David Simmons 在另一篇文章中写了关于这个主题的内容，您可以在这里找到：在 5 分钟或更短的时间内从零到卓越。看看吧。
对于在 AWS 上运行 InfluxDB，我们发现针对内存密集型应用优化的 R4 类型的实例效果最佳。这些实例也使用 SSD 存储，建议在运行 InfluxDB 或 InfluxDB Enterprise 时用于您的数据、wal 和 hh 目录。
为了进行测试，我将在 AWS 上启动以下大小的集群
- （2 个）节点，具有 2 个内核和 15.25 GB 内存 (r4.large)
- （2 个）节点，具有 4 个内核和 30.5 GB 内存 (r4.xlarge)
- （2 个）节点，具有 8 个内核和 61 GB 内存 (r4.2xlarge)
- （2 个）节点，具有 16 个内核和 122 GB 内存 (r4.4xlarge)
我将使用具有以下基数的数据测试这些集群：10,000、100,000 和 1,000,000 个序列，以了解唯一序列的数量如何影响摄取速率和使用的堆。
在本系列的第二部分中，我还将横向扩展到 4、6、8 和 10 个节点集群，并增加基数，以展示 InfluxDB Enterprise 的水平扩展能力。
为了生成具有正确粒度的测试数据，我将使用我们的一位工程师开发的名为 inch 的实用程序，它代表 INflux benCHmarking（Influx 基准测试）。这是一个用于模拟流式数据以进行基准测试的绝佳实用程序。它用 Go 编写，可在 Github 上获得：https://github.com/influxdata/inch。如果您键入 inch –h，您将获得有关使用该实用程序的帮助。我在下面列出了选项
Usage of inch:
-b int
Batch size (default 5000)
-c int
Concurrency (default 1)
-consistency string
Write consistency (default any) (default "any")
-db string
Database to write to (default "stress")
-delay duration
Delay between writes
-dry
Dry run (maximum writer perf of inch on box)
-f int
Fields per point (default 1)
-host string
Host (default "http://localhost:8086")
-m int
Measurements (default 1)
-max-errors int
Terminate process if this many errors encountered
-p int
Points per series (default 100)
-password string
Host Password
-report-host string
Host to send metrics
-report-password string
Password Host to send metrics
-report-tags string
Comma separated k=v tags to report alongside metrics
-report-user string
User for Host to send metrics
-shard-duration string
Set shard duration (default 7d) (default "7d")
-t string
Tag cardinality (default "10,10,10")
-target-latency duration
If set inch will attempt to adapt write delay to meet target
-time duration
Time span to spread writes over
-user string
Host User
-v
Verbose使用 inch，我将从运行在 AWS m4.2xlarge 节点上的两个客户端节点生成数据，这些节点每个都有 8 个内核和 32 GB 内存。我将在每个客户端上运行 8 个流，总共 16 个并发写入器。
扩展到 32 个写入器时，性能差异很小，因此我决定不包括这些数字。
总之，我将在我的测试中使用以下常量
- （2 个）m4.2xlarge 节点，每个节点运行 8 个写入流
- 写入的批处理大小 = 10,000
- 一致性 = ANY
- 复制因子 = 2
- 每个序列要写入的点数 = 100000
测试
对于此测试，我仅使用提供高可用性的 2 节点集群，但由于我们在集群中的两个节点之间复制写入，因此我没有测试横向扩展。实际上，由于集群开销，此性能将略低于您在 InfluxDB 的单个节点上预期的性能。由于我们的大多数客户都想要高可用性，并且 InfluxDB 即使在较小的服务器上也能提供非常高的摄取率，因此这是我们常见的配置。
在 AWS 上启动集群后，我做的第一件事是创建我的数据库，复制因子为 2。我将我的数据库命名为“stress”，并使用 CLI 创建了它
influx -execute 'create database stress with replication 2'接下来，我登录到我的客户端节点并输入以下 inch 命令以开始为 10,000 个唯一序列测试生成我的工作负载
inch -v -c 8 -b 10000 -t 1,5000,1 -p 100000 -consistency any
inch -v -c 8 -b 10000 -t 1,1,5000 -p 100000 -consistency any现在让我解释一下上面 inch 命令的命令行选项。–v 告诉 inch 在运行时打印出详细的统计信息，这样我就可以看到已写入的点数、摄取率以及有关测试的其他详细信息。–c 告诉 inch 要并发运行多少个写入流。我每个运行 8 个，总共 16 个并发写入流。–b 允许我设置批处理大小。建议 InfluxDB 的批处理大小为 5,000 到 10,000，所以我选择了 10,000。–t 允许我定义数据的形状；换句话说，标签的数量以及为每个标签生成多少个唯一值。客户端 1 生成了 3 个标签，第二个标签具有 5000 个唯一值，客户端 2 生成了 3 个标签，第三个标签具有 5000 个唯一值，总共 10000 个唯一值。–p 指示每个序列要生成的点数，–consistency 选项允许我设置我的写入一致性，我将其设置为 any。
以下是生成的数据的示例
细节
以下是我的测试结果。正如您所看到的，当我在具有更多内核的系统上测试时，垂直扩展非常线性。此外，随着基数的增加，它肯定会对摄取率产生影响，我发现当首次创建新序列时，存在性能损失，但一旦创建所有序列，摄取性能就会稳定在您可以在下图中看到的速率。
我还包括了下面的详细数字
观察结果
我惊喜地发现，具有 2 个内核节点的集群可以处理如此多的数据，因为许多物联网用例在网络边缘的服务器尺寸最小，有时需要在那里进行一些本地存储、可视化和告警。
我也很高兴看到，随着内核的增加以及数据基数的增加，垂直扩展是多么的线性。此外，随着基数从 100,000 增加到 1,000,000，所需的内存量也增加了大约 10 倍，这再次非常可预测，这对于在 InfluxDB Enterprise 环境中进行容量规划很有好处。
下一步是什么？
请继续关注第 2 部分，我将在其中测试水平集群的横向扩展。
如果您还想查看 InfluxDB 与 OpenTSDB、ElasticSearch、Cassandra 或 Mongo 的比较基准测试，请查看已运行的这些其他基准测试。
