在 Elasticsearch 中文档是 不可改变 的，不能修改它们。在我们对文档进行更新操作的时候，都会将旧文档删除，在原来的位置创建新的文档.
更新整个文档
UT /website/blog/123
{
"title": "My first blog entry",
"text": "I am starting to get the hang of this...",
"date": "2014/01/02"
}
{
"_index" : "website",
"_type" : "blog",
"_id" : "123",
"_version" : 2,
"created": false
}
我们会发现"_version"字段变成了2,这是因为这个字段标志着版本号，表示这是在这个index，这个type，这个id下，第二次存储的数据.
创建新文档
因为index, type,id会唯一标识的一个文档，当我们给出了相同的index,type,id时，这不会创建新的文档，而是删除存在的文档，将新的JSON文档存储在这个命名空间里.
- 使用POST /index/type/,elasticsearch会自动为我们创建一个唯一的id
POST /website/blog/
{ ... }
在指定的index,type,id创建文档，如果指定的命名空间里没有文档则创建，有则报错。
- 使用op_type参数(optype=create)
PUT /website/blog/123?op_type=create
{ ... }
- 第二种方法是在 URL 末端使用 /_create.
PUT /website/blog/123/_create
{ ... }
删除文档
- 删除指定的文档
DELETE /website/blog/123
{
"found" : true,
"_index" : "website",
"_type" : "blog",
"_id" : "123",
"_version" : 3
}
需要注意的是: _version字段的值加了1,表示这个index,type,id表示的命名空间执行了3次操作,即使文档不存在， _version 值仍然会增加。这是 Elasticsearch 内部记录本的一部分，用来确保这些改变在跨多节点时以正确的顺序执行
处理冲突
有时候，在进行并行处理的时候可能会出现冲突，如下所示:
QQ截图20181022013334.jpg
解决方法:
- 悲观并发控制
这种方法被关系型数据库广泛使用，它假定有变更冲突可能发生，因此阻塞访问资源以防止冲突。 一个典型的例子是读取一行数据之前先将其锁住，确保只有放置锁的线程能够对这行数据进行修改。
- 乐观并发控制
Elasticsearch 中使用的这种方法假定冲突是不可能发生的，并且不会阻塞正在尝试的操作。 然而，如果源数据在读写当中被修改，更新将会失败。应用程序接下来将决定该如何解决冲突。 例如，可以重试更新、使用新的数据、或者将相关情况报告给用户。
