Vonng · ibyte2011 · Apr 5, 2018 · Apr 5, 2018 · Apr 5, 2018 · Apr 11, 2018
diff --git a/ch1.md b/ch1.md
@@ -384,7 +384,7 @@
 
 **可维护性（Maintainability）**有许多方面，但实质上是关于工程师和运维团队的生活质量的。良好的抽象可以帮助降低复杂度，并使系统易于修改和适应新的应用场景。良好的可操作性意味着对系统的健康状态具有良好的可见性，并拥有有效的管理手段。
 
-不幸的是，使应用可靠、可扩展或可持续并不容易。但是某些模式和技术会不断重新出现在不同的应用中。在接下来的几章中，我们将看到一些数据系统的例子，并分析它们如何实现这些目标。
+不幸的是，使应用可靠、可扩展或可维护并不容易。但是某些模式和技术会不断重新出现在不同的应用中。在接下来的几章中，我们将看到一些数据系统的例子，并分析它们如何实现这些目标。
 
 在本书后面的[第三部分](part-iii.md)中，我们将看到一种模式：几个组件协同工作以构成一个完整的系统（例如[图1-1](img/fig1-1.png)中的）
 
@@ -470,4 +470,4 @@
 
 | 上一章                              | 目录                            | 下一章                               |
 | ----------------------------------- | ------------------------------- | ------------------------------------ |
-| [第一部分：数据系统基础](part-i.md) | [设计数据密集型应用](README.md) | [第二章：数据模型与查询语言](ch2.md) |
+| [第一部分：数据系统基础](part-i.md) | [设计数据密集型应用](README.md) | [第二章：数据模型与查询语言](ch2.md) |
diff --git a/ch2.md b/ch2.md
@@ -2,7 +2,7 @@
 
 ![](img/ch2.png)
 
-> 语言的极限即世界的极限
+> 语言的局限即世界的局限
 >
 > —— 路德维奇·维特根斯坦， 《逻辑哲学》（1922）
 >
@@ -26,7 +26,7 @@
 
 掌握一个数据模型可能需要很多努力（想想关系数据建模有多少本书）。即使只使用一种数据模型，而不用担心其内部工作，构建软件也是非常困难的。但是由于数据模型对软件的功能有很大的影响，因此选择适合应用程序的软件是非常重要的。
 
-在本章中，我们将研究一系列用于数据存储和查询的通用数据模型（前面列表中的第2点）。特别是，我们将比较关系模型，文档模型和一些基于图形的数据模型。我们还将查看各种查询语言并比较它们的用例。在第3章中，我们将讨论存储引擎是如何工作的。也就是说，这些数据模型是如何实际实现的（列表中的第3点）。
+在本章中，我们将研究一系列用于数据存储和查询的通用数据模型（前面列表中的第2点）。特别是，我们将比较关系模型，文档模型和一些基于图形的数据模型。我们还将查看各种查询语言并比较它们的用例。在第3章中，我们将讨论存储引擎是如何工作及**_****_**这些数据模型是如何实际实现的（列表中的第3点）。
 
 
 
@@ -46,12 +46,12 @@
 
 ### NoSQL的诞生
 
-现在在2010年代，NoSQL是推翻关系模式主导地位的最新尝试。 “NoSQL”这个名字非常不幸，因为它实际上并没有涉及到任何特定的技术，它最初只是作为一个吸引人的Twitter标签在2009年的一个关于分布式，非关系数据库上的开源聚会。无论如何，这个术语触动了某些神经，并迅速通过网络启动社区和更远的地方传播开来。一些有趣的数据库系统现在与*#NoSQL#*标签相关联，并被追溯性地重新解释为不仅是SQL 【4】。
+现在在2010年代，NoSQL是推翻关系模式主导地位的最新尝试。 “NoSQL”这个名字非常不幸，因为它实际上并没有涉及到任何特定的技术，它最初只是2009年的一个关于分布式，非关系数据库上的开源聚会被用作为一个吸引人的Twitter标签。无论如何，这个术语触动了某些神经，并迅速通过网络创业社区传播开来。一些有趣的数据库系统现在与*#NoSQL#*标签相关联，并被追溯性地重新解释为不仅是SQL 【4】。
 
 采用NoSQL数据库有几个驱动力，其中包括：
 
 * 需要比关系数据库更好的可扩展性，包括非常大的数据集或非常高的写入吞吐量
-* 相比商业数据库产品，偏爱免费和开源软件
+* 相比商业数据库产品，对免费和开源软件广泛喜爱
 * 关系模型不能很好地支持一些特殊的查询操作
 * 对关系模型限制性感到受挫，对更多动态性与表现力的渴望
 
@@ -903,7 +903,7 @@ Datalog方法需要对本章讨论的其他查询语言采取不同的思维方
 
 数据模型是一个巨大的课题，在本章中，我们快速浏览了各种不同的模型。我们没有足够的空间来详细介绍每个模型的细节，但是希望这个概述足以激起您的兴趣，以更多地了解最适合您的应用需求的模型。
 
-在历史上，数据开始被表示为一棵大树（层次数据模型），但是这不利于表示多对多的关系，所以发明了关系模型来解决这个问题。最近，开发人员发现一些应用程序也不适合在关系模型中使用。新的非关系型“NoSQL”数据存储在两个主要方向上有分歧：
+在历史上，数据开始被表示为一棵大树（层次数据模型），但是这不利于表示多对多的关系，所以发明了关系模型来解决这个问题。最近，开发人员发现一些应用程序也不适合在关系模型中使用。新的非关系型“NoSQL”数据存储有两大分支方向：
 
 1. 文档数据库的应用场景是：数据通常是自我包含的，而且文档之间的关系非常罕见。
 2. 图形数据库用于相反的场景： 任何东西都可能和任何东西相关联。

diff --git a/ch5.md b/ch5.md
@@ -776,7 +776,7 @@ LWW实现了最终收敛的目标，但以**持久性**为代价：如果同一
 
 最后，我们讨论了多领导者和无领导者复制方法所固有的并发问题：因为他们允许多个写入并发发生冲突。我们研究了一个数据库可能使用的算法来确定一个操作是否发生在另一个操作之前，或者它们是否同时发生。我们还谈到了通过合并并发更新来解决冲突的方法。
 
-在下一章中，我们将继续研究分布在多个机器上的数据，通过复制的对应方式：将大数据集分割成分区。
+在下一章中，我们将继续研究分布在多个机器上的数据，通过与复制对应的方式：将大数据集分割成分区。
 
 
 
@@ -919,4 +919,4 @@ LWW实现了最终收敛的目标，但以**持久性**为代价：如果同一
 
 |               上一章               |              目录               |         下一章         |
 | :--------------------------------: | :-----------------------------: | :--------------------: |
-| [第二部分：分布式数据](part-ii.md) | [设计数据密集型应用](README.md) | [第六章：分区](ch6.md) |
+| [第二部分：分布式数据](part-ii.md) | [设计数据密集型应用](README.md) | [第六章：分区](ch6.md) |
diff --git a/ch8.md b/ch8.md
@@ -278,6 +278,8 @@
 
 单调钟适用于测量持续时间（时间间隔），例如超时或服务的响应时间：Linux上的`clock_gettime(CLOCK_MONOTONIC)`，和Java中的`System.nanoTime()`都是单调时钟。这个名字来源于他们保证总是前进的事实（而时钟可以及时跳回）。
 
+
+TODO:添加未翻译的三段
 ### 时钟同步与准确性
 
 单调钟不需要同步，但是时钟需要根据NTP服务器或其他外部时间源来设置才能有用。不幸的是，我们获取时钟的方法并不像你所希望的那样可靠或准确——硬件时钟和NTP可能会变幻莫测。举几个例子：