INDEX API 示例:1 2 3 4 5 PUT /test /user/1 { "name" : "silence" , "age" : 27 }
说明:1 2 action.auto_create_index: false #禁用自动创建index index .mapper.dynamic: false #禁用自动生成type
在某些时候允许某类型或者禁用某类型的index自动创建，则可以使用匹配模式和黑白名单形式进行配置
1 action.auto_create_index: +test *,+temp*,+tmp* #只允许自动创建以test ,temp,tmp开头的index
说明: 若action.auto_create_index设置为true或允许某些index执行, index.mapper.dynamic设置为false, 则可第一次时index自动创建一个type，后续不能再单独创建新的type
3.文档中的version属性1 2 3 4 5 6 7 8 9 10 11 { "_index" : "test" , "_type" : "user" , "_id" : "1" , "_version" : 7 , "found" : true , "_source" : { "name" : "silence" , "age" : 27 } }
当我们使用如下请求执行更新动作可看到执行成功，并且version自增1, 返回结果中为8:1 2 3 4 5 PUT /test /user/1?version =7 { "name" : "silence" , "age" : 28 }
输出:1 2 3 4 5 6 7 { "_index" : "test" , "_type" : "user" , "_id" : "1" , "_version" : 8 , "created" : false }
当我们再次发出version=7的请求得到的响应为:1 2 3 4 { "error": "VersionConflictEngineException[[test ][2 ] [user ][1 ]: version conflict, current [8], provided [7]]", "status": 409 }
可自己测试version>8的请求依然失败, 此时你可能会想到在高并发情况下此种效率是否会低效, 可能你会在内存中放置一个version+1的副本, 通过内存中对副本进行自增, 然后异步方式提高并发, 此时执行成功率会下降并且导致数据丢失, 在此种情况下只要满足你指定的version大于存储中的版本号即可, 为解决此种问题es提供version_type可以指定使用的比较策略：
version_type值
说明
internal
默认值, 表示指定version必须与存储中的version一致, 若成功则存储version自增1
external/external_gt
指定值必须大于存储中的version, 若成功存储version设置为提交的version
external_gte
指定值必须大于等于存储中的version, 若成功存储version设置为提交的version
force
强制更新，并将存储version设置为提交的version
4.op_type: 在提交请求时指定op_type=create, 表示若id不存在时创建, 否则失败1 2 3 4 5 PUT /test /user/1?op_type =create { "name" : "silence" , "age" : 28 }
输出:1 2 3 4 { "error": "DocumentAlreadyExistsException[[test ][2 ] [user ][1 ]: document already exists]", "status": 409 }
op_type=create的另一种表示方法为:1 2 3 4 5 PUT /test/ user/1 /_create "name" : "silence" , "age" : 28 }
5.ID生成器: 在大多数情况下我们不需要维护也不关心文档的id是什么, 在es中可以为文档自动生成id，方式为使用post方式提交参数, 并在请求中不指定id值(若指定则使用指定的id值)1 2 3 4 5 POST /test/ user/?routing=name "name" : "silence" , "age" : 28 }
若在索引文档时显示指定routing，则在提交文档中必须存在指定routing对应的值，否则执行失败
7.分布式执行
8.一致性
9.刷新shard
再次分享自己趟过的一个坑:1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 def get_all_store_hosts () '' ' 返回es中存储中所有ip 在索引doc时未设置refresh ' '' return _all_ def get_distinct_hosts_from_logs (day) '' ' 从日志中查询所有的ip并去重 ' '' return _hosts_ def store_hosts (hosts) '' ' 将新的ip存储到es中 ' '' def stat (day) _all_ = get_all_store_hosts() _hosts_ = get_distinct_hosts_from_logs: _hosts_ = [_host for _host in _hosts_ if _host not in _all_ ] if len(_hosts_ ): store_hosts(_hosts_ ) if __name__ == '__main__' : for day in xrange(1 , 30 ): stat(day)
各位看着有问题吗？好吧，貌似没有问题，但是呢执行完成后，你会惊奇的发现es中你的统计的数据里面存储大量重复的ip，问题原因大家已经知道了吧
解决方法：我在内存中做了一个缓存，通过缓存去重，当在缓存中不存在时则放入缓存中并存储到es
timeout
GET API 示例:GET /test/user/11 2 3 4 5 6 7 8 9 10 11 12 13 14 { "_index" : "test" , "_type" : "user" , "_id" : "1" , "_version" : 3 , "found" : true , "_source" : { "name" : "silence" , "age" : 28 , "book" : { "name" : "迷失的自己" } } }
说明:
2.可以通过HEAD方法根据reponse header信息判断文档是否存在curl -XHEAD -i "http://localhost:9200/test/user/1"1 2 3 HTTP/1.1 200 OK Content-Type : text/plain; charset=UTF-8Content-Length : 0`
输入:curl -XHEAD -i "http://localhost:9200/test/user/11 2 3 HTTP/1.1 404 Not Found Content-Type : text/plain; charset=UTF-8Content-Length : 0
可以看到若文档存在使用HEAD方法则返回状态码为200，否则状态码为404
3.GET操作默认是实时的，也就是说文档索引后可立即读取，并不像Search需要等待shard刷新，但是通过在GET请求中通过参数realtime=false或者在elasticsearch.yml配置action.get.realtime:false禁用GET /test/user/1?_source=false 不返回任何_source内容GET /test/user/1?_source=name 只返回_source中的nameGET /test/user/1?_source_include=*.name&_source_exclude=name
_source常用于需要返回一两个字段的情况, 内容较多的文档属性值进行筛选时可以组合_source_include和_source_excludeGET /test/user/1/_source
DELETE API 示例:DELETE /test/user/1
说明: