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)将深**存储引擎**内部，并研究数据库如何在磁盘上摆放数据。不同的存储引擎针对不同的负载进行优化，选择合适的存储引擎对系统性能有巨大影响。
-4. [第四章](ch4)将对几种不同的 **数据编码**进行比较。特别讨论了在应用需求经常变化、模式需要随时间演化的环境中，这些格式的适用情况。
+3. [第三章](ch3.md)将深入**存储引擎**内部，研究数据库如何在磁盘上摆放数据。不同的存储引擎针对不同的负载进行优化，选择合适的存储引擎对系统性能有巨大影响。
+4. [第四章](ch4)将对几种不同的 **数据编码**进行比较。特别地分析了他们在应用需求经常变化、模式需要随着时间演变的环境中的表现情况。
 
-第二部分将专门讨论在**分布式数据系统**中才有的问题。
+第二部分将专门讨论在**分布式数据系统**中特有的问题。