技术译文 | 数据库只追求性能是不够的！

爱可生开源社区

发布于 2024-03-18 20:56:07

770

发布于 2024-03-18 20:56:07

文章被收录于专栏：爱可生开源社区爱可生开源社区

本文和封面来源：https://motherduck.com/，爱可生开源社区翻译。

本文约 4500 字，预计阅读需要 15 分钟。

1论数据库的性能崇拜

从我在西雅图的家到我们在旧金山的办公室大约需要 4.5 小时。假设您建造了一架高超音速飞机，其最高速度比普通波音 737-MAX 快 10 倍（无论是否有额外的防风靠窗座椅）。当你考虑乘 Uber 去机场、排队安检、登机、在停机坪上滑行、起飞和降落、等待登机口、等待行李以及乘优步去办公室之后，你就已经完成了一些惊人的壮举工程，但可能只缩短了 20% 的总行程时间。很好，但我仍然参加不上上午 10 点的会议。

数据库行业一直专注于制造更快的飞机。与此同时，安检队伍越来越长，行李也经常丢失。如果您的数据位于有点不稳定的 CSV 文件中，或者您想要提出的问题很难用 SQL 表述，那么可能理想的查询优化器也无法帮助您。

性能是像我这样的数据库迷用来衡量数据库的最常见指标，并且像体育迷一样，我们倾向于选择我们支持的球队来对抗其他球队。如果您最喜欢的数据库赢得了基准性能测试战争，那么您就有了在饮水机旁边吹牛的权利。您可以炫耀那些有博客文章统计支持的数据，向任何愿意倾听的人证明您最喜欢的数据库是冠军。

一般来说，根据性能（特别是通用基准测试）选择数据库是一个糟糕的方法。您最好根据易用性、生态系统、更新速度或其与工作流程的集成程度来做出决策。最好的情况是，性能是完成某些任务所需时间的时间点视图；然而，最坏的情况是，它会导致您针对错误的事情进行优化。

2基准大战结束

2019 年，GigaOm发布了比较云数据仓库的基准测试报告[1]。他们在三大云供应商以及 Snowflake 上运行 TPC-H 和 TPC-DS。结果？Azure 数据仓库是迄今为止最快的，其次是 Redshift。Snowflake 和 BigQuery 远远落后。

当时，我正在研究 BigQuery，很多人都吓坏了…… 我们怎么会比 Azure 慢那么多呢？然而，结果与我们从用户那里得到的印象并不相符。每次客户对我们与 Azure 进行正面评估时，他们最终都会选择 BigQuery。当时的市场结果几乎与基准相反：Snowflake 和 BigQuery 最终的销量比 Redshift 好得多，而 Redshift 的销量比 Azure 好得多。

如果基准测试与客户体验不匹配，那么要么基准测试做错了，基准测试测试了错误的东西，要么最终证明性能并不那么重要。我们进行了很多探索，这不是第一次。GigaOm 人员非常擅长运行基准测试，而且方法也很合理。他们运行的基准测试 TPC-H 和 TPC-DS 是行业标准，并且被广泛的引用。它们是我们自己在内部运行的基准，用于判断性能，虽然人们可能会对数据大小或其与现实世界工作负载的相关性提出异议，但它们是最好的测试报告。

因此，如果基准很好地体现了性能，而客户最终在很大程度上购买了在基准上表现不佳的系统，那么它会让您相信也许还有比性能更重要的事情。

3快意味着什么？

在我从事云数据库工作的 15 年中，我注意到整个行业的一种反智模式：构建数据库的人往往非常关注某人单击“运行”按钮和实际运行之间的时间。很容易理解为什么数据库人员只关注数据库服务器的相应时间；毕竟那是他们能掌控的范围。但真正对用户产生影响的是完成一项任务所需的时间，这两个时间这不是一回事。

在 BigQuery 中，我们将 JDBC 驱动程序的构建外包给了一家专门构建数据库连接器的公司。如果您不熟悉 JDBC，它们提供了程序员和商业智能工具用来连接数据库的通用接口。当时让一位知名专家构建界面是有意义的。

几年后，在无数客户投诉之后，我们意识到 JDBC 驱动程序中的错误正在影响性能。从我们的角度来看，查询运行得很快，只需一两秒。但是驱动程序轮询查询完成并提取结果的方式使得查询看起来花费了几秒钟甚至几分钟的时间。当存在大量查询结果时，这种影响会加剧，因为即使用户不需要查看所有结果，驱动程序通常也会一次一页地拉取所有结果。有时他们甚至会因为内存不足而崩溃。

我们的工程师花了很多年的时间来提高查询速度，将查询时间缩短了几分之一秒。但我们大多数用户使用的连接器增加的延迟就已经远远超过我们节省的延迟。更重要的是，我们对这个事实完全视而不见。Google 没有人真正使用 JDBC 驱动程序，虽然我们每天晚上都在运行着全套基准测试，但这些基准测试实际上并没有反映出我们的用户所看到的端到端性能。

就像醉汉在路灯下寻找钥匙一样，我们只关注我们可以在服务器上测量的性能。用户看到的查询时间对我们来说是不可见的，我们认为这是其他人的问题。要真正解决问题，而不仅仅是处理问题，需要我们重新构建对性能的看法。

4表现感受是主观的

性能必须从用户的角度而不是数据库的角度来衡量。这是一个用户体验问题，就像任何用户体验问题一样，不能用一个数字来描述。这让很多人感到惊讶，因为他们认为性能就像赛车一样是客观的事情。仅仅因为您可以说兰博基尼比普锐斯更快，他们相信您也应该能够说我的数据库比您的数据库更快。但就像兰博基尼可能无法让我比普锐斯（或自行车，如果有交通）更快地工作一样，数据库的实际工作负载将决定哪一个更快。

主观性受到了不好的批评；人们将其与这样的说法联系起来：“好吧，没有办法知道哪一个更好，所以我们选择哪一个并不重要。” 但仅仅因为福特 F150 皮卡和特斯拉 Roadster 之间的差异是主观的，并不意味着我对两者的体验是相同的。数据库也是同样的道理；如果我们说 Clickhouse 和 Redshift 之间的性能差异是主观的，并不意味着它们是等效的。这只是意味着哪一个更快取决于它们的使用方式。

几年前，Clickhouse 发布了 Clickbench[2]，该基准测试表明 Clickhouse 比他们测试的几十个数据库更快。这让我感到惊讶，因为当时我在 SingleStore 工作，我们相信我们的速度比 Clickhouse 快得多。在深入研究基准之后，我们发现该基准没有执行任何 JOIN，因此在单个表中进行操作，并且还严重依赖于对不同项目进行计数。

虽然您可能认为发布仅执行单表扫描的基准测试很俗气，但 Clickbench 实际上在代表许多实际工作负载方面做得相当好。如果您进行大量日志分析并需要计算网站的不同用户，这可能是性能的良好代理。也就是说，如果您使用星型模式运行更传统的数据仓库工作负载，Clickbench 将会产生误导。

供应商基准往往关注供应商做得好的事情。下图是来自“公平基准测试被认为很困难”[3] 的图表，描述了典型的供应商基准测试结果。

数据库基准测试存在大量陷阱，经验表明基准测试通常在捕获广泛的用户感知性能方面表现不佳。例如，BigQuery 在基准测试中表现得很差，但很多人的实际体验是性能很神奇。BigQuery 亲自表现得很好，因为它没有任何旋钮，并且在很大程度上是自我调整的。高度调优的 SingleStore 实例在大多数任务中都会压垮 BigQuery，但是您有时间花在调优架构上吗？当您添加新的工作负载时会发生什么？

DuckDB 网站曾经有一个免责声明，上面写着：“请不要抱怨性能，我们在努力提高速度之前会先关注正确性。” 并非所有数据库都采用相同的方法。你可以通过去掉安全气囊、牵引力控制、溃缩区、排放控制等安全装置来让汽车跑得更快。但大多数人不想这样驾驶汽车。数据库也不例外；如果删除溢出检查、不刷新写入、为某些操作提供近似结果或不提供 ACID 保证，则可以使它们更快。一些在这些基准测试中表现良好的系统应用了这些捷径，但除非在受控环境下，否则我不想使用它们。

5未来的变化

当您选择数据库时，该数据库在该时间点并没有冻结。您可能最终会坚持自己的决定数年。从现在到明年，数据库的性能和功能将会发生很大变化，从现在到五年后更是如此。

因此，一个非常重要的变量不仅是数据库现在可以做什么，还在于未来一年能够做什么。如果数据库中的错误导致您选择竞争对手，那么在短短几周内，如果该错误已被修复，那么这将看起来是一个愚蠢的原因。这对于性能来说也是如此。如果两个不同的数据库以不同的速度改进，那么您最好选择移动速度更快的数据库。未来的你会感谢你。

6没有魔法

如果你采用一堆数据库，所有这些数据库都得到积极维护，并迭代它们几年，性能将会趋于一致。如果 Clickhouse 正在应用一种能够使其在扫描速度方面具有优势的技术，那么 Snowflake 可能会在一两年内拥有这种优势。如果 Snowflake 添加增量物化视图，BigQuery 很快就会跟进。随着时间的推移，重要的性能差异不太可能持续存在。

尽管这些公司的工程师都很聪明，但他们都没有任何魔法或无法在其他地方复制的东西。每个数据库都使用不同的技巧来获得良好的性能。一种可能将查询编译为机器代码，另一种可能将数据缓存在本地 SSD 上，第三种可能使用专门的网络硬件进行洗牌。只要有时间，任何人都可以实施所有这些技术。如果它们运作良好，它们可能会出现在任何地方。

Fivetran 的首席执行官 George Fraser 发表了一篇有趣的文章[4]，比较了主要数据仓库供应商随时间的表现；虽然 2020 年的分散程度相当大，但到 2022 年，它们会更加紧密地聚集在一起。2020 年最快 8 秒，最慢 18 秒，2022年有 3 家厂商在 7 秒左右，最慢 9 秒。

当然，这条规则需要注意的是，架构差异很难克服。与共享磁盘相比，无共享数据库处于劣势，Redshift 花了很多年才切换到主要共享磁盘架构。依赖于将元数据持久保存到对象存储的 Lakehouse 将很难快速更新；这是内置于模型中的。但这些类型的差异往往会体现在利润率上。例如，从长远来看，Redshift 没有比 Snowflake 更快或更慢的根本原因。

7问题出在椅子和键盘之间以及键盘和数据库之间

对于用户来说，衡量性能的重要指标是他们提出问题和得到答案之间的时间；这可能与数据库运行查询所花费的时间有很大不同。

如果你退后一步，从他们的角度思考，你可以使用更多的手段来实现最大限度地缩短问题提出和回答之间的时间的目标。您可以更轻松地提出问题。您可以更轻松地将查询结果转换为他们可以理解的内容。当他们没有提出正确的问题时，您可以帮助他们获得反馈。您可以帮助他们了解数据何时出现问题。您可以帮助他们在正确的位置以正确的形式获取所需的数据，以便能够首先提出问题。虽然这些通常不被认为是性能问题，但与更好的查询计划相比，改进可以在更大程度上加快分析师和数据工程师的工作流程。

Snowflake 在使编写查询变得更容易方面做得非常出色。尽管许多 SQL 方言都坚持语法一致，并且应该有“一种方法”来完成所有事情，但 Snowflake 设计者的目标是让用户键入的 SQL “正常工作”。例如，在 Snowflake SQL 中，如果要计算两个日期之间的差异，可以使用 DATEDIFF 或 TIMEDIFF；两者都适用于任何合理的类型。您可以指定粒度，也可以不指定。您可以围绕粒度使用引号，也可以不使用引号。因此，如果您只是输入查询，只要可以收集意图，它就应该“正常工作”。这是分析师喜欢 Snowflake 的原因之一，因为他们不必花时间在文档中查找内容。

数据并不总是采用方便查询的格式。世界上大量的数据都存储在 CSV 文件中，其中许多文件的结构很差。尽管如此，大多数数据库供应商并没有认真对待它们。在 BigQuery 中，我编写了第一个 CSV 拆分器，当发现它是一个比预期更棘手的问题时，我们派了一位新的研究生工程师来解决这个问题。它从来都不是很好，无法进行推理，并且如果不同的文件具有稍微不同的模式，就会感到困惑。事实证明，CSV 解析实际上很困难。

如果使用两个不同数据库的两名工程师需要读取 CSV 数据并计算结果，则能够最轻松地正确提取 CSV 文件的工程师可能会第一个得到答案，无论他们的数据库执行查询的速度有多快。因此，CSV 文件推断可以被视为一项性能功能。

数据库处理结果的方式对用户体验有着巨大的影响。例如，很多时候人们运行“SELECT *”查询来尝试了解表中的内容。根据数据库系统的架构方式，此查询可以是瞬时的（返回第一页和游标，如 MySQL），对于大型表可能需要数小时（如果必须在服务器端复制表，如 BigQuery）），或者可能会耗尽内存（如果它尝试将所有数据拉入客户端）。客户端是否与服务器有长时间运行的连接，这可能会出现网络中断的问题？或者它们进行轮询，这可能意味着查询可以在轮询周期之间完成，并使查询显得更慢？