fix format

9672e6f3 · Vonng · d05529b7 · 9672e6f3 · 9672e6f3 · 9672e6f3
9 changed file
--- a/README.md
+++ b/README.md
@@ -83,8 +83,3 @@ PostgreSQL是世界上最先进的开源关系型数据库！

 * [Introduction to PostGIS](http://workshops.boundlessgeo.com/postgis-intro/index.html)

-
-
-## License
-
-闷声发大财才是坠吼地。
\ No newline at end of file
--- a/ddia/README.md
+++ b/ddia/README.md
@@ -3,6 +3,9 @@
 * 作者： Martin Kleppmann
 * 原书名称：《Designing Data-Intensive Application》
 * 译者：冯若航 （fengruohang@outlook.com , http://vonng.com/about）
+* 建议本地使用[Typora](https://www.typora.io)以获取最佳阅读体验。
+
+


 ## 前言
@@ -19,79 +22,35 @@

 ## 目录

-### [序言](preface.md) [机翻]
-
-### 第一部分： [数据系统的基石](part-i.md)
-
-1. [可靠性、可扩展性、可维护性](ch1.md)  [初翻30%]
-   * 关于数据系统的思考
-   * 可靠性
-   * 可扩展性
-   * 可维护性
-2. [数据模型与查询语言](ch2.md) [初翻]
-   * 关系模型与文档模型
-   * 数据查询语言
-   * 图数据模型
-3. [存储与检索](ch3.md) [初翻]
-   * 支撑数据库的数据结构
-   * 分析还是事务处理？
-   * 列存储
-4. [编码与演化](ch4.md) [初翻]
-   * 编码数据的格式
-   * 数据流的模型
-
-### 第二部分： [分布式数据](part-ii.md)
-
-5. [复制](ch5.md) [机翻]
-   * 主从
-   * 复制延迟带来的问题
-   * 多主复制
-   * 无主复制
-6. [分片](ch6.md) [机翻]
-   * 分片与复制
-   * 键值对数据的分片
-   * 分片与次级索引
-   * 分片再平衡
-   * 请求路由
-7. [事务](ch7.md) [机翻]
-   * 事务的棘手概念
-   * ACID的含义
-   * 弱隔离级别
-   * 序列化能力
-8. [分布式系统的麻烦](ch8.md) [待翻]
-   * 故障与部分失效
-   * 不可靠的网络
-   * 不可靠的时钟
-   * 知识、真相与谎言
-9. [一致性与共识](ch9.md) [待翻]
-   * 一致性保证
-   * 线性一致性
-   * 顺序保证
-   * 分布式事务与共识
-
-### 第三部分：[衍生数据](part-iii.md)
-
-10. [批处理](ch10.md) [未翻]
-    * 使用Unix工具的批处理
-    * MapReduce和分布式文件系统
-    * 后MapReduce时代
-11. [流处理](ch11.md) [未翻]
-    * 传递事件流
-    * 流与数据库
-    * 流处理
-12. [数据系统的未来](ch12.md) [未翻]
-    * 数据集成
-    * 拆分数据库
-    * 目标是正确性
-    * 做正确的事情
-
-    
+### [序言](preface.md)
+
+### [数据系统的基石](part-i.md)
+
+1. [可靠性、可扩展性、可维护性](ch1.md)
+2. [数据模型与查询语言](ch2.md)
+3. [存储与检索](ch3.md) 
+4. [编码与演化](ch4.md)
+
+### [分布式数据](part-ii.md)
+
+5. [复制](ch5.md) 
+6. [分片](ch6.md) 
+7. [事务](ch7.md) 
+8. [分布式系统的麻烦](ch8.md) 
+9. [一致性与共识](ch9.md) 
+
+### [衍生数据](part-iii.md)
+
+10. [批处理](ch10.md) 
+11. [流处理](ch11.md) 
+12. [数据系统的未来](ch12.md) 
+



 ## 翻译计划

-机翻：程序翻译，基本保留原书的组织结构，也是阅读原文，学习本书的过程。
+机翻：股沟翻译，整理图片、引用、备注与基本的排版，不对照着原文基本没法看。

 初翻：人工修复格式错误和显著翻译错误，重新组织语言，保障基本的可读性。

@@ -99,7 +58,25 @@

 翻译完全看心情，但通常每周至少会完成一章的初翻。

-阅读建议使用Typora，可以获得最好的阅览体验。
+| 章节   | 文件   | 计划 | 进度 |
+| ------ | ------ | ---- | ---- |
+| 序     | [preface.md](preface.md) |      | 机翻 |
+| 第一部分：数据系统基础 ——概览 | [part-i.md](part-i.md) |      | 精翻 20% |
+| 第一章：可靠性、可扩展性、可维护性 | [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) |      | 初翻 60% |
+| 第六章：分片 | [ch6.md](ch6.md) |      | 机翻 |
+| 第七章：事务 | [ch7.md](ch7.md) |      | 机翻 |
+| 第八章：分布式系统的麻烦 | [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) |      | - |
+




--- a/ddia/ch10.md
+++ b/ddia/ch10.md
@@ -2,9 +2,9 @@

 ![](img/ch10.png)

-带有太强个人色彩的系统无法成功。当第一版健壮的设计完成时，真正的考验才开始：许多不同观点的人会以他们自己的方式来测试。
-
-——高德纳
+> 带有太强个人色彩的系统无法成功。当第一版健壮的设计完成时，不同的人们以自己的方式来测试，真正的考验才开始。
+>
+> ——高德纳

 ---------------


--- a/ddia/ch11.md
+++ b/ddia/ch11.md
@@ -2,7 +2,7 @@

 ![](img/ch11.png)

-> 有效的复杂系统总是从简单的系统演化而来。 反之亦然：从零开始设计的复杂系统没一个能有效工作的。
+> 有效的复杂系统总是从简单的系统演化而来。 反之亦然：从零设计的复杂系统没一个能有效工作的。
 >
 > ——约翰·加尔，Systemantics（1975）


--- a/ddia/ch12.md
+++ b/ddia/ch12.md
@@ -2,7 +2,7 @@

 ![](img/ch12.png)

-> 如果船长的最高目标是保护他的船，他应该永远待在港口。
+> 如果船长的终极目标是保护船只，他应该永远待在港口。
 >
 > ——圣托马斯·阿奎那《神学大全》（1265-1274）


--- a/ddia/ch2.md
+++ b/ddia/ch2.md
@@ -48,7 +48,7 @@

 ### NoSQL的诞生

-现在，在2010年代，NoSQL是推翻关系模式主导地位的最新尝试。 “NoSQL”这个名字是不幸的，因为它实际上并没有涉及到任何特定的技术，它最初只是作为一个吸引人的Twitter标签在2009年的开源，分布式，非关系数据库上聚会。无论如何，这个术语触动了一个神经，并迅速通过网络启动社区和更远的地方传播开来。一些有趣的数据库系统现在与#NoSQL＃标签相关联，并被追溯性地重新解释为不仅是SQL [4]。
+现在，在2010年代，NoSQL是推翻关系模式主导地位的最新尝试。 “NoSQL”这个名字是不幸的，因为它实际上并没有涉及到任何特定的技术，它最初只是作为一个吸引人的Twitter标签在2009年的开源，分布式，非关系数据库上聚会。无论如何，这个术语触动了一个神经，并迅速通过网络启动社区和更远的地方传播开来。一些有趣的数据库系统现在与#NoSQL#标签相关联，并被追溯性地重新解释为不仅是SQL [4]。

 采用NoSQL数据库有几个驱动力，其中包括：

@@ -57,11 +57,13 @@
 * 关系模型不能很好地支持一些特殊的查询操作
 * 对关系模型限制性感到受挫，对更多动态性与表现力的渴望

-不同的应用程序有不同的要求，一个用例的最佳技术选择可能不同于另一个用例的最佳选择。因此，在可预见的未来，关系数据库似乎可能会继续与各种非关系数据库一起使用 - 这种想法有时也被称为混合持久化（Polyglot Persistences）
+不同的应用程序有不同的要求，一个用例的最佳技术选择可能不同于另一个用例的最佳选择。因此，在可预见的未来，关系数据库似乎可能会继续与各种非关系数据库一起使用 - 这种想法有时也被称为**混合持久化（Polyglot Persistences）**

 ### 对象关系不匹配

-现在大多数应用程序开发都是在面向对象的编程语言中完成的，这导致了对SQL数据模型的普遍批评：如果数据存储在关系表中，那么应用程序代码中的对象之间需要一个笨拙的转换层，表，行和列的数据库模型。模型之间的不连贯有时被称为阻抗不匹配（impedance mismatch  从电子学借用一个术语。每个电路的输入和输出都有一定的阻抗（交流电阻）。当您将一个电路的输出连接到另一个电路的输入时，如果两个电路的输出和输入阻抗匹配，则连接上的功率传输将被最大化。阻抗不匹配可能导致信号反射和其他问题。）
+现在大多数应用程序开发都是在面向对象的编程语言中完成的，这导致了对SQL数据模型的普遍批评：如果数据存储在关系表中，那么应用程序代码中的对象之间需要一个笨拙的转换层，表，行和列的数据库模型。模型之间的不连贯有时被称为**阻抗不匹配（impedance mismatch）**[^i]。
+
+[^i]:  从电子学借用一个术语。每个电路的输入和输出都有一定的阻抗（交流电阻）。当您将一个电路的输出连接到另一个电路的输入时，如果两个电路的输出和输入阻抗匹配，则连接上的功率传输将被最大化。阻抗不匹配可能导致信号反射和其他问题

 像ActiveRecord和Hibernate这样的对象关系映射（ORM）框架减少了这个翻译层需要的样板代码的数量，但是它们不能完全隐藏这两个模型之间的差异。

@@ -194,7 +196,9 @@ CODASYL中的查询是通过遍历记录列表和访问路径后，通过在数

 #### 关系模型

-相比之下，关系模型做的就是将所有的数据放在open中：一个关系（table）只是一个元组（行）的集合，就是这样。没有迷宫似的嵌套结构，如果你想看看数据，没有复杂的访问路径。您可以读取表中的任何或所有行，选择符合任意条件的行。您可以通过指定某些列作为关键字并匹配这些关键字来读取特定行。您可以在任何表中插入一个新的行，而不必担心与其他表的外键关系（外键约束允许对修改做限制，对于关系模型这并不是必选项。 即使有约束，在查询时执行外键连接，而在CODASYL中，连接在插入时高效完成。）
+相比之下，关系模型做的就是将所有的数据放在open中：一个关系（table）只是一个元组（行）的集合，就是这样。没有迷宫似的嵌套结构，如果你想看看数据，没有复杂的访问路径。您可以读取表中的任何或所有行，选择符合任意条件的行。您可以通过指定某些列作为关键字并匹配这些关键字来读取特定行。您可以在任何表中插入一个新的行，而不必担心与其他表的外键关系[^iii]。
+
+[^iii]: 外键约束允许对修改做限制，对于关系模型这并不是必选项。 即使有约束，在查询时执行外键连接，而在CODASYL中，连接在插入时高效完成。

 在关系数据库中，查询优化器自动决定查询的哪些部分以哪个顺序执行，以及使用哪些索引。这些选择实际上是“访问路径”，但最大的区别在于它们是由查询优化器自动生成的，而不是由程序员生成，所以我们很少需要考虑它们。

@@ -524,7 +528,7 @@ db.observations.aggregate([

 ![](img/fig2-5.png)

-##### 图2-5 图数据结构示例（框代表顶点，箭头代表边）
+**图2-5 图数据结构示例（框代表顶点，箭头代表边）**

 有几种不同但相关的方法来构建和查询图表中的数据。 在本节中，我们将讨论属性图模型（由Neo4j，Titan和InfiniteGraph实现）和三存储（triple-store）模型（由Datomic，AllegroGraph等实现）。 我们将看图的三种声明性查询语言：Cypher，SPARQL和Datalog。 除此之外，还有像Gremlin [36]这样的图形查询语言和像Pregel这样的图形处理框架（见第10章）。

@@ -866,7 +870,7 @@ Cypher和SPARQL使用SELECT立即跳转，但是Datalog一次只需要一小步

 ![](img/fig2-6.png)

-图2-6. 使用示例2-11中的Datalog规则确定爱达荷州在北美。
+**图2-6 使用示例2-11中的Datalog规则确定爱达荷州在北美。**

 现在规则3可以找到出生在某个地方BornIn的人，并住在某个地方LivingIn。通过查询BornIn ='United States'和LivingIn ='Europe'，并将此人作为变量Who，我们要求Datalog系统找出变量Who可以出现哪些值。因此，最后我们得到了与早先的Cypher和SPARQL查询相同的答案。


--- a/ddia/ch5.md
+++ b/ddia/ch5.md
--- a/ddia/ch6.md
+++ b/ddia/ch6.md
@@ -2,7 +2,7 @@

 ![](img/ch6.png)

-> 显而易见，我们必须从电脑指令序列与限制约束中跳出来。 我们应当叙述定义、元数据、关系，而不是过程。
+> 我们必须跳出电脑指令序列的窠臼。 叙述定义、描述元数据、梳理关系，而不是编写过程。
 >
 > —— Grace Murray Hopper，未来的计算机及其管理（1962）
 >
@@ -15,15 +15,11 @@

 [^i]: 正如本章所讨论的，分区是一种有意将大型数据库分解成小型数据库的方式。它与网络分区（net splits）无关，这是节点之间网络中的一种故障类型。我们将在第8章讨论这些错误。

-
-
 > ##### 术语澄清
 >
-> 我们在这里称之为分区`partition`的东西，在MongoDB，Elasticsearch和Solr Cloud中被称为**分片（shard）**；在HBase中称之为**区域(Region)**，Bigtable中的 `tablet`，Cassandra和Riak中的`vnode`以及Couchbase中的`vBucket`。但是，分区（partition）是最为重要的术语，所以我们坚持使用它。
+> 我们在这里称之为**分区（partition）**的东西，在MongoDB，Elasticsearch和Solr Cloud中被称为**分片（shard）**；在HBase中称之为**区域（Region）**，Bigtable中的 **表块（tablet）**，Cassandra和Riak中**虚节点（vnode）**以及Couchbase中的**虚桶（vBucket）**。但是**分区（partition）**是最重要的术语，所以这里坚持使用它。
 >

-
-
 通常情况下，分区是这样定义的，即每条数据（每条记录，每行或每个文档）只属于一个分区。有很多方法可以实现这一点，本章将深入讨论。实际上，每个分区都是自己的小型数据库，尽管数据库可能支持同时触及多个分区的操作。

 要分区数据的主要原因是可扩展性。不同的分区可以放在不共享的集群中的不同节点上（请参阅[第二部分](part-ii.md)关于无共享架构的定义）。因此，大数据集可以分布在多个磁盘上，并且查询负载可以分布在多个处理器上。
@@ -34,16 +30,12 @@

 在本章中，我们将首先介绍分割大型数据集的不同方法，并观察数据索引如何与分区交互。然后，我们将讨论重新平衡，如果您想要添加或删除群集中的节点，则必须进行重新平衡。最后，我们将概述数据库如何将请求路由到正确的分区并执行查询。

-
-
 ## 分片与复制

 ![](img/fig6-1.png)

 **图6-1 组合使用复制和分区：每个节点充当某些分区的领导者，其他分区充当追随者。**

-
-
 ## 键值数据的分片

 假设你有大量的数据，你想分割它。你如何决定在哪些节点上存储哪些记录？

--- a/ddia/ch9.md
+++ b/ddia/ch9.md
@@ -7,16 +7,48 @@

 ---------------

+[TOC]
+


 ## 一致性保证

 ## 线性一致性

+### 什么使得系统线性一致？
+
+### 依赖线性一致性
+
+### 实现线性一致的系统
+
+### 线性一致性的代价
+
+
+
+
+
 ## 顺序保证

+### 顺序与因果
+
+### 序列号顺序
+
+### 全局序列广播
+
+
+
 ## 分布式事务与共识

+### 原子提交与二阶段提交
+
+### 实践中的分布式事务
+
+### 容错的共识
+
+### 成员与协调服务
+
+
+
 ## 本章小结


@@ -476,31 +508,40 @@

 ![](img/fig9-1.png)

-##### 图9-1 
+图9-1

 ![](img/fig9-2.png)
-##### 图9-2
+
+图9-2

 ![](img/fig9-3.png)
-##### 图9-3
+
+图9-3

 ![](img/fig9-4.png)
-##### 图9-4
+
+图9-4

 ![](img/fig9-5.png)
-##### 图9-5
+
+图9-5

 ![](img/fig9-6.png)
-##### 图9-6
+
+图9-6

 ![](img/fig9-7.png)
-##### 图9-7
+
+图9-7

 ![](img/fig9-8.png)
-##### 图9-8
+
+图9-8

 ![](img/fig9-9.png)
-##### 图9-9
+
+图9-9

 ![](img/fig9-10.png)
-##### 图9-10
+
+图9-10
\ No newline at end of file