# DDIA 第二版翻完了：一个跨越八年的 AI 寓言

LLMS 索引： [llms.txt](/llms.txt)

---

今天上午，我开了 10 路 Codex 并行，用不到半天的时间，
把 DDIA 第二版刚放出的最后四章翻译完了。

这一次出来的译文让我很意外：格式、术语、脚注、锚点，基本一步到位；
中文也足够通顺，不再像早些年的“机翻味”。
我当然还会在春节期间做完整审校和细修，但“从底稿到可读成稿”的距离，
确实被 AI 拉平了。

与此同时，另几个终端窗口里，Pigsty 的管控平台在跑开发循环，
文档润色也在并行推进；刚把 [MinIO 的控制台相关内容补齐](/db/minio-resurrect)。
翻译 DDIA，只是今天上午的一条支线。

回想 2017 年翻第一版，我是一个人逐字逐句磨出来的，
前后花了将近三个月的业余时间。
八年过去，同样是 DDIA，翻译从“三个月”变成“一个上午”，变化很大。

但我更想说的是另一句：在 AI 崛起的当下，
DDIA 反而比八年前更值得读。

预览地址：https://ddia.vonng.com

---

## 先说一句背景：DDIA 为什么值得折腾

可能有些读者没听过 DDIA，或者只是隐约知道“好像是本挺有名的书”。
简单说说它的分量。

DDIA 全名 Designing Data-Intensive Applications，
Martin Kleppmann 2017 年出版，封面是一只野猪，江湖人称“野猪书”。
Kleppmann 的背景比较特殊：先在 LinkedIn 做大规模数据基础设施，
后来回剑桥大学做分布式系统研究。
所以这本书站在了一个独特的交叉点上：
学术论文级别的严谨性，解释的却是工业界天天面对的真实问题。

它在全球软件工程行业里获得了一种罕见的“共识级”认可。
在 Hacker News、Blind、Reddit 这些工程师社区里，
它被反复推荐为“每个软件工程师都该读的书”。
在 Google、Meta、Amazon 的工程团队中，
它实际上扮演了一种非官方教材的角色：
没人指定，但系统设计面试、新人 onboarding、架构评审里到处都是它的影子。
亚马逊数据库品类畅销榜首，一占就是八年。

如果拿计算机科学史上的经典来做个坐标系：
Brooks 的《人月神话》定义了软件工程管理的思维框架，
GoF 的《设计模式》定义了面向对象设计的共同语言，
DDIA 在数据系统领域做了同样的事。
它不是发明了什么新理论，而是为一个快速演进且日益复杂的领域，
建立了共同的认知框架和分析语言。

它出版八年后依然经久不衰，核心原因是 Kleppmann 做了一个关键的写作决策：
聚焦原理和权衡，而非具体工具。
LSM-Tree vs B-Tree 的权衡、复制与分区的基本矛盾、一致性模型的层级，
这些不会因为某个产品的兴衰而过时。
工具会死，原理不朽。

当然，DDIA 也不是零门槛读物。
有些章节密度极高，读起来像把一门课压进一章里；
它也不会教你怎么把某个系统从零配到一。
它的定位一直很清楚：给你一套判断力，而不是给你一张操作表。

---

## 一个仓库，见证了 AI 能力的演变

DDIA 中文翻译是一个 GitHub 仓库，22.6K Star，从 2017 年活到现在。
但我今天想说的不是 Star 数，而是这个仓库里沉淀着四个不同时间点的翻译版本，
每一个都定格了当时 AI 翻译能力的水位线。

同一本书，同一个译者，同一套质量标准，变量只有一个：AI。
你甚至不需要相信我的结论，去看历史 diff 就行。

**2017 年，第一版手工精翻。**
纯人力时代的产物。工作流是“机翻→粗翻→精翻”三步走：
Google 翻译铺底，DeepL 润一遍，最后逐句手工精调。
术语怎么译、长句怎么断、段落怎么收束，全靠人。
三个月业余时间，慢，但扎实。这个版本至今仍是整个仓库的风格基线。

**2024 年 9 月，第二版第一部分，ChatGPT 翻译。**
DDIA 第二版在 O'Reilly 放出 Early Access，前四章率先可读。
我决定试试让 AI 来翻：交给当时的 ChatGPT，给了第一版译文做参考，
要求保持风格和术语一致。
结果很现实：能看出它“会翻”，但读起来明显生硬，术语时不时飘。
评论区有人直说“尴尬”，我自己回头看也不忍直视。
那个阶段的 AI，更像是“把英文换成中文词”，离“中文技术写作”还差一口气。

**2025 年 8 月，第二版第二部分，Claude Sonnet 翻译。**
中间四章放出来，这次换了 Claude Code 搭配 Sonnet 3.7。
比 ChatGPT 好了一截，句子更顺、错误更少，但读者反馈仍然是“怪怪的”。
这种“怪”不是语法问题，而是技术写作的节奏、术语的一致性、
概念落点的稳定性。能读，但不舒服。

**2026 年 2 月，第二版第三部分，Codex 翻译。**
也就是今天。最后四章放出，我开了十路 Codex 并行，一个上午全部完成。
这一次不一样了：它能从原始 HTML 里抽取出干净的 Markdown；
它读懂了 2017 年的旧版译文，把风格和语感迁移了过来；
我提前整理的三千多个索引术语，它严格遵守，全书术语高度一致。
出来的译文，直接接近精翻水准。

四个版本，横跨八年，全部留在同一个 Git 仓库里。
如果有人想研究 AI 翻译能力的演进，
这大概是一组相当干净的对照实验：
控制变量是书和人，自变量是 AI，因变量是译文质量。

当然，“一个上午搞定”不意味着我只是按了回车。
术语表是我花功夫整理的，工程流程和提示词是我设计的，
最终的审校和细修也不会省。
AI 再强，也需要一个知道“好的翻译长什么样”的人来把关。
但核心事实摆在那：从三个月到一个上午，两个数量级的变化，
刻在那个仓库的 Git 历史里。

---

## AI 越强，DDIA 越值得读

AI 连翻译 DDIA 都能一个上午搞定，那人还需要读 DDIA 吗？

我的回答是：需要，而且比过去更需要了。

原因不复杂。
我之所以能把 AI 用到接近可交付的程度，不是因为我比别人更会按按钮，
而是因为有 2017 年那一遍苦功打下来的基线：
我知道术语该怎么译，知道哪些句子“看着没错但不对劲”，
也知道这本书真正想表达的权衡在哪里。

没有 2017 年那个苦哈哈的我，就不可能有 2026 年这个开十路并行出活的我。

这其实就是 AI 时代一条很朴素的道理：
**你不需要比 AI 更会翻译、更会写代码、更会设计架构，
但你需要有能力判断 AI 给你的东西对不对、好不好、够不够。**
AI 可以把产出变快，但它不会自动让产出变对。
你要能判断“对不对”，才配享受“快不快”。

这种判断力不是天上掉下来的，它来自你对底层原理的理解。
DDIA 提供的恰恰就是这种理解。

我现在用 AI 写代码，效率确实高了很多，Pigsty v4.0 大量代码都是 AI 生成的。
但越是这样，我越常见到一种“危险的顺滑”：
AI 会非常流畅地给出一个看起来很专业的架构方案，甚至每个名词都用对了。
你如果缺一套判断框架，就容易被它的流畅带跑。

举两个很典型的场景。

**分布式的诱惑。**
AI 很容易给你一套多节点、分片、最终一致性的方案，语气还很笃定。
但 DDIA 会反复提醒你：分布式不是高级形态，它是成本。
你要先问清楚：你真的需要分布式吗？
如果数据量没到那个级别，一台 PostgreSQL 主库加几个只读副本可能就是最优解。
分布式系统的复杂度是有真实代价的，而这个代价，很多人低估了。

**“概念齐全”不等于“决策正确”。**
AI 可以把事务隔离级别、复制一致性、RTO/RPO 讲得头头是道。
但在你的具体业务场景下，该牺牲什么来换取什么？
哪些一致性可以放松，哪些必须守住？
哪些故障要做到秒级恢复，哪些允许分钟级？
这不是背定义的问题，是拍板的问题。
拍板需要框架，而不是术语表。

**DDIA 不是教你操作数据库的手册，手册会被 AI 替代。
它是教你思考数据系统的书，思考框架不会被替代。**

---

## 第二版新在哪：它把“权衡”提到了台面上

第二版不是简单修订。
它更像一次结构性升级：把“权衡”从全书暗线，提成显性入口。

不逐章复述，挑几条最值得关注的变化。

**全新的总纲章节，把架构决策前置。**
第二版新增了一个全新的第一章，实际上是一张路线图：
云服务 vs 自托管、分布式 vs 单节点、OLTP vs OLAP、记录系统 vs 派生数据。
在你进入任何技术细节之前，先拿到一套完整的决策坐标系。
第一版第一章叫“可靠性、可伸缩性、可维护性”，
第二版改成了“数据系统架构中的权衡”。
光是标题的变化就说明了很多。

**向量检索纳入主线。**
存储与检索章节里，向量嵌入检索和 B 树、LSM 树并列出现。
这不是追热点，而是一种判断：
Kleppmann 认为向量检索已经进入数据系统的常规能力范畴。
AI 时代的印记，写进了教科书的主干。

**云原生全面融入。**
云数据仓库、存储计算分离、云时代运维：
从自建集群到云托管服务，2017 到 2025 年间行业最根本的架构迁移被系统性纳入。
相应地，Hadoop MapReduce 等已经退出历史舞台的技术被大幅删减。

**分布式事务回归事务章。**
旧版的事务章基本是一个隔离级别教程，分布式事务放在后面的章节里。
新版做了合并：2PC、3PC、XA 事务、恰好一次消息处理，全部纳入事务章，
从“并发控制入门”升级为“端到端原子性工程指南”。
现代系统的事务边界早就不在单机上了，书的结构跟上了现实。

**从“知道风险”到“管理风险”。**
旧版的分布式系统章主要在说“这些问题会发生”。
新版新增了形式化验证、模型检查、故障注入、确定性模拟测试。
不只告诉你问题存在，还给你一套系统性验证它不会击穿你的方法论。

**伦理独立成章。**
预测分析中的偏见与歧视、隐私与追踪、数据作为权力资产、GDPR：
数据系统的责任不只是技术正确性，还有社会正确性。
这不是政治正确，而是工程现实：
数据系统已经不可避免地被法律与社会约束包围，
架构决策不再只由技术指标决定。

一句话概括：第一版更像“建立共同语言”，第二版更像“给你决策地图”。
更工程，更落地，更现代。
而那些核心原理：B-Tree vs LSM-Tree、复制与分区、一致性模型，依然稳固。
这本身就验证了第一版的写作策略：聚焦原理而非工具。

---

## 怎么读：给不同读者的建议

- **新人：** 先读总纲和基础概念章节，目标是建立坐标系，不要急着读完。
  有了框架，后面遇到具体问题时再回来查对应章节，效率反而更高。
- **有经验的工程师：** 把它当复盘工具，按主题读，重点看权衡与边界。
  每章末尾的参考文献和总结是最好的进阶材料，不要跳过。
- **AI 时代的开发者：** 把它当验收标准。
  当 AI 帮你写了百分之九十九的代码，你需要有能力判断那百分之一的关键决策。
  DDIA 提供的就是这个判断力。

---

## 关于译文质量

我知道有人天然反感“AI 翻译”，这很正常。
过去几年确实有不少“能看但难读”的技术翻译消耗了读者耐心。

所以把我的做法说清楚：AI 在这里是执行层，不是最终把关者。

具体来说，我做了三件事：

1. 术语字典化：把三千多个索引术语的译法固定下来，
   用事实来源的方式约束输出，避免同一概念前后译法不一。
2. 风格有基线：2017 年第一版的表达方式已经被读者接受，
   我把它作为风格参考，让模型迁移语感。
3. 格式直接交付：HTML 到 Markdown 的处理做成稳定流程，
   脚注、锚点、引用一次处理干净。

不过需要说明：目前的版本还没有经过人工最终校对，属于预览版。
等 EAP 结束正式发布时，我会做一轮完整的人工审核。
如果你在阅读中发现问题，欢迎提 issue。
翻译这种事，最怕糊弄，不怕挑刺。

---

## DDIA 与我的八年

最后说点更个人的。

2017 年我翻译第一版的时候，技术圈正处在一个很典型的“工具爆炸期”：
各种分布式数据库、数据中台、大数据体系层出不穷，
很多讨论被营销话术牵着走。
那个时候，不搞分布式好像就落伍了。

我们也试过不少方案：多节点集群、分片架构、不同数据库体系，
玩过 Citus、Cassandra、TiDB，甚至还自研过分布式数据库 ttdb……
后来能下的都下了，留下来的就是“主从 PostgreSQL”这条路。
事实证明这是一条正路。
在当下，就连 OpenAI 这样规模的独角兽，
[核心业务也只是由一套 1 主 50 从的 PostgreSQL 普通集群扛住](/db/openai-pg)。

原因并不玄学。DDIA 给我的最重要影响，不是某个具体技术点，
而是一种朴素的判断方式：先把需求、约束、代价摊开，再谈方案；
能用简单系统解决，就不要用复杂系统自找麻烦。
分布式的复杂度从来不是“写代码的复杂”，
而是“故障、运维、调试、组织能力”的复杂。
很多团队真正缺的不是分布式组件，而是驾驭复杂度的工程能力。

这套思维方式后来贯穿了我做 Pigsty 的很多决策：
不追热点，不赌概念，尽量把系统做成可理解、可维护、可运维的样子。
回头看，DDIA 更像给了我一双眼睛，能穿透噪音，
看清架构设计背后的本质利弊与权衡。

---

## 结语

八年前我翻译了这本书，八年之后，
这依然是对我职业生涯影响最大的一本书。

翻译这本书，从三个月翻到半天，工具变了很多，
但我越来越确定一件事：
工具越强，认知框架层面的基础知识就越重要。

新人读它，建立坐标系，少走三年弯路。
老兵读它，把散落的经验串成一张网。
AI 时代读它，获得那个“判断 AI 对不对”的能力。

第二版在线阅读：https://ddia.vonng.com