希望长大对我而言，是可以做更多想做的事，而不是被迫做更多不想做的事...... 首页

Elasticsearch之mget、bulk、路由原理、深度分页

丁D
学无止境
2019-09-02 08:56
25441已阅读

摘要本次将介绍：批量查询、bulk、document路由原理、quorum机制、multi-index和multi-type、分页/深度分页、query string基础语法、exact value和full text对比。

**学习目标**
> 批量查询
> bulk批量插入，更新，删除
> bulk格式揭秘
> document路由原理
> 读请求路由原理
> quorum机制
> multi-index和multi-type搜索模式
> 分页/深度分页性能
> query string基础语法
> exact value和full text对比

[本文讲解的可参考](https://es.xiaoleilu.com/040_Distributed_CRUD/00_Intro.html)

**批量查询**
```js
mget很重要用于批量查询可以减少网络的请求次数，减少网络开销，提高性能。
//
GET /_mget
{
   "docs" : [
      {
         "_index" : "test_index1",
         "_type" :  "test_type1",
         "_id" :    1
      },
      {
         "_index" : "test_index2",
         "_type" :  "test_type2",
         "_id" :    2
      }
   ]
}
//
查询相同的index，可以简写
GET /test_index/_mget
{
   "docs" : [
      {
         "_type" :  "test_type",
         "_id" :    1
      },
      {
         "_type" :  "test_type",
         "_id" :    2
      }
   ]
}
查询相同的index，相同的type
GET /test_index/test_type/_mget
{
   "ids": [1, 2]
}

返回 docs数组
{
  "docs": [
    {
      "_index": "test_index",
      "_type": "test_type",
      "_id": "1",
      "_version": 2,
      "found": true,
      "_source": {
        "test_field1": "test field1",
        "test_field2": "test field2"
      }
    },
    {...}
  ]
}
```

**bulk批量插入，更新，删除**
```js
使用bulk来进行批量插入，更新，删除
格式：
{"action": {"metadata"}}
{"data"}
//
有哪些类型的操作可以执行呢？
（1）delete：删除一个文档，只要1个json串就可以了，{"data"}不用
（2）create：相当PUT /index/type/id/_create，强制创建，已经存在报错
（3）index：普通的put操作，可以是创建文档，也可以是全量替换文档
（4）update：执行的partial update操作，放在doc里面
//
每个json串不能换行，只能放一行，同时一个json串和一个json串之间，必须有一个换行
//
bulk操作中，任意一个操作失败，是不会影响其他的操作的，不是原子性，没有事务，但是在返回结果里，会告诉你异常日志
//
POST /_bulk
{ "delete": { "_index": "test_index", "_type": "test_type", "_id": "3" }} 
{ "create": { "_index": "test_index", "_type": "test_type", "_id": "12" }}
{ "test_field":    "test12" }
{ "index":  { "_index": "test_index", "_type": "test_type", "_id": "2" }}
{ "test_field":    "replaced test2" }
{ "update": { "_index":"test_index","_type":"test_type","_id":"1","_retry_on_conflict" : 3} }
{ "doc" : {"test_field2" : "bulk test1"} }
//
相同的index
POST /test_index/_bulk
{ "delete": { "_type": "test_type", "_id": "3" }} 
{ "create": { "_type": "test_type", "_id": "12" }}
{ "test_field":    "test12" }
{ "index":  { "_type": "test_type" }}
{ "test_field":    "auto-generate id test" }
{ "index":  { "_type": "test_type", "_id": "2" }}
{ "test_field":    "replaced test2" }
{ "update": { "_type": "test_type", "_id": "1", "_retry_on_conflict" : 3} }
{ "doc" : {"test_field2" : "bulk test1"} }
//
相同的index，相同的type
POST /test_index/test_type/_bulk
{ "delete": { "_id": "3" }} 
{ "create": { "_id": "12" }}
{ "test_field":    "test12" }
{ "index":  { }}
{ "test_field":    "auto-generate id test" }
{ "index":  { "_id": "2" }}
{ "test_field":    "replaced test2" }
{ "update": { "_id": "1", "_retry_on_conflict" : 3} }
{ "doc" : {"test_field2" : "bulk test1"} }
//
最佳大小
bulk request会加载到内存里，如果太大的话，性能反而会下降，因此需要反复尝试一个最佳的bulk size。一般从1000~5000条数据开始，尝试逐渐增加。另外，如果看大小的话，最好是在5~15MB之间。

```

**bulk格式揭秘**
```js
bulk api奇特的json格式

{"action": {"meta"}}\n
{"data"}\n
{"action": {"meta"}}\n
{"data"}\n

[{
  "action": {
 
  },
  "data": {

}
}]
//
es的bulk为什么不用良好的jsonArray格式，这样可读性就很好了?
（1）首先节点收到请求要将传过来的json文本转成jsonArray，
（2）对jsonArray进行解析发送到各个节点进行处理，

问题：如果这样做内存中就会有两个一模一样的数据，一个json文本，一个jsonArray，内存占用更大；
我们在bulk的最佳大小讲过，一般最佳的大小是5M-15M，那现在假设是一个bulk是10M，此时有100个bulk请求过来，
那么大小就是100*10=1000M，大约1G，然后在加一个jsonArray对象就大约2G多了，占用了大量的内存。
//
奇特的格式
{"action": {"meta"}}\n
{"data"}\n
{"action": {"meta"}}\n
{"data"}\n

（1）不用将其转换为json对象，不会出现内存中的相同数据的拷贝，直接按照换行符切割json
（2）对每两个一组的json，读取meta，进行document路由

5、最大的优势在于，不需要将json数组解析为一个JSONArray对象，形成一份大数据的拷贝，浪费内存空间，尽可能地保证性能

```

**document路由原理**
```js
document是怎么路由到对应得shard上面的

路由算法：shard = hash(routing) % number_of_primary_shards

例子：一个index有3个primary shard，P0，P1，P2
每次增删改查一个document的时候，都会带过来一个routing number，默认就是这个document的_id（可能是手动指定，也可能是自动生成）routing = _id，假设_id=1 
计算_id的hash，对primary shard求余数得到对应得分片

routing默认是id，但是也可以自己指定
//
put /index/type/id?routing=user_id
//

自己指定routing value，很有用，可以保证某一类的document被分到相同的shard上面，在后续负载均衡，和批量查询能提高性能。

这也是primary shard在index创建后不可变的原因，primary shard变了shard就变了。

```

**读请求路由原理**
[参考](https://es.xiaoleilu.com/040_Distributed_CRUD/20_Retrieving.html)
```js
每个node都知道每个shard在哪个node上面
//
1、客户端发送请求到任意一个node，成为coordinate node（协调节点，请求节点）
2、coordinate node对document进行路由，将请求转发到对应的node，此时会使用round-robin随机轮询算法，在primary shard以及其所有replica中随机选择一个，让读请求负载均衡
3、接收请求的node返回document给coordinate node
4、coordinate node返回document给客户端
5、特殊情况：document如果还在建立索引过程中，可能只有primary shard有，任何一个replica shard都没有，
此时可能会导致无法读取到document，但是document完成索引建立之后，primary shard和replica shard就都有了

特殊情况下，到底会不会返回document还会查询不到还是到主分片查询？？？
```

**quorum机制**
```js
我们知道我们的增删改操作，都需要到primark shard进行才行，然后同步到replica shard；
那么是一个primary shard是active就可以执行还是所有的replica和primark都要active呢？？
//
我们在发送任何一个增删改操作的时候，比如说put /index/type/id，都可以带上一个consistency参数
put /index/type/id?consistency=quorum
//
one：要求我们这个写操作，只要有一个primary shard是active活跃可用的，就可以执行
all：要求我们这个写操作，必须所有的primary shard和replica shard都是活跃的，才可以执行这个写操作
quorum：默认的值，要求所有的shard中，必须是大部分的shard都是活跃的，可用的，才可以执行这个写操作
//
quorum机制，写之前必须确保大多数shard都可用，int( (primary + number_of_replicas) / 2 ) + 1，当number_of_replicas>1时才生效
//
举个例子，3个primary shard，number_of_replicas=2，总共有3 + 3 * 2 = 9个shard
quorum = int( (3 + 2) / 2 ) + 1 = 4？还是5
所以，要求9个shard中至少有4个shard是active状态的，才可以执行这个写操作
//
//
quorum不齐全时，会等待wait，默认1分钟，timeout，100，30s
//
等待期间，期望活跃的shard数量可以增加，最后实在不行，就会timeout
我们其实可以在写操作的时候，加一个timeout参数，比如说
put /index/type/id?timeout=30

//
注意：由于replica shard和primary不能再用一个node上，并且相同的replica也不能再相同node上面所以，可能会由于节点不够而导致不能进行写操作，
```

**multi-index和multi-type搜索模式**
```js
如何一次性搜索多个index和多个type下的数据

（1）/_search：所有索引，所有type下的所有数据都搜索出来
（2）/index1/_search：指定一个index，搜索其下所有type的数据
（3）/index1,index2/_search：同时搜索两个index下的数据
（4）/*1,*2/_search：按照通配符去匹配多个索引
（5）/index1/type1/_search：搜索一个index下指定的type的数据
（6）/index1/type1,type2/_search：可以搜索一个index下多个type的数据
（7）/index1,index2/type1,type2/_search：搜索多个index下的多个type的数据
（8）/_all/type1,type2/_search：_all，可以代表搜索所有index下的指定type的数据
```  
**分页/深度分页性能**
```js
GET /_search?size=10
GET /_search?size=10&from=0
GET /_search?size=10&from=20

有这么写数据被分布在不同的shard上面  
8 9 10 10 11 11 11 12 13 13 14 16  18 18  20 20 
现在查询 每页2条  查询第一页的时候返回  8 9 第二页的时候  10  10 
   
shard1    shard2     shard3                       
  10        10         8
  11        11         9

12        11         16 
  13        13         20

14        18         20

当一个请求到协调节点的时候，协调节点将请求转发到所有的primary shard（也可以是replica）
各个节点返回数据到协调节点，协调节点在内存中进行排序，取出数据返回客户端

每个shard返回对应页数的条数??错误，分析如下

查询第一页的时候
shard1    shard2     shard3       8   9  对
  10       10          8                 
  11       11          9

第二页--错误示例         
shard1    shard2     shard3       12  11  错的
  12        11         16        
  13        13         20

第二页--正确
10    10     8            10   10
11    11     9

12    11     16 
13    13     20

所以当分页查询的时候，应该返回对应页面之前所有的数据给协调节点，
因为你不知道当前这个node的第二页的数据在其他node上面是第几页。

这样的话当分页进行到很深的时候，假设我查询第1000页   每页10条   
那么每个node就要返回0~10000的数据给协调节点，
那么假设假设有3个shard  协调节点就要对30000个数据进行排序，就会性能问题

```

**query string基础语法**
```js
查询test_field字段包含test，（分词后，有一个单词是test，即使是test1页不匹配，一定要确切值）
GET /test_index/test_type/_search?q=test_field:test
同上
GET /test_index/test_type/_search?q=+test_field:test
查询test_field字段不包含test（test1  不包含test）
GET /test_index/test_type/_search?q=-test_field:test
没有指定字段则默认是_all
GET /test_index/test_type/_search?q=test

es中的_all元数据，在建立索引的时候，我们插入一条document，它里面包含了多个field，
此时，es会自动将多个field的值，全部用字符串的方式串联起来，变成一个长的字符串，作为_all field的值，如下所示：

{
  "name": "jack",
  "age": 26,
  "email": "jack@sina.com",
  "address": "guamgzhou"
}

"jack 26 jack@sina.com guangzhou"，作为这一条document的_all field的值，同时进行分词后建立对应的倒排索引
```

**exact value和full text对比**
```js
exact value：精准匹配
比如有一个字段值2017-01-01，我们搜索的时候 输入‘2017-01-01’才搜索得到。
如果搜索2017或01是搜索不到的

full text：全文匹配
（1）缩写 vs. 全程：cn vs. china
（2）时态/复数转化：like liked likes
（3）大小写：Tom vs tom
（4）同义词：like vs love

2017-01-01，2017 01 01，搜索2017，或者01，都可以搜索出来
china，搜索cn，也可以将china搜索出来
likes，搜索like，也可以将likes搜索出来
Tom，搜索tom，也可以将Tom搜索出来
like，搜索love，同义词，也可以将like搜索出来

就不是说单纯的只是匹配完整的一个值，而是可以对值进行拆分词语后（分词）进行匹配，
也可以通过缩写、时态、大小写、同义词等进行匹配
```

上一篇：分布式系统的接口幂等性设计

下一篇：Elasticsearch之mapping介绍