https://duckdb.org/2025/09/08/duckdb-on-the-framework-laptop-13.html
TL;DR:我们在配备 12 GB RAM 的 128 核超极本上测试了 DuckDB,运行高达 SF10,000 的 TPC-H 查询。
背景
当 DuckDB 的设计在 2018 年首次草拟时,一个关键的见解是笔记本电脑已经变得足够强大,可以处理数据科学家可以扔给它们的大多数分析工作负载。 这使得将新的分析数据库实现为可以在任何地方(包括笔记本电脑)运行的单节点系统成为一个可行的提议:进入 DuckDB。
2020 年,Apple Silicon 的发布为笔记本电脑上的 DuckDB 设置带来了巨大的性能提升。如今,现代 MacBook 拥有十几个内核的 CPU,以及大量内存和快速磁盘——所有这些都是 DuckDB 非常渴望使用的。然而,这是有代价的:在荷兰,配备 128 GB RAM 和 8 TB 磁盘的 MacBook Pro 将花费您超过 8,500 欧元。
与此同时,x86 土地也出现了重大飞跃。AMD 的 Ryzen AI 300 超薄移动处理器将于 2024 年发布,最多配备 12 个内核和 24 个线程。DuckDB 在 x86_64 架构上运行和在 arm64 处理器上运行一样乐意,因此我们渴望了解 DuckDB 在新 AMD 上的表现如何。
设置
为了进行这项实验,我们购买了 Framework 的 13 英寸模块化笔记本电脑,并为其配备了 128 GB 的 RAM 和 8 TB 的磁盘——所有这些都不到 3,000 欧元。
我们安装了 Omarchy 2.0,这是一个基于 Arch Linux 的发行版,拥有充满活力的社区和对 Framework 笔记本电脑的一流支持。组装笔记本电脑和安装 Omarchy 总共只用了不到一个小时。使用安装程序脚本安装 DuckDB 命令行客户端只需几秒钟:
<span style="color:#0d0d0d"><span style="background-color:#fafafa"><code><span style="color:#0098dd">curl </span>https://install.duckdb.org | <span style="color:#0098dd">sh</span>
</code></span></span>
我们将主题更改为大阪翡翠,以获得更像黑客帝国的外观,然后开始工作:

实验
为了了解这款笔记本电脑的性能,我们运行了一些基准测试,重点关注加载和查询处理时间。
CSV 加载
为了衡量 CSV 加载性能,我们使用了我们最喜欢的数据集之一:荷兰铁路服务。我们选择了过去 80 个月(2019 年 1 月至 2025 年 8 月)的完整数据集。我们可以按如下方式获取和解压缩文件:
<span style="color:#0d0d0d"><span style="background-color:#fafafa"><code><span style="color:#0098dd">wget </span>https://blobs.duckdb.org/nl-railway/railway-services-80-months.zip
<span style="color:#0098dd">unzip </span>railway-services-80-months.zip
</code></span></span>
生成的目录约为 20 GB。让我们看看 DuckDB 加载文件的速度有多快:
<span style="color:#0d0d0d"><span style="background-color:#fafafa"><code><span style="color:#0098dd">duckdb</span>
</code></span></span>
<span style="color:#0d0d0d"><span style="background-color:#fafafa"><code><span style="color:#976f4d">.timer</span> <span style="color:#383a42">on</span>
<span style="color:#0098dd">CREATE</span> <span style="color:#0098dd">TABLE</span> <span style="color:#383a42">services</span> <span style="color:#0098dd">AS</span> <span style="color:#0098dd">FROM</span> <span style="color:#c5a332">'services/services-*.csv.gz'</span><span style="color:#7a82da">;</span>
<span style="color:#a0a1a7">-- Run Time (s): real 10.219 user 217.596664 sys 7.348692</span>
</code></span></span>
事实证明,DuckDB 可以在短短 10.2 秒内将 20 GB 的 CSV 文件加载到内存中,速度为 1.96 GB/s!
TPC-H 基准测试
为了查看查询性能,我们使用了 TPC-H。 我们已经在各种 环境中运行了 TPC-H 查询,并且很好奇:DuckDB 可以在这台笔记本电脑上扩展多远?
数据生成
当然,我们首先需要一些大型 TPC-H 数据集,并且需要在本地生成它们——下载它们可能需要几天时间。 幸运的是,我们可以使用 tpchgen-rs 工具,这是 TPC-H 生成器的纯 Rust 实现,可以在短短几个小时内在笔记本电脑上生成大规模数据集。我们将数据生成为 Parquet 文件并将它们加载到 DuckDB 中。
3,000 瑞士法郎
我们首先在 SF3,000 数据集上运行了所有 22 个 TPC-H 查询,该数据集对应于 3 TB 的 CSV 文件。查询的总运行时间为 47.5 分钟,几何平均查询运行时间为 86.5 秒。
在实验过程中,我们注意到笔记本电脑底盖的温度升高到 45 摄氏度以上:虽然键盘仍然可用,但您绝对不想在运行数据处理工作负载时将这台机器放在腿上。显然,过多的热量还会导致一些热节流,导致 CPU 降频,从而使查询速度变慢。我们对此类问题并不陌生:去年,我们将 iPhone 16 浸入干冰中以提高其散热效果,但这对于笔记本电脑来说似乎不切实际,因此我们采取了更实际的措施。
对于我们的“酷运行”,我们只是在查询之间插入 5 分钟的睡眠时间,让笔记本电脑冷却下来。这非常有效:查询的总运行时间(不包括冷却期)降至 30.8 分钟,几何平均运行时间减少到 58.2 秒 - 加速了 32%!
大多数交互式数据科学工作负载的查询执行都穿插在编码和分析上所花费的时间,这为笔记本电脑提供了这样的冷却期。
SF3,000 电池
到目前为止,我们使用插入充电器的笔记本电脑进行了实验。但笔记本电脑毕竟是便携式设备,所以我们很好奇——我们能否在移动时对 SF3,000 数据集运行查询?
事实证明我们可以!在 SF3,000 数据集上运行所有 TPC-H 查询需要 46.9 分钟(几何平均值运行时间为 83.7 秒),并且将充满电的电池电量消耗到约 30%。 也就是说,如果您在笔记本电脑上分析 TB 大小的数据集,为了安全起见,您可能仍然需要携带移动电源。
TPC-H SF10,000
最后,是时候迎接我们的终极挑战了——这台笔记本电脑能否处理 SF10,000 数据集,对应于 10 TB 的 CSV 文件? 为了找出答案,我们:
- 生成的数据 – Parquet 文件中约 4 TB,
- 将文件加载到 DuckDB 中 – DuckDB 的文件格式约为 2.7 TB,
- 清理了 Parquet 文件——知道额外的空间稍后会派上用场,
- 运行查询 – 偶尔会看到 DuckDB 在磁盘上溢出 3.6 TB,
并最终看到他们毫无问题地完成了比赛!
运行总共花费了 4.2 小时,其几何平均查询运行时间为 6.6 分钟。
不出所料,这里也发生了一些热节流,因此我们在冷却期重复了实验。我们发现,这将总查询运行时间缩短到 3.8 小时,几何平均值运行时间为 5.7 分钟(加速 14%)。这意味着差异比 SF3,000 数据集要小,这是完全有道理的:鉴于查询运行时间更长,冷却期不再有太大影响。
结论
简而言之,我们发现您可以以不到 3,000 欧元的价格构建一台笔记本电脑,它可以以近 2 GB/秒的速度加载 CSV 文件,在电池上运行 SF3,000 上的全方位 TPC-H 查询,并完成 SF10,000 数据集上的所有查询。
虽然我们的运行不是官方的 TPC-H 运行,但值得一提的是,在当前经过审核的 SF10,000 TPC-H 实施排名中,能够执行 TPC-H SF10,000 的最便宜的设置的成本远远超过 100 万欧元或 120 万美元——我们的设置成本不到其中的 0.3%,并且可以完成 99% 的数据科学工作负载。
只是不要忘记时不时地暂停一下,让笔记本电脑稍微冷却一下。
附录
成本明细
以下是笔记本电脑使用欧元零售价(包括 21% 的荷兰增值税)的成本明细。这些物品于 2025 年 8 月购买。
| 项目 | 成本(欧元) |
|---|---|
| 框架笔记本电脑 13 DIY 版,配备 AMD Ryzen AI 9 HX 370 CPU | 1,785.00 |
| Framework 笔记本电脑 13 边框 – 半透明绿色 | 55.00 |
| 键盘 – 美式英语 | 109.00 |
| 电源适配器 – 60W – 欧盟 | 49.00 |
| HDMI(第 3 代)扩展卡 | 20.00 |
| USB-A 扩展卡 | 10.00 |
| USB-C 扩展卡 – 半透明绿色(2 张) | 20.00 |
| WD_BLACK SN850X NVMe 固态硬盘 8TB | 582.69 |
| Crucial 英睿达 DDR5 RAM 128GB 套件 | 327.87 |
| 总计(欧元,含增值税) | 2,974.87 |
请注意,Framework 目前仅销售 96 GB 内存套件,但主板和 CPU 都可以处理 128 GB(2 × 64 GB)套件。
文件系统配置
在我们最初的实验中,我们遇到了来自 dmesg 中的 btrfs 文件系统的间歇性校验和错误,表现为消息和崩溃。我们运行了广泛的磁盘和内存测试,结果表明没有问题,并且还尝试使用 btrfs 在 AWS EC2 云实例上重现错误,但我们无法观察到该问题。如果您深入了解此错误或有重现者,请通过打开问题告诉我们,我们很乐意向您发送一些 DuckDB 商品!BTRFS warning (device dm-0): csum failed ...
由于 DuckDB 的存储已经使用校验和,因此我们可以使用 NOCOW 属性禁用写入时复制和校验和,而不会冒数据损坏的风险:
<span style="color:#0d0d0d"><span style="background-color:#fafafa"><code><span style="color:#0098dd">sudo chattr</span> +C duckdb-tpch-experiment
<span style="color:#0098dd">lsattr</span> <span style="color:#23974a">-d</span> duckdb-tpch-experiment</code></span></span>
5174

被折叠的 条评论
为什么被折叠?



