主要观点总结
本文讲述了作者通过在一台2012年的MacBook Pro上运行DuckDB数据库进行基准测试的故事，展示了现代数据分析与分布式架构的变迁，以及数据处理的进步。文章还讨论了分布式数据库的需求和现状。
关键观点总结
关键观点1: DuckDB在老旧笔记本上的基准测试成功完成
作者使用一台2012年的Retina MacBook Pro成功完成了TPC-H基准测试，展示了现代数据处理能力的发展。
关键观点2: 分布式数据库的需求被质疑
文章通过对比现代笔记本与分布式数据库的性能，质疑了分布式数据库在大多数情况下的必要性，认为在许多场景下，单机处理大数据已成为可能。
关键观点3: 数据分析与存储的进步
文章讨论了从矢量化查询处理技术的出现到现在数据分析与存储技术的飞速发展，以及这种发展对分布式数据库行业的影响。
正文
：实际上早在 2008 年 MacBook Air 就已经是第一款可选配内置 SSD 的 MacBook，只可惜它没有 Pro 版那样强劲的 CPU 火力。
巧的是，我现在手头仍有这样一台笔记本放在
DuckDB Labs
[8]
办公室，我的孩子们平时来玩时，会用它来刷 Youtube 看动画片。那么，这台老古董还跑得动现代版本的 DuckDB 吗？它的性能和现代的 MacBook 相比如何？ 我们可以在 2012 年就迎来当今的数据革命吗？让我们一探究竟！
软件
首先来说说操作系统。为了让这次跨年代的对比更公平，我们特地把 Retina 本的系统
降级
到 OS X 10.8.5 “Mountain Lion”——这正是该笔记本上市几周后的 2012 年 7 月发布的操作系统版本。虽然这台 Retina 笔记本实际上可以运行 10.15 (Catalina)，但我们觉得要做真正的 2012 年对比，就该使用那个年代的操作系统。下面这张截图展示了当年的系统界面，我们这些上了年纪的人看了不禁有点感慨。
再来说 DuckDB 本身。在 DuckDB 团队，我们对可移植性和依赖有着近乎宗教般的坚持（更准确的说是 “
零依赖
”）。正因如此，要让 DuckDB 在古老的 Mountain Lion 上跑起来几乎不费吹灰之力：DuckDB 的预编译二进制默认兼容到 OS X 11.0 (Big Sur)，我们只需调整一个编译标志重新编译，就使 DuckDB 1.2.2 顺利运行在了 Mountain Lion 上。
我们本想尝试用 2012 年的老旧编译器来构建 DuckDB，无奈 C++11 在当年还太新，编译器对它的支持根本跟不上。话虽如此，生成的二进制运行良好——实际上，只要费些功夫绕过编译器的几个 bug，当年也是可以把它编译出来的。或者，我们大可以像
其他人那样
[9]
干脆直接手写汇编。
基准测试
但我们感兴趣的可不是什么 CPU 综合跑分，我们关注的是
SQL综合跑分
[10]
！为了检验这台老机器在严肃的数据处理任务下的表现，我们使用了如今已经有些老掉牙但依然常用的 TPC-H 基准测试，规模因子设为
1000
。这意味着其中两张主要表
lineitem
和
orders
分别包含约 60 亿和 15 亿行数据。将数据生成 DuckDB 数据库文件后，大约有 265 GB 大小。
根据
TPC 官网的审计结果
[11]
，可以看出在单机上跑如此规模的基准测试，似乎需要价值数十万美元的硬件设备。
我们将 22 个基准查询各跑了五遍，取中位数运行时间来降噪。（由于内存只有 16 GB，而数据库大小达到 256 GB，缓冲区几乎无法缓存多少输入数据，因此这些严格来说都算不上大家口中的 “热运行“。）
下面列出了每个查询的耗时（单位：秒）：
