DuckDB 嵌入式分析数据库版本演进指南
项目地址: https://gitcode.com/GitHub_Trending/du/duckdb 这篇文章带你基于 DuckDB 的开源仓库本身，梳理它的版本演进：从 2019 年的第一个可用版本到 2026 年的 v1.5 系列，每个阶段解决了什么问题、现在该用哪个版本、以及升级前要注意什么。DuckDB 的定位一句话就能说清：一个跑在你进程里的分析型 SQL 数据库（README.md 称之为 "an analytical in-process SQL database management system"），不靠独立的数据库服务器，直接把数据文件变成表来查。
版本总览：先记住这张表
仓库里没有 CHANGELOG 文件，以下信息全部来自 git 标签日期、README.md 与目录结构，可逐条核对：
| 版本阶段 | 大致时间（git tag） | 解决的问题 | 代表能力 |
|---|---|---|---|
| v0.1 | 2019-06 | 从 0 到 1，先把 SQL 引擎跑起来 | 进程内执行、基础列存查询 |
| v0.3 | 2021-10 | 速度不够用 | 并行执行框架成型（src/parallel/） |
| v0.7 | 2023-02 | 向 1.0 收敛 | 复杂类型与优化器趋于完整 |
| v1.0 | 2024-05 | 承诺稳定，敢上生产 | 完整 SQL 方言 + 扩展体系 |
| v1.1–v1.5 | 2024-09 ~ 2026-03 | 持续迭代、修得快 | 约每季度一个次版本，最新到 v1.5.5 |
能跑起来：把文件直接当表查
v0.1.0 的 tag 日期是 2019 年 6 月 27 日，这是仓库里最早的可用版本。它确立了两件到今天都没变的事：一是"嵌入式"，二是 SQL 优先。
README.md 里最能代表这个设计哲学的用法是这一句：
SELECT * FROM 'myfile.csv';
Parquet 文件同理。你不需要先建表、导数据、配驱动，一个 FROM 直接把本地文件变成关系表。它意味着：分析流程里最烦的"先把数据弄进来"这一步被压缩到一行 SQL，原型和正式脚本用的是同一种语法。
到 v1.0 之前，SQL 方言已经补得相当完整：任意嵌套的相关子查询、窗口函数、排序规则（collation），以及数组、结构体、Map 这些复杂类型。README 还专门提到 "Friendly SQL" 方言——比如 FROM ... SELECT ... 这种把表放句首的写法，让写查询更像填表格。
🚀 跑得更快：并行流水线与按批次处理
分析数据库的命门是吞吐量，DuckDB 的答案是并行加向量化，两者都能在代码里找到实据。
src/parallel/ 目录下有 executor.cpp、pipeline.cpp、meta_pipeline.cpp、pipeline_broadcast_exchange.cpp 等文件，它把查询拆成流水线，再交给多个线程并行跑。它意味着：你写的单条 SQL，在执行层面其实是多核一起干活，GROUP BY、JOIN 这类重头操作不会卡在单个线程上。
向量化方面，src/include/duckdb/common/vector_size.hpp 里定义了 STANDARD_VECTOR_SIZE 为 2048。也就是说，引擎一次按 2048 行为一批处理数据，就像流水线上一箱一箱地加工零件，而不是一颗一颗地捡——CPU 缓存友好，批量计算效率自然高。
这套性能体系不是靠嘴说，仓库里带着完整的验证工具：benchmark/ 目录下有 TPC-H、TPC-DS、ClickBench、IMDb 等一整套基准，benchmark/README.md 甚至把怎么编译 runner、怎么跑单条 benchmark 写得明明白白。你怀疑某个版本变慢了，可以拿自己的 workload 在这套框架里量一遍，而不是听信跑分传言。
🧩 装得进生态：扩展体系和多语言客户端
v0.5 之后，DuckDB 把"功能"和"核心"做了切割：核心引擎保持精简，新能力尽量做成扩展。extension/README.md 把扩展分成两类——in-tree（住在主仓库里，如 extension/json/、extension/parquet/、extension/tpch/）和 out-of-tree（独立仓库维护、随官方渠道分发）。
日常使用只需要两条命令，扩展二进制按版本绑定分发（见 extension/ExtensionDistribution.md）：
INSTALL json;
LOAD json;
它意味着：你要 JSON 支持就装 JSON 扩展，要全文检索、时区处理（ICU）也各装各的，核心安装包不会因为"以防万一"而变臃肿；而且扩展和主程序按版本一一对应，不会出现"扩展比内核还新"的错位。
客户端层面，README 列出了独立的 CLI，以及 Python、R、Java、Wasm 客户端，并与 pandas、dplyr 有深度集成。对新手最实际的感受是：数据在 DataFrame 和 SQL 之间往返，不用你操心拷贝和转换细节。
我该用哪个版本：一张决策清单
结合上面的演进脉络，选型其实很简单：
- 新项目、不纠结：直接用仓库最新 tag（v1.5.5）。从 git 标签日期看，次版本节奏大约是每季度一个（v1.2 2025-02、v1.3 2025-05、v1.4 2025-09、v1.5 2026-03），跟进成本不高。
- 保守的生产环境：以 v1.0（2024-05 发布）为心理分界线——它是项目第一个正式的 1.0，之后的 v1.x 都是在稳定基线上迭代，而不是重写。
- 要装扩展：先确认扩展与你主程序版本匹配。扩展二进制里"烙着"版本号和平台标识，换主版本后需要重新
INSTALL对应版本。 - 想读懂引擎或提代码：从 src/ 的目录切面入手（
src/parser/、src/planner/、src/execution/、src/optimizer/），贡献规范在 CONTRIBUTING.md，本地构建看 Makefile 里的make/make debug/make unit即可。 - 怀疑性能回退：别急着下结论，用 benchmark/ 里的 runner 跑你自己的查询对比，结论才有说服力。
往前看，仓库的迭代节奏（见 git tag）和 benchmark 目录不断新增的工作负载（如 aoc24、jsonbench）说明团队仍在高频打磨分析场景；对使用者来说，这基本等于"用最新版、盯紧版本说明"就是最稳的策略。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/gitblog_00805/article/details/156348686
