POST/_bulk{"create":{"_index":"shop2","_id":"2005"}}{"id":"2005","nickname":"name-2005"}{"create":{"_index":"shop2","_id":"2006"}}{"id":"2006","nickname":"name-2006"}{"create":{"_index":"shop2","_id":"2007"}}{"i
这句话的大概意思是,bulk的index操作性能是高于单文档的index操作的。至于bulk每个批次多少个文档是最优的,需要根据自己的实际环境进行压力测试,以实际的结果为准。 bulk性能高是自然的,因为它大大降低了业务和ES集群之间的IO。 bulk批量更新重复id的性能问题 之前在ES中文社区看到过一篇关于bulk更新重复id的文档情况...
2、创建 create 文档不存在时创建 vim customer_create.json {"create": {"_index":"customer","_id":"3"} } {"name":"Alice"} {"create": {"_index":"customer","_id":"4"} } {"name":"Smith"} curl-H"Content-Type: application/json"-XPOST"localhost:9200/customer/_bulk?pretty&refresh"...
bulk 请求不是原子操作,它们不能实现事务。每个请求操作时分开的,所以每个请求的成功与否不干扰其它操作。 返回: # bulk批量的混合操作,一般不推荐这种使用,项目中也用的极少。 PUT /_bulk { "create" : { "_index" : "ad", "_id" : "6" }} { "doc" : {"name" : "bulk"}} { "index" : {...
{ "create" : { "_index" : "test", "_type" : "type1", "_id" : "3" } } { "field1" : "value3" } 问题出现的原因是他们在 bulk 测试的时候遇到了写性能的问题,而正巧社区里面前几天有这么一个类似的帖子,说的是 es 5.x 版本里面做 update 操作的性能问题。虽然和这个问题不完全一致,...
{"doc":{"test_field":"bulk test"}}\n{"delete":{"_index":"test_index","_id":5}} bulk的操作类型 create 如果文档不存在就创建,但如果文档存在就返回错误 update 更新一个文档,如果文档不存在就返回错误 delete 删除一个文档,如果要删除的文档id不存在,就返回错误 ...
metadata中需要指定要操作的文档的_index、_type和_id,_index、_type也可以在url中指定。 样例 批量新增记录 POST /_bulk { "create":{ "_index":"shop2", "_id":"2005" } } { "id":"2005", "nickname":"name-2005" } { "create":{ "_index":"shop2","_id":"2006" } } ...
create:PUT /index/type/id/_create,强制创建 index:普通的put操作,可以是创建文档,也可以是全量替换文档 update:执行的partial update操作 注意点 1.bulk api对json的语法有严格的要求,除了delete外,每一个操作都要两个json串,且每个json串内不能换行,非同一个json串必须换行,否则会报错; ...
语法POST /_aliases基本用法##插入数据的一种写法POST/_bulk{"index":{"_index":"test_idx_delay",...
请注意,这个操作都由两行组成:第一行包含操作类型(在这个示例中为 "create")和元数据;第二行包含要创建或索引的实际文档数据。 删除 删除文档,ES 对文档的删除是懒删除机制,即标记删除(lazy delete 原理)。 POST /_bulk{ "delete" : { "_index" : "test-index", "_id" : "1" } }{ "delete" :...