Elasticsearch-2-集群状态检查和CRUD操作

发表于 | 分类于

检查集群的健康状态

Kibana中

1
GET _cat/health?v

返回值

1
2
epoch      timestamp cluster       status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1537168122 15:08:42  elasticsearch yellow          1         1      1   1    0    0        1             0                  -                 50.0%

status:集群的健康状况
green:每个索引的primary shard和replica shard都是active状态的
yellow:每个缩影的primary shard都是active状态的,但是部分replica shard不是active状态,处于不可用的状态.
red:不是所有索引的primary shard都是active状态,部分索引有数据丢失了

当只启动一个es的时候 集群状态是yellow的,，就启动了一个es进程，相当于就只有一个node。现在es中有一个index，就是kibana自己内置建立的index。由于默认的配置是给每个index分配5个primary shard和5个replica shard，而且primary shard和replica shard不能在同一台机器上（为了容错）。现在kibana自己建立的index是1个primary shard和1个replica shard。当前就一个node，所以只有1个primary shard被分配了和启动了，但是一个replica shard没有第二台机器去启动。
此时只要启动第二个es进程，就会在es集群中有2个node，然后那1个replica shard就会自动分配过去，然后cluster status就会变成green状态。

索引管理

快速查看集群中有哪些索引:

1
GET /_cat/indices?v

返回值

1
2
health status index   uuid                   pri rep docs.count docs.deleted store.size pri.store.size
yellow open   .kibana rUm9n9wMRQCCrRDEhqneBg   1   1          1            0      3.1kb          3.1kb

创建索引

1
PUT /test_index?pretty

删除索引

1
DELETE /test_index?pretty

document的CRUD操作

新增document 建立索引
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
PUT /index_name/type_name/id
{
    json数据
}

// 返回值
{
  "_index": "index_name",
  "_type": "type_name",
  "_id": "1",
  "_version": 1,
  "result": "created",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "created": true
}

es会自动建立index和type，不需要提前创建，而且es默认会对document每个field都建立倒排索引，让其可以被搜索

检索/查询文档
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
GET index_name/type_name/id

// 返回值
{
  "_index": "index_name",
  "_type": "type_name",
  "_id": "id",
  "_version": 1,
  "found": true,
  "_source": {
    "name": "gaolujie yagao",
    "desc": "gaoxiao meibai",
    "price": 30,
    "producer": "gaolujie producer",
    "tags": [
      "meibai",
      "fangzhu"
    ]
  }
}
更新document
全量替换
1
2
3
4
5
6
PUT /index_name/type_name/id
{
    json数据
}

// 不做更新的filed也需要传过去

上面这个操作是全量替换,其实是es先把旧的数据标记为deleted,不做物理删除,然后再创建一个新的document出来,id也和原来的一样,当es数据量增大时,es才会去删除被标记为deleted的数据,来释放空间

那么如何强制创建呢,就是上面这个操作不想去更新,就是想去再创建一个新的document,那么这时候可以在请求后面加一个参数 ?_create,但是执行时候发现这样会报错,因为这个id已经存在了引起冲突,所以会报错

partial update
1
2
3
4
5
6
7
8
POST /index_name/type_name/id/_update
{
    "doc":{
        "需要更新的列":"值"
    }
}

//

上面这个更新看起来就比较方便了,每次只需要传递少数的发生修改的filed过去即可,不需要将全量的document数据发送过去.

两者对比

我们使用全量替换的时候,当我们只需要修改document中其中某一个字段的时候必须知道其他字段的值,这时候我们需要进行一次查询,然后将不需要修改的字段原封不动的写入到语句中去,可以很容易的看出进行一次数据修改,需要用于先去查询,然后更新再写回到es中去,耗费的时间相对较长,而且在写入数据的时候,可能别人已经对数据进行修改了,容易产生并发冲突

然后我们来看一下partial update,其实partial update的执行和全量替换是一样的,也是先获取document,然后将传过来的filed更新到document中,将老的document标记为deleted,用新的数据创建新的document, 但是相较于全量替换,partial update的所有查询修改都是发生在es内部的,操作基本都是毫秒级别的,耗费的时间相对较小,并发冲突的可能性也就相对较小.

总结

partial update与全量替换的执行步骤其实是一致的,但是partial update所有的查询和修改操作都是在es内部的shard中进行的,避免了网络数据传输的开销,提升 了性能. 第二减少了查询和修改中的时间间隔,有效减少了并发冲突.

删除document
1
DELETE /index_name/type_name/id

这里的删除也是做的逻辑删除,es把要删除的document标记为deleted状态,也是在存储空间不够的时候es才会去做物理删除来释放空间