在https://db-benchmarks.com/，我们测试了不同的开源数据库和搜索引擎，并开发了一个开源平台，因此您也可以这样做。在本文中，我想分享我们为自己制定的 10 条最重要的原则，这些原则可以帮助我们制定高质量的基准测试。
- 在完全相同的硬件上测试不同的数据库。在许多数据库基准测试中，我看到人们在不同硬件上对竞争对手进行基准测试。例如，在Druid vs Clickhouse vs Rocket基准测试他们说“我们实际上想在相同的硬件和 m5.8xlarge 上进行基准测试，但我们为 m5.8xlarge 提供的唯一预烘焙配置实际上是 m5d.8xlarge ……相反，我们在 c5.9xlarge 上运行实例”。坏消息，伙计们：当你在不同的硬件上运行基准测试时，至少你不能说某个东西是“106.76%”和“103.13%”的东西。即使您在同一台裸机服务器上进行测试，也很难获得低于 5% 的变异系数。不同服务器上 3% 的差异很可能被忽略。既然如此，怎么能确定最后的结论是正确的呢？
- 在每次测试前清除完整的操作系统缓存进行测试。在 DB Benchmarks，我们专注于延迟测试。我们确保今天、明天和一周内对某些数据库的某些查询需要 117 毫秒。这是平台中的基本内容，没有它，其他一切都不重要。这个很难（硬。要做到这一点，重要的是要确保在测试查询时环境与上次完全相同。人们总是忘记的一件事是清除操作系统缓存。如果您没有机会，您的查询必须从磁盘中读取的部分数据已经在内存中，这将使结果不稳定。
- 单独测量冷运行。磁盘，无论是 NVMe 还是 HDD，都仍然比 RAM 慢得多。做benchmark的人往往对它重视不够，而它却很重要，尤其是分析查询和分析型数据库可能经常出现冷查询。所以原则是：分别测量冷运行时间。否则，您将完全隐藏数据库如何处理 I/O 的结果。
- 正在测试的数据库应该禁用其所有内部缓存。另一个相关的事情是禁用内部数据库缓存。否则，您将只测量缓存性能，这可能对某些测试也有意义，但通常不是您想要的。
- 在测试期间不应该运行其他任何东西。否则，您的测试结果可能非常不稳定，因为您的数据库将不得不与另一个进程竞争。
- 您需要在每次查询之前重新启动数据库。否则，尽管清除了内部缓存，以前的查询仍然会影响当前查询的响应时间。
- 您需要等到数据库启动后完全预热。否则，您至少可以最终与 DB 的 I/O 预热过程竞争，这会严重破坏您的测试结果。
- 在固定的 CPU 频率上进行测试。否则，如果您使用“按需”CPU 调节器（通常是默认设置），它可以轻松地将您的 500 毫秒响应时间变成 1000 多毫秒。
- 在 SSD/NVME 而不是 HDD 上进行测试。否则，根据您的文件在 HDD 上的位置，您可以获得高达 2 倍的 I/O 性能（不开玩笑，2 倍），这至少会使您的冷查询结果出错。
- 最重要的是：更多的重复和对 CV 的控制。这可能是延迟基准测试中最常见的错误：人们运行查询 2-3 次，计算平均值，仅此而已。在大多数情况下，尝试几次是不够的，下次运行相同的查询时，您可能会得到 50% 的不同结果。
但是有一种方法可以改进和控制它：做更多的重复并控制变异系数。CV 是一个很好的指标，可以显示测试结果的稳定性。如果它高于 N%，则不能说一个数据库比另一个数据库快 N%。所以只要做足够多的重复，直到你的 CV 足够低（例如 3%）。如果您从未达到它，则意味着您没有按照上述原则尽力而为。
我希望这篇文章能帮助你提高你的基准。如果您想准备一些东西，请查看https://db-benchmarks.com/。它是 100% 免费和开源（包括非常原始的测试结果）的基准测试平台和框架，可以帮助您更轻松、更快地测试数据库和查询。
10-principles-of-proper-database-benchmarking
