t;: "123", "_retry_on_conflict" : 3} } { "doc" : {"title" : "My updated blog post"} }
delete是没有请求体的，而create,update 请求体是必须的 如上所示。如果其中哪个操作失败了，则会在响应中的一个对应的item中给出相应的error. 而成功的则给出200.比如
{ "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 }} ] }
bulk 不是原子性的，不能用它来实现事务控制。每个请求是单独处理的，因此一个请求的成功或失败不会影响其他的请求。为什么是下面这种格式的写法，为什么是每个请求单独处理，这是因为不同的文档数据，他们主分片可能不同，每个文档可能被分配给不同节点，所以ES这种设计的方式是最明智的。如果使用json数组，看起来简便了，实则导致需要ES解析大量数据，占用更多内存，让JVM来花大量时间进行回收。相反ES现有的方式，则可以直接将原始请求转发到正确的分片上，用最小的内存处理。
也许你正在批量索引日志数据到相同的 index 和 type 中。 但为每一个文档指定相同的元数据是一种浪费。相反，可以像 mget API 一样，在 bulk 请求的 URL 中接收默认的 /_index 或者 /_index/_type ，比如：
POST /website/_bulk { "index": { "_type": "log" }} { "event": "User logged in" }
POST /website/log/_bulk { "index": {}} { "event": "User logged in" } { "index": { "_type": "blog" }} { "title": "Overriding the default type" }
五.分布式文档存储
当索引一个文档的时候，文档将被存储到ES的一个主分片当中。ES索引文档到分片遵从公式：shard = hash(routing) % number_of_primary_shards 。
routing是一个可变值，默认你为文档_id。 如上公式hash出的结果是 0 到 number_of_primary_shards-1 之间的余数，将来我们寻找数据所在分片，就是这样找到的。所以在创建索引的时候就要确定好主分片数量，并且永远不改变primary_shards ，因为一旦改变了，之前hash路由的值将全部无效，文档也就不能被正确找到。当然如果你想扩容，可以有其他的奇技淫巧，后面将会提到。
比如我们有三个节点，两个主分片，每个主分片有两个副本。我们依然可以将请求指向任意节点，每个节点都知道任一文档的位置，并转发请求到目标节点。为了扩展负载，更好的做法是轮询所有节点，以单节点免压力过大。我想，ES知道任一文档的位置，通过上一段给出的公式即可。
向node1发送存储数据请求，路由到node3主分片上，复制给node1和node2,最后返回结果给node1
向node1 发送更新数据请求，路由到node3主分片，更改_source，重新索引数据，成功后复制到node1和node2。如果是部分更新的时候，通知副本节点更新的时候，不是转发部分更新的内容，而是转发完整文档的新版本。
六.搜索
上面，我们可以简单的把ES当作NOSQL风格的分布式文档存储系统。我们可以将文档扔到ES里，然后根据ID检索。但其真正的强大之处并不在于此，而是从无规律的数据找出有意义的信息，从大数据到大信息。
搜索（search） 可以做到：
1.在类似于 gender 或者 age 这样的字段 上使用结构化查询，join_date 这样的字段上使用排序，就像SQL的结构化查询一样。
2.全文检索，找出所有匹配关键字的文档并按照相关性（relevance） 排序后返回结果。
3.以上二者兼而有之。
下面分析一则查询：
GET /_search （curl -XGET 'localhost:9200/_search?pretty'）
{ "hits" : { "total" : 14, "hits" :
[ { "_index": "us", "_type": "tweet", "_id": "7", "_score": 1,
"_source": { "date": "2014-09-17", "name": "John Smith", "tweet": "The Query DSL is really powerful and flexible", "user_id": 2 } },
... 9 RESULTS REMOVED ... ], "max_score" : 1 },
"took" : 4,
"_shards" : { "failed" : 0, "successful" : 10, "total" : 10 }, "time