提交 2413ea0e 编写于 作者: V Vonng

移除无关笔记

上级 16261671
# db
# 设计数据密集型应用 - 中文翻译
> 不懂数据库的全栈工程师不是好架构师
>
> —— Vonng
- 作者: [Martin Kleppmann](https://martin.kleppmann.com)
- 原书名称:[《Designing Data-Intensive Application》](http://shop.oreilly.com/product/0636920032175.do)
- 译者:[冯若航]( http://vonng.com/about) (fengruohang@outlook.com )
- 建议本地使用[Typora](https://www.typora.io)以获取最佳阅读体验。
-------------
## 法律声明
## [设计数据密集型应用 - 中文翻译](ddia/README.md)
译者纯粹出于学习目的与个人兴趣翻译,本译文只供学习研究参考之用,不得公开传播发行,用于商业用途。有能力阅读英文书籍者请购买正版支持。
译者保留对译文的署名权,其他权利以原作者和出版社的主张为准,侵删。
- 作者: Martin Kleppmann
- 原书名称:《Designing Data-Intensive Application》
- 译者:[冯若航]( http://vonng.com/about) (fengruohang@outlook.com )
- 建议本地使用[Typora](https://www.typora.io)以获取最佳阅读体验。
-------------
## 译序
> 不懂数据库的全栈工程师不是好架构师
>
> —— Vonng
现今,尤其是在互联网领域,大多数应用都属于数据密集型应用。本书从底层数据结构到顶层架构设计,将数据系统设计中的精髓娓娓道来。其中的宝贵经验无论是对架构师,DBA、还是后端工程师、甚至产品经理都会有帮助。
这是一本理论结合实践的书,书中很多问题,译者在实际场景中都曾遇到过,读来让人击节扼腕。如果能早点读到这本书,该少走多少弯路啊!
这也是一本深入浅出的书,讲述概念的来龙去脉而不是卖弄定义,介绍事物发展演化历程而不是事实堆砌,将复杂的概念讲述的浅显易懂,但又直击本质不失深度。每章最后的引用质量非常好,是深入学习各个主题的绝佳索引。
本书为数据系统的设计、实现、与评价提供了很好的概念框架。读完并理解本书内容后,读者可以轻松看破大多数的技术忽悠,与技术砖家撕起来虎虎生风🤣。
本书为数据系统的设计、实现、与评价提供了很好的概念框架。读完并理解本书内容后,读者可以轻松看破大多数的技术忽悠,与技术砖家撕起来虎虎生风🤣。
这是2017年译者读过最好的一本技术类书籍,这么好的书没有中文翻译,实在是遗憾。某不才,愿为先进技术文化的传播贡献一分力量。既可以深入学习有趣的技术主题,又可以锻炼中英文语言文字功底,何乐而不为?
......@@ -35,17 +39,15 @@
> 在我们的社会中,技术是一种强大的力量。数据、软件、通信可以用于坏的方面:不公平的阶级固化,损害公民权利,保护既得利益集团。但也可以用于好的方面:让底层人民发出自己的声音,让每个人都拥有机会,避免灾难。本书献给所有将技术用于善途的人们。
---------
> 计算是一种流行文化,流行文化鄙视历史。 流行文化关乎个体身份和参与感,与合作无关。它活在当下,也与过去和未来无关。 我认为大部分(为钱)写代码的人就是这样, 他们不知道他们的文化来自哪里。
> ​计算是一种流行文化,流行文化鄙视历史。 流行文化关乎个体身份和参与感,但与合作无关。流行文化活在当下,也与过去和未来无关。 我认为大部分(为了钱)编写代码的人就是这样的, 他们不知道自己的文化来自哪里。
>
> ​ ——阿兰·凯接受Dobb博士的杂志采访时(2012年)
> ——阿兰·凯接受Dobb博士的杂志采访时(2012年)
## 目录
#### [序言](ddia/preface.md)
## [目录](ddia/README.md)
#### [I. 数据系统基础](ddia/part-i.md)
......@@ -77,33 +79,31 @@
## 翻译计划
机翻:只在乎结构:梳理文章结构、图片、引用、备注。
初翻:保证自己经完全理解本章内容,人工修复显著的错误,重新组织语言。
精翻:确定术语的最终译法,修复格式瑕疵,着力信达雅。
* 机翻:只在乎结构:梳理文章结构、图片、引用、备注。
* 初翻:保证经完全理解本章内容,人工修复显著的错误,重新组织语言。
* 精翻:阅读相关领域文献书籍,确定术语的最终译法,修复格式瑕疵,着力信达雅。
通常机翻一章1个小时左右,初翻一章6小时,精翻一章三到五天。
精翻可以看,初翻凑合看,机翻没法看。精翻太累了,看心情吧。
| 章节 | 进度 |
| ---------------------------------- | ------------ |
| 序言 | 机翻 |
| 第一部分:数据系统基础 ——概览 | 初翻 |
| 第一章:可靠性、可扩展性、可维护性 | **精翻** |
| 第二章:数据模型与查询语言 | 初翻 |
| 第三章:存储与检索 | 初翻 |
| 第四章:编码与演化 | 初翻 |
| 第二部分:分布式数据——概览 | 初翻 |
| 第五章:复制 | 初翻 |
| 第六章:分片 | 初翻 |
| 第七章:事务 | **精翻 50%** |
| 第八章:分布式系统的麻烦 | 机翻 |
| 第九章:一致性与共识 | 机翻 |
| 第三部分:前言 | 机翻 |
| 第十章:批处理 | 机翻 |
| 第十一章:流处理 | 机翻 |
| 第十二章:数据系统的未来 | 机翻 |
| 术语表 | - |
| 后记 | 机翻 |
\ No newline at end of file
精翻可以看,机翻基本没法看,初翻对于业内人士能凑合看。
| 章节 | 计划 | 进度 |
| ---------------------------------- | :--: | ------------ |
| 序言 | | 机翻 |
| 第一部分:数据系统基础 ——概览 | | 初翻 |
| 第一章:可靠性、可扩展性、可维护性 | | **精翻** |
| 第二章:数据模型与查询语言 | | 初翻 |
| 第三章:存储与检索 | | 初翻 |
| 第四章:编码与演化 | | 初翻 |
| 第二部分:分布式数据——概览 | | 初翻 |
| 第五章:复制 | | 初翻 |
| 第六章:分片 | | 初翻 |
| 第七章:事务 | | **精翻 50%** |
| 第八章:分布式系统的麻烦 | | 机翻 |
| 第九章:一致性与共识 | | 机翻 |
| 第三部分:前言 | | 机翻 |
| 第十章:批处理 | | 机翻 |
| 第十一章:流处理 | | 机翻 |
| 第十二章:数据系统的未来 | | 机翻 |
| 术语表 | | - |
| 后记 | | 机翻 |
\ No newline at end of file
......@@ -16,7 +16,7 @@
又是一本深入浅出的书,按照事物发展演化的历程来介绍,将复杂的概念讲述的浅显易懂,但又直击本质,不失深度。每章最后的参考引用质量非常好,是进一步深入学习各个主题的绝佳索引。
本书为系统的设计、实现、与评价提供了很好的概念框架。读完并理解本书内容后,读者可以轻松看破大多数的技术忽悠,与技术砖家撕起来虎虎生风。
本书为系统的设计、实现、与评价提供了很好的概念框架。读完并理解本书内容后,读者可以轻松看破大多数的技术忽悠,与技术砖家撕起来虎虎生风。
这是2017年译者读过最好的一本技术类书籍,这么好的书没有中文翻译,实在是遗憾。某不才,愿为先进技术文化的传播贡献一分力量。既可以深入学习有趣的技术主题,又可以锻炼中英文语言文字功底,何乐而不为呢?
......@@ -40,7 +40,7 @@
### [数据系统的基石](part-i.md)
1. [可靠性、可扩展性、可维护性](ch1.md)
1. [可靠性、可扩展性、可维护性](ch1.md)
2. [数据模型与查询语言](ch2.md)
3. [存储与检索](ch3.md)
4. [编码与演化](ch4.md)
......@@ -78,26 +78,26 @@
精翻可以看,初翻凑合看,机翻没法看。精翻太累了,看心情吧。
| 章节 | 文件 | 计划 | 进度 |
| ------ | ------ | ---- | ---- |
| 序言 | [preface.md](preface.md) | | 机翻 |
| 第一部分:数据系统基础 ——概览 | [part-i.md](part-i.md) | | 初翻 |
| 第一章:可靠性、可扩展性、可维护性 | [ch1.md](ch1.md) | | **精翻** |
| 第二章:数据模型与查询语言 | [ch2.md](ch2.md) | | 初翻 |
| 第三章:存储与检索 | [ch3.md](ch3.md) | | 初翻 |
| 第四章:编码与演化 | [ch4.md](ch4.md) | | 初翻 |
| 第二部分:分布式数据——概览 | [part-ii.md](part-ii.md) | | 初翻 |
| 第五章:复制 | [ch5.md](ch5.md) | | 初翻 |
| 第六章:分片 | [ch6.md](ch6.md) | | 初翻 |
| 第七章:事务 | [ch7.md](ch7.md) | | **精翻 50%** |
| 第八章:分布式系统的麻烦 | [ch8.md](ch8.md) | | 机翻 |
| 第九章:一致性与共识 | [ch9.md](ch9.md) | | 机翻 |
| 第三部分:前言 | [part-iii.md](part-iii.md) | | 机翻 |
| 第十章:批处理 | [ch10.md](ch10.md) | | 机翻 |
| 第十一章:流处理 | [ch11.md](ch11.md) | | 机翻 |
| 第十二章:数据系统的未来 | [ch12.md](ch12.md) | | 机翻 |
| 术语表 | [glossary.md](glossary.md) | | - |
| 后记 | [colophon.md](colophon.md) | | 机翻 |
| 章节 | 文件 | 进度 |
| ------ | ------ | ---- |
| 序言 | [preface.md](preface.md) | 机翻 |
| 第一部分:数据系统基础 ——概览 | [part-i.md](part-i.md) | 初翻 |
| 第一章:可靠性、可扩展性、可维护性 | [ch1.md](ch1.md) | **精翻** |
| 第二章:数据模型与查询语言 | [ch2.md](ch2.md) | 初翻 |
| 第三章:存储与检索 | [ch3.md](ch3.md) | 初翻 |
| 第四章:编码与演化 | [ch4.md](ch4.md) | 初翻 |
| 第二部分:分布式数据——概览 | [part-ii.md](part-ii.md) | 初翻 |
| 第五章:复制 | [ch5.md](ch5.md) | 初翻 |
| 第六章:分片 | [ch6.md](ch6.md) | 初翻 |
| 第七章:事务 | [ch7.md](ch7.md) | **精翻 50%** |
| 第八章:分布式系统的麻烦 | [ch8.md](ch8.md) | 机翻 |
| 第九章:一致性与共识 | [ch9.md](ch9.md) | 机翻 |
| 第三部分:前言 | [part-iii.md](part-iii.md) | 机翻 |
| 第十章:批处理 | [ch10.md](ch10.md) | 机翻 |
| 第十一章:流处理 | [ch11.md](ch11.md) | 机翻 |
| 第十二章:数据系统的未来 | [ch12.md](ch12.md) | 机翻 |
| 术语表 | [glossary.md](glossary.md) | - |
| 后记 | [colophon.md](colophon.md) | 机翻 |
......
此差异已折叠。
......@@ -16,7 +16,7 @@
[TOC]
最近几章中反复出现的主题是系统如何处理错误的事情。例如,我们讨论了**副本故障转移**第156页的“[处理节点中断]()”),**复制延迟**(第161页的“[复制延迟问题](ch6.md#复制延迟问题)”)和事务的控制(第233页的“弱隔离级别”)。当我们了解可能在实际系统中出现的各种边缘情况时,我们会更好地处理它们。
最近几章中反复出现的主题是系统如何处理错误的事情。例如,我们讨论了**副本故障转移**[处理节点中断](#ch5.md#处理节点宕机)”),**复制延迟**(第161页的“[复制延迟问题](ch6.md#复制延迟问题)”)和事务控制(“[弱隔离级别](ch7.md#弱隔离级别)”)。当我们了解可能在实际系统中出现的各种边缘情况时,我们会更好地处理它们。
但是,尽管我们已经谈了很多错误,但最后几章仍然过于乐观。现实更加黑暗。我们现在将我们的悲观主义转向最大化,并假设任何可能出错的东西**都会**出错[^i]。(经验丰富的系统运维会告诉你这是一个合理的假设,如果你问得好,他们可能会一边治疗心理创伤一边告诉你一些可怕的故事)
......@@ -36,15 +36,16 @@
单个计算机上的软件没有根本的原因:当硬件正常工作时,相同的操作总是产生相同的结果(这是确定性的)。如果存在硬件问题(例如,内存损坏或连接器松动),其后果通常是整个系统故障(例如,内核恐慌,“蓝屏死机”,启动失败)。具有良好软件的个人计算机通常功能完全或完全破坏,但不是介于两者之间。
、这是计算机设计中的一个慎重的选择:如果发生内部错误,我们宁愿电脑完全崩溃,而不是返回错误的结果,因为错误的结果很难处理。因此,计算机隐藏了它们所实现的模糊的物理现实,并呈现出一个理想化的系统模型,并以数学完美的方式运作。 CPU指令总是做同样的事情;如果您将一些数据写入内存或磁盘,那么这些数据将保持不变,并且不会被随机破坏。总是正确的计算这个设计目标一直回到第一台数字计算机[3]
、这是计算机设计中的一个慎重的选择:如果发生内部错误,我们宁愿电脑完全崩溃,而不是返回错误的结果,因为错误的结果很难处理。因此,计算机隐藏了它们所实现的模糊的物理现实,并呈现出一个理想化的系统模型,并以数学完美的方式运作。 CPU指令总是做同样的事情;如果您将一些数据写入内存或磁盘,那么这些数据将保持不变,并且不会被随机破坏。总是正确的计算这个设计目标一直回到第一台数字计算机【3】
当你编写运行在多台计算机上的软件时,情况根本不同。在分布式系统中,我们不再处于理想化的系统模型中,我们别无选择,只能面对现实世界的混乱现实。而在现实世界中,如此轶事所示,各种各样的事情可能会出现问题[4]
当你编写运行在多台计算机上的软件时,情况根本不同。在分布式系统中,我们不再处于理想化的系统模型中,我们别无选择,只能面对现实世界的混乱现实。而在现实世界中,如此轶事所示,各种各样的事情可能会出现问题【4】
> 在我有限的经验中,我已经和很多东西打过交道:单个数据中心(DC)中长期存在的网络分区,配电单元PDU故障,开关故障,整个机架意外的电源短路,全直流主干故障,全直流电源故障,以及一个低血糖的司机把他的福特皮卡撞碎在数据中心的HVAC(加热,通风和空气)系统上。而且我甚至不是一个运维。
>
> ——柯达黑尔
在分布式系统中,尽管系统的其他部分工作正常,但系统的某些部分可能会以某种不可预知的方式被破坏。这被称为部分失败。难点在于部分失败是不确定的:如果你试图做任何涉及多个节点和网络的事情,它有时可能会工作,有时会出现不可预知的失败。正如我们将要看到的,你甚至不知道是否成功了,因为消息通过网络传播的时间也是不确定的!
这种不确定性和部分失效的可能性,使得分布式系统难以工作[5]。
### 云计算与超级计算机
......@@ -55,7 +56,7 @@
* 另一个极端是云计算,这种云计算的定义不是很好[6],但通常与多租户数据中心,连接IP网络的商品计算机(通常是以太网),弹性/按需资源分配以及计量计费。
* 传统企业数据中心位于这两个极端之间。
用这些哲学来处理错误的方法非常不同。在超级计算机中,作业通常会检查计算的状态,以便持久存储。如果一个节点出现故障,通常的解决方案是简单地停止整个集群的工作负载。故障节点修复后,计算从上一个检查点重新开始[7,8]。因此,超级计算机更像是一个单节点计算机而不是分布式系统:它通过让它升级成完全失败来处理部分失败 - 如果系统的任何部分发生故障,只是让所有的事情都崩溃(就像单台机器上的内核恐慌)。
用这些哲学来处理错误的方法非常不同。在超级计算机中,作业通常会检查计算的状态,以便持久存储。如果一个节点出现故障,通常的解决方案是简单地停止整个集群的工作负载。故障节点修复后,计算从上一个检查点重新开始【7,8】。因此,超级计算机更像是一个单节点计算机而不是分布式系统:它通过让它升级成完全失败来处理部分失败 - 如果系统的任何部分发生故障,只是让所有的事情都崩溃(就像单台机器上的内核恐慌)。
在本书中,我们将重点放在实现互联网服务的系统上,这些系统通常与超级计算机看起来有很大不同
......@@ -84,7 +85,7 @@
> * 纠错码允许数字数据在通信信道上准确传输,偶尔会出现一些错误,例如由于无线网络上的无线电干扰[12]。
> * IP(Internet协议)不可靠:可能丢弃,延迟,复制或重排数据包。 TCP(传输控制协议)在IP之上提供了更可靠的传输层:它确保丢失的数据包被重新传输,消除重复,并且数据包被重新组装成它们被发送的顺序。
>
> 虽然这个系统可以比它的底层部分更可靠,但它的可靠性总是有限的。例如,纠错码可以处理少量的单比特错误,但是如果你的信号被干扰所淹没,那么通过你的通信信道可以得到多少数据是有根本的限制的[13]。 TCP可以隐藏数据包的丢失,重复和重新排序,但是它不能神奇地消除网络中的延迟。
> 虽然这个系统可以比它的底层部分更可靠,但它的可靠性总是有限的。例如,纠错码可以处理少量的单比特错误,但是如果你的信号被干扰所淹没,那么通过你的通信信道可以得到多少数据是有根本的限制的【13】。 TCP可以隐藏数据包的丢失,重复和重新排序,但是它不能神奇地消除网络中的延迟。
>
> 虽然更可靠的高级系统并不完美,但它仍然有用,因为它处理了一些棘手的低级错误,所以其余的错误通常更容易推理和处理。我们将在第519页的“端到端的论点”中进一步探讨这个问题。
......@@ -98,11 +99,11 @@
互联网和数据中心(通常是以太网)中的大多数内部网络都是异步分组网络。在这种网络中,一个节点可以向另一个节点发送一个消息(一个数据包),但是网络不能保证它什么时候到达,或者是否到达。如果您发送请求并期待响应,则很多事情可能会出错(其中一些如图8-1所示):
1. 您的请求可能已经丢失(可能有人拔掉了网线)。
2. 您的请求可能正在队列中等待,稍后将交付(也许网络或收件人超载)。
3. 远程节点可能失败(可能是崩溃或关机)。
1. 请求可能已经丢失(可能有人拔掉了网线)。
2. 请求可能正在排队,稍后将交付(也许网络或收件人超载)。
3. 远程节点可能已经失效(可能是崩溃或关机)。
4. 远程节点可能暂时停止了响应(可能会遇到长时间的垃圾回收暂停;请参阅第295页上的“暂停进程”),但稍后会再次响应。
5. 远程节点可能已经处理了的请求,但是网络上的响应已经丢失(可能是网络交换机配置错误)。
5. 远程节点可能已经处理了的请求,但是网络上的响应已经丢失(可能是网络交换机配置错误)。
6. 远程节点可能已经处理了您的请求,但是响应已经被延迟并且稍后将被传递(可能是网络或者您自己的机器过载)。
![](img/fig8-1.png)
......@@ -609,7 +610,7 @@ Web应用程序确实需要预期受终端用户控制的客户端(如Web浏
安全性通常被非正式地定义为没有什么不好的事情发生,而活着就像最终发生的事情一样。但是,最好不要过多地阅读那些非正式的定义,因为好与坏的含义是主观的。安全性和活性的实际定义是精确的和数学的[90]:
* 如果安全属性被违反,我们可以指向一个特定的时间点(例如,如果违反了唯一性属性,我们可以确定重复的防护令牌返回的特定操作) 。违反安全财产后,违规行为不能撤销 - 损害已经完成
* 如果安全属性被违反,我们可以指向一个特定的时间点(例如,如果违反了唯一性属性,我们可以确定重复的防护令牌返回的特定操作) 。违反安全属性后,违规行为不能撤销——损失已经发生
* 活性属性反过来:在某个时间点(例如,一个节点可能发送了一个请求,但还没有收到响应),它可能不成立,但总是希望在未来(即通过接受答复)。
区分安全性和活性属性的一个优点是可以帮助我们处理困难的系统模型。对于分布式算法,在系统模型的所有可能情况下,要求安全属性始终保持是常见的[88]。也就是说,即使所有节点崩溃,或者整个网络出现故障,算法仍然必须确保它不会返回错误的结果(即保证安全性得到满足)。
......@@ -624,7 +625,7 @@ Web应用程序确实需要预期受终端用户控制的客户端(如Web浏
法定人数算法(请参见第179页的“读写法定人数”)依赖节点来记住它声称存储的数据。如果一个节点可能患有健忘症,忘记了以前存储的数据,这会打破法定条件,从而破坏算法的正确性。也许需要一个新的系统模型,在这个模型中,我们假设稳定的存储大多存在崩溃,但有时可能会丢失。但是那个模型就变得更难以推理了。
算法的理论描述可以简单宣称一些事在假设上是不会发生的——在非拜占庭式系统中。但实际上我们还是需要对可能发生和不可能发生的故障做出假设,真实世界的实现,仍然会包括处理“假设上不可能”情况的代码,即使代码可能就是`printf("你逊爆了")``exit(666)`,实际上也就是留给运维来擦屁股。(这可以说是计算机科学和软件工程间的一个差异)。
算法的理论描述可以简单宣称一些事在假设上是不会发生的——在非拜占庭式系统中。但实际上我们还是需要对可能发生和不可能发生的故障做出假设,真实世界的实现,仍然会包括处理“假设上不可能”情况的代码,即使代码可能就是`printf("you sucks")``exit(666)`,实际上也就是留给运维来擦屁股。(这可以说是计算机科学和软件工程间的一个差异)。
这并不是说理论上抽象的系统模型是毫无价值的,恰恰相反。它们对于将实际系统的复杂性降低到一个我们可以推理的可处理的错误是非常有帮助的,以便我们能够理解这个问题,并试图系统地解决这个问题。我们可以证明算法是正确的,通过显示它们的属性总是保持在某个系统模型中
......@@ -642,7 +643,7 @@ Web应用程序确实需要预期受终端用户控制的客户端(如Web浏
这种部分失效可能发生的事实是分布式系统的决定性特征。每当软件试图做任何涉及其他节点的事情时,就有可能偶尔会失败,或者随机变慢,或者根本没有响应(最终超时)。在分布式系统中,我们试图将部分故障的容忍度建立到软件中,这样整个系统即使在某些组成部分被破坏的情况下也可以继续运行。
为了容忍错误,第一步是检测它们,但即使这样也很难。大多数系统没有检测节点是否发生故障的准确机制,所以大多数分布式算法依靠超时来确定远程节点是否仍然可用。但是,超时无法区分网络和节点故障,并且可变的网络延迟有时会导致节点被错误地怀疑发生故障。此外,有时一个节点可能处于降级状态:例如,由于驱动程序错误[94],千兆网络接口可能突然下降到1 Kb / s的吞吐量。这样一个“跛行”而不是死的节点可能比一个干净的故障节点更难处理。
为了容忍错误,第一步是检测它们,但即使这样也很难。大多数系统没有检测节点是否发生故障的准确机制,所以大多数分布式算法依靠超时来确定远程节点是否仍然可用。但是,超时无法区分网络和节点故障,并且可变的网络延迟有时会导致节点被错误地怀疑发生故障。此外,有时一个节点可能处于降级状态:例如,由于驱动程序错误[94],千兆网络接口可能突然下降到1 Kb/s的吞吐量。这样一个“跛行”而不是死的节点可能比一个干净的故障节点更难处理。
一旦检测到故障,使系统容忍它是不容易的:没有全局变量,没有共享内存,没有共同的知识或机器之间的任何其他种类的共享状态。节点甚至不知道现在几点了,更不用说更深刻的了。信息从一个节点流向另一个节点的唯一方法是通过不可靠的网络发送信息。重大决策不能由一个节点安全地完成,因此我们需要从其他节点获得帮助的协议,并争取达到法定人数。
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册