improve text in chapter 2

ch02.md

@@ -192,30 +192,30 @@ network model 是 hierarchical model 的一种扩展：允许一个节点有多
 
 | 数据模型        |                                        | 编程语言 |                    | 性能 & 空间                                                            |
 | --------------- | -------------------------------------- | -------- | ------------------ | ---------------------------------------------------------------------- |
-| schema-on-read  | 写入时不校验，而在读取时进行动态解析。 | 弱类型   | 动态，在运行时解析 | 读取时动态解析，性能较差。写入时无法确定类型，无法对齐空间利用率较差。 |
+| schema-on-read  | 写入时不校验，而在读取时进行动态解析。 | 弱类型   | 动态，在运行时解析 | 读取时动态解析，性能较差。写入时无法确定类型，无法对齐，空间利用率较差。 |
 | schema-on-write | 写入时校验，数据对齐到 schema          | 强类型   | 静态，编译时确定   | 性能和空间使用都较优。                                                 |
 
 文档型数据库使用场景特点：
 
 1. 有多种类型的数据，但每个放一张表又不合适。
-2. 数据类型和结构又外部决定，你没办法控制数据的变化。
+2. 数据类型和结构由外部决定，你没办法控制数据的变化。
 
 ### 查询时的数据局部性
 
-如果你同时需要文档中所有内容，把文档顺序存会效率比较高。
+如果你同时需要文档中所有内容，把文档顺序存储，访问会效率比较高。
 
 但如果你只需要访问文档中的某些字段，则文档仍需要将文档全部加载出。
 
 但运用这种局部性不局限于文档型数据库。不同的数据库，会针对不同场景，调整数据物理分布以适应常用访问模式的局部性。
 
-- 如 Spanner 中允许表被声明为嵌入到父表中——常见关联内嵌
+- Spanner 中允许表被声明为嵌入到父表中——常用关联内嵌（获得类似文档模型的结构）
 - HBase 和 Cassandra 使用列族来聚集数据——分析型
 - 图数据库中，将点和出边存在一个机器上——图遍历
 
 ### 关系型和文档型的融合
 
 - MySQL 和 PostgreSQL 开始支持 JSON
-  原生支持 JSON 可以理解为，MySQL 可以理解 JSON 格式。如 Date 格式一样，可以把某个字段作为 JSON 格式，可以修改其中的某个字段，可以在其中某个字段建立索引。
+  原生支持 JSON 可以理解为，MySQL 可以理解 JSON 类型。如 Date 这种复杂格式一样，可以让某个字段为 JSON 类型、可以修改 Join 字段的某个属性、可以在 Json 字段中某个属性建立索引。
 - RethinkDB 在查询中支持 relational-link Joins
 
 科德（Codd）：**nonsimple domains**，记录中的值除了简单类型（数字、字符串），还可以一个嵌套关系（表）。这很像 SQL 对 XML、JSON 的支持。
@@ -367,7 +367,7 @@ db.observations.mapReduce(
 );
 ```
 
-上述语句在执行时，经历了：筛选 → 遍历并执行 map → 对输出按 key 聚集（shuffle）→ 对聚集的数据注意 reduce → 输出结果集。
+上述语句在执行时，经历了：筛选（filter） → 遍历并执行 map → 对输出按 key 聚集（shuffle）→ 对聚集的数据逐一 reduce → 输出结果集。
 
 MapReduce 一些特点：
 
@@ -378,7 +378,7 @@ MapReduce 一些特点：
 
 1. 不是所有的分布式 SQL 都基于 MapReduce 实现。
 2. 不是只有 MapReduce 才允许嵌入通用语言（如 js）模块。
-3. MapReduce 是有一定**理解成本**的，需要熟悉其执行逻辑才能让两个函数紧密配合。
+3. MapReduce 是有一定**理解成本**的，需要非常熟悉其执行原理才能让两个函数紧密配合。
 
 MongoDB 2.2+ 进化版，_aggregation pipeline:_
 
@@ -400,13 +400,13 @@ db.observations.aggregate([
 # 图模型
 
 - 文档模型的适用场景？
-  你的数据集中存在着大量**一对多**（one-to-many）的关系。
+  你的建模场景中存在着大量**一对多**（one-to-many）的关系。
 - 图模型的适用场景？
-  你的数据集中存在大量的**多对多**（many-to-many）的关系。
+  你的建模场景中存在大量的**多对多**（many-to-many）的关系。
 
 ## 基本概念
 
-图数据模型的基本概念一般有三个：**点**，**边**和附着于两者之上的**属性**。
+图数据模型（属性图）的基本概念一般有三个：**点**，**边**和附着于两者之上的**属性**。
 
 常见的可以用图建模的场景：
 
@@ -416,19 +416,19 @@ db.observations.aggregate([
 | 互联网   | 网页是点，链接关系是边      | PageRank               |
 | 路网     | 交通枢纽是点，铁路/公路是边 | 路径规划，导航最短路径 |
 | 洗钱     | 账户是点，转账关系是边      | 判断是否有环           |
-| 知识图谱 | 概念时点，关联关系是边      | 启发式问答             |
+| 知识图谱 | 概念是点，关联关系是边      | 启发式问答             |
 
-- 同构（_homogeneous_）数据和异构数据
+> 同构（homogeneous）数据和异构数据
-  图中的点可以都具有相同类型，但是，也可以具有不同类型，并且更为强大。
+> 图模型中的点变可以像关系中的表一样都具有相同类型；但是，一张图中的点和变也可以具有不同类型，能够容纳异构数据是图模型善于处理多对多关系的一大原因。
 
-本节都会以下图为例，它表示了一对夫妇，来自美国爱达荷州的 Lucy 和来自法国 的 Alain。他们已婚，住在伦敦。
+本节都会以下图为例，它表示了一对夫妇，来自美国爱达荷州的 Lucy 和来自法国 的 Alain：他们已婚，住在伦敦。
 
 ![example](img/ch02-fig05.png)
 
 有多种对图的建模方式：
 
-1. 属性图（property graph）：比较主流，如 Neo4j、Titan、InfiniteGraph
+1. **属性图（property graph）**：比较主流，如 Neo4j、Titan、InfiniteGraph
-2. 三元组（triple-store）：如 Datomic、AllegroGraph
+2. **三元组（triple-store）**：如 Datomic、AllegroGraph
 
 ## 属性图（PG，Property Graphs）
 
@@ -440,8 +440,8 @@ db.observations.aggregate([
 | 属性集（kv 对表示）            | 属性集（kv 对表示）         |
 | 表示点类型的 type？            | 表示边类型的 label          |
 
-- Q：有一个疑惑点，为什么书中对于 PG 点的定义中没有 Type？
+> Q：有一个疑惑点，为什么书中对于 PG 点的定义中没有 Type？
-  如果数据是异构的，应该有才对；莫非是通过不同的属性来标记不同的类型？
+> 因为属性图具体实现时也可以分为强类型和弱类型，NebulaGraph 是强类型，好处在于效率高，但灵活性差；Neo4j 是弱类型。书中应该是用的弱类型，此时每个点都是一组属性集，不需要 type。
 
 如果感觉不直观，可以使用我们熟悉的 SQL 语义来构建一个图模型，如下图。（Facebook TAO 论文中的单机存储引擎便是 MySQL）
 
@@ -522,7 +522,7 @@ RETURN person.name
 
 正如声明式查询语言的一贯特点，你只需描述问题，不必担心执行过程。但与 SQL 的区别在于，SQL 基于关系代数，Cypher 类似正则表达式。
 
-无论是 BFS、DFS 还是剪枝等实现细节，都不需要关心。
+无论是 BFS、DFS 还是剪枝等实现细节，一般来说（但是不同厂商通常都会有不同的最佳实践），用户都不需要关心。
 
 ## 使用 SQL 进行图查询
 
@@ -596,7 +596,7 @@ _:namerica a :Location; :name "North America"; :type "continent".
 
 ### 语义网（The **Semantic Web**）
 
-万维网之父 Tim Berners Lee 于 1998 年提出，知识图谱前身。其目的在于对网络中的资源进行结构化，从而让计算机能够**理解**网络中的数据。即不是以文本、二进制流等等，而是通过某种标准结构化互相关联的数据。
+万维网之父 Tim Berners Lee 于 1998 年提出，知识图谱前身。其目的在于对网络中的资源进行结构化，从而让计算机能够**理解**网络中的数据。即不是以文本、二进制流等非结构数据呈现内容，而是以某种标准结构化互联网上通过超链接而关联的数据。
 
 **语义**：提供一种统一的方式对所有资源进行描述和**结构化**（机器可读）。
 
@@ -606,7 +606,7 @@ _:namerica a :Location; :name "North America"; :type "continent".
 
 ![ddia2-rdf.png](img/ch02-semantic-web-stack.png)
 
-其中 **RDF** （_ResourceDescription Framework，资源描述框架_）提供了一种结构化网络中数据的标准。使发布到网络中的任何资源（文字、图片、视频、网页），都能以统一的形式被计算机理解。即，不需要让资源使用方深度学习抽取资源的语义，而是靠资源提供方通过 RDF 主动提供其资源语义。
+其中 **RDF** （ *ResourceDescription Framework，资源描述框架* ）提供了一种结构化网络中数据的标准。使发布到网络中的任何资源（文字、图片、视频、网页），都能以统一的形式被计算机理解。从另一个角度来理解，即，不需要资源使用方通过深度学习等方式来抽取语义，而是靠资源提供方通过 RDF 主动提供其资源语义。
 
 感觉有点理想主义，但互联网、开源社区都是靠这种理想主义、分享精神发展起来的！