注：此文档仅适用于 Elasticsearch > 5.0 版本
Index API
index api 用于在指定的索引和类型下添加或修改文档。例如：
PUT twitter/tweet/1
{
"user" : "kimchy",
"post_date" : "2009-11-15T14:12:12",
"message" : "trying out Elasticsearch"
}
路径 twitter/tweet/1 中包含了三部分信息，其中，twitter 表示索引名称，tweet 表示类型名称，1表示文档的 id ，文档的 id 是可选的。
如果 id 不存在，表示新增一个文档，并为这个文档分配一个 id 。
如果 id 存在，并且这个 id 对应的文档在 Elasticsearch 中存在，则表示更新文档，这时的更新表示全量更新，直接替换。如果 id 对应的文档在 Elasticsearch 中不存在，则会在 Elasticsearch 中创建新的文档，文档的 id 为 path 上的 id。
在 Elasticsearch 中，索引、类型、ID 组合定位一个文档。也就是说，不同类型下，ID 是可以重复的。
Create API
Create API 也用于创建文档，与 index API 不同，Create API只用于创建文档，没有更新文档的功能。并且，Create API 必须提供 id ，当相同id的文档已经存在时，Elasticsearch 会返回 409 Conflicat 响应码。
PUT twitter/tweet/1/_create
{
"user" : "kimchy",
"post_date" : "2009-11-15T14:12:12",
"message" : "trying out Elasticsearch"
}
Get API
GET API 非常简单，它通过索引名称、类型名称、ID这三个信息获取制定文档：
GET twitter/tweet/1
返回的信息中包含了文档的一些元数据，以及 _source 属性。
{
"_index" : "twitter",
"_type" : "tweet",
"_id" : "1",
"_version" : 1,
"found": true,
"_source" : {
"user" : "kimchy",
"date" : "2009-11-15T14:12:12",
"likes": 0,
"message" : "trying out Elasticsearch"
}
}
如果将 GET 请求变成 DELETE 请求，则表示删除文档。
DELETE twitter/tweet/1
Update API
在 index API 中，我们已经可以进行更新文档操作了。但是使用 index API 时，更新操作是全量更新的，如果我只想更新文档的一个字段，那么就需要使用 Update API 来进行增量更新。
POST /website/blog/1/_update
{
"views": 1
}
乐观并发控制
在数据库中，我们一般使用事务来处理冲突的情况。在 Elasticsearch 中，我们一般使用乐观锁的方式来避免冲突。
在前面的例子中，我们可能注意到文档都有一个 _version 的元信息，这个信息表示文档的版本号，当文档被修改时，版本号递增。Elasticsearch 就是利用 _version 做的乐观锁。
在更新文档时，我们可以指定 _version 版本，
PUT twitter/tweet/1?version=2
{
"message" : "elasticsearch now has versioning support, double cool!"
}
上面的例子表示文档只有版本号为 2 时，更新才能成功。如果更新失败，Elasticsearch 会返回 409 Conflict HTTP 响应码，以及一个错误提示的相应体。当冲突发生时，可以使用新的数据重新更新，或者将相关情况告诉用户。
Bulk API
bulk API 允许在单个步骤中进行多次 create 、 index 、 update 或 delete 请求。 如果你需要索引一个数据流比如日志事件，它可以排队和索引数百或数千批次。
bulk 与其他请求的请求体格式不同，如下所示：
POST /_bulk
{ "delete": { "_index": "website", "_type": "blog", "_id": "123" }}
{ "create": { "_index": "website", "_type": "blog", "_id": "123" }}
{ "title": "My first blog post" }
{ "index": { "_index": "website", "_type": "blog" }}
{ "title": "My second blog post" }
{ "update": { "_index": "website", "_type": "blog", "_id": "123", "_retry_on_conflict" : 3} }
{ "doc" : {"title" : "My updated blog post"} }
这种格式类似一个有效的单行 JSON 文档 流 ，它通过换行符(\n)连接到一起。注意两个要点：
- 每行一定要以换行符(
\n)结尾， 包括最后一行 。这些换行符被用作一个标记，可以有效分隔行。 - 这些行不能包含未转义的换行符，因为他们将会对解析造成干扰。这意味着这个 JSON 不 能使用 pretty 参数打印。
delete动作不能有请求体，它后面跟着的是另外一个操作。
bulk 请求的每个子请求都是独立执行，因此某个子请求的失败不会对其他子请求的成功与否造成影响。 如果其中任何子请求失败，则返回值的最顶层的 error 标志被设置为 true ，并且在相应的请求报告出错误明细：
{
"took": 3,
"errors": true,
"items": [
{ "create": {
"_index": "website",
"_type": "blog",
"_id": "123",
"status": 409,
"error": "DocumentAlreadyExistsException
[[website][4] [blog][123]:
document already exists]"
}},
{ "index": {
"_index": "website",
"_type": "blog",
"_id": "123",
"_version": 5,
"status": 200
}}
]
}
整个批量请求都需要由接收到请求的节点加载到内存中，因此该请求越大，其他请求所能获得的内存就越少。 批量请求的大小有一个最佳值，大于这个值，性能将不再提升，甚至会下降。 但是最佳值不是一个固定的值。它完全取决于硬件、文档的大小和复杂度、索引和搜索的负载的整体情况。一个好的批量大小在开始处理后所占用的物理大小约为 5-15 MB。
Scroll
scroll 查询 可以用来对 Elasticsearch 有效地执行大批量的文档查询，而又不用付出深度分页那种代价。
启用游标查询可以通过在查询的时候设置参数 scroll 的值为我们期望的游标查询的过期时间。 游标查询的过期时间会在每次做查询的时候刷新，所以这个时间只需要足够处理当前批的结果就可以了，而不是处理查询结果的所有文档的所需时间。 这个过期时间的参数很重要，因为保持这个游标查询窗口需要消耗资源，所以我们期望如果不再需要维护这种资源就该早点儿释放掉。 设置这个超时能够让 Elasticsearch 在稍后空闲的时候自动释放这部分资源。
GET /old_index/_search?scroll=1m
{
"query": { "match_all": {}},
"sort" : ["_doc"],
"size": 1000
}
size 指的是每次返回的文档个数，这个字段作用于每个分片，实际上每次返回的文档个数最大为 size * number_of_primary_shards。
这个查询的返回结果包括一个字段 _scroll_id， 它是一个base64编码的长字符串。 现在我们能传递字段 _scroll_id 到 _search/scroll 查询接口获取下一批结果：
GET /_search/scroll
{
"scroll": "1m",
"scroll_id" : "cXVlcnlUaGVuRmV0Y2g7NTsxMDk5NDpkUmpiR2FjOFNhNnlCM1ZDMWpWYnRROzEwOTk1OmRSamJHYWM4U2E2eUIzVkMxalZidFE7MTA5OTM6ZFJqYkdhYzhTYTZ5QjNWQzFqVmJ0UTsxMTE5MDpBVUtwN2lxc1FLZV8yRGVjWlI2QUVBOzEwOTk2OmRSamJHYWM4U2E2eUIzVkMxalZidFE7MDs="
}
参考资料：
