Elasticsearch系列简单入门实战

42次阅读

共计 6179 个字符,预计需要花费 16 分钟才能阅读完成。

概要

本篇主要介绍一下 Elasticsearch Document 的数据格式,在 Java 应用程序、关系型数据库建模的对比,介绍在 Kibana 平台编写 Restful API 完成基本的集群状态查询,Document 最基本 CRUD 操作示例以及 bulk 批处理示例。

Document 数据格式

Java 应用系统的数据模型都是面向对象的,有些对象比较复杂,传统的业务系统,数据需要落地到关系型数据库,在数据库领域模型设计时,会把复杂的 POJO 对象设计成一对一或一对多的关系,进行扁平化处理,查询的时候,需要多表查询并还原回 POJO 对象的格式。
Elasticsearch 是文档数据库,Document 存储的数据结构,可以和 POJO 保持一致,并且使用 JSON 格式,这样查询数据时比较方便。

Document 文档数据示例:

{
  "fullname" : "Three Zhang",
  "text" : "hello elasticsearch",
  "org": {
      "name": "development",
      "desc": "all member are lovely"
  }
}

Restful API 让请求更容易

前面文章有提及 Elasticsearch 与 Kibana 搭配使用,Kibana 界面的 Dev Tools 菜单,可以发送 Elasticsearch 的 Restful 请求。后续的 Restful API 请求,如无例外,均是在 Kibana 平台上执行的。

我们先拿几个查询集群信息的请求来试试

  1. 检查集群的健康状况

GET /_cat/health?v

epoch      timestamp cluster        status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1573626290 14:24:50  hy-application yellow          1         1     1  1    0    0       1             0                  -                 50.3%

从上面能看出 node、shard 的数量等,还有一个是集群的状态,上面显示的是 yellow,为什么是 yellow?
集群的状态有 green、yellow、red 三种,定义如下:

  • green:每个索引的 primary shard 和 replica shard 都是 active 状态的
  • yellow:每个索引的 primary shard 都是 active 状态的,但是部分 replica shard 不是 active 状态,处于不可用的状态
  • red:不是所有索引的 primary shard 都是 active 状态的,部分索引有数据丢失了

我们的示例只启动了一个 elasticsearch 实例,只有一个 node,由于索引默认会使用 5 个 primary shard 和 5 个 replica shard,并且同一个 node 下面的 primary shard 和 replica shard 不能分配在一台机器上(容错机制),所有只有 1 个 primary shard 被分配和启动了,replica shard 没有第二台 node 去启动,因而是 yellow 状态。如果想变成 green 判断,另外启一台 node 即可。

  1. 查看集群中有哪些索引

GET /_cat/indices?v

health status index                  uuid                   pri rep docs.count docs.deleted store.size pri.store.size
yellow open   location               48G_CgE7TiWomlYsyQW1NQ   5   1          3            0       11kb           11kb
yellow open   company_mem            s9DKUeyWTdCj2J8BaFYXRQ   5   1          3            0       15kb           15kb
yellow open   %{[appname]}           ysT9_OibR5eSRu19olrq_w   5   1         32            0    386.5kb        386.5kb
yellow  open   .kibana                4yS67TTOQGOD7l-uMtICOg   1   0          2            0       12kb           12kb
yellow open   tvs                    EM-SvQdfSaGAXUADmDFHVg   5   1          8            0     16.3kb         16.3kb
yellow open   company_org            wIOqfx5hScavO13vvyucMg   5   1          3            0     14.6kb         14.6kb
yellow open   blog                   n5xmcGSbSamYphzI_LVSYQ   5   1          1            0      4.9kb          4.9kb
yellow open   website                5zZZB3cbRkywC-iTLCYUNg   5   1         12            0     18.2kb         18.2kb
yellow open   files                  _6E1d7BLQmy9-7gJptVp7A   5   1          2            0      7.3kb          7.3kb
yellow open   files-lock             XD7LFToWSKe_6f1EvLNoFw   5   1          1            0        8kb            8kb
yellow open   music                  i1RxpIdjRneNA7NfLjB32g   5   1          3            0     15.1kb         15.1kb
yellow open   book_shop              1CrHN1WmSnuvzkfbVCuOZQ   5   1          4            0     18.1kb         18.1kb
yellow open   avs                    BCS2qgfFT_GqO33gajcg_Q   5   1          0            0      1.2kb          1.2kb
  1. 查看 node 信息

GET /_cat/nodes?v

响应:

ip             heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
192.168.17.137           38          68   0    0.08    0.03     0.05 mdi       *      node-1

我们可以看到 node 的名称。

  1. 创建索引命令

创建名称为 ”location” 的索引

PUT /location?pretty

响应:

{
  "acknowledged": true,
  "shards_acknowledged": true
}

查看索引,能看到刚刚创建的索引 location

health status index                  uuid                   pri rep docs.count docs.deleted store.size pri.store.size
yellow open   location               48G_CgE7TiWomlYsyQW1NQ   5   1          3            0       11kb           11kb
yellow open   .kibana                4yS67TTOQGOD7l-uMtICOg   1   0          2            0       12kb           12kb
  1. 删除索引命令

删除名称为 ”location” 的索引

DELETE /location?pretty

再查看索引,刚刚创建的索引 location 已经删除掉了

health status index                  uuid                   pri rep docs.count docs.deleted store.size pri.store.size
yellow open   .kibana                4yS67TTOQGOD7l-uMtICOg   1   0          2            0       12kb           12kb

是不是很简单,交互界面挺友好吧?

入门 CRUD 操作

介绍 document 最基本的 CRUD 操作,以儿童英文歌曲为背景

  1. 新增歌曲

我们设计的儿歌结构包含四个字段:歌名 name,歌词 content,语言种类 language,歌曲时间长 length,单位是秒,放在 JSON 字符串里。
PUT 语法:
<REST Verb> /<Index>/<Type>/<ID>
REST Verbs 可以是 PUT、POST、DELETE,后斜杠后的内容分别是索引名、类型名、ID。

请求如下:

PUT /music/children/1
{
    "name": "gymbo",
    "content": "I hava a friend who loves smile, gymbo is his name",
    "language": "english",
    "length": "75"
}

响应内容包含索引名、类型名、ID 值,version 版本号(乐观锁控制),结果类型 (created/updated/deleted 三种),shard 信息等,如果新增时该索引不存在,会自动创建索引,索引名即请求时指定的那个,document 里面的 field 类型,就根据 elasticsearch 定义的自动映射类型,并且每个 field 都会建立倒排索引,让其可以被搜索到。

total 和 successful 为什么数据不相等?
新增 document 时,会往 primary shard 和 replica shard 分别写入 document,但由于只有一个 node,replica 未启动,所以总共写入 2 次,primary shard 成功,数量是 1。failed 只记录 primary shard 写入失败的情况。

响应如下:

{
  "_index": "music",
  "_type": "children",
  "_id": "1",
  "_version": 1,
  "result": "created",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "_seq_no": 0,
  "_primary_term": 1
}
  1. 修改歌曲

修改 document 有两种方式,一种是增量修改,只修改指定的 field,另一种是全量替换文档,原有的信息全部被替换掉

  • 增量修改 length 的值,注意是 POST 请求,并且尾部有_update,doc 是固定写法,请求如下:
POST /music/children/1/_update
{
  "doc": {"length": "76"}
}

响应:

{
  "_index": "music",
  "_type": "children",
  "_id": "1",
  "_version": 2,
  "result": "updated",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "_seq_no": 1,
  "_primary_term": 1
}
  • 全量替换文档,请求如下:
PUT /music/children/1
{
    "name": "gymbo",
    "content": "I hava a friend who loves smile, gymbo is his name",
    "language": "english",
    "length": "77"
}

响应:

{
  "_index": "music",
  "_type": "children",
  "_id": "1",
  "_version": 3,
  "result": "updated",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "_seq_no": 2,
  "_primary_term": 1
}

细心的童鞋可以,全量替换文档的语法和创建索引是一样的,对!就是同一个语法,是创建还是更新取决于上面的 ID 存不存在,不存在做创建,存在做更新,更新成功 version+1,但这种全量替换有个不好的地方,必须带上完整的属性,否则未声明属性就没有了。

想想要使用这个语法的场景:先 GET 所有的属性,然后把要更新的属性更新上,再调用全量替换的更新语法。实际上这种做法不多,原因不外乎两个:操作复杂,要先查询后更新;报文过大(相对于增量更新)。所以企业研发一般使用增量方式做 document 更新。

  1. 查询歌曲

查询语句:GET /music/children/1

_source 即为 JSON 的内容,查询结果:

{
  "_index": "music",
  "_type": "children",
  "_id": "1",
  "_version": 1,
  "found": true,
  "_source": {
    "name": "gymbo",
    "content": "I hava a friend who loves smile, gymbo is his name",
    "language": "english",
    "length": "75"
  }
}
  1. 删除歌曲

删除语句:DELETE /music/children/1

响应结果:

{
  "_index": "music",
  "_type": "children",
  "_id": "1",
  "_version": 4,
  "result": "deleted",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "_seq_no": 3,
  "_primary_term": 1
}

bulk 批处理

上一节提及的增删改操作,是针对单个 document 的,Elasticsearch 还有一个批处理命令,可以批量执行这些操作。

  1. bulk 的基本语法示例

还是以上面的儿歌为案例背景

POST /music/children/_bulk
{"index":{"_id":"1"}}
{"name": "gymbo", "content": "I hava a friend who loves smile, gymbo is his name", "language": "english", "length": "75"}
{"create":{"_id":"2"}}
{"name": "wake me, shark me", "content": "don't let me sleep too late","language":"english","length":"55"}
{"update": {"_id": "2", "retry_on_conflict" : 3} }
{"doc" : {"content" : "don't let me sleep too late, gonna get up brightly early in the morning"} }
{"delete": {"_id": "3"}}

可以把多条命令放在一起执行,如果一个 bulk 请求内有不同的 index 和 type,可以把 index 和 type 也可以写在 body json 里,每一个操作要两个 json 串:

{"action": {"metadata"}}
{"data"}

delete 例外,它只需要 1 个 json 串就可以了

action 的类型有以下几种:

  • index:普通的 PUT 操作,ID 不存在时创建 document,ID 存在时做全量替换
  • create:强制创建,等同于 PUT /index/type/id/_create 命令
  • update:执行的增量修改操作
  • delete:删除 document 操作
  1. bulk 注意事项

bulk api 有严格的语法要求,每个 json 串内不能换行,同时每个 json 串之间必须要有一个换行,否则会报语法错误。
bulk 既然是多条命令批量执行,遇到错误怎么办?会中断吗?
如果 bulk 请求内有命令执行错误,会直接跳过,继续执行下一条,同时在响应报文里会对每条命令的结果分别展示,正确的就展示正确的结果,错误的会相应提示错误日志。

  1. bulk 的性能问题

bulk 既然是批处理,那 bulk size 与最佳性能肯定存在一定的联系,bulk 请求的内存会先加载到内存里,bulk 的请求取决于命令的条数和每个命令内容的多少,与性能的关系示例图(表达概念,数据不具备参考性)如下:

bulk 性能优化的目标就是找到这个拐点,需要反复尝试一个最佳的 size,跟具体的业务数据特性,并发量有关,常见的设置范围一般是 1000-5000 之间,bulk 请求的大小控制在 5 -15MB 之间(仅供参考)。

小结

本篇简单介绍了一下 document 的数据格式,并顺带讲解了一下 Elasticsearch 集群红黄绿三种状态的判定标准,重点是在 kibana 平台演示的 CRUD 小案例和 bulk 批处理示例,最为基础,可以多花一些时间熟悉熟悉。

专注 Java 高并发、分布式架构,更多技术干货分享与心得,请关注公众号:Java 架构社区

正文完
 0