@@ -27,13 +27,13 @@ PUT weibo/_settings
2727}
2828```
2929
30- ES 支持修改索引的副本系数,但不支持随意修改索引的主分片数,这与 ES 分片的路由机制有关,ES 使用以下公式来决定每条数据存储在哪个具体的分片上 :
30+ ES 支持修改索引的副本系数,但不支持随意修改索引的主分片数,这与 ES 分片的路由机制有关,ES 使用以下公式来决定每条数据存储在哪个分片上 :
3131
3232``` java
3333shard = hash(routing) % number_of_primary_shards
3434```
3535
36- routing 是一个任意字符串 ,默认是 ` _id ` ,同时也支持自定义 。ES 对其进行哈希运算然后按 number_of_primary_shards 进行取余,之后就计算出存储分片的序号 。基于这个原因,所以 ES 不允许对 number_of_primary_shards 进行修改,因为这会导致已有数据存储位置的计算规则失效 。
36+ routing 是一个任意的字符串 ,默认是 ` _id ` ,即使用 ` _id ` 进行分片计算,当然也支持自定义分片键 。ES 对其进行哈希运算然后按 ` number_of_primary_shards ` 取余后计算出存储分片的序号 。基于这个原因,所以 ES 不允许对 ` number_of_primary_shards ` 进行修改,因为这会导致已有数据存储位置的失效 。
3737
3838## 1.3 查看与删除
3939
@@ -52,7 +52,7 @@ DELETE weibo
5252
5353## 1.4 打开与关闭
5454
55- ES 中的索引支持打开和关闭操作,索引关闭不能进行读写操作,后其占用的系统资源也会随之减少 。索引打开和关闭的语法为:
55+ ES 中的索引支持打开和关闭操作,索引关闭后就无法进行读写操作,因此其占用的系统资源也会随之减少 。索引打开和关闭的语法为:
5656
5757``` shell
5858# 关闭索引
@@ -62,7 +62,7 @@ POST weibo/_close
6262POST weibo/_open
6363```
6464
65- ES 支持一次关闭多个索引,多个索引名之间使用逗号分隔,同时也支持通配符和 ` _all ` 关键字,示例如下:
65+ ES 支持一次关闭多个索引,多个索引名之间需要使用逗号分隔,同时也支持使用通配符和 ` _all ` 关键字,示例如下:
6666
6767``` shell
6868# 关闭多个索引,ignore_unavailable=true代表如果其中某个索引不存在,则忽略该索引
@@ -88,7 +88,7 @@ PUT weibo/_doc/1
8888}
8989```
9090
91- 这里需要注意的是在 7.x 版本后 ES 已经不推荐使用文档类型 ,所以这里的 ` _doc ` 其表示端点名称而不是文档类型 。输出如下:
91+ 这里需要注意的是在 7.x 版本后 ES 已经不推荐使用文档类型的概念 ,所以这里的 ` _doc ` 表示端点名称而不是文档类型 。输出如下:
9292
9393``` json
9494{
@@ -114,23 +114,23 @@ PUT weibo/_doc/1
114114
115115### 2. _ version
116116
117- ` _version ` 为文档版本号,基于它可以实现乐观锁的效果,需要配合 version_type 使用,version_type 有以下可选值:
117+ ` _version ` 为文档版本号,基于它可以实现乐观锁的效果,需要配合 ` version_type ` 使用,` version_type ` 有以下可选值:
118118
119119+ ** interna** :当给定的版本号与文档版本号相同时候,才执行对应的操作;
120120
121- + ** external 或 external_gt** :如果给定版本号大于存储文档的版本或者原文档不存在时,才执行对应的操作,给定版本号将用作新的版本。
121+ + ** external 或 external_gt** :如果给定版本号大于存储文档的版本或者原文档不存在时,才执行对应的操作,给定的版本号将用作新的版本;
122122
123- + ** external_gte** :和上一条类似,等价于 gt + equal ,即给定版本号大于或等于存储文档的版本或者原文档不存在时,才执行对应的操作。
123+ + ** external_gte** :和上一条类似,等价于 ` gt + equal ` ,即给定版本号大于或等于存储文档的版本或者原文档不存在时,才执行对应的操作。
124124
125125使用示例:` PUT weibo/_doc/1?version=2&version_type=external { ... } `
126126
127127### 3. _ shards
128128
129129输出结果中的 ` _shards ` 节点下有三个参数,其含义分别如下:
130130
131- - ** total** :操作涉及到的分片综述 ,这里由于创建 ` weibo ` 索引时指定主分片数量和副本系数都是1 ,所以 只有 1个 primary 分片和 1 个 replica 分片,故其总数为 2;
132- - ** successful** :这里我采用的是单节点的 ES , replica 分片实际上是不存在的。因为按照 ES 的规则,primary 分片及其对应的replica 分片不能处于同一台主机上,因为处于同一台主机上时无法达到容错的效果。所以这里只有 primary 分片写入数据成功,故值为1 ;
133- - ** failed** :执行复制操作失败的 replica 分片的数量,这里由于 replica 分片本生就不存在所以值为 0。
131+ - ** total** :操作涉及到的分片总数 ,这里由于创建 ` weibo ` 索引时指定主分片数量和副本系数都是 1 ,所以 只有 1 个 primary 分片和 1 个 replica 分片,故总数为 2;
132+ - ** successful** :这里我采用的是单节点的 ES , replica 分片实际上是不存在的。因为按照 ES 的规则,primary 分片及其对应的 replica 分片不能处于同一台主机上,因为处于同一台主机上时无法达到容错的效果。所以这里只有 primary 分片写入数据成功,故值为 1 ;
133+ - ** failed** :执行复制操作失败的 replica 分片的数量,这里由于 replica 分片本生就不存在所以值为 0 。
134134
135135### 4. routing
136136
@@ -151,7 +151,7 @@ POST weibo/_doc?routing=kimchy
151151GET weibo/_doc/1
152152```
153153
154- 需要注意的是, 文档的实际内容位于查询结果的 ` _source ` 节点下,输出如下:
154+ 文档的实际内容位于查询结果的 ` _source ` 节点下,输出如下:
155155
156156``` json
157157{
@@ -170,7 +170,7 @@ GET weibo/_doc/1
170170}
171171```
172172
173- 默认情况下会返回文档全部字段,如果你只想返回部分字段或者排除部分字段,则可以使用 ` _source_includes ` 关键字或 ` _source_excludes ` 关键字。
173+ 默认情况下会返回文档全部字段,如果你只想返回部分字段或者排除部分字段,则可以使用 ` _source_includes ` 关键字或 ` _source_excludes ` 关键字:
174174
175175``` shell
176176GET weibo/_doc/1? _source_includes=user
@@ -189,7 +189,7 @@ GET weibo/_doc/1?_source=false
189189GET weibo/_source/1
190190```
191191
192- 此时也支持使用 ` _source_includes ` 和 ` _source_excludes ` 来包含和排除部分字段:
192+ 此时依然支持使用 ` _source_includes ` 和 ` _source_excludes ` 来包含和排除部分字段:
193193
194194```
195195GET weibo/_source/1?_source_includes=user
@@ -198,7 +198,7 @@ GET weibo/_source/1?_source_excludes=message
198198
199199## 2.3 更新文档
200200
201- 新增相同 ` _id ` 的文档就等价于执行更新操作 ,此时会用新的文档内容完全替换已有的文档内容,示例如下:
201+ 新增相同 ` _id ` 的文档等价于执行更新操作 ,此时会用新的文档内容完全替换已有的文档内容,示例如下:
202202
203203``` json
204204POST weibo/_doc/1
@@ -220,7 +220,7 @@ POST weibo/_update/1
220220}
221221```
222222
223- 如果你的更新操作需要依赖原值,这里假设我要更新的用户名需要由之前的用户名拼接而成 ,此时语法如下。更新完成后,新的用户名为 ` Tom Cat ` 。这里的 painless 是 ES 内置的一种脚本语言,params 是参数的集合,ctx 是上下文执行对象,其 ` _source ` 指向原文档的内容。
223+ 如果更新操作需要依赖原值,这里假设要更新的用户名需要由之前的用户名拼接而成 ,此时语法如下。更新完成后,新的用户名为 ` Tom Cat ` 。这里的 painless 是 ES 内置的一种脚本语言,params 是参数的集合,ctx 是上下文执行对象,其 ` _source ` 指向原文档的内容:
224224
225225``` json
226226POST weibo/_update/1/
@@ -237,7 +237,7 @@ POST weibo/_update/1/
237237
238238## 2.4 删除文档
239239
240- 删除文档时,可以指定版本以确保我们尝试删除的相关文档实际上已被删除,并且在此期间没有更改。 对文档执行的每个写入操作(包括删除)都会导致其版本递增。删除文档的版本号在删除后仍可短时间使用,以便控制并发操作。已删除文档的版本保持可用的时间长度由 index.gc_deletes 索引设置确定,默认为60秒 。删除示例如下:
240+ 对文档执行的每个写入操作(包括删除)都会导致其版本号递增。删除文档时,可以通过指定版本号来确保文档在删除期间没有被其它用户更改;被删除的文档版本在删除后的短时间内仍使用,以便更好地支持并发操作。该时间长度由 ` index.gc_deletes ` 索引设置,默认为 60 秒 。删除示例如下:
241241
242242``` shell
243243DELETE /weibo/_doc/1? version=2& version_type=interna
@@ -263,7 +263,7 @@ GET /weibo/_mget
263263}
264264```
265265
266- 上面的查询语句也可以进行如下简写 :
266+ 上面的查询语句也可以简写如下 :
267267
268268``` json
269269GET /weibo/_mget
@@ -293,7 +293,7 @@ GET /weibo/_mget
293293}
294294```
295295
296- 通常我们的查询都没有这么复杂,只需要所有文档都返回特定字段即可,此时可以使用以下语法 :
296+ 如果想要所有的文档都返回相同的字段,可以使用以下语法 :
297297
298298``` json
299299GET /weibo/_mget?_source_includes=user,message
@@ -312,7 +312,7 @@ POST _bulk
312312{ "script" :{"source" :" ctx._source.user+=params.user" ,"lang" :" painless" ,"params" :{"user" : " Cat" }}}
313313```
314314
315- 上面是一个批量更新的示例,其简化后抽象语法格式如下, 需要注意的是这里语法是非常严格的:一个更新操作必须由两行 Json 组成,第一行 Json 用于说明操作、标识文档位置和其他可选配置, 第二行 Json 用于存放数据或者指明更新方式 :
315+ 上面是一个批量更新的示例,其抽象语法格式如下。 需要注意的是这里语法是非常严格的:一个更新操作必须由两行 Json 组成,第一行 Json 用于指明操作,文档位置和其他可选配置, 第二行 Json 用于存放数据或指明更新的方式 :
316316
317317``` txt
318318POST _bulk
@@ -325,7 +325,7 @@ POST _bulk
325325....
326326```
327327
328- 另外一个需要注意的点是每行 Json 都必须遵循单行模式,不能是多行模式,即如下的语法是错误的:
328+ 另外一个需要注意的是每行 Json 都必须遵循单行模式,不能是多行模式,即如下的语法是错误的:
329329
330330``` json
331331{
@@ -339,4 +339,4 @@ POST _bulk
339339}
340340```
341341
342- 之所以这样设计是因为如果允许多行模式,则其解析会比较麻烦且耗费性能,假设我们一次性批量执行上万个更新,则用于描述其操作的 Json 文件就会非常大,此时程序需要将其拷贝到内存中先进行解析,这个操作既浪费了内存又浪费了计算资源 。而采用单行模式就能避免这个问题,程序只需要逐行读取记录,每读取两行则必然就是一个完整的操作,此时只需要将其发送到对应分片节点上执行即可。
342+ 之所以这样设计是因为如果允许多行模式,其解析就会比较繁琐且耗费性能,假设我们一次批量执行上万个更新,则用于描述操作的 Json 文件就会非常大,此时程序需要将其拷贝到内存中先进行解析,这个操作既浪费内存又浪费计算资源 。而采用单行模式就能避免这个问题,程序只需要逐行读取记录,每读取两行则必然就是一个完整的操作,此时只需要将其发送到对应分片节点上执行即可。
0 commit comments