diff --git a/070_Index_Mgmt/50_Reindexing.asciidoc b/070_Index_Mgmt/50_Reindexing.asciidoc index de15cd59f..c0452ccb8 100644 --- a/070_Index_Mgmt/50_Reindexing.asciidoc +++ b/070_Index_Mgmt/50_Reindexing.asciidoc @@ -38,7 +38,7 @@ GET /old_index/_search?scroll=1m -------------------------------------------------- -如果旧的索引持续会有变化，你希望新的索引中也包括那些新加的文档。那就可以对新加的文档做重新索引， +如果旧的索引会持续变化，你希望新的索引中也包括那些新加的文档。那就可以对新加的文档做重新索引， 但还是要用日期类字段过滤来匹配那些新加的文档。 **** diff --git a/070_Index_Mgmt/55_Aliases.asciidoc b/070_Index_Mgmt/55_Aliases.asciidoc index 7110018cb..95741cba4 100644 --- a/070_Index_Mgmt/55_Aliases.asciidoc +++ b/070_Index_Mgmt/55_Aliases.asciidoc @@ -3,7 +3,7 @@ 在前面提到的，重建索引的问题是必须更新应用中的索引名称。 ((("index aliases"))) 索引别名就是用来解决这个问题的！ -索引 _别名_ 就像一个快捷方式或软连接，可以指向一个或多个索引，也可以给任何一个需要索引名的API来使用。别名 ((("aliases, index"))) 带给我们极大的灵活性，允许我们做下面这些： +索引 _别名_ 就像一个快捷方式或软连接，可以指向一个或多个索引，也可以给任何一个需要索引名的API来使用。_别名_ ((("aliases, index"))) 带给我们极大的灵活性，允许我们做下面这些： * 在运行的集群中可以无缝的从一个索引切换到另一个索引 * 给多个索引分组 (例如， `last_three_months`) diff --git a/075_Inside_a_shard/10_Intro.asciidoc b/075_Inside_a_shard/10_Intro.asciidoc index df1755ae0..9bf147f40 100644 --- a/075_Inside_a_shard/10_Intro.asciidoc +++ b/075_Inside_a_shard/10_Intro.asciidoc @@ -1,7 +1,7 @@ [[inside-a-shard]] == 分片内部原理 -在 <>, 我们介绍了 _分片_, 并将它((("shards"))) 描述成最小的 _工作单元_。但是究竟什么 _是_ 一个分片，它是如何工作的？ +在 <>, 我们介绍了 _分片_, 并将它((("shards"))) 描述成最小的 _工作单元_ 。但是究竟什么 _是_ 一个分片，它是如何工作的？ 在这个章节，我们回答以下问题: * 为什么搜索是 _近_ 实时的？ diff --git a/075_Inside_a_shard/50_Persistent_changes.asciidoc b/075_Inside_a_shard/50_Persistent_changes.asciidoc index fac93613d..4a3a9cca2 100644 --- a/075_Inside_a_shard/50_Persistent_changes.asciidoc +++ b/075_Inside_a_shard/50_Persistent_changes.asciidoc @@ -76,7 +76,7 @@ POST /_flush?wait_for_ongoing <2> <1> 刷新（flush） `blogs` 索引。 <2> 刷新（flush）所有的索引并且并且等待所有刷新在返回前完成。 -你很少需要自己手动执行一个的 `flush` 操作；通常情况下，自动刷新就足够了。 +你很少需要自己手动执行 `flush` 操作；通常情况下，自动刷新就足够了。 这就是说，在重启节点或关闭索引之前执行 <> 有益于你的索引。当 Elasticsearch 尝试恢复或重新打开一个索引， 它需要重放 translog 中所有的操作，所以如果日志越短，恢复越快。 diff --git a/075_Inside_a_shard/60_Segment_merging.asciidoc b/075_Inside_a_shard/60_Segment_merging.asciidoc index e18f760fc..a3c5153a4 100644 --- a/075_Inside_a_shard/60_Segment_merging.asciidoc +++ b/075_Inside_a_shard/60_Segment_merging.asciidoc @@ -42,7 +42,7 @@ TIP: 查看 <> 来为你的实例获取关于合并调整 `optimize` API大可看做是 _强制合并_ API((("merging segments", "optimize API and")))((("optimize API")))((("segments", "merging", "optimize API")))。它会将一个分片强制合并到 `max_num_segments` 参数指定大小的段数目。 这样做的意图是减少段的数量（通常减少到一个），来提升搜索性能。 -WARNING: `optimize` API _不应该_ 被用在一个动态索引————一个正在被活跃更新的索引。后台合并流程已经可以很好地完成工作。 +WARNING: `optimize` API _不应该_ 被用在一个活跃的索引————一个正积极更新的索引。后台合并流程已经可以很好地完成工作。 optimizing 会阻碍这个进程。不要干扰它！ 在特定情况下，使用 `optimize` API 颇有益处。例如在日志这种用例下，每天、每周、每月的日志被存储在一个索引中。 @@ -59,6 +59,6 @@ POST /logstash-2014-10/_optimize?max_num_segments=1 <1> [WARNING] ==== -请注意，使用 `optimize` API 触发段合并的操作一点也不会受到任何资源上的限制。这可能会消耗掉你节点上全部的I/O资源, 使其没有余裕来处理搜索请求，从而有可能使集群失去响应。 +请注意，使用 `optimize` API 触发段合并的操作不会受到任何资源上的限制。这可能会消耗掉你节点上全部的I/O资源, 使其没有余裕来处理搜索请求，从而有可能使集群失去响应。 如果你想要对索引执行 `optimize`，你需要先使用分片分配（查看 <>）把索引移到一个安全的节点，再执行。 ====