概要
本篇主要介绍一下 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 平台上执行的。
我们先拿几个查询集群信息的请求来试试
- 检查集群的健康状况
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 即可。
- 查看集群中有哪些索引
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- 查看 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 的名称。
- 创建索引命令
创建名称为 ”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- 删除索引命令
删除名称为 ”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 操作，以儿童英文歌曲为背景
- 新增歌曲
我们设计的儿歌结构包含四个字段：歌名 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
}- 修改歌曲
修改 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 更新。
- 查询歌曲
查询语句：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"
}
}- 删除歌曲
删除语句：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 还有一个批处理命令，可以批量执行这些操作。
- 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 操作
- bulk 注意事项
bulk api 有严格的语法要求，每个 json 串内不能换行，同时每个 json 串之间必须要有一个换行，否则会报语法错误。
bulk 既然是多条命令批量执行，遇到错误怎么办？会中断吗？
如果 bulk 请求内有命令执行错误，会直接跳过，继续执行下一条，同时在响应报文里会对每条命令的结果分别展示，正确的就展示正确的结果，错误的会相应提示错误日志。
- bulk 的性能问题
bulk 既然是批处理，那 bulk size 与最佳性能肯定存在一定的联系，bulk 请求的内存会先加载到内存里，bulk 的请求取决于命令的条数和每个命令内容的多少，与性能的关系示例图（表达概念，数据不具备参考性）如下：
bulk 性能优化的目标就是找到这个拐点，需要反复尝试一个最佳的 size，跟具体的业务数据特性，并发量有关，常见的设置范围一般是 1000-5000 之间，bulk 请求的大小控制在 5 -15MB 之间（仅供参考）。
小结
本篇简单介绍了一下 document 的数据格式，并顺带讲解了一下 Elasticsearch 集群红黄绿三种状态的判定标准，重点是在 kibana 平台演示的 CRUD 小案例和 bulk 批处理示例，最为基础，可以多花一些时间熟悉熟悉。
专注 Java 高并发、分布式架构，更多技术干货分享与心得，请关注公众号：Java 架构社区