作者： 数据源的 TiDB 学习之路原文来源：https://tidb.net/blog/6e7ad23c

注：本文翻译自 https://motherduck.com/blog/perf-is-not-enough/

数据库中的性能崇拜

从我家在西雅图到我们在旧金山的办公室，我需要花费大约 4.5 小时的时间。假设你建造了一架超音速飞机，其最高速度是普通波音 737-MAX 飞机（无论是否有额外的靠窗座位）的 10 倍。在考虑到你需要乘坐优步（Uber）去机场、在安检队伍中等待、登机、在停机坪滑行、起飞和降落、等待登机口、等待行李，以及我再乘坐优步去办公室之后，你会完成一些令人惊叹的工程壮举，但可能只节省了 20% 的整体旅行时间。这很不错，但我还是赶不上上午 10 点的会议。

数据库行业一直专注于制造更快的飞机。与此同时，安检队伍越来越长，行李也会丢失。如果你的数据存在于稍有问题的 CSV 文件中，或者你难以用 SQL 语言表述你想问的问题，那么理想的查询优化器也无济于事。

性能是我这样的数据库极客用来衡量自身重要性的最常见指标。与体育迷一样，我们往往选择自己支持的团队与其他团队竞争。如果你最喜欢的数据库赢得了基准测试 PK，那么你就可以在饮水机旁炫耀自己的权利了。你可以挥舞你的统计数据，这些数据得到了博客文章的支持，向任何愿意倾听的人证明你最喜欢的数据库是冠军。

总的来说，性能，尤其是通用基准测试，是选择数据库的一种糟糕方法。你最好还是根据易用性、生态系统、更新速度或它与你的工作流程的集成程度来做出决策。最好的情况下，性能只是完成某些任务所需时间的即时观点；然而，最坏的情况下，它会导致你优化错误的东西。

基准测试 PK 已结束

2019 年，GigaOm 发布了一份对比云数据仓库的基准测试报告。他们对三大主要云供应商以及 Snowflake 进行了 TPC-H 和 TPC-DS 测试。结果如何？Azure Data Warehouse 遥遥领先，其次是 Redshift。Snowflake 和 BigQuery 远远落后。

当时，我正在 BigQuery 工作，很多人都非常恐慌……我们怎么可能比 Azure 慢那么多？然而，测试结果与我们对用户的印象并不匹配。每当客户进行我们与 Azure 的对比评估时，他们最终都选择了 BigQuery。当时的市场结果与基准测试几乎相反：Snowflake 和 BigQuery 的销量最终远远超过了 Redshift，而 Redshift 的销量又远远超过了 Azure。

如果基准测试与客户的体验不符，那么要么是基准测试做错了，要么是基准测试测试的是错误的东西，要么是性能最终证明并不那么重要。我们做了很多调查，发现这并不是第一次出现这种情况；GigaOm 的工作人员在基准测试方面非常擅长，其方法也很可靠。他们运行的 TPC-H 和 TPC-DS 基准测试是行业标准，涵盖了一系列广泛的查询。这些基准测试也是我们自己在内部用来判断性能的标准，尽管有人可能会对数据量或其与真实工作负载的相关性提出质疑，但它们是目前最好的选择。

因此，如果基准测试能够很好地代表性能，而客户最终却大量购买在基准测试中表现不佳的系统，那么这就会让人相信，也许还有其他比性能更重要的因素。

什么是“快”？

在我从事云数据库工作的 15 年里，我注意到行业内存在一个反模式：构建数据库的人往往非常关注从某人点击“运行”按钮到结果准备就绪所需的时间。很容易理解为什么数据库从业者会只关注数据库服务器的时间，毕竟这是他们最有控制力的事情。但对用户来说，真正有影响的是完成任务所需的时间，这两者并不相同。

在 BigQuery 中，我们将 JDBC 驱动程序的构建外包给了一家专门构建数据库连接器的公司。如果你不熟悉 JDBC，这些驱动程序为程序员和商业智能工具提供了一个通用的接口，用于连接到数据库。当时，让一位知名专家来构建这些接口似乎是明智之举。

几年后，在收到众多客户投诉后，我们意识到 JDBC 驱动程序中的错误严重影响了性能。从我们的角度来看，查询运行得很快，只需一两秒。但是，驱动程序查询完成并拉取结果的方式使查询看起来像是花费了数秒甚至数分钟的时间。当查询结果很多时，这种影响更为严重，因为驱动程序通常会一次拉取一页结果，即使用户不需要查看所有结果。有时，它们甚至会因内存耗尽而崩溃。

我们投入了大量工程年数来使查询变快，从查询时间中节省了几分之一秒。但是，我们的大多数用户使用的连接器增加的延迟远超过我们节省的时间。更糟糕的是，我们对此一无所知。谷歌内部没有人使用 JDBC 驱动程序，虽然我们每晚都会运行完整的基准测试套件，但这些基准测试并没有反映用户所看到的端到端性能。

就像醉汉在路灯下找钥匙一样，我们只关注我们能够测量到的服务器性能。用户看到的查询时间对我们来说是不可见的，我们认为那是别人的问题。为了真正解决问题，而不仅仅是治标不治本，我们需要重新思考我们对性能的看法的方式。

性能是主观的

性能必须从用户的角度来衡量，而不是从数据库角度。这是一个用户体验问题，与任何用户体验问题一样，无法用单一数字来描述。这对很多人来说很意外，因为他们认为性能就像赛车一样，是客观的事物。仅仅因为你可以说一辆兰博基尼比一辆普锐斯快，他们就认为你也应该能够说“我的数据库比你的数据库快”。但就像兰博基尼在交通拥堵的情况下可能并不会比普锐斯（或自行车）更快地把我送到工作地点一样，数据库的实际工作负载将决定哪个更快。

主观性常常受到负面评价；人们将其与“无法判断哪个更好，所以选择哪个无所谓”的观点联系起来。但是，仅仅因为福特 F150 皮卡和特斯拉 Roadster 之间的差异是主观的，并不意味着我对两者的体验会是一样的。数据库也是如此；如果说 Clickhouse 和 Redshift 之间的性能差异是主观的，这并不意味着它们是等效的。只是说哪个更快取决于它们的使用方式。

几年前，Clickhouse 发布了 Clickbench 基准测试，该测试显示 Clickhouse 比他们测试的几十种数据库都快。这让我感到惊讶，因为当时我在 SingleStore 工作，我们相信我们的速度总体上比 Clickhouse 快。深入研究基准测试后，我们发现该基准测试没有进行任何 JOIN 操作，因此只在单个表中操作，并且大量依赖于计算不同项的数量。

尽管你可能会认为发布一个只进行单表扫描的基准测试很可疑，但 Clickbench 实际上在代表许多真实工作负载方面做得相当不错。如果你需要进行大量的日志分析并需要计算访问你网站的不同用户，这可能是一个很好的性能代理。然而，如果你正在使用星型模式运行更传统的数据仓库工作负载，那么 Clickbench 可能会产生误导。

供应商基准测试往往侧重于供应商擅长的方面。以下是一个来自“公平基准测试难以考虑”的图表，描述了典型的供应商基准测试结果。

数据库基准测试中存在许多陷阱，经验表明，基准测试通常无法很好地捕捉广泛的用户感知性能。例如，BigQuery 在基准测试中的表现非常糟糕，但许多人的实际体验是性能极佳。BigQuery 之所以给人留下了好印象，是因为它几乎没有需要调整的设置，而且很大程度上是自我调优的。一个经过高度调优的 SingleStore 实例在大多数任务上都会优于 BigQuery，但你有时间花费在调整你的模式上吗？当你添加新的工作负载时又会发生什么？

DuckDB 的网站曾有一个免责声明：“请不要抱怨性能问题，我们正在努力在追求速度之前确保正确性。”并非所有数据库都采用相同的方法。你可以通过移除安全气囊、牵引力控制、吸能区、排放控制等安全装备来提高汽车的速度。但是大多数人不想驾驶这样的汽车。数据库也是如此；你可以通过移除溢出检查、不刷新写入、为某些操作提供近似结果或不提供 ACID 保证来使它们更快。一些在这些基准测试中表现良好的系统采用了这种捷径，但除非在受控情况下，否则我不会想使用它们。

变化率

去年，当我决定在 DuckDB 的基础上创建一家公司时，许多人向我指出，如果你在谷歌上搜索 DuckDB 的性能，会出现一个基准测试结果，其中 DuckDB 的表现相当糟糕。难道我不担心吗？为什么不选择一个“更快”的数据库呢？

我对此并不担心，原因有两个。首先，我认为性能是次要的。但其次，DuckDB 展现出了让当前基准测试变得无关紧要的东西；它们的性能提升速度非常快。部分原因是某些架构决策，部分原因是代码库相对较新且干净，部分原因是涉及的工程师非常有才华，DuckDB 以惊人的速度不断进步。

事实证明，我不担心是对的。那份相同基准测试的最新发布结果显示，与最新的 DuckDB 版本相比，它们已经从中等水平跃升至遥遥领先。

更广泛的一点是，当你选择一个数据库时，它并不是在那个时间点就固定不变的。你可能会坚持自己的决定好几年。从现在到明年，甚至从现在到五年后，你的数据库的性能和功能都会发生很大的变化。

因此，一个非常重要的变量不仅仅是数据库现在能做什么，而是它在未来一年内将能够做什么。如果因为数据库中的一个 bug 而选择竞争对手，那么如果这个 bug 已经被修复，那么在几周后这似乎就是一个愚蠢的理由。性能也是如此；如果两个不同的数据库以不同的速度改进，那么你最好选择那个进步更快的数据库。未来的你会感谢现在的你。

没有魔法豆

如果你选择了一批积极维护的数据库，并让它们发展几年，性能将会趋同。如果 ClickHouse 现在应用了一种技术来提高扫描速度，Snowflake 很可能在一两年内就会拥有这项技术。如果 Snowflake 增加了增量物化视图，BigQuery 也会很快跟进。重要的性能差异不太可能长期存在。

尽管这些公司的工程师都非常聪明，但他们并没有任何魔法咒语或无法在其他地方复制的东西。每个数据库都使用不同的技巧组合以获得良好的性能。有的可能将查询编译成机器代码，有的可能将数据缓存在本地 SSD 上，还有的可能使用专用网络硬件进行混洗。只要给足时间，这些技术都可以被任何人实现。如果它们效果很好，那么很可能到处都会被使用。

Fivetran 公司的 CEO 乔治·弗雷泽尔（George Fraser）曾发表了一篇有趣的文章，比较了主要数据仓库供应商在不同时间点的性能。2020 年时，性能差异相当大，但到了 2022 年，它们就更为接近了。2020 年，最快的时间是 8 秒，最慢的是 18 秒，而到了 2022 年，三个供应商的时间都在 7 秒左右，最慢的是 9 秒。

当然，这条规则有一个例外，那就是架构差异很难克服。无共享数据库相对于共享磁盘数据库处于劣势，而 Redshift 也花费了多年时间才转向以共享磁盘为主的架构。依赖将元数据持久化到对象存储的 Lakehouses 在进行快速更新时会遇到困难；这是内置在模型中的。但是，这些类型的差异往往只体现在细微差别上；例如，从长远来看，没有根本的原因可以解释为什么 Redshift 会比 Snowflake 更快或更慢。

总的来说…

最成功的数据库公司并非仅仅因为比竞争对手更快而取得那样的成就。Redshift 曾经一度称霸，而 Snowflake 之所以能够进入市场，靠的是可维护性，而非基准测试的性能表现。那些将性能作为主要卖点的数据库在市场上的表现并不理想。而那些能够轻松完成工作的数据库则取得了更好的成绩。

总结如下：

• 没有魔法豆；抛开架构差异不谈，性能最终会趋同。

• 数据库引擎的演进速度各不相同；最终胜出的是那些快速迭代的数据库。

• 要警惕那些最关心性能的数据库供应商；这从长远来看会拖慢他们的步伐。

• 数据库性能没有单一的衡量指标；一个“快”的数据库可能在你的工作负载下表现糟糕。

• 数据库的重要特性在于你能够多快地从想法到答案，而不仅仅是查询到结果。

当然，更快的查询优于较慢的查询。但如果你正在选择数据库，最好确保你的决策是基于除原始速度之外的其他因素。