{
"_index": "test_index",
"_type": "test_type",
"_id": "1",
"_version": 3,
"found": true,
"_source": {
"test_field1": "test field1",
"test_field2": "test field2"
}
}
（1）_id元数据
代表document的唯一标识，与index和type一起，可以唯一标识和定位一个document
我们可以手动指定document的id（put /index/type/id），也可以不指定，由es自动为我们创建一个id。
自动生成的id，长度为20个字符，URL安全，base64编码，GUID，分布式系统并行生成时不可能会发生冲突
（2）_source元数据
是document的完整文本，返回字段可定制
PUT /test_index/test_type/1
{
"test_field1": "test field1",
"test_field2": "test field2"
}
GET /test_index/test_type/1?_source=test_field1
（3）lazy delete
document的全量替换
语法与创建文档是一样的，es会将老的document标记为deleted，然后新增我们给定的一个document
document的强制创建
PUT /index/type/id?op_type=create，PUT /index/type/id/_create
document的删除
DELETE /index/type/id
不会理解物理删除，只会将其标记为deleted，当数据越来越多的时候，在后台自动删除
（4）_version
基于_version进行乐观锁并发控制，第一次创建一个document的时候，它的_version内部版本号就是1；以后每次对这个document执行修改或者删除操作，都会对这个_version版本号自动加1；哪怕是删除，也会对这条数据的版本号加1。删除一条document，再重新创建这条document，其实会在delete version基础之上，再把version号加1 。侧面印证了lazy delete，而不是物理删除
## 新增一个文档
PUT /test_index/test_type/7
{
"test_field7": "test field7"
}
GET /test_index/test_type/7
{
"_index": "test_index",
"_type": "test_type",
"_id": "7",
"_version": 1,
"found": true,
"_source": {
"test_field7": "test field7"
}
}
## 客户端A修改文档成功
PUT /test_index/test_type/7?version=1
{
"test_field7": "test client A"
}
## 客户端B修改文档失败
PUT /test_index/test_type/7?version=1
{
"test_field7": "test client B"
}
## 在乐观锁成功阻止并发问题之后，尝试正确的完成更新。基于最新的数据和版本号，去进行修改。可能这个步骤会需要反复执行好几次，才能成功，特别是在多线程并发更新同一条数据很频繁的情况下
GET /test_index/test_type/7
PUT /test_index/test_type/7?version=2
{
"test_field7": "test client B"
}
external version
使用乐观锁并发控制的时候，若不想要用es内部的_version来进行控制，也可以自己维护的版本号来进行控制
?version=1
?version=1&version_type=external
唯一的区别在于：version只有当你提供的version与es中的version一模一样的时候，才可以进行修改，只要不一样，就报错；当version_type=external的时候，只有当你提供的version比es中的_version大的时候，才能完成修改
GET /test_index/test_type/7 获取到版本version是4
PUT /test_index/test_type/7?version=4&version_type=external
{
"test_field7": "test client C"
}
-- 失败
PUT /test_index/test_type/7?version=5&version_type=external
{
"test_field7": "test client C"
}
-- 成功
（5）partial update
PUT是document的全量替换，会先lazy delete，然后创建新文档。
POST则是document的部分更新，只要传入部分要修改的字段，网络开销更少、保证在同一个shard上。
并且：
（1）partial update 内置乐观锁并发控制，不用我们自己写version判断
（2）retry_on_conflict 会自动获取最新的版本号比对再更新，并发情况下失败了会重试。可设置重试次数
POST /index/type/id/_update?retry_on_conflict=5
(3) 当然partial update 也可以我们自己强制指定版本号修改
POST /index/type/id/_update?retry_on_conflict=5&version=6
