文档
在Elasticsearch中,文档以JSON格式进行存储,可以是复杂的结构,如:
1 { 2 "_index": "test", 3 "_type": "doc", 4 "_id": "1005", 5 "_version": 2, 6 "_seq_no": 10, 7 "_primary_term": 1, 8 "found": true, 9 "_source": { 10 "id": 1005, 11 "name": "孙七", 12 "age": 37, 13 "sex": "女", 14 "card": { 15 "card_number": "123456789" 16 } 17 } 18 }
其中,card是一个复杂对象,嵌套的Card对象。
元数据(metadata)
一个文档不只有数据。它还包含了元数据(metadata)——关于文档的信息。三个必须的元数据节点是:
节点 | 说明 |
_index |
文档存储的地方 |
_type |
文档代表的对象的类 |
_id |
文档的唯一标识 |
_index
索引(index)类似于关系型数据库里的“数据库”——它是我们存储和索引关联数据的地方。
提示: 事实上,我们的数据被存储和索引在分片(shards)中,索引只是一个把一个或多个分片分组在一起的逻辑空 间。然而,这只是一些内部细节——我们的程序完全不用关心分片。对于我们的程序而言,文档存储在索引 (index)中。剩下的细节由Elasticsearch关心既可。
_type
在应用中,我们使用对象表示一些“事物”,例如一个用户、一篇博客、一个评论,或者一封邮件。每个对象都属于一 个类(class),这个类定义了属性或与对象关联的数据。 user 类的对象可能包含姓名、性别、年龄和Email地址。
在关系型数据库中,我们经常将相同类的对象存储在一个表里,因为它们有着相同的结构。同理,在Elasticsearch 中,我们使用相同类型(type)的文档表示相同的“事物”,因为他们的数据结构也是相同的。
每个类型(type)都有自己的映射(mapping)或者结构定义,就像传统数据库表中的列一样。所有类型下的文档被存储 在同一个索引下,但是类型的映射(mapping)会告诉Elasticsearch不同的文档如何被索引。
_id
id仅仅是一个字符串,它与 _index 和 _type 组合时,就可以在Elasticsearch中唯一标识一个文档。当创建一个文 档,你可以自定义 _id ,也可以让Elasticsearch帮你自动生成(32位长度)。
查询响应
1、pretty
可以在查询url后面添加pretty参数,使得返回的json更易查看。
2、指定响应字段
在响应的数据中,如果我们不需要全部的字段,可以指定某些需要的字段进行返回。
1 GET /test/doc/1005?_source=id,name&pretty 2 3 #响应 4 { 5 "_index" : "test", 6 "_type" : "doc", 7 "_id" : "1005", 8 "_version" : 2, 9 "_seq_no" : 10, 10 "_primary_term" : 1, 11 "found" : true, 12 "_source" : { 13 "name" : "孙七", 14 "id" : 1005 15 } 16 }
如不需要返回元数据,仅仅返回原始数据,可以这样:
1 GET /test/doc/1005/_source 2 3 #响应 4 { 5 "id" : 1005, 6 "name" : "孙七", 7 "age" : 37, 8 "sex" : "女", 9 "card" : { 10 "card_number" : "123456789" 11 } 12 }
还可以这样:
1 GET /test/doc/1005/_source?_source=id,name 2 3 #响应 4 { 5 "id" : 1005, 6 "name" : "孙七" 7 }
3、判断文档是否存在
如果我们只需要判断文档是否存在,而不是查询文档内容,那么可以这样:
1 HEAD /test/doc/1005
判断响应状态码
4、批量操作
1、批量查询
1 POST /test/doc/_mget 2 3 { 4 "ids" : [ "1001", "1003" ] 5 }
效果如下:
2、_bulk操作
在Elasticsearch中,支持批量的插入、修改、删除操作,都是通过_bulk的api完成的。
请求格式如下:(请求格式不同寻常)
1 { action: { metadata }} 2 { request body } 3 { action: { metadata }} 4 { request body } 5 ...
批量插入数据:
1 POST /test2/doc/_bulk 2 3 {"create":{"_index":"test2","_type":"doc","_id":2001}} 4 {"id":2001,"name":"name1","age": 20,"sex": "男"} 5 {"create":{"_index":"test2","_type":"doc","_id":2002}} 6 {"id":2002,"name":"name2","age": 20,"sex": "男"} 7 {"create":{"_index":"test2","_type":"doc","_id":2003}} 8 {"id":2003,"name":"name3","age": 20,"sex": "男"}
效果如下:
批量删除:
1 POST /test2/doc/_bulk 2 3 {"delete":{"_index":"test2","_type":"doc","_id":2001}} 4 {"delete":{"_index":"test2","_type":"doc","_id":2002}} 5 {"delete":{"_index":"test2","_type":"doc","_id":2003}}
其他操作就类似了。 一次请求多少性能最高?
整个批量请求需要被加载到接受我们请求节点的内存里,所以请求越大,给其它请求可用的内存就越小。有一 个最佳的bulk请求大小。超过这个大小,性能不再提升而且可能降低。 最佳大小,当然并不是一个固定的数字。它完全取决于你的硬件、你文档的大小和复杂度以及索引和搜索的负 载。 幸运的是,这个最佳点(sweetspot)还是容易找到的:试着批量索引标准的文档,随着大小的增长,当性能开始 降低,说明你每个批次的大小太大了。开始的数量可以在1000~5000个文档之间,如果你的文档非常大,可以 使用较小的批次。 通常着眼于你请求批次的物理大小是非常有用的。一千个1kB的文档和一千个1MB的文档大不相同。一个好的 批次最好保持在5-15MB大小间。
5、分页
和SQL使用 LIMIT 关键字返回只有一页的结果一样,Elasticsearch接受 from 和 size 参数:
-
size: 结果数,默认10
-
2 from: 跳过开始的结果数,默认0
如果你想每页显示5个结果,页码从1到3,那请求如下:
1 GET /_search?size=5 2 GET /_search?size=5&from=5 3 GET /_search?size=5&from=10
应该当心分页太深或者一次请求太多的结果。结果在返回前会被排序。
但是记住一个搜索请求常常涉及多个分 片。每个分片生成自己排好序的结果,它们接着需要集中起来排序以确保整体排序正确。
在集群系统中深度分页
为了理解为什么深度分页是有问题的,让我们假设在一个有5个主分片的索引中搜索。当我们请求结果的第一 页(结果1到10)时,每个分片产生自己最顶端10个结果然后返回它们给请求节点(requesting node),它再 排序这所有的50个结果以选出顶端的10个结果。
现在假设我们请求第1000页——结果10001到10010。工作方式都相同,不同的是每个分片都必须产生顶端的 10010个结果。然后请求节点排序这50050个结果并丢弃50040个!
6、映射
前面我们创建的索引以及插入数据,都是由Elasticsearch进行自动判断类型,有些时候我们是需要进行明确字段类型的,否则,自动判断的类型和实际需求是不相符的。
自动判断的规则如下:
JSON type |
Field type |
Boolean: true or false | "boolean" |
Whole number: 123 | "long" |
Floating point: 123.45 | "double" |
String, valid date: "2014-09-15" | "date" |
String: "foo bar" | "string" |
Elasticsearch中支持的类型如下:
类型 |
表示的数据类型 |
String | string,text,keyword |
Whole number | byte,short,integer,long |
Floating point | float,double |
Boolean | boolean |
Date | date |
- string类型在ElasticSearch 旧版本中使用较多,从ElasticSearch 5.x开始不再支持string,由text和 keyword类型替代。
- text 类型,当一个字段是要被全文搜索的,比如Email内容、产品描述,应该使用text类型。设置text类型 以后,字段内容会被分析,在生成倒排索引以前,字符串会被分析器分成一个一个词项。text类型的字段 不用于排序,很少用于聚合。
- keyword类型适用于索引结构化的字段,比如email地址、主机名、状态码和标签。如果字段需要进行过 滤(比如查找已发布博客中status属性为published的文章)、排序、聚合。keyword类型的字段只能通过精 确值搜索到。
创建明确类型的索引:
1 PUT /person 2 3 4 { 5 "settings": { 6 "index": { 7 "number_of_shards": "2", 8 "number_of_replicas": "0" 9 } 10 }, 11 "mappings": { 12 "properties": { 13 "name": { 14 "type": "text" 15 }, 16 "age": { 17 "type": "integer" 18 }, 19 "mail": { 20 "type": "keyword" 21 }, 22 "hobby": { 23 "type": "text" 24 } 25 } 26 } 27 }
效果如下:
查看映射:
1 GET /person/_mapping
效果如下:
插入数据:
1 POST /person/_bulk 2 3 {"index":{"_index":"person"}} 4 {"name":"张三","age": 20,"mail": "111@qq.com","hobby":"羽毛球、乒乓球、足球"} 5 {"index":{"_index":"person"}} 6 {"name":"李四","age": 21,"mail": "222@qq.com","hobby":"羽毛球、乒乓球、足球、篮球"} 7 {"index":{"_index":"person"}} 8 {"name":"王五","age": 22,"mail": "333@qq.com","hobby":"羽毛球、篮球、游泳、听音乐"} 9 {"index":{"_index":"person"}} 10 {"name":"赵六","age": 23,"mail": "444@qq.com","hobby":"跑步、游泳"} 11 {"index":{"_index":"person"}} 12 {"name":"孙七","age": 24,"mail": "555@qq.com","hobby":"听音乐、看电影"}
测试搜索:
1 POST /person/_search 2 3 { 4 "query": { 5 "match": { 6 "hobby": "音乐" 7 } 8 } 9 }
效果如下:
7、结构化查询
7.1、term查询
term 主要用于精确匹配哪些值,比如数字,日期,布尔值或 not_analyzed 的字符串(未经分析的文本数据类型):
1 { "term": { "age": 26 }} 2 { "term": { "date": "2014-09-01" }} 3 { "term": { "public": true }} 4 { "term": { "tag": "full_text" }}
示例:
1 POST /person/_search 2 3 { 4 "query": { 5 "term": { 6 "age": 20 7 } 8 } 9 }
效果如下:
7.2、terms查询
terms 跟 term 有点类似,但 terms 允许指定多个匹配条件。 如果某个字段指定了多个值,那么文档需要一起去做匹配:
格式:
1 { 2 "terms": { 3 "tag": [ 4 "search", 5 "full_text", 6 "nosql" 7 ] 8 } 9 }
示例:
1 POST /person/_search 2 3 { 4 "query": { 5 "terms": { 6 "age": [20, 21] 7 } 8 } 9 }
效果如下:
7.3、range查询
range 过滤允许我们按照指定范围查找一批数据:
1 { 2 "range": { 3 "age": { 4 "gt": 20, 5 "lt": 30 6 } 7 } 8 }
范围操作符包含:
- gt ::大于
- gte :: 大于等于
- lt ::小于
- lte :: 小于等于
示例:
1 POST /person/_search 2 3 { 4 "query": { 5 "range": { 6 "age": { 7 "gt": 20, 8 "lt": 30 9 } 10 } 11 } 12 }
效果如下:
7.4、exists 查询
exists 查询可以用于查找文档中是否包含指定字段或没有某个字段,类似于SQL语句中的IS_NULL条件
1 { 2 "exists": { 3 "field": "title" 4 } 5 }
示例:
1 POST /person/_search 2 3 { 4 "query": { 5 "exists": { 6 "field": "name" 7 } 8 } 9 }
效果如下:
6.5、match查询
match 查询是一个标准查询,不管你需要全文本查询还是精确查询基本上都要用到它。
如果你使用 match 查询一个全文本字段,它会在真正查询之前用分析器先分析 match 一下查询字符:
1 { 2 "match": { 3 "tweet": "About Search" 4 } 5 }
如果用match下指定了一个确切值,在遇到数字,日期,布尔值或者not_analyzed 的字符串时,它将为你搜索你 给定的值:
示例:
1 POST /person/_search 2 3 { 4 "query": { 5 "match": { 6 "name": "孙七" 7 } 8 } 9 }
效果如下:
7.6、bool查询
- bool 查询可以用来合并多个条件查询结果的布尔逻辑,它包含一下操作符: must :: 多个查询条件的完全匹配,相当于 and 。
- must_not :: 多个查询条件的相反匹配,相当于 not 。
- should :: 至少有一个查询条件匹配, 相当于 or 。
- 这些参数可以分别继承一个查询条件或者一个查询条件的数组:
1 { 2 "bool": { 3 "must": { 4 "term": { 5 "folder": "inbox" 6 } 7 }, 8 "must_not": { 9 "term": { 10 "tag": "spam" 11 } 12 }, 13 "should": [] 14 } 15 }
示例效果:
7.7、过滤查询
前面讲过结构化查询,Elasticsearch也支持过滤查询,如term、range、match等。
示例:查询年龄为20岁的用户。
查询和过滤的对比
- 一条过滤语句会询问每个文档的字段值是否包含着特定值。
- 查询语句会询问每个文档的字段值与特定值的匹配程度如何。
- 一条查询语句会计算每个文档与查询语句的相关性,会给出一个相关性评分 _score,并且 按照相关性对匹配到的文档进行排序。 这种评分方式非常适用于一个没有完全配置结果的全文本搜索。
- 一个简单的文档列表,快速匹配运算并存入内存是十分方便的, 每个文档仅需要1个字节。这些缓存的过滤结果 集与后续请求的结合使用是非常高效的。
- 查询语句不仅要查找相匹配的文档,还需要计算每个文档的相关性,所以一般来说查询语句要比 过滤语句更耗 时,并且查询结果也不可缓存。
建议:
做精确匹配搜索时,最好用过滤语句,因为过滤语句可以缓存数据。