merge & fix preface

ch1.md

@@ -2,7 +2,7 @@
 
 ![](img/ch1.png)
 
-> 互联网做得太棒了，以至于多数人将它看作像太平洋这样的自然资源，而不是什么人工产物。上一次出现这种大规模且无差错的技术， 你还记得是什么时候吗？
+> 互联网做得太棒了，以至于大多数人将它看作像太平洋这样的自然资源，而不是什么人工产物。上一次出现这种大规模且无差错的技术， 你还记得是什么时候吗？
 >
 > ——阿兰·凯在接受Dobb博士杂志采访时说（2012年）
 
@@ -34,9 +34,9 @@
 
 ​	定期处理累积的大批量数据
 
-上述组件如果听上去显而易见，那是因为这些**数据系统（data system）**是非常成功的抽象：我们一直不假思索地使用它们并习以为常。绝大多数工程师不会想从零开始编写存储引擎，因为在开发应用时，数据库已经是足够完美的工具了。
+如果这些功能听上去平淡无奇，那是因为这些**数据系统（data system）**是非常成功的抽象：我们一直不假思索地使用它们并习以为常。绝大多数工程师不会幻想从零开始编写存储引擎，因为在开发应用时，数据库已经是足够完美的工具了。
 
-但现实并没有这么简单。不同的应用有着不同的需求，因而数据库系统也是百花齐放，有着各式各样的特性。实现缓存有很多种手段，创建搜索索引也有好几种方法，诸如此类。因此在开发应用前，我们依然有必要先弄清楚最适合手头工作的工具和方法。而且当单个工具解决不了你的问题时，你会意识到组合使用这些工具是挺有难度的。
+但现实没有这么简单。不同的应用有着不同的需求，因而数据库系统也是百花齐放，有着各式各样的特性。实现缓存有很多种手段，创建搜索索引也有好几种方法，诸如此类。因此在开发应用前，我们依然有必要先弄清楚最适合手头工作的工具和方法。而且当单个工具解决不了你的问题时，组合使用这些工具可能还是有些难度的。
 
 本书将是一趟关于数据系统原理、实践与应用的旅程，并讲述了设计数据密集型应用的方法。我们将探索不同工具之间的共性与特性，以及各自的实现原理。
 
@@ -205,7 +205,7 @@
 
 推特的第一个版本使用了方法1，但系统很难跟上主页时间线查询的负载。所以公司转向了方法2，方法2的效果更好，因为发推频率比查询主页时间线的频率几乎低了两个数量级，所以在这种情况下，最好在写入时做更多的工作，而在读取时做更少的工作。
 
-然而方法2的缺点是，发推现在需要大量的额外工作。平均来说，一条推文会发往约75个关注者，所以每秒4.6k的发推写入，变成了对主页时间线缓存每秒345k的写入。但这个平均值隐藏了用户粉丝数差异巨大这一现实，一些用户有超过3000万的粉丝，这意味着一条推文就可能会导致主页时间线缓存的3000万次写入！及时完成这种操作是一个巨大的挑战——推特尝试在5秒内向粉丝发送推文。
+然而方法2的缺点是，发推现在需要大量的额外工作。平均来说，一条推文会发往约75个关注者，所以每秒4.6k的发推写入，变成了对主页时间线缓存每秒345k的写入。但这个平均值隐藏了用户粉丝数差异巨大这一现实，一些用户有超过3000万的粉丝，这意味着一条推文就可能会导致主页时间线缓存的3000万次写入！及时完成这种操作是一个巨大的挑战 —— 推特尝试在5秒内向粉丝发送推文。
 
 在推特的例子中，每个用户粉丝数的分布（可能按这些用户的发推频率来加权）是探讨可扩展性的一个关键负载参数，因为它决定了扇出负载。你的应用程序可能具有非常不同的特征，但可以采用相似的原则来考虑它的负载。
 
@@ -226,7 +226,7 @@
 
 > #### 延迟和响应时间
 >
-> **延迟（latency）**和**响应时间（response time）**通常互当成同义词来使用，但实际上它们并不一样。响应时间是客户所看到的，除了实际处理请求的时间（**服务时间（service time）**）之外，还包括网络延迟和排队延迟。延迟是某个请求等待处理的**持续时长**，在此期间它处于**休眠（latent）**状态，并等待服务【17】。
+> **延迟（latency）**和**响应时间（response time）**经常用作同义词，但实际上它们并不一样。响应时间是客户所看到的，除了实际处理请求的时间（**服务时间（service time）**）之外，还包括网络延迟和排队延迟。延迟是某个请求等待处理的**持续时长**，在此期间它处于**休眠（latent）**状态，并等待服务【17】。
 >
 
 即使不断重复发送同样的请求，每次得到的响应时间也都会略有不同。现实世界的系统会处理各式各样的请求，响应时间可能会有很大差异。因此我们需要将响应时间视为一个可以测量的数值**分布（distribution）**，而不是单个数值。
@@ -237,7 +237,7 @@
 
 **图1-4 展示了一个服务100次请求响应时间的均值与百分位数**
 
-通常报表都会展示服务的平均响应时间。 （严格来讲“平均”一词并不指代任何特定公式，但实际上它通常被理解为**算术平均值（arithmetic mean）**：给定n个值，加起来除以n）。然而如果你想知道“**典型（typical）**”响应时间，那么平均值并不是一个非常好的指标，因为它不能告诉你有多少用户实际上经历了这个延迟。
+通常报表都会展示服务的平均响应时间。 （严格来讲“平均”一词并不指代任何特定公式，但实际上它通常被理解为**算术平均值（arithmetic mean）**：给定 n 个值，加起来除以 n ）。然而如果你想知道“**典型（typical）**”响应时间，那么平均值并不是一个非常好的指标，因为它不能告诉你有多少用户实际上经历了这个延迟。
 
 通常使用**百分位点（percentiles）**会更好。如果将响应时间列表按最快到最慢排序，那么**中位数（median）**就在正中间：举个例子，如果你的响应时间中位数是200毫秒，这意味着一半请求的返回时间少于200毫秒，另一半比这个要长。
 
@@ -245,7 +245,7 @@
 
 为了弄清异常值有多糟糕，可以看看更高的百分位点，例如第95、99和99.9百分位点（缩写为p95，p99和p999）。它们意味着95％，99％或99.9％的请求响应时间要比该阈值快，例如：如果第95百分位点响应时间是1.5秒，则意味着100个请求中的95个响应时间快于1.5秒，而100个请求中的5个响应时间超过1.5秒。如[图1-4](img/fig1-4.png)所示。
 
-响应时间的高百分位点（也称为**尾部延迟（tail latencies）**）非常重要，因为它们直接影响用户的服务体验。例如亚马逊在描述内部服务的响应时间要求时以99.9百分位点为准，即使它只影响一千个请求中的一个。这是因为请求响应最慢的客户往往也是数据最多的客户，也可以说是最有价值的客户——因为他们掏钱了【19】。保证网站响应迅速对于保持客户的满意度非常重要，亚马逊观察到：响应时间增加100毫秒，销售量就减少1％【20】；而另一些报告说：慢1秒钟会让客户满意度指标减少16%【21，22】。
+响应时间的高百分位点（也称为**尾部延迟（tail latencies）**）非常重要，因为它们直接影响用户的服务体验。例如亚马逊在描述内部服务的响应时间要求时以99.9百分位点为准，即使它只影响一千个请求中的一个。这是因为请求响应最慢的客户往往也是数据最多的客户，也可以说是最有价值的客户 —— 因为他们掏钱了【19】。保证网站响应迅速对于保持客户的满意度非常重要，亚马逊观察到：响应时间增加100毫秒，销售量就减少1％【20】；而另一些报告说：慢 1 秒钟会让客户满意度指标减少16%【21，22】。
 
 另一方面，优化第99.99百分位点（一万个请求中最慢的一个）被认为太昂贵了，不能为亚马逊的目标带来足够好处。减小高百分位点处的响应时间相当困难，因为它很容易受到随机事件的影响，这超出了控制范围，而且效益也很小。
 
@@ -386,7 +386,7 @@
 
 不幸的是，使应用可靠、可扩展或可持续并不容易。但是某些模式和技术会不断重新出现在不同的应用中。在接下来的几章中，我们将看到一些数据系统的例子，并分析它们如何实现这些目标。
 
-在本书后面的[第三部分](part-iii.md)中，我们将看到一种模式：几个组件协同工作以构成一个完整的系统（例如[图1-1](img/fig1-1.png)中的）
+在本书后面的[第三部分](part-iii.md)中，我们将看到一种模式：几个组件协同工作以构成一个完整的系统（如[图1-1](img/fig1-1.png)中的例子）
 
 
 

colophon.md

@@ -16,18 +16,18 @@ Martin是一位常规会议演讲者，博主和开源贡献者。他认为，
 
 PostgreSQL DBA @ TanTan
 
-前Alibaba+-Finplus 架构师/全栈工程师 (15.08 ~ 17.12)
+Alibaba+-Finplus 架构师/全栈工程师 (2015 ~ 2017)
 
 
 
 ## 后记
 
-设计数据密集型应用程序封面上的动物是印度野猪（Sus scrofa cristatus），它是在印度，缅甸，尼泊尔，斯里兰卡和泰国发现的一种野猪的亚种。它们与欧洲公猪不同，它们具有较高的背部刷毛，没有羊毛底毛，以及更大，更直的头骨。
+《设计数据密集型应用》封面上的动物是**印度野猪（Sus scrofa cristatus）**，它是在印度，缅甸，尼泊尔，斯里兰卡和泰国发现的一种野猪的亚种。它们与欧洲公猪不同，它们具有较高的背部刷毛，没有羊毛底毛，以及更大，更直的头骨。
 
-印度的野猪有一头灰色或黑色的头发，脊椎上有僵硬的硬毛。男性有突出的犬齿（称为t），用来与对手战斗或抵御掠食者。男性比女性大，但这些物种平均肩高33-35英寸，体重200-300磅。他们的天敌包括熊，老虎和各种大型猫科动物。
+印度的野猪有一头灰色或黑色的头发，脊椎上有僵硬的硬毛。雄性有突出的犬齿（称为T），用来与对手战斗或抵御掠食者。雄性比雌性大，但这些物种平均肩高33-35英寸，体重200-300磅。他们的天敌包括熊，老虎和各种大型猫科动物。
 
-这些动物夜行和杂食 - 他们吃各种各样的东西，包括根，昆虫，腐肉，坚果，浆果和小动物。野猪也被称为通过垃圾和作物田地，造成大量的破坏，并赢得农民的仇恨。他们需要每天吃4,000-4,500卡路里。公猪有一个发达的嗅觉，这有助于他们寻找地下植物材料和挖掘动物。但是，他们的视力很差。
+这些动物夜行且杂食 —— 它们吃各种各样的东西，包括根，昆虫，腐肉，坚果，浆果和小动物。野猪也被称为通过垃圾和作物田地，造成大量的破坏，并赢得农民的仇恨。他们需要每天吃4,000 ~ 4,500卡路里。公猪有着发达的嗅觉，这有助于它们寻找地下的植物材料和挖掘动物。但是它们的视力很差。
 
-野猪在人类文化中一直具有重要意义。在印度教传说中，野猪是毗湿奴神的化身。在古希腊的丧葬纪念碑中，它是一个勇敢的失败者的象征（与胜利的狮子相反）。由于它的侵略，它被描绘在斯堪的纳维亚，日耳曼和盎格鲁 - 撒克逊战士的盔甲和武器上。在中国十二生肖中，它象征着决心和急躁。
+野猪在人类文化中一直具有重要意义。在印度教传说中，野猪是毗湿奴神的化身。在古希腊的丧葬纪念碑中，它是一个勇敢失败者的象征（与胜利的狮子相反）。由于它的侵略，它被描绘在斯堪的纳维亚，日耳曼和盎格鲁 ~ 撒克逊战士的盔甲和武器上。在中国十二生肖中，它象征着决心和急躁。
 
 O'Reilly封面上的许多动物都受到威胁;所有这些对世界都很重要。要了解有关如何提供帮助的更多信息，请访问animals.oreilly.com。封面图片来自Shaw's Zoology。封面字体是URW Typewriter和Guardian Sans。文字字体是Adobe Minion Pro;图中的字体是Adobe Myriad Pro;标题字体是Adobe Myriad Condensed;代码字体是Dalton Maag的Ubuntu Mono。

part-i.md

@@ -5,7 +5,7 @@
 1. [第一章](ch1.md)将介绍本书使用的术语和方法。**可靠性，可扩展性和可维护性** ，这些词汇到底意味着什么？如何实现这些目标？
 2. [第二章](ch2.md)将对几种不同的**数据模型和查询语言**进行比较。从程序员的角度看，这是数据库之间最明显的区别。不同的数据模型适用于不同的应用场景。
 3. [第三章](ch3.md)将深入**存储引擎**内部，研究数据库如何在磁盘上摆放数据。不同的存储引擎针对不同的负载进行优化，选择合适的存储引擎对系统性能有巨大影响。
-4. [第四章](ch4)将对几种不同的 **数据编码**进行比较。特别地分析了他们在应用需求经常变化、模式需要随着时间演变的环境中的表现情况。
+4. [第四章](ch4)将对几种不同的 **数据编码**进行比较。特别研究了这些格式在应用需求经常变化、模式需要随时间演变的环境中表现如何。
 
 第二部分将专门讨论在**分布式数据系统**中特有的问题。
 

preface.md

@@ -1,4 +1,4 @@
-# 序
+# 序言
 
 如果近几年从业于软件工程，特别是服务器端和后端系统开发，那么您很有可能已经被大量关于数据存储和处理的时髦词汇轰炸过了： NoSQL！大数据！Web-Scale！分片！最终一致性！ACID！ CAP定理！云服务！MapReduce！实时！
 
@@ -7,94 +7,96 @@
 * 谷歌，雅虎，亚马逊，脸书，领英，微软和推特等互联网公司正在和巨大的流量/数据打交道，这迫使他们去创造能有效应对如此规模的新工具。
 * 企业需要变得敏捷，需要低成本地检验假设，需要通过缩短开发周期和保持数据模型的灵活性，快速地响应新的市场洞察。
 * 免费和开源软件变得非常成功，在许多环境中比商业软件和定制软件更受欢迎。
-* 处理器主频几乎没有增长，但是多核处理器已经成为标配，网络也越来越快。这意味着并行化只增不减。
+* 处理器主频几乎没有增长，但是多核处理器已经成为标配，网络也越来越快。这意味着并行化程度只增不减。
 * 即使您在一个小团队中工作，现在也可以构建分布在多台计算机甚至多个地理区域的系统，这要归功于譬如亚马逊网络服务（AWS）等基础设施即服务（IaaS）概念的践行者。
 * 许多服务都要求高可用，因停电或维护导致的服务不可用，变得越来越难以接受。
 
-数据密集型应用正在通过利用这些技术进步推动可能性的边界。如果**数据是其主要挑战**（数据量，数据复杂度或数据变化速度），这类应用被称为**数据密集型**，与之相对的是**计算密集型**，即处理器速度是其瓶颈。
+**数据密集型应用（data-intensive applications）**正在通过使用这些技术进步来推动可能性的边界。一个应用被称为**数据密集型**的，如果**数据是其主要挑战**（数据量，数据复杂度或数据变化速度）—— 与之相对的是**计算密集型**，即处理器速度是其瓶颈。
 
-工具和技术迅速适应着这些变化，帮助数据密集型应用程序来存储和处理数据。新型数据库系统（“NoSQL”）已经引起了众多关注，然而消息队列，缓存，搜索索引，批处理和流处理框架以及相关技术也非常重要。这些技术被组合使用在很多应用程序上。
+帮助数据密集型应用存储和处理数据的工具与技术，正迅速地适应这些变化。新型数据库系统（“NoSQL”）已经备受关注，而消息队列，缓存，搜索索引，批处理和流处理框架以及相关技术也非常重要。很多应用组合使用这些工具与技术。
 
-这些充满整个空间的流行语体现出人们对新可能性的热情，这是一件好事。但是，作为软件工程师和架构师，如果要建立良好的应用程序，我们还需要对各种层出不穷的技术及其利弊持有准确而严谨的技术性理解。为此，必须深入挖掘流行语背后的内容。
+这些生意盎然的时髦词汇体现出人们对新的可能性的热情，这是一件好事。但是作为软件工程师和架构师，如果要开发优秀的应用，我们还需要对各种层出不穷的技术及其利弊权衡有精准的技术理解。为了获得这种洞察，我们需要深挖时髦词汇背后的内容。
 
-幸运的是，在技术快速变化的背后，无论您使用的是哪个版本的特定工具，存在一些持久的原则。如果您了解这些原则，您就可以领会这些工具适用于何处，如何充分利用它们，以及如何避免其中的陷阱。这正是本书的初衷。
+幸运的是，在技术迅速变化的背后总是存在一些持续成立的原则，无论您使用了特定工具的哪个版本。如果您理解了这些原则，就可以领会这些工具的适用场景，如何充分利用它们，以及如何避免其中的陷阱。这正是本书的初衷。
 
-本书的目标是帮助您在多样而快速变化的处理和存储数据技术的大观园中找到方向。这本书不是一个特定工具的教程，也不是一本充满干枯理论的教科书。相反，我们将看到一些成功的数据系统示例：一些构成了许多流行应用程序基础，必须在每天的生产中满足可伸缩性，性能和可靠性需求的技术。
+本书的目标是帮助您在飞速变化的数据处理和数据存储技术大观园中找到方向。本书并不是某个特定工具的教程，也不是一本充满枯燥理论的教科书。相反，我们将看到一些成功数据系统的样例：许多流行应用每天都要在生产中会满足可扩展性、性能、以及可靠性的要求，而这些技术构成了这些应用的基础。
 
-我们将深入这些系统的内部，梳理他们的关键算法，讨论他们的原则和他们必须做出的权衡。在这个过程中，我们将尝试寻找有用的方式来思考数据系统 —— 不仅仅关于它们是如何工作的，还包括为什么它们以这种方式工作，以及我们需要问什么问题。
+我们将深入这些系统的内部，理清它们的关键算法，讨论背后的原则和它们必须做出的权衡。在这个过程中，我们将尝试寻找**思考**数据系统的有效方式 —— 不仅关于它们**如何**工作，还包括它们**为什么**以这种方式工作，以及哪些问题是我们需要问的。
 
-阅读本书后，您将能够很好地决定哪种技术适合哪种用途，并了解如何将工具组合起来，为一个良好应用架构奠定基础。您并不能够因此准备好从头开始构建自己的数据库存储引擎的技能，不过幸运地很，这很少是必要的。您将会获得的是，建立起对系统底层运行的敏锐直觉，这样您就有能力推理它们的行为，做出好的设计方案，并追踪任何可能出现的问题。
+阅读本书后，你能很好地决定哪种技术适合哪种用途，并了解如何将工具组合起来，为一个良好应用架构奠定基础。本书并不足以使你从头开始构建自己的数据库存储引擎，不过幸运的是这基本上很少有必要。你将获得对系统底层发生事情的敏锐直觉，这样你就有能力推理它们的行为，做出优秀的设计决策，并追踪任何可能出现的问题。
 
 
 
 ## 本书的目标读者
 
-如果您开发的应用程序具有用于存储或处理数据的某种服务器/后端系统，并且您的应用程序使用互联网（例如，Web应用程序，移动应用程序或连接到互联网的传感器），那么本书就是为您准备的。
+如果你开发的应用具有用于存储或处理数据的某种服务器/后端系统，而且使用网络（例如，Web应用，移动应用或连接到互联网的传感器），那么本书就是为你准备的。
 
-本书适用于热爱编写代码的软件工程师，软件架构师和技术经理。如果您需要就您所从事的系统架构做出决定，例如您需要选择解决某个特定问题的工具，并找出如何最好地应用这些工具来解决问题，那么这本书对您尤其重要。但即使您不能选择您的工具，这本书仍将帮助您更好地了解您所使用工具的长处和短处。
+本书是为软件工程师，软件架构师，以及喜欢写代码的技术经理准备的。如果您需要对所从事系统的架构做出决策 —— 例如您需要选择解决某个特定问题的工具，并找出如何最好地使用这些工具，那么这本书对您尤有价值。但即使你无法选择你的工具，本书仍将帮助你更好地了解所使用工具的长处和短处。
 
-您应该具有构建基于Web的应用程序或网络服务的一些经验，并且您应该熟悉关系数据库和SQL。任何您了解的非关系型数据库和其他与数据相关的工具都会更有帮助，但不是必需的。常见的网络协议如TCP和HTTP的一般理解是有帮助的。编程语言或框架的选择对阅读本书没有任何不同影响。
+您应当具有一些开发Web应用或网络服务的经验，且应当熟悉关系型数据库和SQL。任何您了解的非关系型数据库和其他与数据相关工具都会有所帮助，但不是必需的。对常见网络协议如TCP和HTTP的大概理解是有帮助的。编程语言或框架的选择对阅读本书没有任何不同影响。
 
-如果以下任何一条对您是真的，您会发现这本书很有价值：
+如果以下任意一条对您为真，你会发现这本书很有价值：
 
-* 您想了解如何使数据系统可扩展，例如，支持拥有数百万用户的Web或移动应用程序。
+* 您想了解如何使数据系统可扩展，例如，支持拥有数百万用户的Web或移动应用。
-* 您需要提高应用程序的可用性（最大限度地减少停机时间）和运行稳定。
+* 您需要提高应用程序的可用性（最大限度地减少停机时间），保持稳定运行。
-* 您正在寻找使系统长期易于维护的方法，即使随着需求和技术的变化而变化。
+* 您正在寻找使系统在长期运行过程易于维护的方法，即使系统规模增长，需求与技术也发生变化。
-* 您对事物的运作方式有着天然的好奇心，并且希望知道一些主要网站和在线服务背后发生的事情。这本书打破了各种数据库和数据处理系统的内幕，探索他们设计中的智慧是非常有趣的。
+* 您对事物的运作方式有着天然的好奇心，并且希望知道一些主流网站和在线服务背后发生的事情。这本书打破了各种数据库和数据处理系统的内幕，探索这些系统设计中的智慧是非常有趣的。
 
-有时在讨论可扩展的数据系统时，人们会评论：“你又不在谷歌或亚马逊，别操心可扩展性了，直接上关系数据库。“这个陈述有一定的道理：为了您不需要的规模而构建程序不仅会浪费不必要的精力，并且可能会把您锁死在一个不灵活的设计中。实际上这是“过早优化”的一种形式。不过，选择合适的工具确实很重要，而不同的技术各有优缺点。我们将会看到，关系数据库虽然很重要，但绝不是数据处理的终章。
+有时在讨论可扩展的数据系统时，人们会说：“你又不在谷歌或亚马逊，别操心可扩展性了，直接上关系型数据库”。这个陈述有一定的道理：为了不必要的扩展性而设计程序，不仅会浪费不必要的精力，并且可能会把你锁死在一个不灵活的设计中。实际上这是一种“过早优化”的形式。不过，选择合适的工具确实很重要，而不同的技术各有优缺点。我们将看到，关系数据库虽然很重要，但绝不是数据处理的终章。
 
 
 
 ## 本书涉及的领域
 
-本书不会试图给出详细的指导，说明如何安装或使用特定的软件包或API，因为已经有大量的文档。相反，我们讨论了基本的数据系统的各种原则和权衡，并探讨了不同产品所做出的不同设计决策。
+本书并不会尝试告诉读者如何安装或使用特定的软件包或API，因为已经有大量文档给出了详细的使用说明。相反，我们会讨论数据系统的基石——各种原则与利弊权衡，并探讨了不同产品所做出的不同设计决策。
 
-在电子书版本中，我们包含了在线资源全文的链接。所有链接都在发布时进行了验证，但不幸的是，由于网络的性质，链接往往频繁地中断。如果您遇到链接断开的情况，或者您正在阅读本书的打印副本，则可以使用搜索引擎查找引用。对于学术论文，您可以在Google学术搜索中搜索标题以查找开放获取的PDF文件。或者，您可以在[DDIA-Reference](https://github.com/ept/ddia-references)上找到所有的参考资料，我们在那里维护最新的链接。
+在电子书中包含了在线资源全文的链接。所有链接在出版时都进行了验证，但不幸的是，由于网络的自然规律，链接往往会频繁地破损。如果您遇到链接断开的情况，或者正在阅读本书的打印副本，可以使用搜索引擎查找参考文献。对于学术论文，您可以在Google学术中搜索标题，查找可以公开获取的PDF文件。或者，您也可以在 https://github.com/ept/ddia-references 中找到所有的参考资料，我们在那儿维护最新的链接。
 
-我们主要关注数据系统的体系结构以及它们被集成到数据密集型应用程序中的方式。本书没有讨论部署，操作，安全，管理等领域的空间 —— 这些都是复杂而重要的话题，仅仅在本书中用肤浅的注解讨论它们对它们不公平。它们各自配得上一本单独的书。
+我们主要关注的是数据系统的**架构（architecture）**，以及它们被集成到数据密集型应用中的方式。本书没有足够的空间覆盖部署，运维，安全，管理等领域 —— 这些都是复杂而重要的主题，仅仅在本书中用粗略的注解讨论这些对它们很不公平。每个领域都值得用单独的书去讲。
-
-本书中描述的许多技术都被涵盖在**大数据**这个时髦词的范畴中。然而“大数据”这个术语被滥用，缺乏明确定义，以至于在严肃的工程讨论中没有用处。这本书使用更少歧义的术语，如“单点系统”之于”分布式系统“，或”在线/交互式“之于”离线/批处理系统“。
-
-本书对自由和开放源码的软件（FOSS）有一定偏好，因为阅读，修改和执行源代码是了解一个东西详细工作原理的好方法。开放平台还可以降低供应商垄断的风险。然而，在适当的情况下，我们也讨论专有软件（封闭源码软件，软件即服务，或一些公司内部的仅在文献中描述但未公开发布的软件）。
 
+本书中描述的许多技术都被涵盖在**大数据（Big Data）**这个时髦词的范畴中。然而“大数据”这个术语被滥用，缺乏明确定义，以至于在严肃的工程讨论中没有用处。这本书使用歧义更小的术语，如“单节点”之于”分布式系统“，或”在线/交互式系统“之于”离线/批处理系统“。
 
+本书对自由和开源软件（FOSS）有一定偏好，因为阅读，修改和执行源码是了解一样东西详细工作原理的好方法。开放的平台也可以降低供应商垄断的风险。然而在适当的情况下，我们也会讨论专利软件（闭源软件，软件即服务 SaaS，或一些在文献中描述过但未公开发行的公司内部软件）。
 
 ## 本书纲要
 
 本书分为三部分：
 
-1. 在[第一部分](part-i.md)中，我们会讨论设计数据密集型应用所赖的基本思想。我们从[第1章](ch1.md)开始，讨论我们实际要达到的目标：可靠性，可扩展性和可维护性；我们该如何考虑它们；以及如何实现它们。在[第2章](ch2.md)中，我们比较了几种不同的数据模型和查询语言，看看它们是如何适用于不同的场景。在[第3章](ch3.md)中将讨论存储引擎：数据库如何在磁盘上摆放数据，以便能高效地再次找到它。[第4章](ch4.md)转向数据编码（序列化），以及随时间演化的模式。
+1. 在[第一部分](part-i.md)中，我们会讨论设计数据密集型应用所赖的基本思想。我们从[第1章](ch1.md)开始，讨论我们实际要达到的目标：可靠性，可扩展性和可维护性；我们该如何思考这些概念；以及如何实现它们。在[第2章](ch2.md)中，我们比较了几种不同的数据模型和查询语言，看看它们如何适用于不同的场景。在[第3章](ch3.md)中将讨论存储引擎：数据库如何在磁盘上摆放数据，以便能高效地再次找到它。[第4章](ch4.md)转向数据编码（序列化），以及随时间演化的模式。
 
-2. 在[第二部分](part-ii.md)中，我们从讨论存储在一台机器上的数据转向讨论分布在多台机器上的数据。这对于可扩展性通常是必需的，但带来了各种独特的挑战。我们首先讨论复制（[第5章](ch5.md)），分区/分片（[第6章](ch6.md)）和事务（[第7章](ch7.md)）。我们然后探索关于分布式系统的问题的更多细节（[第8章](ch8.md)），以及在分布式系统中实现共识和一致性意味着什么（[第9章](ch9.md)）。
+2. 在[第二部分](part-ii.md)中，我们从讨论存储在一台机器上的数据转向讨论分布在多台机器上的数据。这对于可扩展性通常是必需的，但带来了各种独特的挑战。我们首先讨论复制（[第5章](ch5.md)），分区/分片（[第6章](ch6.md)）和事务（[第7章](ch7.md)）。然后我们将探索关于分布式系统问题的更多细节（[第8章](ch8.md)），以及在分布式系统中实现一致性与共识意味着什么（[第9章](ch9.md)）。
 
-3. 在[第三部分](part-iii.md)中，我们讨论从其他数据集衍生一些数据集的系统。派生数据经常发生在异构系统中：当没有一个数据库可以把所有事都做好时，应用程序需要集成几个不同的数据库，缓存，索引等等。在[第10章](ch10.md)中我们将从一种批处理派生数据的方法开始，然后我们将在第11章中在此基础上用流处理构建。最后，在[第12章](ch12.md)中，我们将所有内容放在一起，并讨论未来构建可靠，可伸缩和可维护的应用程序的方法。
+3. 在[第三部分](part-iii.md)中，我们讨论那些从其他数据集衍生出一些数据集的系统。衍生数据经常出现在异构系统中：当没有单个数据库可以把所有事情都做的很好时，应用需要集成几种不同的数据库，缓存，索引等。在[第10章](ch10.md)中我们将从一种衍生数据的批处理方法开始，然后在此基础上建立在[第11章](ch11.md)中讨论的流处理。最后，在[第12章](ch12.md)中，我们将所有内容汇总，讨论在将来构建可靠，可伸缩和可维护的应用程序的方法。
 
 
 
 
 ## 参考文献与延伸阅读
 
-本书中讨论的大部分内容已经在其它地方以某种形式出现过了 —— 会议演示文稿，研究论文，博客文章，代码，BUG跟踪器，邮件列表，以及工程习惯中。本书总结了不同来源资料中最重要的想法，并在文本中包含了指向原始文献的指针。 如果你想更深入地探索一个领域，那么每章末尾的参考文献都是很好的资源，其中大部分可以免费在线获取。
+本书中讨论的大部分内容已经在其它地方以某种形式出现过了 —— 会议演示文稿，研究论文，博客文章，代码，BUG跟踪器，邮件列表，以及工程习惯中。本书总结了不同来源资料中最重要的想法，并在文本中包含了指向原始文献的链接。 如果你想更深入地探索一个领域，那么每章末尾的参考文献都是很好的资源，其中大部分可以免费在线获取。
 
 
 
 ## O‘Reilly Safari
 
-[Safari](http://oreilly.com/safari)赛高！
+[Safari](http://oreilly.com/safari) (formerly Safari Books Online) is a membership-based training and reference platform for enterprise, government, educators, and individuals.
+
+Members have access to thousands of books, training videos, Learning Paths, interac‐ tive tutorials, and curated playlists from over 250 publishers, including O’Reilly Media, Harvard Business Review, Prentice Hall Professional, Addison-Wesley Pro‐ fessional, Microsoft Press, Sams, Que, Peachpit Press, Adobe, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, and Course Technology, among others.
+
+For more information, please visit http://oreilly.com/safari.
 
 
 
 ## 致谢
 
-本书融合了学术研究和工业实践的经验，是大量其他人的思想和知识的融合与系统化。在计算中，我们往往会被新的东西所吸引，但是我认为我们有很多东西可以从以前的东西中学习。这本书有超过800篇文章，博客文章，讲座，文档等参考资料，对我来说这是一个宝贵的学习资源。我非常感谢这些材料的作者分享他们的知识。
+本书融合了学术研究和工业实践的经验，融合并系统化了大量其他人的想法与知识。在计算领域，我们往往会被各种新鲜花样所吸引，但我认为前人完成的工作中，有太多值得我们学习的地方了。本书有800多处引用：文章，博客，讲座，文档等，对我来说这些都是宝贵的学习资源。我非常感谢这些材料的作者分享他们的知识。
 
-我也从个人对话中学到了很多东西，这要感谢大量的人花时间讨论想法，耐心地向我解释。特别感谢Joe Adler, Ross Anderson, Peter Bailis, Márton Balassi, Alastair Beresford, Mark Callaghan, Mat Clayton, Patrick Collison, Sean Cribbs, Shirshanka Das, Niklas Ekström, Stephan Ewen, Alan Fekete, Gyula Fóra, Camille Fournier, Andres Freund, John Garbutt, Seth Gilbert, Tom Haggett, Pat Hel‐ land, Joe Hellerstein, Jakob Homan, Heidi Howard, John Hugg, Julian Hyde, Conrad Irwin, Evan Jones, Flavio Junqueira, Jessica Kerr, Kyle Kingsbury, Jay Kreps, Carl Lerche, Nicolas Liochon, Steve Loughran, Lee Mallabone, Nathan Marz, Caitie McCaffrey, Josie McLellan, Christopher Meiklejohn, Ian Meyers, Neha Narkhede, Neha Narula, Cathy O’Neil, Onora O’Neill, Ludovic Orban, Zoran Perkov, Julia Powles, Chris Riccomini, Henry Robinson, David Rosenthal, Jennifer Rullmann, Matthew Sackman, Martin Scholl, Amit Sela, Gwen Shapira, Greg Spurrier, Sam Stokes, Ben Stopford, Tom Stuart, Diana Vasile, Rahul Vohra, Pete Warden, 以及 Brett Wooldridge.
+我也从与人交流中学到了很多东西，很多人花费了宝贵的时间与我讨论想法并耐心解释。特别感谢 Joe Adler, Ross Anderson, Peter Bailis, Márton Balassi, Alastair Beresford, Mark Callaghan, Mat Clayton, Patrick Collison, Sean Cribbs, Shirshanka Das, Niklas Ekström, Stephan Ewen, Alan Fekete, Gyula Fóra, Camille Fournier, Andres Freund, John Garbutt, Seth Gilbert, Tom Haggett, Pat Hel‐ land, Joe Hellerstein, Jakob Homan, Heidi Howard, John Hugg, Julian Hyde, Conrad Irwin, Evan Jones, Flavio Junqueira, Jessica Kerr, Kyle Kingsbury, Jay Kreps, Carl Lerche, Nicolas Liochon, Steve Loughran, Lee Mallabone, Nathan Marz, Caitie McCaffrey, Josie McLellan, Christopher Meiklejohn, Ian Meyers, Neha Narkhede, Neha Narula, Cathy O’Neil, Onora O’Neill, Ludovic Orban, Zoran Perkov, Julia Powles, Chris Riccomini, Henry Robinson, David Rosenthal, Jennifer Rullmann, Matthew Sackman, Martin Scholl, Amit Sela, Gwen Shapira, Greg Spurrier, Sam Stokes, Ben Stopford, Tom Stuart, Diana Vasile, Rahul Vohra, Pete Warden, 以及 Brett Wooldridge.
 
-通过审阅草案并提供反馈意见，更多的人对本书的撰写非常有价值。对于这些贡献，我特别感谢Raul Agepati，Tyler Akidau，Mattias Andersson，Sasha Baranov，Veena Basavaraj，David Beyer，Jim Brikman，Paul Carey，Raul Castro Fernandez，Joseph Chow，Derek Elkins，Sam Elliott，Alexander Gallego，Mark Grover ，斯图尔·万洛威（Stu Hallow Halloway），海蒂·霍华德（Heidi Howard），尼科拉·克莱普曼（Nicola Kleppmann），斯特凡·克鲁帕（Stefan Kruppa），比约恩·马德森（Bjorn Madsen），麦克尔·桑德（Sandder Mak），斯特凡·波德科维斯基（Stefan Podkowinski），菲尔·波特（Phil Potter）当然，对于本书中的任何遗留错误或不愉快的意见，我承担全部责任。
+更多人通过审阅草稿并提供反馈意见在本书的创作过程中做出了无价的贡献。我要特别感谢Raul Agepati, Tyler Akidau, Mattias Andersson, Sasha Baranov, Veena Basavaraj, David Beyer, Jim Brikman, Paul Carey, Raul Castro Fernandez, Joseph Chow, Derek Elkins, Sam Elliott, Alexander Gallego, Mark Grover, Stu Halloway, Heidi Howard, Nicola Kleppmann, Stefan Kruppa, Bjorn Madsen, Sander Mak, Stefan Podkowinski, Phil Potter, Hamid Ramazani, Sam Stokes, 以及Ben Summers。当然对于本书中的任何遗留错误或难以接受的见解，我都承担全部责任。
 
-为了帮助这本书出版，并且耐心地处理我缓慢的写作和不寻常的要求，我感谢编辑Marie Beaugureau，Mike Loukides，Ann Spencer和O'Reilly的所有团队。为了帮助找到合适的单词，我要感谢Rachel Head。尽管有其他的工作承诺给了我写作的时间和自由，但我要感谢Alastair Beresford，Susan Goodhue，Neha Narkhede和Kevin Scott。
+为了帮助这本书落地，并且耐心地处理我缓慢的写作和不寻常的要求，我要对编辑Marie Beaugureau，Mike Loukides，Ann Spencer和O'Reilly的所有团队表示感谢。我要感谢Rachel Head帮我找到了合适的术语。我要感谢Alastair Beresford，Susan Goodhue，Neha Narkhede和Kevin Scott，在其他工作事务之外给了我充分地创作时间和自由。
 
-非常特别的感谢是Shabbir Diwan和Edie Freedman，他们非常小心的说明了各章的地图。他们以非常规的创作地图的想法，使他们如此美丽和令人兴奋，真是太棒了。
+特别感谢Shabbir Diwan和Edie Freedman，他们非常用心地为各章配了地图。他们提出了不落俗套的灵感，创作了这些地图，美丽而引人入胜，真是太棒了。
 
-最后，我的爱情传到了我的家人和朋友身上，没有他，我将无法完成这个花了近四年时间的写作过程。你是最好的。
+最后我要表达对家人和朋友们的爱，没有他们，我将无法走完这个将近四年的写作历程。你们是最棒的。