【数据库研究前沿】系列总结：2026 开发者选型矩阵与开放问题

这是【数据库研究前沿】系列的第 25 篇，也是收尾篇。

从第 01 篇的系列导论开始，我们用 24 篇文章走了七条主线。现在是时候把散落的观察收回成一张图，并且诚实地列出所有还没有答案的问题。

写这篇总结时，我刻意避免两种常见写法：第一种是”未来十年数据库会如何”的大预测——五十年数据库史已经反复证明这种预测很少应验；第二种是”我最看好的系统是 X”的推荐——任何具体系统的推荐都会在两年内过时。

取而代之，本文只做两件事：

1. 选型决策矩阵：按负载类型给出 2026 年的”首选方向 + 候选系统 + 论文指引”。这张矩阵不保证最优，但能把读者从”零信息”状态带到”知道去哪里深读”的位置；
2. 开放问题清单：12 个在本系列里反复出现、仍未收敛的问题。把它们写下来，既是给读者的研究方向参考，也是对整个系列的诚实收尾。

一、七条主线的再回看

1.1 主线 1 · AI-Native 数据库（03–07）

五篇文章走完之后可以得到一个并不乐观的判断：AI-Native 在 2026 年仍处于”组件替换”而非”范式革命”阶段。

• 学习型查询优化器：Bao 式的”hint 选择器”比 Neo 式的”重建优化器”更容易落地；
• 学习型索引再审视：ALEX、PGM 在只读和缓存场景仍然有效，通用 OLTP 仍首选 B+Tree；
• 自治数据库十年复盘：OtterTune、NoisePage 的遗产主要落在”参数推荐”层面，自动切分区、自动加索引尚未形成稳定实践；
• Text-to-SQL 与 Agentic Query：BIRD、Spider 2.0 上的准确率进入”可辅助但不可独立”的阶段；
• 数据库作为 LLM 记忆体：语义缓存与 RAG 一致性仍在摸索，没有事实上的标准。

整体落地度：⭐⭐（部分组件可用，整体架构未成型）

1.2 主线 2 · 向量与多模态检索（08–11）

这是 2022–2026 年工程落地最快的主线。

• 向量索引深度解读：HNSW 是内存型默认、DiskANN/SPANN 是单机十亿级默认；
• 向量 + 标量混合检索：ACORN、pgvector 的”先过滤后检索 / 先检索后过滤”策略已有明确选型依据；
• GraphRAG 与图增强检索：仍在快速变化，查询语言缺失是最大空白；
• 多模态数据库：张量存储尚无统一抽象，pgvector + 对象存储的组合是最小可用栈。

整体落地度：⭐⭐⭐⭐

1.3 主线 3 · HTAP、存算分离与云原生（12–15）

经典话题，但在 2026 年仍有新进展。

• HTAP 新范式：TiDB、SingleStore、F1 Lightning、Lakehouse 形成四种不同的”边界划分”；
• Serverless 数据库：Neon 的”bottomless PostgreSQL”给出了最低成本方案；
• Disaggregated DB 合集：Socrates、PolarDB、Taurus 在细节上高度收敛；
• 共享内存数据库复兴：RDMA / CXL 重新引发讨论，仍未形成工业可用系统。

整体落地度：⭐⭐⭐⭐

1.4 主线 4 · 新硬件冲击（16–18）

工业化节奏比论文慢得多。

• CXL 3.0 与内存池化：硬件层 2025 年才广泛量产，数据库适配仍处于原型阶段；
• 近数据处理与可计算存储：Smart SSD 与 DPU offload 在云厂商内部已规模使用，开源数据库尚未形成统一接口；
• ZNS SSD 与下一代 NVM：PMEM 退场后的”下一代 NVM 路线”尚无赢家。

整体落地度：⭐⭐（仅云厂商内部有规模化使用）

1.5 主线 5 · 隐私、安全与主权（19–21）

合规驱动大于技术驱动。

• TEE 数据库：SGX 被 Intel 部分退场，TDX / AMD SEV / ARM CCA 仍在分裂；
• 差分隐私数据库：Google ZetaSQL DP、Uber Chorus 等工业实现存在，但参数调优依赖专家；
• 加密查询的边界：FHE 的几个数量级性能差距短期无法弥合，PIR 在特定场景可用。

整体落地度：⭐⭐（强合规场景已用）

1.6 主线 6 · 新范式与新理论（22–24）

• CRDT 与 CALM 定理再读：CRDT 进入生产系统（Automerge、Yjs、Riak），CALM 在数据库里仍主要是分析工具；
• 流批一体再讨论：Materialize、RisingWave、Feldera 三家同时证明增量视图维护的工程可行性；
• 湖仓一体一致性：Iceberg 已成为事实标准，但写入事务边界、并发冲突仍是活跃战场。

整体落地度：⭐⭐⭐⭐

1.7 七条主线的 2026 年”可用阈值”

读者常问一个具体问题：“这些方向现在可以在生产用吗？”下面给出笔者的主观回答。

“可用阈值”不是精确的工业统计，而是笔者结合公开案例的主观判断。遇到矛盾时，请以你自己的负载测试为准。

二、2026 开发者选型决策矩阵

这一节是本文的核心工具。先定位负载类型 → 得到推荐方向 → 进入对应深度文章。

2.1 按负载类型的选型矩阵

2.2 决策树：从负载到方向

如果上表仍然难以映射，可以按这张决策树走：

Q1. 是否需要写事务？
├─ 否 → Q2
└─ 是 → Q3

Q2. 读模式是？
├─ 点查（键查找） → KV / 文档 / 向量库
├─ 范围扫描 / 聚合 → 列存 OLAP / Lakehouse
└─ 图遍历 → 图数据库

Q3. 数据规模？
├─ 单机 (<1TB) → PostgreSQL / MySQL
└─ 需分布式 → Q4

Q4. 是否要同时做分析？
├─ 否（纯 OLTP） → CockroachDB / TiDB / YugabyteDB
└─ 是 → HTAP (TiDB / SingleStore) 或 CDC 到 Lakehouse

2.3 反面决策：什么时候不要用某方向

选型矩阵常被忽略的一面，是”什么时候不要用某个方向”。下面是本系列各篇反复出现的警告：

2.4 三张典型系统的”一页纸选型”

场景 A · AI 应用的数据底座

用户查询 → 语义缓存 (Redis+embedding) → pgvector (top-k) → PostgreSQL (结构化关联)
                                         └─ 大于 1 亿向量时 → Milvus / Qdrant
                                         └─ 跨文档推理时 → GraphRAG (自建)

对应阅读：第 08 + 第 09 + 第 10。

场景 B · 金融级 HTAP

交易 OLTP → TiDB / OceanBase / CockroachDB（主库）
             └─ 分析副本（TiFlash / 列存）
                                 └─ 全量归档 → Lakehouse (Iceberg)
                                                 └─ BI / ML

对应阅读：第 12 + 第 14 + 第 24。

场景 C · 合规驱动的 SaaS 数据平台

客户数据 → PostgreSQL (按租户分 schema) → DP-SQL 聚合接口 → 分析看板
                                        └─ TEE enclave → 联邦查询

对应阅读：第 19 + 第 20 + 第 21。

2.5 从选型矩阵回到工程实践

决策矩阵给出方向，真正落地还需要三步：

1. 版本对齐：确认系统的 LTS / GA 版本与本系列对应文章的版本一致；
2. 容量预估：先用真实数据的 1/10 或 1/100 跑 benchmark，再外推；
3. 回归路径：任何新方向都应当有”退回旧方案”的路径，至少保留原始数据或双写。

三、12 个开放问题

本节列出在七条主线中反复出现、尚无共识的问题。每一条都是潜在的研究题目，也是工程上”暂时不要押重注”的信号。

3.1 Text-to-SQL 的语义一致性边界

LLM 生成的 SQL 在语法上几乎总是正确，在语义上却可能和自然语言意图不一致（例如混淆”平均”与”中位数”）。如何在执行前对 SQL 做语义验证，或者让模型对不确定的部分显式提问，目前没有工业标准。

相关篇：第 06 Text-to-SQL。

3.2 HTAP 行列同步的 freshness SLA

几乎所有 HTAP 系统都承诺”毫秒级到秒级”的行列同步延迟，但没有一个系统把这个 SLA 写成契约——在极端写入尖峰下该延迟可能退化到分钟级。形式化 freshness SLA，并让应用按需降级，是一个开放问题。

相关篇：第 12 HTAP。

3.3 CXL 内存池化下的缓冲池重构

传统缓冲池（Buffer Pool）把”DRAM vs 磁盘”作为两级。CXL 引入第三级”远端内存”，其延迟在 DRAM 与 NVMe 之间。是否应该引入”三级缓冲池”？如何避免远端内存成为新的一致性瓶颈？2026 年尚无共识。

相关篇：第 16 CXL、第 15 共享内存数据库。

3.4 TEE 侧信道与工程对抗

Spectre、Foreshadow、SGAxe 等侧信道攻击让 TEE 的威胁模型持续收紧。数据库作为 TEE 内部的复杂应用，是否需要额外的”侧信道感知查询规划”？这是 2026 年仍在发散的方向。

相关篇：第 19 TEE 数据库。

3.5 DP 在 OLAP 的实用化精度边界

当前 DP-SQL 的精度-隐私权衡主要依赖 DBA 或数据科学家手工设定 epsilon。自动选择 epsilon、跨查询预算分配，仍缺乏工业级标准。

相关篇：第 20 差分隐私。

3.6 Learned Component 的稳定性与回滚

学习型组件（QO / 索引 / 基数估计）在数据漂移下的退化是工程落地最大障碍。如何检测漂移、如何在线回滚到非学习型基线、如何保证最坏情况延迟，是所有学习型方向共同的问题。

相关篇：第 03、第 04、第 05。

3.7 GraphRAG 的查询语言空白

GraphRAG 把图结构嵌进 RAG 流程，但如何用一种可组合的语言表达”从向量到图再回向量”的查询，目前业界完全没有标准。Cypher、Gremlin、SPARQL 都只覆盖了一部分。

相关篇：第 10 GraphRAG、第 11 多模态。

3.8 Serverless 数据库的冷启动下限

Neon、Aurora Serverless v2 已经把冷启动压到亚秒级，但从 0 到首次查询的延迟仍在 500ms–几秒之间波动。如何把冷启动做到 100ms 以下，使得”无连接”模式真正可用，仍是开放问题。

相关篇：第 13 Serverless DB。

3.9 Lakehouse 的并发写入事务边界

Iceberg 的 optimistic concurrency 在高并发写入下冲突回滚率会升高；Delta 的事务日志存在 “checkpoint 频率 vs 启动性能” 的权衡；Hudi 的 MOR 在合并尾部延迟仍不稳定。统一的”写入事务 SLA”定义尚未出现。

相关篇：第 24 Lakehouse。

3.10 可计算存储的抽象层

Smart SSD、DPU offload 在云厂商内部规模使用，但对外的编程接口（谁决定哪部分下推、错误如何报告、如何兼容现有 SQL 引擎）仍未形成标准。

相关篇：第 17 近数据处理。

3.11 CRDT × 关系代数

CRDT 目前主要用于文档、计数、集合。关系代数层面的 CRDT（例如”可合并的关系表”）尚未有广为接受的形式化。单表之上的 JOIN、GROUP BY 的 CRDT 语义，是 CALM 研究的延伸方向。

相关篇：第 22 CRDT 与 CALM。

3.12 增量视图维护的语义等价性

Materialize、RisingWave、Feldera 都声称”SQL 的增量化”，但在窗口函数、递归 CTE、UDF 等边缘语义上各有取舍。给定一份 SQL，能否机械地判断它是否可以增量化，是一个仍未完全解决的判定问题。

相关篇：第 23 流批一体。

3.13 开放问题之间的关联图

把上面 12 个开放问题放在一起看，能发现几对相互依赖的”开放问题组”：

• 稳定性组（3.6 Learned Component + 3.11 CRDT × 关系代数 + 3.12 IVM 语义等价）：共同的挑战是”在保证 SQL 语义完备的前提下引入新技术”；
• 隐私组（3.1 Text-to-SQL 一致性 + 3.4 TEE 侧信道 + 3.5 DP 实用化）：共同的挑战是”如何在不可信环境里保持可用性”；
• 硬件组（3.3 CXL 缓冲池 + 3.10 可计算存储接口）：共同的挑战是”如何把设备侧计算暴露给 SQL 优化器”；
• 架构组（3.2 HTAP freshness + 3.8 Serverless 冷启动 + 3.9 Lakehouse 写入事务）：共同的挑战是”把过去隐含的 SLA 写成契约”。

这种分组提示我们：解决一个开放问题常常需要相邻问题先取得进展。研究者在选题时，选中的往往不是某一个”最难”的问题，而是一个可以引发连锁进展的问题。

四、工程启示：三年内做什么、不做什么

本系列反复强调”不做无来源的未来预测”，这里只做三点有把握的建议。

4.1 可以动手做

1. 把向量检索纳入通用数据库：pgvector、MySQL 9.x 的向量类型让向量能力成为普通 DBA 技能，学习成本低、收益显著。
2. 用 Iceberg / Delta 打通数据湖与数仓：开放表格式可以避免被任一引擎锁死。
3. 在现有 SQL 上加一层增量视图：Materialize、RisingWave 作为边车（sidecar），不改动主库即可获得实时物化视图。
4. 把 Learned Hint 作为可选优化：Bao 式方案与 Postgres/MySQL 已有 hint 机制兼容，失败时可回退。

4.2 可以跟进但不要重押

1. CXL 内存池化：2026 年硬件刚就绪，生产规模应用至少再等 1–2 年。
2. 自治数据库全自动化：参数推荐已可用，自动切分区 / 加索引仍不稳定。
3. LLM 直连数据库的 Agentic Query：对话式 BI 体验已经可用，但错误成本高，需要 human-in-the-loop。
4. GraphRAG：研究方向清晰，但查询接口尚未稳定。

4.3 可以观望的

1. FHE 全流程加密：性能差距仍是几个数量级，2026 年只适合极少数场景。
2. 通用”自适应 CBO”：实验室与生产差距仍大。
3. 统一多模态数据库：尚无赢家。
4. 量子数据库：本系列没有专门成篇，基础物理尚未到工程窗口。

4.4 一张”决策时间轴”

把上面三组建议按时间轴展开，大致是这样：

   现在 (2026)                2028                  2030
     │                          │                      │
     ├── pgvector 生产化         │                      │
     ├── Iceberg 事实标准        │                      │
     ├── 实时 IVM 边车           │                      │
     │     │                    │                      │
     │     └── Learned Hint 通用 │                      │
     │                          │                      │
     │                          ├── CXL 内存池化生产   │
     │                          ├── GraphRAG 语言定型   │
     │                          │                      │
     │                          │                      └── FHE 实用化？
     │                          │                      └── 自动切分区？
     │                          │                      └── Text-to-SQL 独立？

时间轴不是预测，而是笔者根据当前节奏给出的合理下注区间。读者应该根据自己的业务窗口调整——如果项目生命周期超过 5 年，可以押中间阶段的方向；如果是短期项目，保守选”现在”那一列即可。

五、给读者的最后一页

这个系列总共 25 篇。如果只有时间读 5 篇，我会推荐：

1. 第 01 导论——系列地图；
2. 第 02 读论文——方法论；
3. 第 08 向量索引——2026 年工业落地最快的主线；
4. 第 14 Disaggregated DB——所有云数据库的底座；
5. 本文——2026 年选型矩阵与开放问题。

如果有时间读 10 篇，再加：第 03（Learned QO）、第 12（HTAP）、第 16（CXL）、第 22（CRDT/CALM）、第 24（Lakehouse）。

如果想系统地用一个季度学完，请按第 02 篇介绍的”论文 sprint”方法走：每周一个主线、每周 3–4 小时，三个月后你会在 2026 年数据库研究前沿上拥有完整地图。

最后一句：数据库是一个已有五十年历史、仍在快速演化的领域。它既不像 Web 框架那样每两年推倒重来，也不像某些”基础学科”那样缓慢静止。工程师在这个领域里的价值，正是在”稳定的抽象”和”快速的变化”之间做翻译——把论文里的新想法翻译成项目里的代码、把项目里的新问题翻译成下一篇论文。希望这个系列在这个翻译过程中帮到你。

感谢读到这里。

六、附录 A：按角色给出的”一页纸”选型速查

选型矩阵按负载排列较精确，但一些读者更习惯按自己的角色来找答案。下面是按角色组织的速查表。

6.1 后端工程师（做业务系统）

• 单体应用：PostgreSQL 17 + pgvector + Redis。向量规模 < 5000 万时，pgvector 的 HNSW 足够。
• 微服务拆分：主库仍可用 PostgreSQL；需要跨服务查询时走 Debezium CDC 到 Kafka，下游以 Materialize / RisingWave 做聚合。
• 慢慢出现大表：超过 1TB 后考虑分区表；超过 10TB 后考虑 TiDB / CockroachDB 或迁到 Lakehouse（对分析部分）。
• 踩坑点：不要在业务还没起量时就上分布式数据库，运维复杂度远大于收益。

6.2 数据工程师（做数据平台）

• 批处理层：Spark 或 Trino + Iceberg；小数据量用 DuckDB 代替。
• 流处理层：Flink（通用） 或 RisingWave / Materialize（物化视图）；Feldera 作为新兴选择。
• 元数据层：Hive Metastore 已过时，迁到 Iceberg REST Catalog 或 Unity Catalog。
• 踩坑点：避免被某一个引擎锁死，表格式必须是开放的（Iceberg / Delta / Hudi 选一个）。

6.3 AI / 搜推工程师

• embedding 存储：< 1000 万向量用 pgvector；> 1 亿用 Milvus / Qdrant。
• 混合检索：pgvector 的过滤目前先过滤后索引；Milvus 2.4+ 支持分层过滤；ACORN 算法值得关注。
• 召回 + 精排：召回用 ANN，精排用 Cross-Encoder；数据落地走 Kafka → ClickHouse 做 A/B。
• 踩坑点：向量维度不要盲目取 1024/1536，要基于语料做消融。

6.4 SRE / 平台工程师

• 监控：Prometheus + VictoriaMetrics 或 Grafana Mimir；时序规模大选 ClickHouse。
• 日志：OpenSearch 或 ClickHouse + Grafana Loki；向量化的日志检索是新方向。
• 配置：etcd 或 Consul；小规模单机用 SQLite 也足够。
• 踩坑点：数据库的监控不要只看 QPS，要看 P99、P999 延迟与 WAL 堆积情况。

6.5 安全 / 合规工程师

• 数据脱敏：PostgreSQL 的 pg_anonymizer 扩展；或在 ETL 层做；
• 差分隐私：Google ZetaSQL DP 扩展或 OpenDP 库；
• 租户隔离：行级安全（RLS） + 列加密；大规模多租户用 Citus 的 distribution key。
• 踩坑点：TEE 在非云厂商环境里的运维成本非常高，合规需求不够强时不建议上。

七、附录 B：2026 年不应再使用的技术选择

选型矩阵讲了”做什么”；这一节讲”不做什么”。列出的每一条，都来自本系列各篇文章或笔者在生产环境里的踩坑记录。

7.1 MongoDB 作为唯一事务型数据库

MongoDB 在 4.0 之后支持多文档事务，但性能代价显著。在 2026 年，中等规模以上的事务型工作负载应首选 PostgreSQL 或 CockroachDB / TiDB。MongoDB 仍是文档存储的不错选择，但不应承担核心 OLTP。

7.2 Kafka 作为”数据库”使用

Kafka 作为分布式消息队列与 CDC 总线非常成熟，但有些团队会把 KSQL / Kafka Streams 当作数据库，存储业务状态。随着 Materialize / RisingWave 的出现，这条路不再必要——把持久状态交给真正的数据库，Kafka 只做流。

7.3 Hadoop + Hive 作为新建数据平台

对新项目而言，Hadoop 的运维复杂度已不再合理。新建数据平台应选 Iceberg / Delta + S3 / GCS + Trino / Spark 的组合。老 Hadoop 集群保留即可，不要扩建。

7.4 手写 Raft / Paxos 实现

Raft 的开源实现（etcd/raft、tikv/raft-rs、hashicorp/raft）足够成熟。新项目里”自研 Raft”几乎总是错误的——除非你的要求比这些实现更严苛。本仓库 分布式共识系列 有更深入的讨论。

7.5 把所有 embedding 塞进 Elasticsearch

Elasticsearch 8 以上提供 dense_vector 字段，但其 ANN 在超大规模下性能不如 pgvector / Milvus。Elasticsearch 适合”少量向量 + 强全文检索”场景，不要当成全功能向量数据库。

7.6 依赖 PMEM 的新设计

Intel Optane Persistent Memory 2022 年退场已成定局。任何还在假设 PMEM 的系统设计都应切换到 CXL 或 ZNS SSD。相关教训详见 第 18 篇。

7.7 纯手写 SQL 优化器

除非你在做数据库研究，否则 PostgreSQL / MySQL / DuckDB 的优化器已经足够好。与其自己写一个不完整的 CBO，不如贡献给开源社区或基于 Apache Calcite 扩展。

八、附录 C：本系列的延伸资源

本系列并不孤立，下面是可以配合使用的外部资源。

8.1 追论文

• arXiv cs.DB 订阅（每日）
• PVLDB 每期（每月）
• SIGMOD / CIDR / ICDE 会议官网（每年）
• Andy Pavlo 的 CMU Database Group 每年综述

8.2 追系统

• DuckDB 博客：现代列存引擎设计的最佳教材
• PingCAP / Databricks / Snowflake 工程博客：工业最佳实践
• Neon、Materialize、RisingWave 博客：新系统的设计日志

8.3 配套代码

本系列多篇配有 demo/ 目录：

• 第 03 Learned QO demo：基于 PostgreSQL + pg_hint_plan 的最小 hint 切换
• 第 08 向量索引 demo：pgvector + hnswlib 对比
• 第 09 混合检索 demo：预过滤 vs 后过滤延迟对比
• 第 20 差分隐私 demo：OpenDP + SQL 聚合的最小例子

下载链接在每篇对应文章末尾。所有 demo 都保证离线可跑、依赖版本固定。

九、结语：数据库是一个”慢变量”

2026 年的数据库研究看起来很热闹：LLM、向量、CXL、Lakehouse 同时出现在顶会日程里。但真正推动领域前进的，往往是需要 5–10 年才能收敛的”慢变量”：

• MVCC 从 1981 年 Reed 的博士论文，到 PostgreSQL 90 年代的成熟实现，花了 15 年；
• LSM-Tree 从 1996 年 O’Neil 的原论文，到 RocksDB / Cassandra 的工业化，花了 15 年；
• 向量检索从 HNSW 2016 年的预印本，到成为主流数据库 first-class citizen，花了 8 年；
• CRDT 从 Shapiro 2011 年的原论文，到 Figma / Notion 的产品化，花了 10 年。

下一代数据库的”慢变量”会是什么？也许是 Learned Component 的稳定化、也许是 CXL 内存池化的通用接口、也许是 DP-SQL 的标准参数、也许是 GraphRAG 的查询语言。本系列不下结论。我们能做的，只是把 2026 年的研究前沿诚实地整理下来，等待 5 年后回看。

若有任何错漏或新的进展，欢迎在仓库的 Issue 里讨论。本系列会按季度做一次”勘误 + 新论文补充”的迭代。

祝你在数据库这条慢而宽广的道路上，走得久一点。

十、附录 D：写给三类读者的”下一步”

本系列到这里正式结束。根据读者角色，给出三条具体的”下一步”建议。

10.1 工程师：把一个主线变成可落地的小项目

从本系列 24 条主线里挑一条最贴近自己工作的，做一个 2–4 周的小项目：

• 做向量 RAG 的，尝试把 pgvector 和自己的业务表做一次 JOIN 查询，度量延迟；
• 做 HTAP 的，拿 TiDB / StarRocks 的开源版本，加载一份 TPC-H SF=10 的数据，对比 OLTP 与 OLAP 混合负载下的延迟；
• 做湖仓的，用 DuckDB + Iceberg 跑一个小 ETL，验证并发写入的冲突行为。

小项目的核心价值不是”产出”，而是把论文里的抽象概念变成你手里的可调变量。调过变量的人，选型时会更冷静。

10.2 架构师：写一份公司级的”选型决策记录”（ADR）

把本系列的选型矩阵按公司实际情况裁剪、补充内部系统版本约束、历史踩坑记录，形成一份公司级的 ADR（Architecture Decision Record）。结构建议：

1. 业务上下文（负载规模、合规要求、团队技能）；
2. 候选方案清单；
3. 淘汰原因（每个没选的方案写一句话）；
4. 选中方案的已知局限；
5. 退出条件（什么情况下要回到备选）。

这份 ADR 应该放在公司内网，所有新人入职时阅读。它会成为未来每次”要不要换数据库”讨论的起点。

10.3 研究生：用 12 个开放问题中的 1–2 个作为开题候选

第 25 篇列出的 12 个开放问题都是可以独立成题的方向。选题建议：

• 找 1 个和自己导师方向重合、1 个和自己兴趣重合的候选；
• 对每个候选，写一份 3–5 页的 “research brief”：问题定义、已有工作梳理、可能的切入角度；
• 把 brief 发给 2–3 位领域内的教师或工业研究员，征求反馈。

这个流程比”在实验室等导师指派题目”主动得多，也是笔者观察到在几所学校里最有效的开题方式。

十一、写在最后

从【数据库研究前沿】系列第 01 篇到第 25 篇，加起来近二十万字。写作的出发点其实很朴素：2026 年的数据库研究信息量太大，而且碎片化严重。如果能有一份”面向工程师、诚实、不虚构、中文”的地图，也许可以帮一些和笔者一样在夜里加班追论文的人节省几个月时间。

这个系列会继续维护下去。每季度会有一次小迭代，每年会有一次大迭代。希望若干年后再来读时，你会记得这份地图曾经帮过你；也希望你会在自己的角落里，给下一代工程师画一份更好的地图。

感谢陪伴。

参考文献

1. 【数据库研究前沿】系列 01–24 篇（见本仓库 post/db-frontier/）。

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

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

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

5. M. Armbrust et al. Lakehouse: A New Generation of Open Platforms. CIDR 2021. https://www.cidrdb.org/cidr2021/papers/cidr2021_paper17.pdf

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

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

8. Y. A. Malkov, D. A. Yashunin. HNSW. IEEE TPAMI, 2018. https://arxiv.org/abs/1603.09320

9. S. Jayasuriya et al. DiskANN. NeurIPS 2019. https://papers.nips.cc/paper_files/paper/2019

10. J. M. Hellerstein, P. Alvaro. Keeping CALM. CACM 2020. https://cacm.acm.org/research/keeping-calm/

11. M. Shapiro et al. Conflict-Free Replicated Data Types. SSS 2011. https://hal.inria.fr/inria-00609399v1/document

12. C. Priebe, K. Vaswani, M. Costa. EnclaveDB: A Secure Database Using SGX. IEEE S&P 2018. https://ieeexplore.ieee.org/document/8418608

13. I. Kotsogiannis et al. Architecting a Differentially Private SQL Engine. CIDR 2019. http://cidrdb.org/cidr2019/papers/p125-kotsogiannis-cidr19.pdf

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

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

16. Apache Hudi 官方文档. https://hudi.apache.org/docs/overview

17. Materialize 工程博客. https://materialize.com/blog/

18. RisingWave 工程博客. https://risingwave.com/blog/

19. Neon (Serverless PostgreSQL) 架构文档. https://neon.tech/docs/introduction/architecture-overview

20. PostgreSQL pgvector 扩展. https://github.com/pgvector/pgvector

上一篇：【数据库研究前沿】湖仓一体的一致性模型与事务边界