elasticsearch 第五篇(文档操作接口)
来源:互联网 发布:ubuntu登陆界面修改 编辑:程序博客网 时间:2024/04/30 09:38
INDEX API
示例:
12345
PUT /test/user/1{ "name": "silence", "age": 27}
说明:
1.索引文档使用PUT方法,需要指定index(test)、type(user)和文档编号,提交数据为json格式为文档的内容
2.在索引文档时,会自动检查index和type是否存在,若不存在则自动创建,对于type会自动调用putmapping方法为type自动创建mapping,当提交的json数据新增字段时也会自动对type自动调用putmapping方法在mapping中添加新的字段类型
可通过elasticsearch.yml中添加配置禁用自动创建index和type
12
action.auto_create_index: false index.mapper.dynamic: false
在某些时候允许某类型或者禁用某类型的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属性
es为每个文档自动设置一个version属性, version从1开始, 当文档发生更新,删除操作时version都会自增1, version是范围为[1, 9.2e+18]的整数, 在获取或查询文档是version作为文档的一部分返回
version属性主要使用乐观锁机保证数据在读取后再进行更新动作时的数据一致性问题,在提交请求时通过指定version参数表示存储的版本必须符合条件时才可执行成功, 默认条件为两者一致,若不提交version表示不进行检查
使用方法:
例如编号为1的文档version为7
1234567891011
{ "_index": "test", "_type": "user", "_id": "1", "_version": 7, "found": true, "_source": { "name": "silence", "age": 27 }}
当我们使用如下请求执行更新动作可看到执行成功,并且version自增1, 返回结果中为8:
输入:
12345
PUT /test/user/1?version=7{ "name": "silence", "age": 28}
输出:
1234567
{ "_index": "test", "_type": "user", "_id": "1", "_version": 8, "created": false}
当我们再次发出version=7的请求得到的响应为:
1234
{ "error": "VersionConflictEngineException[[test][2] [user][1]: version conflict, current [8], provided [7]]", "status": 409}
可自己测试version>8的请求依然失败, 此时你可能会想到在高并发情况下此种效率是否会低效, 可能你会在内存中放置一个version+1的副本, 通过内存中对副本进行自增, 然后异步方式提高并发, 此时执行成功率会下降并且导致数据丢失, 在此种情况下只要满足你指定的version大于存储中的版本号即可, 为解决此种问题es提供version_type可以指定使用的比较策略:
4.op_type: 在提交请求时指定op_type=create, 表示若id不存在时创建, 否则失败
输入
12345
PUT /test/user/1?op_type=create{ "name": "silence", "age": 28}
输出:
1234
{ "error": "DocumentAlreadyExistsException[[test][2] [user][1]: document already exists]", "status": 409}
op_type=create的另一种表示方法为:
12345
PUT 1/_create{ user/ "name": "silence", "age": 28}
5.ID生成器: 在大多数情况下我们不需要维护也不关心文档的id是什么, 在es中可以为文档自动生成id,方式为使用post方式提交参数, 并在请求中不指定id值(若指定则使用指定的id值)
6.routing路由分配: 在创建index时通常会将index数据存放在不同的shard上,es默认通过hash(id) % shard_num决定将文档存储在哪个shard上,此刻你应该想到routing的作用,对,就是用来指定做负载是hash的输入参数:
输入:
12345
POST name{ user/?routing= "name": "silence", "age": 28}
若在索引文档时显示指定routing,则在提交文档中必须存在指定routing对应的值,否则执行失败
7.分布式执行
索引操作会被路由到shard上,并在包含该shard的node中执行,若存在复制shard,则当所有复制节点从主shard中执行成功后,返回结果
8.一致性
为防止某些网络节点错误,默认情况下当索引成功数量>=仲裁(replicas/2+1)时,则认为操作成功,对于复制数量为1时则数据一共存两份(主shard和复制shard),此时若主shard写成功则认为执行成功
可在elasticsearch.yml中将action.write_consistency设置为one,all,quorum修改判断依据
9.刷新shard
为了在索引文档成功后立即查询到文档(当shard刷新后才可search到), 可以通过设置refresh=true在索引文档成功后立即执行存储该数据shard的刷新动作, 在设置前应该对索引和查询进行对性能测试,对于get接口获取文档是完全实时的
再次分享自己趟过的一个坑:
背景:需要在一堆日志中统计所有存在的源IP,日志时按天存放的,代码结构如下:
12345678910111213141516171819202122232425262728
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
当文档被索引时会从主shard将数据复制到复制shard, 主shard需要等待复制shard的响应后返回执行结果, 此等待时间默认为1min, 可以通过在请求中添加timeout修改此时间
GET API
示例:
输入:GET /test/user/1
输入:
1234567891011121314
{ "_index": "test", "_type": "user", "_id": "1", "_version": 3, "found": true, "_source": { "name": "silence", "age": 28, "book": { "name": "迷失的自己" } }}
说明:
1.可以通过GET方法根据文档的ID读取文档内容
_index,_type,_id三元组唯一标识一个文档, 分别表示索引,类型和文档id
_version为文档的版本
found表示是否查询到结果, true表示存在, false表示不存在
_source是真正的文档内容
2.可以通过HEAD方法根据reponse header信息判断文档是否存在
输入:curl -XHEAD -i "http://localhost:9200/test/user/1"
123
HTTP/1.1 200 OKContent-Type: text/plain; charset=UTF-8Content-Length: 0`
输入:curl -XHEAD -i "http://localhost:9200/test/user/1
输出:
123
HTTP/1.1 404 Not FoundContent-Type: text/plain; charset=UTF-8Content-Length: 0
可以看到若文档存在使用HEAD方法则返回状态码为200,否则状态码为404
3.GET操作默认是实时的,也就是说文档索引后可立即读取,并不像Search需要等待shard刷新,但是通过在GET请求中通过参数realtime=false或者在elasticsearch.yml配置action.get.realtime:false禁用
4.在GET数据时可以使用”_all”替代要查询的_type, 此时会返回在所有type中第一个匹配到的document
5.在GET数据时可以通过_source, _source_include & _source_exclude设置返回文档包含的属性
输入: GET /test/user/1?_source=false
不返回任何_source内容
输入: GET /test/user/1?_source=name
只返回_source中的name
输入: GET /test/user/1?_source_include=*.name&_source_exclude=name
_source常用于需要返回一两个字段的情况, 内容较多的文档属性值进行筛选时可以组合_source_include和_source_exclude
6.若只想返回_source中的内容可以使用:GET /test/user/1/_source
7.若在索引文档时指定了routing_key为了可以正确GET到文档,则需要在GET请求中添加routing指定正确的routing_key
8.默认GET文档执行在复制shard的上,但可以通过设置preference为_primary或者_local, _primary表示在主shard上执行, _local表示在一个分配且可用的shard上执行
9.GET请求中也可以添加refresh=true参数强制使获取文档相关shard刷新, 从而可以被search到
10.在GET请求发出后,会根据需要获取文档id将请求转发到一个相关的复制节点上执行并返回结果
11.可以在GET请求中指定version属性用于需要获取符合规则version的文档
DELETE API
示例:
输入DELETE /test/user/1
说明:
1.在DELETE方法提交的参数中可以设置version属性用于删除符合规则的version文档
2.当在index文档是设置routing_key, 那么在删除文档时也需要使用routing设置正确的routing_key
3.当删除文档是若index不存在, 则es会自动创建
4.删除文档请求会被转发到主shard上, 主shard操作完成后, 各复制shard会从主shard进行同步
5.
from: http://imsilence.github.io/2015/09/17/elasticsearch/elasticsearch_05/
- elasticsearch 第五篇(文档操作接口)
- ElasticSearch入门 第五篇:使用C#查询文档
- Elasticsearch 文档更新操作
- Elasticsearch之文档基本操作。
- ElasticSearch.net第五步-c#操作ElasticSearch详解
- 操作文档的接口
- 第五篇 如何调用驱动接口,完成互操作
- 通过HTTP RESTful API 操作elasticsearch文档
- ElasticSearch-深入理解系列6 -文档操作
- Elasticsearch基于RESTful接口的索引操作
- rsyslog 入门 第五篇 out put elasticsearch
- elasticsearch 文档
- elasticsearch-java api之文档(document)各种操作
- ElasticSearch在JPA与原生操作接口的对应关系
- DOM应用编程接口,操作HTML文档
- 第五篇 elasticsearch中document的核心元数据
- Elasticsearch操作
- elasticsearch 操作
- 1002. A+B for Polynomials (25)
- MongoDB关键点集锦(更新中...)
- linux学习笔记(2)
- 1027
- 如何在Linux中加入cron任务
- elasticsearch 第五篇(文档操作接口)
- 1019
- HTTP协议简介及TCP三次握手和四次挥手
- STemWin移植到MiCO物联网操作系统笔记-基于秉火STM32F429开发板【1】
- MySql-5.7.17 -winx32的安装配置
- 远程连接不上的各种问题
- 为什么计算机时间要从1970年1月1日开始算起
- 记录自己制作投票系统的坑
- 完美的代价