基数对数据摄取的影响——第1部分
作者：Ed Bernier / 产品，开发者，公司
2017年12月01日
导航到
在我作为 InfluxData 销售工程师的角色中，我有机会与许多客户谈论他们如何使用 InfluxDB 和其他 TICK Stack。我们有很多客户使用 InfluxDB 企业版进行 DevOps 领域的指标收集、分析、可视化和警报，因此我们为这些客户做了大量的扩展测试。在这些测试中，我们看到随着我们向 InfluxDB 企业集群添加更多节点，扩展非常线性。我将在我的下一篇博客文章中谈论这一点。
在过去6个月中，我看到越来越多的大型制造商、能源公司和公用事业公司来我们这里收集其物联网设备的指标。很多时候，他们与专注于构建物联网解决方案的咨询公司合作，这些公司将 InfluxDB 带入解决方案，因为我们非常适合时序应用程序。
我在这些物联网应用程序中注意到的一些事情是，很多时候，需要一个本地运行的 InfluxDB 实例在工厂中本地警报他们正在监控的任何事物。在这种情况下，他们运行的设备相当轻量级，因此了解我们如何缩小规模与了解我们如何扩大规模一样重要。另一件事是，与要摄取的数据量相比，数据的基数可能相当大。因此，我想进行一些缩小规模测试，并测量基数对写入吞吐量的影响。这就是这篇博客文章的主题。这是关于 InfluxDB 企业版性能测试的一系列文章中的第一篇。所以如果你对这个话题感兴趣，请保持关注。
设置
为了进行这项测试，我将在 AWS 上启动一个集群，使用我们构建的一些实用工具使这个过程变得简单。如果你以前没有使用过 InfluxData 的 TICK Stack，你会惊讶于安装和设置有多容易。事实上，我的一个同事 David Simmons 写了另一篇关于这个话题的文章，你可以在这里找到5分钟或更少的时间从零开始变得出色。查看它。
我们发现，对于在 AWS 上运行 InfluxDB，R4 类型的实例（针对内存密集型应用程序进行了优化）效果最好。这些实例也使用 SSD 存储，这对于运行 InfluxDB 或 InfluxDB 企业版时的数据、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。这是一个用于模拟流数据以进行基准测试的强大工具。它用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 "https://127.0.0.1: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) 每个节点运行8个写入流的m4.2xlarge节点
- 写入批大小 = 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选项允许我设置我的写入一致性，我将其设置为任何。
以下是生成的数据的示例：
详细信息
以下是我测试的结果。如您所见，在具有更多核心的系统上进行垂直扩展时，效果非常线性。此外，随着基数增加，这无疑对摄取率产生了影响。我发现，在创建新序列时，性能会有所下降，但一旦所有序列都创建完成，摄取性能就会稳定到下图中所示的水平。
以下还包括了详细的数字
观察结果
我对具有2核心节点的集群可以处理多少数据感到非常高兴，因为许多物联网用例在网络的边缘有最小尺寸的服务器，有时需要一些本地存储、可视化和警报。
我还很高兴看到随着核心的增加和数据基数的增加，垂直扩展是如何线性增长的。此外，随着基数从100,000增加到1,000,000，所需的内存量也增加了约10倍，这同样是非常可预测的，在进行InfluxDB企业环境容量规划时是个好消息。
接下来是什么？
请关注第二部分，我将测试水平集群扩展。
如果您还想查看InfluxDB与OpenTSDB、ElasticSearch、Cassandra或Mongo的比较基准，请查看以下已运行的基准。
