InfluxDB 存储引擎测试
作者：Philip O'Toole / 产品
2015 年 10 月 20 日
导航至
当您决定构建数据库时，您就给自己设定了一个特定的软件工程挑战。作为基础设施软件，它必须工作。如果人们要依靠您的系统来可靠地存储他们的数据，您需要确保它确实能做到这一点。
InfluxDB 以多种方式进行测试。我们使用 CircleCI 进行单元级测试以及一些基本的集成级测试。我们发现 CircleCI 易于使用、设计精良且响应迅速。但随着我们接近 1.0 版本，我们的测试变得更加复杂和彻底。
正确的软件显然至关重要——收到的每个数据点都必须被索引，并且每个查询都必须返回正确的结果。但是资源使用——CPU、磁盘 IO 和 RAM——同样重要。我们希望系统在运行时保持稳定，并且在测试期间监控资源使用情况可以标记问题。内存泄漏变得明显，过度的磁盘 IO 可能表明设计或实现欠佳。错误也可能被暴露出来——CPU 占用率过高可能表明代码中存在问题。因此，在这篇文章中，我们将讨论我们如何在被测系统上监控资源使用情况。
测试基础设施
我们的测试基础设施的高级视图如下所示。
在每个被测节点上，我们运行 collectd，配置为以 Graphite 格式 输出，以及 Telegraf。来自这些代理的数据随后被发送到另一个 InfluxDB 系统，我们专门运行该系统来存储来自我们测试系统的指标数据。这种设置实现了两个目标——它允许我们分析测试结果，并且意味着我们也在 dogfooding 我们自己的软件。
当 InfluxDB 系统处于负载状态时，我们记录整个测试运行期间主机机器的各种指标。最重要的是，我们记录磁盘 IO、内存使用率、CPU 负载以及 InfluxDB 进程的 常驻集大小。在测试期间和测试之后，结果会与团队共享，并在我们的 Grafana 仪表板的帮助下，我们研究结果以查找问题，并（希望！）确认我们的软件按预期工作。
测试 TSM1 引擎
我们最近开始测试 新的 tsm1 存储引擎。最近的一次测试运行了大约 8 个小时，涉及将数十亿个点写入单个 InfluxDB 节点，跨越数千个不同的系列。目标保留策略的持续时间也为 1 小时，因此我们也可以测试那些代码路径——因为旧数据将每小时删除一次，因为新数据正在被索引。Grafana 仪表板显示了完整测试运行的结果，如下所示。
存在一些有趣的特征。写入负载稳定，CPU 负载也是如此。磁盘使用率达到稳态，因为保留执行以大约与传入数据被索引的速度删除数据。磁盘使用率中的锯齿模式是 tsm1 引擎执行的压缩以及保留执行的混合。有趣的是，InfluxDB RSS 与磁盘使用率密切相关，这对我们来说是有道理的。该软件在磁盘上内存映射数据，因此随着磁盘上的数据被删除，内存使用率会下降。但从长远来看，内存使用率通常是稳定的，约为主机机器上物理 RAM 总量的 30%。这告诉我们，该软件没有任何可检测到的内存泄漏。（每个图表最左侧的短峰是中止的运行。）
相比之下，bz1 引擎以更不规则的方式消耗资源，如下所示。
测试环境
我们在多种系统上运行这种类型的测试——AWS EC2 实例、Digital Ocean droplet 和物理机器。物理机器是我们测试基础设施中特别重要的部分，因为它们允许我们专注于我们的软件——毕竟，除了我们的代码之外，测试运行之间没有任何变化。我们不必担心 嘈杂的邻居 或繁忙的网络——在物理硬件上运行允许我们排除所有因素，除了我们控制的因素。但是，当然，使用云环境进行测试非常重要，因为我们的许多用户在这样的环境中运行 InfluxDB 系统。
我们还使用 Ansible 进行测试系统部署和配置管理。
测试策略
我们最近开始构建 race-detection 启用的构建以及我们的 nightly builds。这使我们能够针对这些二进制文件运行测试套件，这有助于我们检测代码中的竞争条件。我们还区分了压力测试（将系统加载到极限直到它崩溃）与中高负载测试，我们希望后者可以运行数天而没有任何问题。我们将后一种测试称为“老化测试”。
未来计划
随着我们加强测试，我们还有更多的工作要做。单元测试和基本集成测试只能带您走这么远，运行持续数小时和数天的测试非常重要。其他关键功能（例如集群）仍处于 Beta 阶段，因此随着新功能上线，这些领域的测试将会增加。查询性能是另一个关键领域，在不久的将来将进行大量的工作和测试。
正如 Richard Feynman 曾经说过：“对于成功的技术，现实必须优先于公共关系，因为自然是无法愚弄的。” 我们的测试确保我们不会自欺欺人。
