Merge pull request #9 from jiajiadebug/master

Preface, ch1, part-i translation minor fixes

ch1.md

@@ -2,7 +2,7 @@
 
 ![](img/ch1.png)
 
-> 互联网做得太棒了，以至于多数人将它看作像海洋这样的天然资源，而不是什么人工产物。上一次出现这种大规模且无差错的技术， 你还记得是什么时候吗？          
+> 互联网做得太棒了，以至于多数人将它看作像太平洋这样的自然资源，而不是什么人工产物。上一次出现这种大规模且无差错的技术， 你还记得是什么时候吗？
 >
 > ——阿兰·凯在接受Dobb博士杂志采访时说（2012年）
 
@@ -32,11 +32,11 @@
 
 ***批处理（batch processing）***
 
-​	定期压缩累积的大批量数据
+​	定期处理累积的大批量数据
 
-如果这些功能听上去平淡无奇，那是因为这些**数据系统（data system）**是非常成功的抽象，我们一直不假思索地使用它们并习以为常。绝大多数工程师不会想从零开始编写存储引擎，因为在开发应用时，数据库已经是足够完美的工具了。
+上述组件如果听上去显而易见，那是因为这些**数据系统（data system）**是非常成功的抽象：我们一直不假思索地使用它们并习以为常。绝大多数工程师不会想从零开始编写存储引擎，因为在开发应用时，数据库已经是足够完美的工具了。
 
-但事实并没有这么简单。不同的应用有着不同的需求，所以数据库系统也是百花齐放，有着各式各样的特性。我们有很多种手段可以实现缓存，也有好几种方法可以搞定搜索索引，诸如此类。因此在开发应用前，我们有必要先弄清楚最适合手头工作的工具和方法。而且当单个工具解决不了你的问题时，你会发现组合使用这些工具还是挺有难度的。
+但现实并没有这么简单。不同的应用有着不同的需求，因而数据库系统也是百花齐放，有着各式各样的特性。实现缓存有很多种手段，创建搜索索引也有好几种方法，诸如此类。因此在开发应用前，我们依然有必要先弄清楚最适合手头工作的工具和方法。而且当单个工具解决不了你的问题时，你会意识到组合使用这些工具是挺有难度的。
 
 本书将是一趟关于数据系统原理、实践与应用的旅程，并讲述了设计数据密集型应用的方法。我们将探索不同工具之间的共性与特性，以及各自的实现原理。
 
@@ -141,7 +141,7 @@
 
 尽管人类不可靠，但怎么做才能让系统变得可靠？最好的系统会组合使用以下几种办法：
 
-* 以最小化犯错机会的方式设计系统。例如，精心设计的抽象、API和管理后台使做对事情更容易，搞砸事情更困难。但如果接口限制太多，人们就会否定它们的好处而想办法绕开。这是一个很难正确把握的棘手平衡。
+* 以最小化犯错机会的方式设计系统。例如，精心设计的抽象、API和管理后台使做对事情更容易，搞砸事情更困难。但如果接口限制太多，人们就会忽略它们的好处而想办法绕开。很难正确把握这种微妙的平衡。
 * 将人们最容易犯错的地方与可能导致失效的地方**解耦（decouple）**。特别是提供一个功能齐全的非生产环境**沙箱（sandbox）**，使人们可以在不影响真实用户的情况下，使用真实数据安全地探索和实验。
 * 在各个层次进行彻底的测试【3】，从单元测试、全系统集成测试到手动测试。自动化测试易于理解，已经被广泛使用，特别适合用来覆盖正常情况中少见的**边缘场景（corner case）**。
 * 允许从人为错误中简单快速地恢复，以最大限度地减少失效情况带来的影响。 例如，快速回滚配置变更，分批发布新代码（以便任何意外错误只影响一小部分用户），并提供数据重算工具（以备旧的计算出错）。
@@ -150,7 +150,7 @@
 
 ### 可靠性有多重要？
 
-可靠性不仅仅是针对核电站和空中交通管制软件而言，我们也期望许多平凡的应用能可靠地运行。商务应用中的错误会导致生产力损失（也许数据报告不完整还会有法律风险），而电商网站的中断则可能会导致收入和声誉的巨大损失。
+可靠性不仅仅是针对核电站和空中交通管制软件而言，我们也期望更多平凡的应用能可靠地运行。商务应用中的错误会导致生产力损失（也许数据报告不完整还会有法律风险），而电商网站的中断则可能会导致收入和声誉的巨大损失。
 
 即使在“非关键”应用中，我们也对用户负有责任。试想一位家长把所有的照片和孩子的视频储存在你的照片应用里【15】。如果数据库突然损坏，他们会感觉如何？他们可能会知道如何从备份恢复吗？
 
@@ -166,7 +166,7 @@
 
 ### 描述负载
 
-讨论增长问题（如果负载加倍会发生什么？）前，首先要能简要描述系统的当前负载。负载可以用一些称为**负载参数（load parameters）**的数字来描述。参数的最佳选择取决于系统架构，它可能是每秒向Web服务器发出的请求、数据库中的读写比率、聊天室中同时活跃的用户数量、缓存命中率或其他东西。除此之外，也许平均情况对你很重要，也许你的瓶颈是少数极端场景。
+在讨论增长问题（如果负载加倍会发生什么？）前，首先要能简要描述系统的当前负载。负载可以用一些称为**负载参数（load parameters）**的数字来描述。参数的最佳选择取决于系统架构，它可能是每秒向Web服务器发出的请求、数据库中的读写比率、聊天室中同时活跃的用户数量、缓存命中率或其他东西。除此之外，也许平均情况对你很重要，也许你的瓶颈是少数极端场景。
 
 为了使这个概念更加具体，我们以推特在2012年11月发布的数据【16】为例。推特的两个主要业务是：
 
@@ -207,29 +207,29 @@
 
 然而方法2的缺点是，发推现在需要大量的额外工作。平均来说，一条推文会发往约75个关注者，所以每秒4.6k的发推写入，变成了对主页时间线缓存每秒345k的写入。但这个平均值隐藏了用户粉丝数差异巨大这一现实，一些用户有超过3000万的粉丝，这意味着一条推文就可能会导致主页时间线缓存的3000万次写入！及时完成这种操作是一个巨大的挑战——推特尝试在5秒内向粉丝发送推文。
 
-在推特的例子中，每个用户粉丝数的分布（可能按这些用户的发推频率来加权）是讨论可扩展性的关键负载参数，因为它决定了扇出负载。你的应用程序可能具有非常不同的特征，但可以使用相似的原则来考虑你的负载。
+在推特的例子中，每个用户粉丝数的分布（可能按这些用户的发推频率来加权）是探讨可扩展性的一个关键负载参数，因为它决定了扇出负载。你的应用程序可能具有非常不同的特征，但可以采用相似的原则来考虑它的负载。
 
-推特轶事的最终转折：现在方法2已经稳健地实现了，但推特又转向了两种方法的混合。大多数用户发推时仍然是扇出写入粉丝的主页时间线缓存中。但是少数拥有海量粉丝的用户（即名流）被排除在外。当用户读取主页时间线时，来自所关注名流的推文都会单独拉取，并与用户的主页时间线缓存合并，如方法1所示。这种混合方法能始终如一地提供良好性能。在[第12章](ch12.md)中将重新讨论这个例子，那时我们已经覆盖了更多的技术层面。
+推特轶事的最终转折：现在已经稳健地实现了方法2，推特逐步转向了两种方法的混合。大多数用户发的推文会被扇出写入其粉丝主页时间线缓存中。但是少数拥有海量粉丝的用户（即名流）会被排除在外。当用户读取主页时间线时，分别地获取出该用户所关注的每位名流的推文，再与用户的主页时间线缓存合并，如方法1所示。这种混合方法能始终如一地提供良好性能。在[第12章](ch12.md)中我们将重新讨论这个例子，这在覆盖更多技术层面之后。
 
 ### 描述性能
 
-一旦系统的负载可以被描述，就可以研究当负载增加会发生什么。我们可以从两种角度来看：
+一旦系统的负载被描述好，就可以研究当负载增加会发生什么。我们可以从两种角度来看：
 
-* 增加负载参数并保持系统资源（CPU、内存、网络带宽等）不变时，系统性能将有什么影响？
+* 增加负载参数并保持系统资源（CPU、内存、网络带宽等）不变时，系统性能将受到什么影响？
 * 增加负载参数并希望保持性能不变时，需要增加多少系统资源？
 
 这两个问题都需要性能数据，所以让我们简单地看一下如何描述系统性能。
 
-对于Hadoop这样的批处理系统，通常关心的是**吞吐量（throughput）**，即每秒可以处理的记录数量，或者在特定规模数据集上运行作业的总时间[^iii]。对于在线系统，通常更重要的是服务的**响应时间（response time）**，即客户端发送请求和接收响应之间的时间。
+对于Hadoop这样的批处理系统，通常关心的是**吞吐量（throughput）**，即每秒可以处理的记录数量，或者在特定规模数据集上运行作业的总时间[^iii]。对于在线系统，通常更重要的是服务的**响应时间（response time）**，即客户端发送请求到接收响应之间的时间。
 
 [^iii]: 理想情况下，批量作业的运行时间是数据集的大小除以吞吐量。 在实践中由于数据倾斜（数据不是均匀分布在每个工作进程中），需要等待最慢的任务完成，所以运行时间往往更长。
 
 > #### 延迟和响应时间
 >
-> **延迟（latency）**和**响应时间（response time）**通常当成同义词用，但实际上它们并不一样。响应时间是客户所看到的，除了实际处理请求的时间（**服务时间（service time）**）之外，还包括网络延迟和排队延迟。延迟是某个请求等待处理的**持续时长**，在此期间它处于**休眠（latent）**状态，并等待服务【17】。
+> **延迟（latency）**和**响应时间（response time）**通常互当成同义词来使用，但实际上它们并不一样。响应时间是客户所看到的，除了实际处理请求的时间（**服务时间（service time）**）之外，还包括网络延迟和排队延迟。延迟是某个请求等待处理的**持续时长**，在此期间它处于**休眠（latent）**状态，并等待服务【17】。
 >
 
-即使不断重复发送同样的请求，每次得到的响应时间也都会略有不同。现实世界的系统会处理各式各样的请求，响应时间可能会有很大差异。因此我们需要将响应时间视为一个可以测量的**分布（distribution）**，而不是单个数值。
+即使不断重复发送同样的请求，每次得到的响应时间也都会略有不同。现实世界的系统会处理各式各样的请求，响应时间可能会有很大差异。因此我们需要将响应时间视为一个可以测量的数值**分布（distribution）**，而不是单个数值。
 
 在[图1-4](img/fig1-4.png)中，每个灰条表代表一次对服务的请求，其高度表示请求花费了多长时间。大多数请求是相当快的，但偶尔会出现需要更长的时间的异常值。这也许是因为缓慢的请求实质上开销更大，例如它们可能会处理更多的数据。但即使（你认为）所有请求都花费相同时间的情况下，随机的附加延迟也会导致结果变化，例如：上下文切换到后台进程，网络数据包丢失与TCP重传，垃圾收集暂停，强制从磁盘读取的页面错误，服务器机架中的震动【18】，还有很多其他原因。
 
@@ -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 percentil）**）非常重要，因为它们直接影响用户的服务体验。例如亚马逊在描述内部服务的响应时间要求时以99.9百分位点为准，即使它只影响一千个请求中的一个。这是因为请求响应最慢的客户往往也是数据最多的客户，也可以说是最有价值的客户——因为他们掏钱了【19】。保证网站响应迅速对于保持客户的满意度非常重要，亚马逊观察到：响应时间增加100毫秒，销售量就减少1％【20】；而另一些报告说：慢1秒钟会让客户满意度指标减少16%【21，22】。
+响应时间的高百分位点（也称为**尾部延迟（tail latencies）**）非常重要，因为它们直接影响用户的服务体验。例如亚马逊在描述内部服务的响应时间要求时以99.9百分位点为准，即使它只影响一千个请求中的一个。这是因为请求响应最慢的客户往往也是数据最多的客户，也可以说是最有价值的客户——因为他们掏钱了【19】。保证网站响应迅速对于保持客户的满意度非常重要，亚马逊观察到：响应时间增加100毫秒，销售量就减少1％【20】；而另一些报告说：慢1秒钟会让客户满意度指标减少16%【21，22】。
 
 另一方面，优化第99.99百分位点（一万个请求中最慢的一个）被认为太昂贵了，不能为亚马逊的目标带来足够好处。减小高百分位点处的响应时间相当困难，因为它很容易受到随机事件的影响，这超出了控制范围，而且效益也很小。
 

part-i.md

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

preface.md

@@ -4,26 +4,26 @@
 
 在最近十年中，我们看到了很多有趣的进展，关于数据库，分布式系统，以及在此基础上构建应用程序的方式。这些进展有着各种各样的驱动力：
 
-* 谷歌，雅虎，亚马逊，脸书，领英，微软和推特等互联网公司正在和巨大的流量/数据打交道，这迫使它们创造能有效应对这种规模的新工具。
+* 谷歌，雅虎，亚马逊，脸书，领英，微软和推特等互联网公司正在和巨大的流量/数据打交道，这迫使他们去创造能有效应对如此规模的新工具。
-* 企业需要敏捷，廉价地测试假设，通过缩短开发周期和保持数据模型的灵活性，快速响应新的市场洞察。
+* 企业需要变得敏捷，需要低成本地检验假设，需要通过缩短开发周期和保持数据模型的灵活性，快速地响应新的市场洞察。
 * 免费和开源软件变得非常成功，在许多环境中比商业软件和定制软件更受欢迎。
-* 处理器主频几乎没有增长，但是多核处理器已经成为标配，网络也越来越快。这意味着并行程度只增不减。
+* 处理器主频几乎没有增长，但是多核处理器已经成为标配，网络也越来越快。这意味着并行化只增不减。
 * 即使您在一个小团队中工作，现在也可以构建分布在多台计算机甚至多个地理区域的系统，这要归功于譬如亚马逊网络服务（AWS）等基础设施即服务（IaaS）概念的践行者。
 * 许多服务都要求高可用，因停电或维护导致的服务不可用，变得越来越难以接受。
 
-数据密集型应用正在通过利用这些技术进步推动可能性的边界。如果**数据是其主要挑战**（数据量，数据复杂度或数据变化速度），我们称这类应用为**数据密集型**，与之相对的是**计算密集型**，即处理器速度是瓶颈。
+数据密集型应用正在通过利用这些技术进步推动可能性的边界。如果**数据是其主要挑战**（数据量，数据复杂度或数据变化速度），这类应用被称为**数据密集型**，与之相对的是**计算密集型**，即处理器速度是其瓶颈。
 
-帮助数据密集型应用程序存储和处理数据的工具和技术已经迅速适应这些变化。新型数据库系统（“NoSQL”）已经引起了人们的关注，但消息队列，缓存，搜索索引，批处理和流处理框架以及相关技术也非常重要。许多应用程序组合使用这些技术。
+工具和技术迅速适应着这些变化，帮助数据密集型应用程序来存储和处理数据。新型数据库系统（“NoSQL”）已经引起了众多关注，然而消息队列，缓存，搜索索引，批处理和流处理框架以及相关技术也非常重要。这些技术被组合使用在很多应用程序上。
 
-这些充满整个空间的流行语是对新的可能性的热情的表现，这是一件好事。但是，作为软件工程师和架构师，如果我们想要建立良好的应用程序，我们还需要对各种层出不穷的技术持有准确而严谨的技术性理解，以及它们之间的取舍权衡。为此，我们必须深入挖掘流行语背后的内容。
+这些充满整个空间的流行语体现出人们对新可能性的热情，这是一件好事。但是，作为软件工程师和架构师，如果要建立良好的应用程序，我们还需要对各种层出不穷的技术及其利弊持有准确而严谨的技术性理解。为此，必须深入挖掘流行语背后的内容。
 
-幸运的是，在技术快速变化的背后，无论您使用的是什么版本的特定工具，都存在一些持久的原则。如果你了解这些原则，你就可以看到每个工具的适用位置，如何充分利用它们，以及如何避免其中的陷阱。这是本书的初衷。
+幸运的是，在技术快速变化的背后，无论您使用的是哪个版本的特定工具，存在一些持久的原则。如果您了解这些原则，您就可以领会这些工具适用于何处，如何充分利用它们，以及如何避免其中的陷阱。这正是本书的初衷。
 
 本书的目标是帮助您在多样而快速变化的处理和存储数据技术的大观园中找到方向。这本书不是一个特定工具的教程，也不是一本充满干枯理论的教科书。相反，我们将看到一些成功的数据系统示例：一些构成了许多流行应用程序基础，必须在每天的生产中满足可伸缩性，性能和可靠性需求的技术。
 
-我们将深入这些系统的内部，梳理他们的关键算法，讨论他们的原则和它们必须做出的权衡。在这个过程中，我们将尝试寻找有用的思考数据系统的方式 —— 不仅仅关于它们是如何工作的，还包括为什么它们以这种方式工作，以及我们需要问什么问题。
+我们将深入这些系统的内部，梳理他们的关键算法，讨论他们的原则和他们必须做出的权衡。在这个过程中，我们将尝试寻找有用的方式来思考数据系统 —— 不仅仅关于它们是如何工作的，还包括为什么它们以这种方式工作，以及我们需要问什么问题。
 
-阅读本书后，您将能够很好地决定哪种技术适合哪种用途，并了解如何将工具组合起来，形成良好应用架构的基础。您不会获得从头开始构建自己的数据库存储引擎的能力，但幸运的是，这是很少有必要的。您将会获得的是，对你的系统在底层做什么有一个很好的直觉，这样您就可以推断它们的行为，做出好的设计决定，并追踪任何可能出现的问题。
+阅读本书后，您将能够很好地决定哪种技术适合哪种用途，并了解如何将工具组合起来，为一个良好应用架构奠定基础。您并不能够因此准备好从头开始构建自己的数据库存储引擎的技能，不过幸运地很，这很少是必要的。您将会获得的是，建立起对系统底层运行的敏锐直觉，这样您就有能力推理它们的行为，做出好的设计方案，并追踪任何可能出现的问题。
 
 
 
@@ -35,7 +35,7 @@
 
 您应该具有构建基于Web的应用程序或网络服务的一些经验，并且您应该熟悉关系数据库和SQL。任何您了解的非关系型数据库和其他与数据相关的工具都会更有帮助，但不是必需的。常见的网络协议如TCP和HTTP的一般理解是有帮助的。编程语言或框架的选择对阅读本书没有任何不同影响。
 
-如果以下任何一条对你是真的，你会发现这本书很有价值：
+如果以下任何一条对您是真的，您会发现这本书很有价值：
 
 * 您想了解如何使数据系统可扩展，例如，支持拥有数百万用户的Web或移动应用程序。
 * 您需要提高应用程序的可用性（最大限度地减少停机时间）和运行稳定。