Fix pic and finished

milu2003 · Feb 23, 2015 · 379b0ba · 379b0ba
1 parent 8033b8b
commit 379b0ba
Show file tree

Hide file tree

Showing 17 changed files with 139 additions and 212 deletions.
diff --git a/020_Distributed_Cluster/05_Empty_cluster.md b/020_Distributed_Cluster/05_Empty_cluster.md
@@ -2,7 +2,7 @@
 
 如果我们启动一个单独的节点，没有数据和索引，这个集群我们称作“只有一个空节点的集群”。
 
-![A cluster with one empty node](https://raw.githubusercontent.com/looly/elasticsearch-definitive-guide-cn/master/images/02-01_cluster.png)
+![A cluster with one empty node](https://raw.githubusercontent.com/looly/elasticsearch-definitive-guide-cn/master/images/elas_0201.png)
 
 一个**节点(node)**就是一个Elasticsearch实例，而一个**集群(cluster)**由一个或多个节点组成，它们具有相同的`cluster.name`，它们协同工作，分享数据和负载。当有新的节点加入或者删除节点，集群就会感知到并平衡数据。
 

diff --git a/020_Distributed_Cluster/15_Add_an_index.md b/020_Distributed_Cluster/15_Add_an_index.md
@@ -27,7 +27,7 @@ PUT /blogs
 ```
 
 附带索引的单一节点集群：
-![附带索引的单一节点集群](https://raw.githubusercontent.com/looly/elasticsearch-definitive-guide-cn/master/images/02-02_one_node.png)
+![附带索引的单一节点集群](https://raw.githubusercontent.com/looly/elasticsearch-definitive-guide-cn/master/images/elas_0202.png)
 
 我们的集群现在看起来像**单节点集群(cluster-one-node)**——三个主分片都被分配到`Node 1`。如果我们现在想检查**集群健康(cluster-health)**，我们将见到以下信息：
 

diff --git a/020_Distributed_Cluster/20_Add_failover.md b/020_Distributed_Cluster/20_Add_failover.md
@@ -11,7 +11,7 @@
 如果我们启动了第二个节点，这个集群应该叫做**双节点集群(cluster-two-nodes)**
 
 双节点集群——所有的主分片和复制分片都被分配:
-![双节点集群](../images/02-03_two_nodes.png)
+![双节点集群](https://raw.githubusercontent.com/looly/elasticsearch-definitive-guide-cn/master/images/elas_0203.png)
 
 第二个节点加入集群时，三个**复制碎片(replica shards)**已经被分配了——与三个主分片一一对应。那意味着在丢失一个节点的情况下依旧可以保证数据的完整性。
 

diff --git a/020_Distributed_Cluster/25_Scale_horizontally.md b/020_Distributed_Cluster/25_Scale_horizontally.md
@@ -3,7 +3,7 @@
 随着应用需求的增长，我们该如何扩展？如果我们启动第三个节点，我们的集群会自我感知，这时便成为了**三节点集群(cluster-three-nodes)**
 
 分片已经被重新分配以平衡负载：
-![三节点集群](../images/02-04_three_nodes.png)
+![三节点集群](https://raw.githubusercontent.com/looly/elasticsearch-definitive-guide-cn/master/images/elas_0204.png)
 
 从`Node 1`和`Node 2`来的分片已经被移动到新的`Node 3`上，这样每个节点就有两个分片，以代替之前的三个。这意味着每个节点的硬件资源（CPU、RAM、I/O）被较少的分片共享，这样每个分片就会有更好的表现。
 

diff --git a/020_Distributed_Cluster/30_Scale_more.md b/020_Distributed_Cluster/30_Scale_more.md
@@ -13,7 +13,7 @@ PUT /blogs/_settings
 ```
 
 增加`number_of_replicas`到2：
-![三节点两复制集群](../images/02-05_replicas.png)
+![三节点两复制集群](https://raw.githubusercontent.com/looly/elasticsearch-definitive-guide-cn/master/images/elas_0205.png)
 
 从图中可以看出，`blogs`索引现在有9个分片：三个主分片和6个复制分片。这意味着我们能够扩展到9个节点，再次的变成每个节点一个分片。这样使我们的搜索性能相比标准的三节点集群扩展**三倍**。
 

diff --git a/020_Distributed_Cluster/35_Coping_with_failure.md b/020_Distributed_Cluster/35_Coping_with_failure.md
@@ -2,7 +2,7 @@
 
 我们已经说过Elasticsearch可以应对节点失效，所以让我们继续尝试。如果我们杀掉第一个节点的进程（以下简称杀掉节点），看起来像如此：
 
-![杀掉一个节点后的集群](../images/02-06_node_failure.png)
+![杀掉一个节点后的集群](https://raw.githubusercontent.com/looly/elasticsearch-definitive-guide-cn/master/images/elas_0206.png)
 
 我们杀掉的节点是一个主节点。必须有一个主节点来让集群的功能可用，所以发生的第一件事就是各节点选举了一个新的主节点：`Node 2`。
 

diff --git a/030_Data/40_Version_control.md b/030_Data/40_Version_control.md
@@ -8,7 +8,7 @@
 
 一天，老板决定做一个促销。瞬间，我们每秒就销售了几个商品。想象两个同时运行的web进程，两者同时处理一件商品的订单：
 
-![img-data-lww](../images/03-01_concurrency.png)
+![img-data-lww](https://raw.githubusercontent.com/looly/elasticsearch-definitive-guide-cn/master/images/elas_0301.png)
 
 `web_1`让`stock_count`失效是因为`web_2`没有察觉到`stock_count`的拷贝已经过期（译者注：`web_1`取数据，减一后更新了`stock_count`。可惜在`web_1`更新`stock_count`前它就拿到了数据，这个数据已经是过期的了，当`web_2`再回来更新`stock_count`时这个数字就是错的。这样就会造成看似卖了一件东西，其实是卖了两件，这个应该属于幻读。）。结果是我们认为自己确实还有更多的商品，最终顾客会因为销售给他们没有的东西而失望。
 

diff --git a/040_Distributed_CRUD/10_Shard_interaction.md b/040_Distributed_CRUD/10_Shard_interaction.md
@@ -2,7 +2,7 @@
 
 为了阐述意图，我们假设有三个节点的集群。它包含一个叫做`bblogs`的索引并拥有两个主分片。每个主分片有两个复制分片。相同的分片不会放在同一个节点上，所以我们的集群是这样的：
 
-![有三个节点一个索引的集群](../images/04-01_index.png)
+![有三个节点一个索引的集群](https://raw.githubusercontent.com/looly/elasticsearch-definitive-guide-cn/master/images/elas_0401.png)
 
 我们能够发送请求给集群中任意一个节点。每个节点都有能力处理任意请求。每个节点都知道任意文档所在的节点，所以也可以将请求转发到需要的节点。下面的例子中，我们将发送所有请求给`Node 1`，这个节点我们将会称之为**请求节点(requesting node)**
 

diff --git a/040_Distributed_CRUD/15_Create_index_delete.md b/040_Distributed_CRUD/15_Create_index_delete.md
@@ -2,7 +2,7 @@
 
 新建、索引和删除请求都是**写(write)**操作，它们必须在主分片上成功完成才能复制到相关的复制分片上。
 
-![新建、索引或删除单一文档](../images/04-02_write.png)
+![新建、索引或删除单一文档](https://raw.githubusercontent.com/looly/elasticsearch-definitive-guide-cn/master/images/elas_0402.png)
 
 下面我们罗列在主分片和复制分片上成功新建、索引或删除一个文档必要的顺序步骤：
 

diff --git a/040_Distributed_CRUD/20_Retrieving.md b/040_Distributed_CRUD/20_Retrieving.md
@@ -2,7 +2,7 @@
 
 文档能够从主分片或任意一个复制分片被检索。
 
-![检索一个文档](../images/04-03_get.png)
+![检索一个文档](https://raw.githubusercontent.com/looly/elasticsearch-definitive-guide-cn/master/images/elas_0403.png)
 
 下面我们罗列在主分片或复制分片上检索一个文档必要的顺序步骤：
 

diff --git a/040_Distributed_CRUD/25_Partial_updates.md b/040_Distributed_CRUD/25_Partial_updates.md
@@ -2,7 +2,7 @@
 
 `update` API 结合了之前提到的读和写的模式。
 
-![局部更新文档](../images/04-04_update.png)
+![局部更新文档](https://raw.githubusercontent.com/looly/elasticsearch-definitive-guide-cn/master/images/elas_0404.png)
 
 下面我们罗列执行局部更新必要的顺序步骤：
 

diff --git a/040_Distributed_CRUD/30_Bulk_requests.md b/040_Distributed_CRUD/30_Bulk_requests.md
@@ -4,7 +4,7 @@
 
 一旦接收到每个节点的应答，然后整理这些响应组合为一个单独的响应，最后返回给客户端。
 
-![通过mget检索多个文档](../images/04-05_mget.png)
+![通过mget检索多个文档](https://raw.githubusercontent.com/looly/elasticsearch-definitive-guide-cn/master/images/elas_0405.png)
 
 下面我们将罗列通过一个`mget`请求检索多个文档的顺序步骤：
 
@@ -13,7 +13,7 @@
 
 `routing` 参数可以被`docs`中的每个文档设置。
 
-![通过打包批量修改文档](../images/04-06_bulk.png)
+![通过打包批量修改文档](https://raw.githubusercontent.com/looly/elasticsearch-definitive-guide-cn/master/images/elas_0406.png)
 
 下面我们将罗列使用一个`bulk`执行多个`create`、`index`、`delete`和`update`请求的顺序步骤：
 

diff --git a/050_Search/10_Multi_index_multi_type.md b/050_Search/10_Multi_index_multi_type.md
@@ -2,39 +2,31 @@
 
 你注意到空搜索的结果中不同类型的文档——`user`和`tweet`——来自于不同的索引——`us`和`gb`。
 
-通过限制我们的搜索到不同的索引或类型，我们可以在集群中跨**所有**文档搜索。Elasticsearch转发搜索请求到集群中平行的主分片或每个分片的复制分片上，收集结果然后选择顶部十个返回给我们。
+通过限制搜索的不同索引或类型，我们可以在集群中跨**所有**文档搜索。Elasticsearch转发搜索请求到集群中平行的主分片或每个分片的复制分片上，收集结果后选择顶部十个返回给我们。
 
 通常，当然，你可能想搜索一个或几个自定的索引或类型，我们能通过定义URL中的索引或类型达到这个目的，像这样：
 
-```javascript
-`/_search`::
+#### `/_search`
+在所有索引的所有类型中搜索
 
-    search all types in all indices
+#### `/gb/_search`
+在索引`gb`的所有类型中搜索
 
-`/gb/_search`::
+#### `/gb,us/_search`
+在索引`gb`和`us`的所有类型中搜索
 
-    search all types in the `gb` index
+#### `/g*,u*/_search`
+在以`g`或`u`开头的索引的所有类型中搜索
 
-`/gb,us/_search`::
+#### `/gb/user/_search`
+在索引`gb`的类型`user`中搜索
 
-    search all types in the `gb` and `us` indices
-
-`/g*,u*/_search`::
-
-    search all types in any indices beginning with `g` or beginning with `u`
-
-`/gb/user/_search`::
-
-    search type `user` in the `gb` index
-
-`/gb,us/user,tweet/_search`::
-
-    search types `user` and `tweet` in the `gb` and `us` indices
-
-`/_all/user,tweet/_search`::
+#### `/gb,us/user,tweet/_search`
+在索引`gb`和`us`的类型为`user`和`tweet`中搜索
 
+#### `/_all/user,tweet/_search`
+在所有索引的`user`和`tweet`中搜索
     search types `user` and `tweet` in all indices
-```
 
 当你搜索包含单一索引时，Elasticsearch转发搜索请求到这个索引的主分片或每个分片的复制分片上，然后聚集每个分片的结果。搜索包含多个索引也是同样的方式——只不过或有更多的分片被关联。
 

diff --git a/050_Search/15_Pagination.md b/050_Search/15_Pagination.md
@@ -10,13 +10,11 @@
 
 如果你想每页显示5个结果，页码从1到3，那请求如下：
 
---------------------------------------------------
 ```javascript
 GET /_search?size=5
 GET /_search?size=5&from=5
 GET /_search?size=5&from=10
 ```
---------------------------------------------------
 
 应该当心分页太深或者一次请求太多的结果。结果在返回前会被排序。但是记住一个搜索请求常常涉及多个分片。每个分片生成自己排好序的结果，它们接着需要集中起来排序以确保整体排序正确。
 

diff --git a/052_Mapping_Analysis/35_Inverted_index.md b/052_Mapping_Analysis/35_Inverted_index.md
@@ -9,34 +9,33 @@ Elasticsearch使用一种叫做**倒排索引(inverted index)**的结构来做
 
 为了创建倒排索引，我们首先切分每个文档的`content`字段为单独的单词（我们把它们叫做**词(terms)**或者**表征(tokens)**）（译者注：关于`terms`和`tokens`的翻译比较生硬，只需知道语句分词后的个体叫做这两个。），把所有的唯一词放入列表并排序，结果是这个样子的：
 
-    Term      Doc_1  Doc_2
-    -------------------------
-    Quick   |       |  X
-    The     |   X   |
-    brown   |   X   |  X
-    dog     |   X   |
-    dogs    |       |  X
-    fox     |   X   |
-    foxes   |       |  X
-    in      |       |  X
-    jumped  |   X   |
-    lazy    |   X   |  X
-    leap    |       |  X
-    over    |   X   |  X
-    quick   |   X   |
-    summer  |       |  X
-    the     |   X   |
-    ------------------------
+|Term    | Doc_1 |Doc_2|
+|--------|-------|-----|
+|Quick   |       |  X  |
+|The     |   X   |     |
+|brown   |   X   |  X  |
+|dog     |   X   |     |
+|dogs    |       |  X  |
+|fox     |   X   |     |
+|foxes   |       |  X  |
+|in      |       |  X  |
+|jumped  |   X   |     |
+|lazy    |   X   |  X  |
+|leap    |       |  X  |
+|over    |   X   |  X  |
+|quick   |   X   |     |
+|summer  |       |  X  |
+|the     |   X   |     ||
 
 现在，如果我们想搜索`"quick brown"`，我们只需要找到每个词在哪个文档中出现既可：
 
 
-    Term      Doc_1  Doc_2
-    -------------------------
-    brown   |   X   |  X
-    quick   |   X   |
-    ------------------------
-    Total   |   2   |  1
+|Term | Doc_1 |Doc_2|
+|-----|-------|-----|
+|brown|   X   |  X  |
+|quick|   X   |     |
+|-----|-------|-----|
+|Total|   2   |  1  |
 
 两个文档都匹配，但是第一个比第二个有更多的匹配项。
 如果我们加入简单的**相似度算法(similarity algorithm)**，计算匹配单词的数目，这样我们就可以说第一个文档比第二个匹配度更高——对于我们的查询具有更多相关性。
@@ -59,19 +58,18 @@ Elasticsearch使用一种叫做**倒排索引(inverted index)**的结构来做
 
 现在的索引：
 
-    Term      Doc_1  Doc_2
-    -------------------------
-    brown   |   X   |  X
-    dog     |   X   |  X
-    fox     |   X   |  X
-    in      |       |  X
-    jump    |   X   |  X
-    lazy    |   X   |  X
-    over    |   X   |  X
-    quick   |   X   |  X
-    summer  |       |  X
-    the     |   X   |  X
-    ------------------------
+|Term    | Doc_1 |Doc_2|
+|--------|-------|-----|
+|brown   |   X   |  X  |
+|dog     |   X   |  X  |
+|fox     |   X   |  X  |
+|in      |       |  X  |
+|jump    |   X   |  X  |
+|lazy    |   X   |  X  |
+|over    |   X   |  X  |
+|quick   |   X   |  X  |
+|summer  |       |  X  |
+|the     |   X   |  X  |
 
 但我们还未成功。我们的搜索`"+Quick +fox"`*依旧*失败，因为`"Quick"`的确切值已经不在索引里，不过，如果我们使用相同的标准化规则处理查询字符串的`content`字段，查询将变成`"+quick +fox"`，这样就可以匹配到两个文档。