# 数据库引擎内核七强精读：从DuckDB崛起到PostgreSQL 18，2026年最值得看的工程级深度内容 ## 本期概述 数据库领域正在经历近十年最猛烈的一次"内核复兴"。这不是夸大其词——当 DuckDB 一个进程内分析型数据库在 GitHub 上累积超过几十万星、被嵌入到无数数据管线里时；当 PostgreSQL 凭借 vector search、异步 I/O 和 serverless 变体（如 Neon）持续蚕食专有数据库市场时；当 CMU 的数据库内核课程成为全网工程师"补课"的标配时，我们显然站在一个新周期的起点。 本期 **programming（编程与开发）** 分类聚焦"数据库引擎内核"，精选 7 个 2025–2026 年最具工程价值的 YouTube 视频/频道。它们的共同点是：**不浮于"如何写 SQL"，而是讲清楚引擎内部究竟发生了什么**——存储页与元组如何组织、B+ 树与 LSM 树如何取舍、MVCC 如何让读不阻塞写、向量化执行如何把列式存储的性能榨干。 读懂这些内容，你的收获不是"会用某个数据库"，而是具备**判断任何数据库优劣的底层坐标系**。 ## 七强速览对比 | # | 视频/频道 | 核心主题 | 工程深度 | 适合人群 | |---|----------|---------|---------|---------| | 1 | What is DuckDB? | 进程内列式 OLAP + 向量化执行 | ★★★★ | 数据工程师、全栈 | | 2 | SQLite vs DuckDB (2026) | 嵌入式 OLTP vs OLAP 选型 | ★★★ | 架构师、独立开发者 | | 3 | Database Indexing Explained (Hussein Nasser) | 索引原理与代价 | ★★★★ | 后端、DBA | | 4 | PostgreSQL Internal Architecture | 进程模型/WAL/MVCC | ★★★★★ | 后端、SRE | | 5 | PostgreSQL 18 Deep Dive | 新版特性（async I/O 等） | ★★★★ | 升级评估者 | | 6 | CMU 15-445/645 (Andy Pavlo) | 数据库内核系统级课程 | ★★★★★ | 想造 DB 的人 | | 7 | Scaling Databases in the AI Era | AI 时代数据库演进 | ★★★★ | 技术决策者 | --- ## 一、What is DuckDB? The Database Changing Data Engineering Forever **频道/链接**：[YouTube](https://www.youtube.com/watch?v=iEbDXlKJQSo) · 数据工程方向 ### 核心内容与关键洞察 这条视频把 DuckDB 的定位讲得极其清晰：**它是 OLAP（分析型）世界的 SQLite**。就像 SQLite 是一个可以塞进任何进程、零配置、单文件的 OLTP（事务型）数据库一样，DuckDB 是一个可以塞进任何进程、零配置、5 秒安装、能直接嚼碎 CSV/Parquet 的 OLAP 数据库。 最关键的工程洞察是**向量化执行（vectorized execution）**。传统数据库逐行解释执行查询，每行都要经过函数调用、类型检查的开销；DuckDB 借鉴 MonetDB 的思想，一次处理一批（通常 1024 或 2048 个值）数据，把解释开销摊薄到整批上，同时让 CPU 能利用 SIMD 指令、保持缓存友好。叠加**列式存储**（只读取查询真正需要的列）和 **morsel-driven parallelism**（把查询切分成小块分发到所有核心），DuckDB 在单机分析上常常能跑赢需要拉起集群的 Spark。 ### 实用价值与应用场景 如果你正在用 Pandas 处理超出内存的数据、或者为了跑一个临时聚合查询就启动一个 Spark 集群，这条视频会改变你的工作流。DuckDB 让"本地 SQL 分析"变得几乎免费——进程内运行、无服务端、直接 `SELECT * FROM 'data.parquet'`。 **适合人群**：数据工程师、数据分析师、做本地数据处理的独立开发者、需要给应用加嵌入式分析能力的全栈工程师。 --- ## 二、SQLite vs DuckDB: Which Embedded Database Should You Choose in 2026 **频道/链接**：[YouTube](https://www.youtube.com/watch?v=99VFrPmOqaY) ### 核心内容与关键洞察 2026 年这条"嵌入式数据库选型"视频之所以反复被推荐，是因为它精准戳中了一个普遍误区：**很多人以为 DuckDB 是要取代 SQLite 的，其实两者根本不在一个赛道。** 视频从架构层做了清晰切分： - **SQLite**：行式存储、完整的 ACID 事务、单文件即数据库、世界级的可嵌入性与可靠性（据称是全球部署量最大的数据库，每个手机里都有）。它擅长高频的小事务——`INSERT/UPDATE/DELETE` 一行行来，延迟低、持久性强。 - **DuckDB**：列式存储、向量化执行、不追求极致的单行事务吞吐，而是追求"扫一遍大表算聚合"的吞吐。它还能直接对外部文件（CSV、Parquet，甚至 S3 上的）做查询，无需先导入。 一个反直觉的洞察：**选型本质上取决于"你的查询是点查还是扫描"**。点查（按主键取一行）选 SQLite；扫描（对几百万行求 SUM/GROUP BY）选 DuckDB。强行用错，性能差几个数量级。 ### 实用价值与应用场景 给应用选本地存储时，先问自己：是"存用户状态、频繁增删改"（→SQLite），还是"存日志/事件、批量分析"（→DuckDB）。很多现代应用其实**两个都要**——用 SQLite 管事务，用 DuckDB 跑分析报表，各司其职。 **适合人群**：架构师、独立开发者、需要做技术选型的技术负责人。 ```mermaid flowchart TD A[嵌入式数据库选型] --> B{主要查询模式?} B -->|点查/事务 增删改| C[SQLite] B -->|扫描/聚合 分析| D[DuckDB] C --> C1[行存 + ACID + 单文件] D --> D1[列存 + 向量化 + 外部文件直读] C1 --> C2[移动端/嵌入式/本地配置] D1 --> D2[本地分析/报表/数据科学] ``` --- ## 三、Database Indexing Explained (with PostgreSQL) — Hussein Nasser **频道/链接**：[Hussein Nasser · 37.9万次观看](https://www.youtube.com/watch?v=-qNSXK7s7_w) ### 核心内容与关键洞察 Hussein Nasser 是后端工程领域最被低估的"硬核 YouTuber"之一，这条索引讲解是他播放量最高的视频之一。他没有停留在"索引让查询变快"这种废话，而是讲透了**索引的代价**。 核心洞察一：**索引是空间换时间，更是"写"换"读"**。每多一个索引，每一次 `INSERT/UPDATE/DELETE` 都要同步维护这棵索引树，写放大（write amplification）随之上升。所以"给所有列建索引"是新手最经典的反模式。 核心洞察二：PostgreSQL 支持多种索引类型，**选对类型比建索引本身更重要**——`B-tree` 适合范围和等值查询；`Hash` 只适合等值；`BRIN`（块范围索引）适合有序大表，占用极小；`GIN` 适合全文检索和 JSONB；`GiST` 适合地理/范围数据。 核心洞察三：**复合索引的最左前缀原则**和**部分索引（partial index）、覆盖索引（covering index，PG 用 INCLUDE 实现）**的实战用法——这是把慢查询从秒级压到毫秒级的关键。 ### 实用价值与应用场景 掌握这套方法后，配合 `EXPLAIN (ANALYZE, BUFFERS)`，你能独立诊断 90% 的"数据库变慢"问题：看是走了 Seq Scan（全表扫描）还是 Index Scan，估算了多少行，命中了多少缓冲。 **适合人群**：所有写后端的工程师、DBA、面试中会被问索引原理的求职者。这是"一次学习、终身复利"的知识。 --- ## 四、PostgreSQL Internal Architecture Explained **频道/链接**：[YouTube](https://www.youtube.com/watch?v=Q56kljmIN14) ### 核心内容与关键洞察 如果说上一条讲的是"索引"这一个点，这条讲的是 **PostgreSQL 整个引擎的骨架**，是理解所有 PG 行为的根基。 **进程模型**：与 MySQL/Oracle 的多线程不同，PostgreSQL 采用**多进程架构**（每个连接 fork 一个 backend 进程）。这带来了极佳的稳定性（一个连接崩溃不会拖垮整个数据库），但也意味着连接数不能无限涨——每个进程都占内存，所以 PG 生态演化出了 PgBouncer 这类连接池。理解这一点，才能理解为什么"连接风暴"会把 PG 打挂。 **WAL（Write-Ahead Log，预写日志）**：所有修改先写日志再改数据页。这是持久性与复制的基石——崩溃恢复靠回放 WAL，主从复制靠传输 WAL。它也解释了为什么 PG 的 `synchronous_commit` 设置能权衡延迟与安全。 **MVCC（多版本并发控制）**：这是 PG 最优雅的设计。每次 `UPDATE` 不就地改，而是写一个新版本（新元组），旧版本标记为死元组。好处是**读不阻塞写、写不阻塞读**；代价是会产生"膨胀"（bloat），需要 autovacuum 定期回收死元组。不懂 MVCC，就不懂为什么 PG 表会越用越慢、为什么需要 VACUUM。 ### 实用价值与应用场景 诊断"表膨胀""连接耗尽""复制延迟""长事务锁等待"这些生产顽疾，底层都靠这套架构知识。它是 SRE 和资深后端的必修内功。 **适合人群**：PostgreSQL 重度使用者、SRE、想从"会用 PG"升级到"懂 PG"的工程师。 ```mermaid flowchart LR Client -->|连接| Postmaster Postmaster --> Backend1[Backend 进程 1] Postmaster --> Backend2[Backend 进程 2] Backend1 --> SB[Shared Buffers 共享内存] Backend2 --> SB SB -->|刷盘| DF[数据文件 8KB 页] Backend1 -.先写.-> WAL[WAL 预写日志] WAL -.崩溃恢复/复制.-> DF SB -->|MVCC 多版本| T1[新元组] T1 -.旧版本.-> DT[死元组] DT -->|autovacuum 回收| Free[可复用空间] ``` --- ## 五、PostgreSQL 18 Deep Dive: Performance, Indexing **频道/链接**：[YouTube](https://www.youtube.com/watch?v=GTLXW9SnWgw) ### 核心内容与关键洞察 每个大版本发布时，"新特性深度解读"类视频都会刷一波流量。PG 18 这条值得看，是因为它讲的不是 changelog 罗列，而是**特性背后的工程动机**。 最重磅的是**异步 I/O（async I/O）**。PG 花了很多年才真正落地这件事——视频会解释为什么：PG 的多进程架构、缓冲管理、错误处理都建立在"同步 read() 返回数据"的假设上，要改成异步意味着重写整个 I/O 栈。一旦完成，对于能跑在 io_uring 上的现代系统，大表扫描、备份、复制的吞吐会有可观提升。 此外通常涵盖：改进的 `EXPLAIN`（更易读的执行计划）、虚拟生成列（virtual generated columns）、增强的索引能力、更智能的增量排序和并行查询。这些不是炫技，而是把"过去需要手动调优才能拿到"的性能变成"开箱即用"。 ### 实用价值与应用场景 直接服务于一个决策：**你的系统要不要升级到 PG 18？** 这条视频给你评估依据——哪些新特性恰好解决你的痛点（比如异步 I/O 对 I/O 密集型负载、生成列对派生数据）。 **适合人群**：负责数据库升级规划的技术负责人、追求性能极限的 DBA、对引擎演进感兴趣的工程师。配套可看 Hussein Nasser 的"Why It took Postgres years to do async"，专门拆解异步 I/O 的历史包袱。 --- ## 六、CMU Intro to Database Systems (15-445/645, Fall 2025) — Andy Pavlo **频道/链接**：[CMU Database Group · 25 集完整课程](https://www.youtube.com/playlist?list=PLSE8ODhjZXjYMAgsGH-GtY5rJYZ6zjsd5) · [频道主页](https://www.youtube.com/channel/UCHnBsf2rH-K7pn09rb3qvkA) ### 核心内容与关键洞察 这是**全球数据库内核教育的"金标准"**，主讲 Andy Pavlo 是数据库系统领域最活跃的研究者之一。课程完全开源（CC 协议），免费、系统、硬核，堪称"想造数据库的人的圣经"。 它真正值得精读的几集： - **Database Storage: Files, Pages, Tuples**：把磁盘抽象成页（page，通常 4–8KB 的固定大小块），页内如何组织元组（tuple）、如何用槽（slot）定位变长记录。这是所有存储引擎的起点。 - **Log-Structured Merge Trees**：对比 B+ 树（读友好、写需随机 I/O）和 LSM 树（写顺序化、读需合并多级），讲清楚为什么 Cassandra、RocksDB、LevelDB 都选 LSM——本质是用读放大换写吞吐，适配写多读少的场景。 - **Row vs. Column Storage + Compression**：行存适合事务（一次写一整行）、列存适合分析（只读查询涉及的列）。列存还能做游程编码、字典编码、位图编码，压缩率惊人。 - **Query Optimization**：基于规则（heuristic）和基于成本（cost-based）的两层优化，统计信息如何驱动计划选择。 课程最大的价值是**用统一框架拆解所有数据库**——学完之后，你再看 MySQL、PG、ClickHouse、DuckDB、Spanner，不再是孤立的知识点，而是同一个设计空间里的不同取舍。 ### 实用价值与应用场景 适合想要"知其所以然"的资深工程师，尤其是构建中间件、数据基础设施、自研存储引擎的人。配套的 BusTub（CMU 的教学型数据库）代码作业更是把理论变成手感的最佳路径。 **适合人群**：数据库内核爱好者、基础架构工程师、准备数据库相关面试/读研的人、想从应用层下沉到底层系统的工程师。 ```mermaid flowchart TD DB[数据库内核设计空间] --> ST[存储层] DB --> QP[查询处理层] ST --> ST1{页内组织} ST1 --> Row[行存 OLTP] ST1 --> Col[列存 OLAP] ST --> ST2{索引结构} ST2 --> BT[B+ 树 读友好] ST2 --> LSM[LSM 树 写友好] QP --> QP1[解析/绑定] QP --> QP2[优化 规则+成本] QP --> QP3[执行 向量化/编译] QP3 --> EX1[DuckDB 向量化] QP3 --> EX2[Hyper/PG JIT 编译] ``` --- ## 七、Scaling Databases in the AI Era: Insights from Andy Pavlo **频道/链接**：[YouTube](https://www.youtube.com/watch?v=0FiAJ4EKwTs) ### 核心内容与关键洞察 这是一场访谈形式的视频，Pavlo 教授跳出课堂、谈他对**AI 时代数据库往哪走**的判断，含金量很高。 **洞察一：vector search 正在成为关系型数据库的"标配能力"**。`pgvector` 让 PostgreSQL 直接支持向量相似度检索，意味着做 RAG（检索增强生成）、语义搜索不必再单独引入一个向量数据库。Pavlo 的观点是：大多数应用的向量规模，PG 加上合适的索引（HNSW、IVFFlat）完全扛得住，"专用向量库"的护城河正在被侵蚀。 **洞察二：HTAP（混合事务分析）与存算分离**。云原生时代，存储和计算解耦（如 Neon、Aurora）让数据库能弹性伸缩、按需付费。PG 生态凭借这一点，正在挑战那些专有的云数据库。 **洞察三：异步 I/O 与现代硬件的适配**（呼应前文 PG 18）。数据库内核长期滞后于硬件演进，现在正在补课。 ### 实用价值与应用场景 这条视频是"技术选型战略级输入"。如果你要为一个 AI 应用设计数据层，它会帮你判断：到底要不要上专用向量库？要不要选 serverless PG？如何避免过早优化和过度架构。 **适合人群**：技术决策者、AI 应用架构师、关注数据库趋势的资深工程师。 --- ## 本期知识图谱：数据库引擎内核全景 ```mermaid flowchart TD ROOT[数据库引擎内核] --> DIV1[按负载类型] ROOT --> DIV2[按核心子系统] ROOT --> DIV3[按时代趋势] DIV1 --> OLTP[OLTP 事务型] DIV1 --> OLAP[OLAP 分析型] OLTP --> SQLite[SQLite 嵌入式] OLTP --> PG1[PostgreSQL 行存] OLAP --> DuckDB[DuckDB 嵌入式列式] OLAP --> CH[ClickHouse] DIV2 --> STORE[存储: 页/元组] DIV2 --> IDX[索引] DIV2 --> CC[并发控制] DIV2 --> QOPT[查询优化] STORE --> LSM[LSM 树] STORE --> BPT[B+ 树] STORE --> ROWCOL[行存 vs 列存] IDX --> IDX1[B-tree/Hash/BRIN/GIN] CC --> MVCC[MVCC 多版本] CC --> WAL[WAL 预写日志] QOPT --> VEC[向量化执行] QOPT --> JIT[JIT 编译] DIV3 --> VEC2[进程内分析 DuckDB 崛起] DIV3 --> AI[向量检索 pgvector] DIV3 --> SERVERLESS[存算分离 serverless] SQLite -.对比.-> DuckDB PG1 -.演进.-> PG18[PG18 async I/O] VEC -.被讲解.-> CMU[CMU 15-445 课程] ``` ## 延伸推荐（5 个相关优质资源） 1. **DuckDB in the Cloud — FOSDEM 2026**（[YouTube](https://www.youtube.com/watch?v=a2KcteGKfwg)）：DuckDB Labs 工程师 Tom Ebergen 的会议演讲，讲云端部署 DuckDB 的工程挑战，是官方第一手信息。 2. **The Backend Engineering Show — Postgres index bloat**（Hussein Nasser · [YouTube](https://www.youtube.com/watch?v=qcInj-XW1Vc)）：承接本期的 MVCC 主题，专门讲死元组如何导致索引膨胀以及如何治理。 3. **Databases In-Depth — Complete Course**（[YouTube](https://www.youtube.com/watch?v=pPqazMTzNOM)）：偏入门的全景式课程，适合作为看 CMU 之前的垫脚石。 4. **ByteByteGo（Alex Xu）**：系统设计领域顶流频道，擅长用动画讲架构。本期讲的是引擎内部，他的频道补足"数据库在系统中的位置"这一层。 5. **Martin Kleppmann 的演讲**：《Designing Data-Intensive Applications》作者，分布式/数据库领域的思想领袖，演讲深度极高，适合进阶。 ## 结语：从"用数据库"到"懂数据库" 把本期 7 个内容连起来看，你会发现一条清晰的进阶路径：先用 SQLite vs DuckDB 建立选型直觉（第二篇）→ 用 Hussein Nasser 的索引视频掌握最常用的高频知识（第三篇）→ 用 PG 架构视频理解生产级引擎的全貌（第四篇）→ 跟着 CMU 课程下沉到内核设计空间（第六篇）→ 最后用 Pavlo 的访谈看清 AI 时代的演进方向（第七篇）。DuckDB 和 PG 18 则是贯穿其中的"当下热点"（第一、五篇）。 数据库是软件系统中最难、也最复利的知识领域之一。一台引擎的设计权衡（读优化还是写优化？强一致还是高可用？通用还是专用？）几乎是所有系统设计的缩影。把这几条视频真正消化掉，你获得的不仅是几个工具的用法，而是一套可以迁移到缓存、消息队列、文件系统乃至分布式协调的**底层思维框架**。 --- ## 参考来源 1. [What is DuckDB? The Database Changing Data Engineering Forever](https://www.youtube.com/watch?v=iEbDXlKJQSo) — DuckDB 进程内列式分析数据库的定位与向量化执行讲解 2. [SQLite vs DuckDB: Which Embedded Database Should You Choose in 2026](https://www.youtube.com/watch?v=99VFrPmOqaY) — 嵌入式 OLTP 与 OLAP 数据库的架构对比与选型 3. [Database Indexing Explained (with PostgreSQL) — Hussein Nasser](https://www.youtube.com/watch?v=-qNSXK7s7_w) — PostgreSQL 索引类型、代价与调优实战（37.9万次观看） 4. [CMU Intro to Database Systems 15-445/645 (Fall 2025) — Andy Pavlo](https://www.youtube.com/playlist?list=PLSE8ODhjZXjYMAgsGH-GtY5rJYZ6zjsd5) — 数据库内核系统级完整开源课程 5. [10 Best YouTube Channels for Data Engineering (2026 Guide) — Skyvia](https://skyvia.com/blog/best-youtube-channels-data-engineering/) — 2026 年数据工程优质 YouTube 频道社区评选 --- > 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 > 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。