【数据库研究前沿】系列导论：从 System R 到 AI-Native 的 2026 研究地图

这是【数据库研究前沿】系列的第 01 篇，也是整个系列的目录页。

写这个系列的直接动机很简单：过去两年，数据库方向的顶会（SIGMOD、VLDB、CIDR、ICDE、OSDI、SOSP、NSDI）发表了大量和”AI 原生（AI-Native）“、”向量检索（Vector Search）“、”分离式架构（Disaggregated Architecture）“、”可计算内存（Computational Memory / CXL）“、”可信执行环境（Trusted Execution Environment, TEE）“相关的论文。工程师读起来并不轻松——论文里的符号系统、基线对比、实验语料和真正能落地的工程决策之间，隔着一层相当厚的抽象。

本仓库已有三个互相补充的系列：post/storage/ 偏存储内核与硬件、post/db/ 收集了经典数据库话题、post/distributed/ 是分布式系统的理论百科。缺的正是一个以近两年顶会论文为骨架、面向工程师解读的”研究前沿”系列。本系列尝试填这个缺口：每一篇上半讲论文、定义、定理与直观推导；下半讲工程落地——代码、选型、踩坑、与仓库已有文章的互链。

本文只做两件事：

1. 用一张 25 篇的阅读地图，把这个系列的骨架铺开；
2. 用一段从 1970 年到 2026 年的迷你史，说明为什么要把七条主线放在一起看。

读者可以把本文当成书的目录页，按需跳转到任一主题。

版本说明 本系列写作时间窗口以 2026 年 Q2 前公开可访问的论文与系统为主：PostgreSQL 17、DuckDB 1.x、RocksDB 9.x、TiDB 8.x、Milvus 2.4.x、pgvector 0.7.x、Iceberg 1.5.x、Delta Lake 3.x、Hudi 0.15.x 等。涉及版本差异时各篇会单独标注。

一、五十年简史：从关系模型到 AI-Native

1.1 关系代数的奠基（1970）

Codd 1970 年发表在 CACM 的 A Relational Model of Data for Large Shared Data Banks 不是一篇”数据库论文”那么简单：它把用户看到的数据结构和系统里的物理存储严格分层，让”问什么（What）“和”怎么做（How）“彼此独立。今天所有 SQL 优化器里”查询可改写、物理执行可替换”的底层前提，都来自这一篇。

关系代数给后来五十年提供了三样东西：

• 运算封闭性：关系的并、交、差、选择、投影、连接仍返回关系，优化器可以无穷组合。
• 声明式接口：开发者只描述目标集合，执行引擎可以自由换实现——从火山模型（Volcano Model）到向量化（Vectorized Execution）到编译执行（Compiled Execution）。
• 可证明等价的改写规则：谓词下推（Predicate Pushdown）、连接重排（Join Reordering）、投影裁剪（Projection Pruning）的合法性都来自关系代数的代数定律。

值得一提的是，Codd 的论文并不是凭空出现的：IBM 当时的 IMS（Information Management System）使用层次模型、CODASYL 组织推广的 DBTG 提案采用网状模型，两者都要求应用程序按物理链表的方式去导航数据。Codd 的论文首先是对这种”程序员必须理解物理结构”的反叛。五十多年后，当我们讨论 Text-to-SQL、Agentic Query 时，本质上是把同样的抽象推到自然语言这一层。

1.2 System R 与 INGRES（1974–1979）

IBM San Jose 的 System R 把 Codd 的论文变成了可运行的系统。1979 年 Selinger 等人发表的 Access Path Selection in a Relational Database Management System 是基于代价的优化器（Cost-Based Optimizer, CBO）的起点：动态规划枚举左深连接树、选择率估计（Selectivity Estimation）、使用磁盘页数作为代价单位——这些概念一直活到今天。

同一时期加州大学 Berkeley 的 INGRES 走了另一条路：QUEL 语言、查询分解（Query Decomposition）而非动态规划。两个系统最终在 SQL 语法与 CBO 架构上收敛，但”学院派”和”工业派”的张力此后一直是数据库领域的隐性主旋律——这种张力决定了 CIDR（学院风向标）和 SIGMOD/VLDB（工业与学术混合）的分工。

1.3 面向对象与 Postgres（1986）

Stonebraker 1986 年的 The Design of Postgres 把两个今天看起来习以为常的思想写了下来：用户自定义类型（User-Defined Types）、用户自定义函数（User-Defined Functions）。四十年后，pgvector、PostGIS、TimescaleDB、Citus 全都是在这个扩展机制上搭起来的。Postgres 的另一条贡献是把 MVCC（Multi-Version Concurrency Control）作为第一等公民——仓库中另一篇 MVCC 实战 对此有深入讨论。

1.4 NoSQL 与”Big Data”（2003–2010）

Google 这十年发表了三篇引爆整个工业界的论文：

• GFS（SOSP 2003）：分布式文件系统抽象；
• MapReduce（OSDI 2004）：批处理编程模型；
• Bigtable（OSDI 2006）：列族（Column Family）、SSTable（Sorted String Table）、LSM-Tree（Log-Structured Merge Tree）的工业化。

Amazon 2007 年 SOSP 的 Dynamo 则把最终一致性（Eventual Consistency）、向量时钟（Vector Clock）、一致性哈希（Consistent Hashing）带进生产系统。这批论文在 2010 年前后催生了 HBase、Cassandra、MongoDB、Riak 等一长串系统。但它们共同的代价是放弃 SQL 与 ACID——“NoSQL”本意是”Not Only SQL”，实际工程中长期意味着”No SQL”。

值得注意的是，这一时期还埋下了两个”地雷”：其一是最终一致性的认知负担被严重低估，后来大量应用需要在客户端做补偿逻辑；其二是没有 JOIN 的代价被低估，业务方不得不把 JOIN 的计算挪到应用层或预计算层。正是这两个代价，促成了 2012 年之后 NewSQL 的回归——关系模型的严格性是一种不可替代的工程资产。

1.5 NewSQL 与 Spanner（2012）

Google 2012 年 OSDI 的 Spanner: Google’s Globally-Distributed Database 重新把 SQL 和强一致性放回分布式：通过原子钟与 GPS 组成的 TrueTime API 获取有界时钟偏差，实现外部一致性（External Consistency）。这一篇直接启发了 CockroachDB、YugabyteDB 和国内的 TiDB。仓库中 Paxos 与 Raft 系列对 Spanner 的共识层做过工程拆解。

1.6 云原生与 Snowflake（2016）

Snowflake 团队 2016 年 SIGMOD 的 The Snowflake Elastic Data Warehouse 把”存算分离（Storage-Compute Disaggregation）“带到主流视野：对象存储（S3）作为共享层、虚拟仓库（Virtual Warehouse）作为弹性计算、元数据服务（Foundation）作为事务和调度。这套架构后来被 Databricks、BigQuery、Redshift RA3、PolarDB、Aurora 反复重组——本系列第 14 篇会做专门综述。

1.7 HTAP 与 Lakehouse（2018–2022）

HTAP（Hybrid Transactional/Analytical Processing）把 OLTP 和 OLAP 合并到同一系统：SingleStore（原 MemSQL）走内存型、TiDB 走行列分离副本、F1 Lightning 用变更数据捕获（Change Data Capture, CDC）做近实时同步。

Databricks 团队 2021 年 CIDR 的 Lakehouse: A New Generation of Open Platforms That Unify Data Warehousing and Advanced Analytics 则把”湖仓一体”作为第三代数据平台正式命名。Iceberg、Delta Lake、Hudi 三大开源表格式（Table Format）的竞争正是这一主线的延续。

1.8 AI-Native（2022–2026）

真正把研究界从”NewSQL vs Lakehouse”的局部战争里拔出来的，是 2022 年底起大语言模型（Large Language Model, LLM）带来的冲击：

• 数据库作为 AI 基础设施：向量索引、混合检索、GraphRAG 进入主流；
• AI 作为数据库组件：Learned Index、Learned Cardinality、Bao/Balsa 等学习型优化器、自治数据库（Self-Driving Database）重新被关注；
• 自然语言接口：Text-to-SQL 在 Spider 2.0、BIRD 等新基准上达到可用阈值，Agentic Query 开始出现。

2026 年的研究地图，本质上是把这三股新力量叠加到”关系代数 + 分布式 + 存算分离”的旧骨架上。

1.9 历史的三个反复出现的模式

把 1970 到 2026 这五十六年压成一张图，会看到三个反复出现的模式，值得工程师铭记：

模式一：每一次范式更替都从”放弃 SQL”开始，到”重新拥抱 SQL”结束。

• NoSQL 早期放弃 SQL，NewSQL 把 SQL 找回来；
• MapReduce 早期放弃 SQL，Hive / Presto / Spark SQL 把 SQL 找回来；
• 早期向量数据库放弃 SQL，pgvector / MyScale 把向量塞回 SQL；
• 早期图数据库放弃 SQL，SQL/PGQ 标准（ISO/IEC 9075-16:2023）正式把图查询纳入 SQL。

这不是 SQL 有多”完美”，而是声明式 + 优化器的工程复利太强，最终会把所有特定语言重新收拢到类 SQL 的形式上。

模式二：每一代硬件进入数据库都要经历”先硬塞、后重构”两阶段。

• 磁盘时代的 B-Tree 在 SSD 早期沿用、最终由 LSM-Tree 更合理地利用闪存特性；
• 多核 CPU 从锁瓶颈到 lock-free 数据结构再到 vectorized execution；
• GPU 从早期的并行 join 尝试到今天的 AI workload 推理；
• PMEM / CXL 在早期的”硬塞”阶段，真正的重构方案未定。

模式三：研究思想的扩散节奏稳定在 5–8 年。

一个在顶会上被首次提出的 idea，通常需要 5–8 年才会变成产业标准。这个节奏对工程师意味着：现在读 2024–2025 的顶会论文，可以预期它们在 2030–2033 年进入生产。这为技术选型提供了一个稳定的先导信号。

1.10 五十年里数据库领域”错过”的几件事

最后值得提醒的是：数据库领域并非每次都押对方向，也有过几次明显的”错过”。这些错过构成了我们今天理解 2026 年研究地图时必要的谦虚。

• 面向对象数据库（ODBMS）：1990 年代投入大量研究，最终被”关系数据库 + ORM”击败。教训：不要和生态基础设施对抗。
• XML 数据库：2000 年代投入大量研究（XQuery 甚至成了标准），最终被 JSON + 文档数据库边缘化。教训：语法简洁性比理论优雅重要。
• 持久内存数据库（PMEM DBMS）：2015–2022 年一整波论文，Intel Optane 退场后大部分失去工程意义。教训：跟硬件赌要有退路。
• 区块链作为数据库：2017–2021 年的一整波尝试，至今没有进入主流数据库教科书。教训：信任模型不是数据库的主要轴。

这些”错过”并不意味着相关研究没有价值——很多技术在其他领域开花结果——但它们提醒我们：任何 hype 都有 50% 的概率在 5 年后被边缘化。本系列对 2026 年热点的讨论会保持这种谦虚。

1.11 从”错过”反推 2026 年的警惕清单

对照上一小节的”错过”规律，对 2026 年的几个方向可以预先设立警惕：

• 向量数据库作为独立赛道：会不会重演”XML 数据库被 JSON 边缘化”？pgvector 在 Postgres 里的快速集成暗示了这种风险。独立向量库的真正护城河，必须在超大规模、低延迟、专业化特性（例如多向量、张量、量化）上做到主流数据库短期无法复制；
• 全链路 AI-Native 数据库：如果”AI 作为组件”已经足够好，“AI 重写数据库”的路径可能和 ODBMS 一样被主流 RDBMS 反噬；
• 区块链式的”去中心化数据库”：在 2026 年的选型矩阵里几乎看不到其位置。除非有新的监管窗口打开，否则大概率继续停留在特定场景；
• 仅围绕特定硬件的整栈重写：CXL、DPU、Smart SSD 值得跟踪，但 “只有在 X 硬件上才能跑” 的设计在通用数据库路径上走不远。

这个警惕清单不是预测，而是用历史规律建立的”反面假设”。一个技术如果能反驳清单里的假设，就值得投入；反之，应当保持观望。

二、2026 研究地图：七条主线

把近两年 SIGMOD / VLDB / CIDR / ICDE / OSDI 的论文聚类，可以得到七条互相交织的主线。

2.1 主线 0 · 总览与方法论

这是读懂其他六条主线的前置：研究地图本身（本文）+ 如何读顶会论文（第 02 篇）。

2.2 主线 1 · AI-Native 数据库

用 AI 重建数据库组件。核心三问：

1. 能否用机器学习代替代价模型、基数估计（Cardinality Estimation）？——Neo（VLDB 2019）、Bao（SIGMOD 2021）、Balsa（SIGMOD 2022）。
2. 能否用模型代替 B+Tree、Bloom Filter？——RMI（SIGMOD 2018）、ALEX（SIGMOD 2020）、PGM-Index（VLDB 2020）。
3. 能否让数据库自己选索引、自己切分区、自己调参数？——Peloton、NoisePage、OtterTune（SIGMOD 2017）的后续演化。

LLM 的加入让 Text-to-SQL（DIN-SQL、C3、DAIL-SQL）和”数据库作为 LLM 记忆体”成为新的子方向。

2.3 主线 2 · 向量与多模态检索

向量检索（Approximate Nearest Neighbor Search, ANN）从信息检索圈进入数据库主会议是过去两年最明显的变化。值得关注的三条支线：

• 索引算法：HNSW（TPAMI 2018）、DiskANN（NeurIPS 2019）、SPANN（NeurIPS 2021）。
• 标量过滤 + 向量（混合检索）：ACORN（SIGMOD 2024）、Milvus、pgvector 的过滤算法差异。
• 图增强检索（GraphRAG）：微软研究院 2024 年提出，正在影响查询语言设计。

2.4 主线 3 · HTAP、存算分离与云原生

• HTAP 新范式：TiDB（VLDB 2020）、SingleStore、F1 Lightning（VLDB 2020）、Lakehouse；
• Serverless 数据库：Neon、Aurora Serverless v2 的弹性定价和冷启动模型；
• 分离式架构综述：Socrates（SIGMOD 2019, Azure SQL DB Hyperscale）、PolarDB（VLDB 2018）、Taurus（SIGMOD 2020, Huawei）。

这条主线和 仓库中的分布式系列 强相关。

2.5 主线 4 · 新硬件冲击

三件硬件在同时改写数据库假设：

• CXL 3.0：内存池化（Memory Pooling）对缓冲池（Buffer Pool）和共享内存模型的重塑；
• 近数据处理（Near-Data Processing, NDP）与可计算存储（Computational Storage）：Smart SSD 与 DPU Offload；
• 下一代 NVM：持久内存（Persistent Memory, PMEM）退场后，ZNS SSD（Zoned Namespace）与下一代 NVM 路线。

本仓库 存储硬件系列 讨论过基本硬件，本系列聚焦数据库侧的架构变化。

2.6 主线 5 · 隐私、安全与主权

• TEE 数据库：EnclaveDB（S&P 2018）、Oblivious Join；
• 差分隐私（Differential Privacy, DP）数据库：PINQ、APEx（SIGMOD 2018）、到生产级 DP-SQL；
• 加密查询：全同态加密（Fully Homomorphic Encryption, FHE）、可搜索加密、私人信息检索（Private Information Retrieval, PIR）。

这条主线最受主权数据（Data Sovereignty）与欧盟 GDPR、美国 HIPAA 等法规驱动。

2.7 主线 6 · 新范式与新理论

• CRDT（Conflict-free Replicated Data Type）与 CALM（Consistency As Logical Monotonicity）定理：Hellerstein 等 Keep CALM and Carry On（PVLDB 2020）后的新工作；
• 流批一体（Streaming / Batch Unification）：Materialize、RisingWave、Feldera 的增量视图维护（Incremental View Maintenance, IVM）；
• 湖仓一体的一致性：Iceberg、Delta、Hudi 的事务边界差异。

2.8 七条主线的权重分布

读者经常问的另一个问题是：“这七条主线应该花多少时间？”这里给一个笔者的主观权重：

这张表不具备严格的客观性，但可以作为新入行工程师的参考起点。

2.9 七条主线的”论文密度”对比

如果按 2023–2025 年三届 SIGMOD / VLDB 顶会论文的粗略数量分布（基于 DBLP 关键词检索，数字仅作量级参考），可以得到如下对比：

论文密度高不等于工程价值高。向量检索同时密度高 + 落地度高，是最值得投入的方向；新硬件密度中低但落地度低，更适合做观察；隐私主题密度低但在金融、医疗、政务场景不可替代。这种交叉视角对选型非常重要。

三、25 篇阅读地图

下表是整个系列的骨架。编号即文件夹编号，slug 与文件夹末段一致，链接按 .html 后缀构造。

七条主线与 25 篇文章的对应关系可以用一张极简的拓扑图表示：

┌──────────────────────── 方法论 (01, 02) ────────────────────────┐
│                                                                  │
│   主线1  AI-Native             主线2  向量/多模态                │
│   03 04 05 06 07               08 09 10 11                       │
│                                                                  │
│   主线3  HTAP/云原生           主线4  新硬件                     │
│   12 13 14 15                  16 17 18                          │
│                                                                  │
│   主线5  隐私/安全             主线6  新范式                     │
│   19 20 21                     22 23 24                          │
│                                                                  │
└──────────────────────── 总结 (25) ──────────────────────────────┘

四、为什么是”七条主线”而不是一条

新入行的工程师常问：2026 年应该学哪一个方向？这个问题没有唯一答案，但有一个经验法则：七条主线之间存在强耦合，单独看任何一条都会漏掉另一半故事。下面是三个具体例子。

4.1 向量检索 × HTAP

pgvector 在 Postgres 里实现 HNSW 的同时，要解决一个被传统 ANN 论文忽略的问题：向量索引必须和行的 MVCC 语义兼容。被回滚的插入必须不出现在搜索结果里；正在执行的事务应该看到自己的新向量。这不是 HNSW 原论文研究的范围，而是”HTAP × 向量”的交集。第 09 篇会展开。

4.2 AI-Native × 新硬件

Learned Index 在 2018 年被提出时，关键论据是”模型预测比树遍历快”。但 RMI 之后的工作（ALEX、PGM）把重点转到”如何处理更新”。而 CXL 内存池化让”索引常驻 CPU 本地 DRAM”这个假设松动——远端内存（Far Memory）的访问延迟在 200–300 ns 级别，可能让单次模型推理的相对收益被抹平。第 04 篇和第 16 篇互为镜像。

4.3 隐私 × AI-Native

Text-to-SQL 的训练数据几乎必然包含真实业务表结构。DP-SQL 在这一场景下的意义不是”保护查询结果”，而是”保护被用于微调的 schema”。反过来，TEE 又可以成为本地小模型的可信执行容器。这让第 06 / 19 / 20 三篇形成一个小闭环。

4.4 新硬件 × HTAP

HTAP 的核心瓶颈之一是行列数据同步延迟。CXL 内存池化在理论上可以把行列存储映射到同一段共享内存，这会彻底改变 HTAP 系统的工程取舍。目前这条路径还停留在 POC 阶段，但值得工程师跟踪：如果它走通，第 12、14、15、16 篇的结论会在 3 年内被全部重写。

4.5 向量检索 × 隐私

向量 embedding 天然是”去标识化”的，但并不等于”去信息化”。多篇论文（例如 2023 年 USENIX Security 上的 embedding inversion 攻击研究）表明，embedding 可以被近似还原出原始文本。这让”向量存储 + DP”成为一个尚未被充分研究的新方向。

结论：七条主线是一个网状而非链式的结构。任何一篇都可以当独立入口，但读两三条相邻主线会得到 1+1>2 的信息密度。

五、工程启示：怎么用这份地图

前四节是”论文视角”，这一节是”读者视角”。

5.1 三种典型读者路径

5.2 和仓库已有系列的协作方式

本系列尽量避免和已有文章重复。交叉引用的规则：

• 涉及 LSM-Tree、WAL、压缩、校验和等存储内核机制时，跳到 post/storage/；
• 涉及 Paxos/Raft、租约（Lease）、外部一致性等分布式共识时，跳到 post/distributed/；
• 涉及 MVCC、SQL 范式、事务隔离等经典话题时，跳到 post/db/。

例如第 15 篇讨论共享内存数据库时不会重复解释 Raft，而是直接链接 仓库中的共识系列。

5.3 配套 demo 的读法

本系列有一部分文章（第 03、08、09、10、20 篇等）附带可下载的最小 demo，放在 post/db-frontier/NN-slug/demo/ 目录。demo 的设计原则：

1. 离线可跑。涉及大模型的 demo 使用本地小模型（例如 sentence-transformers/all-MiniLM-L6-v2、llama.cpp 量化模型）或预录制数据；
2. 最小依赖。能用 PostgreSQL + pgvector + Python 跑的，就不引入 Spark；
3. 可改可复用。demo 的参数、数据集路径、连接串都集中在一个 .env.example。

demo 的命名约定是 NN-slug-demo.zip，正文用相对链接提供下载。

5.4 怎么”追”这个系列

# 订阅本仓库 RSS
curl -O https://ltl.im/rss.xml

# 或直接 clone 仓库，本地 grep 前沿关键词
git clone https://github.com/zltl/2bzltl.git
cd 2bzltl
grep -rln "db-frontier" post/

对研究生和高级工程师，推荐把本系列作为”论文 + 工程注释”双栏读物：开一个浏览器标签读原论文，另一个标签读本系列的对应文章，遇到不一致的地方在 GitHub Issue 里讨论。

5.5 常见误区

1. “AI-Native 会取代传统数据库”：本系列持保守态度。Learned Index 在 2018 年后的工程化进展并不如预期（第 04 篇展开）。更务实的视角是：AI 作为数据库的一个可选组件，而不是替代者。
2. “向量数据库是独立赛道”：pgvector 在 Postgres 里的工程化表明，向量能力正在被吸收进通用数据库。独立向量库（Milvus、Weaviate、Qdrant）的生存空间在超大规模和专业化优化。
3. “HTAP = 一个系统同时做 OLTP 和 OLAP”：第 12 篇会说明，主流 HTAP 方案依然是物理隔离的行列副本；真正的”同一数据同一路径”还没有定论。
4. “新硬件立即重写数据库”：持久内存（PMEM）2019 年的热度和 2022 年 Intel Optane 退场是一面镜子；CXL 在 2026 年还处于早期。第 16 / 18 篇会冷静讨论。

5.6 一个可复制的”12 周前沿追踪计划”

工程师常见的痛点是”想追前沿但没时间”。下面这个 12 周计划是笔者多次验证过的可行节奏。每周 3–5 小时，12 周后你会在 2026 年的数据库研究前沿上有一份”自己的”地图。

这个计划的关键不是”读完 12 篇论文”，而是强迫自己每周都把新学到的东西写下来。写 + 读的组合比单纯读快 3–5 倍地建立长期记忆。

5.7 把本系列放进团队知识库

如果你负责一个技术团队，本系列可以作为”新人入职阅读清单”的一部分。建议做法：

1. Fork 本仓库或按 Pandoc 生成 PDF，挂到团队内网；
2. 按主线分配读书负责人——每条主线找 1 个团队成员做”主理人”，负责季度更新；
3. 每篇配一个”内部案例”附录，把公司内部使用到的相关系统、踩坑、配置记录下来；
4. 建立”前沿 → 选型”的反馈闭环：当团队选型会议引用本系列的哪一篇时，把会议结论反馈到对应文章的附录。

这样做的好处是把”个人知识”和”团队知识”打通——工程师读完文章不再只是增加了自己的理解，而是直接改进了团队的决策流程。

5.8 系列的版本与勘误

本系列会按季度做一次”勘误 + 新论文补充”的迭代：

• 每季度末：Review 每篇文章，把新的 SIGMOD / VLDB 论文、新版本的系统工程博客补进参考文献；
• 每年末：Review 选型矩阵和开放问题列表，根据过去一年的进展更新；
• 重大事件后：例如重要硬件或系统退场、重要顶会论文发布，做紧急更新。

所有更新会在文章末尾”版本说明”或 Changelog 中标注。读者如发现错误，欢迎在仓库 Issue 提出。本系列不追求”一次写成不改”——数据库研究前沿本身就在变化中，文档也应如此。

六、七条主线的交叉阅读表

单独读一条主线会漏掉另一半故事。下面这张表按”如果你在读 X，建议同时翻一翻 Y”的方式组织。

交叉阅读不是形式，而是为了逼迫自己在两个上下文里反复使用同一个概念。例如”一致性”在 HTAP 和 Lakehouse 里含义不同：前者指主从副本的 freshness、后者指表格式的事务边界。反复对照能帮你避免在工程沟通时混用术语。

七、术语表：第一次进入本系列请先读

很多文章会反复出现以下术语。在这里一次性列出，后文不再每次展开。

• CBO（Cost-Based Optimizer）：基于代价的查询优化器，SQL 引擎选择执行计划的主流机制。
• MVCC（Multi-Version Concurrency Control）：多版本并发控制，PostgreSQL、MySQL InnoDB、SQL Server 等主流系统的并发基础。
• HTAP（Hybrid Transactional / Analytical Processing）：在同一系统里同时支持事务和分析负载。
• OLTP / OLAP：联机事务 / 分析处理，二者的典型负载特征在第 12 篇有对比。
• LSM-Tree（Log-Structured Merge Tree）：日志结构合并树，RocksDB、LevelDB、Cassandra 的存储引擎基础。本仓库 LSM-Tree 工程实践 有系统讨论。
• WAL（Write-Ahead Log）：预写日志，所有主流数据库的事务持久化基础。
• CDC（Change Data Capture）：变更数据捕获，主从复制、ETL 与 HTAP 的底层机制。
• ANN（Approximate Nearest Neighbor Search）：近似最近邻搜索，向量检索的核心问题。
• RAG（Retrieval-Augmented Generation）：检索增强生成，把向量 / 图检索嵌入到 LLM 生成流程。
• CXL（Compute Express Link）：一种 CPU 与外设间的缓存一致性互联协议，本系列讨论的版本是 CXL 2.0 / 3.0。
• TEE（Trusted Execution Environment）：可信执行环境，Intel SGX / TDX、AMD SEV、ARM CCA 等。
• DP（Differential Privacy）：差分隐私，用数学方式限制单条记录对查询结果的影响。
• CRDT（Conflict-Free Replicated Data Type）：无冲突复制数据类型，最终一致性下的可合并数据结构。
• IVM（Incremental View Maintenance）：增量视图维护，流批一体的理论根基。

本系列不会把每个术语都从零开始解释——遇到陌生术语请先回到这里或查对应主线的第一篇。

八、一个小历史：为什么 2026 年是一个合适的”整理窗口”

每隔 10–15 年，数据库领域会出现一次”边界被重画”的时刻。

• 1970–1985：关系代数 + System R + SQL 标准化，边界从”层次模型 / 网状模型”切到”关系模型”；
• 1995–2005：互联网催生了 Oracle / DB2 / SQL Server 三足鼎立，以及开源的 MySQL / PostgreSQL 并行起步；
• 2005–2015：Google 三篇论文 + NoSQL 浪潮 + Spanner 让”分布式 + 强一致”变成可能；
• 2015–2022：云原生与存算分离 + HTAP + Lakehouse 重写云端数据平台；
• 2022–2026：LLM 冲击 + 新硬件（CXL / DPU / ZNS） + 合规需求三股力量同时发力。

每一次重画边界后的 3–4 年是”整理窗口”：新旧范式已经显形、但产业标准尚未完全固化。现在恰好处在这样一个窗口里。本系列所做的事情，本质上是在窗口关闭之前留下一份面向工程师的地图。

整理窗口的典型特征：

1. 同一问题会有 3–5 种工程解法，尚未收敛。例如”向量检索”在 pgvector、Milvus、Qdrant、Weaviate、Elasticsearch 向量版、SQLite 向量扩展之间差异巨大。
2. 顶会论文数量短时间内暴涨。2024 年 SIGMOD 向量方向论文数量是 2020 年的 5 倍以上（按 DBLP 粗略检索）。
3. 工业界开始发白皮书而非论文。一些真正领先的系统（如 Google F1、Microsoft Synapse 内部版本）在顶会上只留下片段。
4. 教科书滞后 2–4 年。主流数据库教材（Ramakrishnan、Garcia-Molina、Elmasri）都还没有把向量检索、CXL、GraphRAG 作为独立章节。

这种窗口期对工程师是机会也是风险：机会是”提前 2 年看懂范式、可以在技术选型上拉开差距”；风险是”选错会付出 12–24 个月的工程代价”。本系列下半的”工程落地”部分会尽量把这种风险提示出来。

8.1 历史整理窗口下的工程师策略

在每个整理窗口下，工程师有三种可选策略，收益和风险各不相同：

策略一：早期采用（Early Adopter）

在新范式刚出现时就开始用。例如 2018 年用 TiDB、2020 年用 pgvector、2023 年用 Iceberg。这种策略的收益是”在成本低时占据经验高地”，代价是踩坑——文档不全、社区小、版本频繁 break。适合：创业公司、内部小项目、有强技术储备的团队。

策略二：稳定采用（Mainstream Adopter）

等范式稳定 2–3 年、产业标准基本形成后再上。例如 2022 年用 PostgreSQL 15 的并行 VACUUM、2024 年用 Iceberg 1.x。这种策略的收益是”风险低”，代价是”和竞对拉不开差距”。适合：大多数中大型团队的核心系统。

策略三：观察者（Observer）

只读论文、写笔记，不在生产上动。这种策略的收益是”始终保持理解”，代价是”落地经验欠缺”。适合：架构师、咨询顾问、研究方向的 DBA。

本系列本身假设读者是一个在”观察者”和”稳定采用者”之间摆动的工程师：想理解前沿，但不会盲目跳到早期采用。我们的文章尽量把”什么时候可以从观察者变成采用者”的阈值说清楚。

8.2 不变的部分

尽管整理窗口每 10–15 年会重画一次，下面这些东西五十年来几乎没有变：

• 关系代数的七个基本运算（并、交、差、笛卡尔积、选择、投影、重命名）
• 事务的 ACID 语义——即使实现从 2PL 到 MVCC 到 Optimistic Concurrency Control 都变了，语义维持
• 代价模型驱动的优化器架构——System R 的动态规划依然是现代 CBO 的骨架
• B-Tree 和 LSM-Tree 两套索引范式的长期共存
• WAL 作为持久性基石

真正的数据库工程师的核心能力，是对这些”不变量”的深刻理解。新范式只是在这些不变量之上加了新约束。读懂了不变量，任何新系统都能在一周内快速上手。

九、读者可以期待什么 · 以及不能

最后说清楚这个系列的边界。

可以期待：

• 每篇上半讲清楚论文在解决什么问题、核心机制、代价、适用场景；
• 每篇下半给出可以直接拷到项目里的代码或配置，哪怕只是最小骨架；
• 对每个方向标注开放问题和尚无共识，不做没有依据的未来预测；
• 跨系列的互链，避免读者在几十篇文章里迷路。

不能期待：

• 不做商业系统对比评测。TiDB vs OceanBase、Milvus vs Qdrant 这类对比涉及商业立场和快速变化的版本，不在本系列目标内；
• 不代替读论文。本系列是”地图 + 注释”，不是论文摘要的翻译；
• 不追每一篇 SIGMOD 的 short paper。选题标准是”在 3 年后仍然会被讨论”。

下一篇是第 02 篇：如何读数据库顶会论文。在进入具体技术之前，先把”怎么读”这件事理清楚。

十、致谢与致读者

这个系列的写作从最早的选题到第一批文章落稿，大约花了半年。期间得到了一些朋友的帮助——在读书会上贡献疑问的同事、在 GitHub Issue 里指出引用错误的读者、在国内几个数据库社区（PingCAP 用户群、TiDB 社区、OceanBase 社区、PostgreSQL 中文社区）参与讨论的工程师。整个系列的基调——“诚实、克制、重工程”——很大程度是被这些真实反馈塑造的。

给准备开始读的你一些最后的嘱托：

1. 不要把本系列当成权威。任何一篇都只是一份旁注。遇到重要决策时，还是要回到原论文、系统的源码与官方文档；
2. 不要追求”读完全部 25 篇”。挑 3–5 篇真正和你的工作相关的，深读到第三遍，比泛读 25 篇收益大得多；
3. 欢迎质疑与补充。数据库方向的边界正在每季度变化，本系列也在被持续修订。如果你在某一篇里找到了错误，或发现了重要遗漏，请在 GitHub 仓库的 Issue 区提出；
4. 写自己的笔记。最好的”读后感”不是点赞转发，而是你自己的一份独立总结——哪怕只在团队 Wiki 里私有发布，也会形成长期回报。

参考文献

1. E. F. Codd. A Relational Model of Data for Large Shared Data Banks. Communications of the ACM, 13(6):377–387, 1970. https://doi.org/10.1145/362384.362685

2. P. G. Selinger et al. Access Path Selection in a Relational Database Management System. SIGMOD 1979. https://dl.acm.org/doi/10.1145/582095.582099

3. M. Stonebraker, L. A. Rowe. The Design of Postgres. SIGMOD 1986. https://dl.acm.org/doi/10.1145/16894.16888

4. S. Ghemawat, H. Gobioff, S.-T. Leung. The Google File System. SOSP 2003. https://dl.acm.org/doi/10.1145/945445.945450

5. J. Dean, S. Ghemawat. MapReduce: Simplified Data Processing on Large Clusters. OSDI 2004. https://www.usenix.org/legacy/events/osdi04/tech/dean.html

6. F. Chang et al. Bigtable: A Distributed Storage System for Structured Data. OSDI 2006. https://research.google/pubs/pub27898/

7. G. DeCandia et al. Dynamo: Amazon’s Highly Available Key-value Store. SOSP 2007. https://dl.acm.org/doi/10.1145/1294261.1294281

8. J. C. Corbett et al. Spanner: Google’s Globally-Distributed Database. OSDI 2012. https://research.google/pubs/pub39966/

9. B. Dageville et al. The Snowflake Elastic Data Warehouse. SIGMOD 2016. https://dl.acm.org/doi/10.1145/2882903.2903741

10. M. Armbrust et al. Lakehouse: A New Generation of Open Platforms That Unify Data Warehousing and Advanced Analytics. CIDR 2021. https://www.cidrdb.org/cidr2021/papers/cidr2021_paper17.pdf

11. D. Huang et al. TiDB: A Raft-based HTAP Database. PVLDB 13(12):3072–3084, 2020. https://www.vldb.org/pvldb/vol13/p3072-huang.pdf

12. T. Kraska et al. The Case for Learned Index Structures. SIGMOD 2018. https://dl.acm.org/doi/10.1145/3183713.3196909

13. R. Marcus et al. Bao: Making Learned Query Optimization Practical. SIGMOD 2021. https://dl.acm.org/doi/10.1145/3448016.3452838

14. Y. A. Malkov, D. A. Yashunin. Efficient and Robust Approximate Nearest Neighbor Search Using Hierarchical Navigable Small World Graphs. IEEE TPAMI, 2018. https://arxiv.org/abs/1603.09320

15. S. Jayasuriya et al. DiskANN: Fast Accurate Billion-point Nearest Neighbor Search on a Single Node. NeurIPS 2019. https://papers.nips.cc/paper_files/paper/2019/hash/09853c7fb1d3f8ee67a61b6bf4a7f8e6-Abstract.html

16. J. M. Hellerstein, P. Alvaro. Keeping CALM: When Distributed Consistency Is Easy. CACM 63(9):72–81, 2020. https://cacm.acm.org/research/keeping-calm/

17. D. Das et al. Socrates: The New SQL Server in the Cloud. SIGMOD 2019. https://dl.acm.org/doi/10.1145/3299869.3314047

18. W. Cao et al. PolarFS: An Ultra-low Latency and Failure Resilient Distributed File System for Shared Storage Cloud Database. PVLDB 11(12):1849–1862, 2018. https://www.vldb.org/pvldb/vol11/p1849-cao.pdf

19. D. Van Aken et al. Automatic Database Management System Tuning Through Large-scale Machine Learning. SIGMOD 2017. https://dl.acm.org/doi/10.1145/3035918.3064029

20. PostgreSQL Documentation, pgvector 扩展文档，https://github.com/pgvector/pgvector

21. Apache Iceberg 官方文档，https://iceberg.apache.org/docs/latest/

22. Delta Lake 官方文档，https://docs.delta.io/latest/index.html

下一篇：【数据库研究前沿】如何读数据库顶会论文：SIGMOD/VLDB/CIDR 阅读路线