ElasticarchURIarch查询语法整理
Elasticarch URI arch
⼀、请求体查询与空查询
1. 请求体查询（request body arch）
简单查询语句（lite）是⼀种有效的命令⾏adhoc查询。但是，如果你想要善⽤搜索，你必须使⽤请求体查询（request body arch） API。之所以这么称呼，是因为⼤多数的参数以JSON格式所容纳⽽⾮查询字符串。
请求体查询（以下简称查询），并不仅仅⽤于处理查询，⽽且还可以⾼亮返回结果中的⽚段，并且给出帮助你的⽤户找寻最好结果的相关数据建议。
2. 空查询
我们以最简单的arch API开始，空查询将会返回索引中所有的⽂档。
GET /_arch
{}
同字符串查询⼀样，你可以查询⼀个，多个或_all索引（indices）或类型（types）：
GET /index_2014*/type1,typ2/_arch
{}
你可以使⽤from及size参数进⾏分页：
GET /_arch
{
"from" : 30,
"size" : 10
}
携带内容的GET请求？
任何⼀种语⾔（特别是js）的HTTP库都不允许GET请求中携带交互数据。事实上，有些⽤户很惊讶GET请求中居然会允许携带交互数据。真实情况是，[RFC 7231]，⼀份规定HTTP语义及内容的RFC中并未规定 GET 请求中允许携带交互数据！所以，有些HTTP服务允许这种⾏为，⽽另⼀些(特别是缓存代理)，则不允许这种⾏为。
Elasticarch的作者们倾向于使⽤GET提交查询请求，因为他们觉得这个词相⽐POST来说，能更好的描述这种⾏为。然⽽，因为携带交互数据的GET请求并不被⼴泛⽀持，所以arch API同样⽀持POST请求，类似于这样：
POST /_arch
{
"from" : 30,
"size" : 10
}特殊的一天
这个原理同样应⽤于其他携带交互数据的GET API请求中。
桑提亚哥相对于神秘的查询字符串⽅法，请求体查询允许我们使⽤结构化查询Query DSL（Query Domain Specific Language）
⼆、结构化查询
bool联合查询: must, should, must_not
must: ⽂档必须完全匹配条件，选择多个即且的意思；
should: should下⾯会带⼀个以上的条件，⾄少满⾜⼀个条件，这个⽂档就符合should，选择多个即且的意思；
must_not: ⽂档必须不匹配条件，选择多个即且的意思；
如果我们想要请求"content中带宝马，但是tag中不带宝马"这样类似的需求，就需要⽤到bool联合查询。
样例
全⽂检索，模糊匹配，message.keyword 包含“Error”，项⽬名称不以“boe”开头的数据。
此处我们需要使⽤ bool 查询：
GET awsbpm_prod_log-2019.08.20/_arch
{
"query":{
"bool":{
"must": [
{
"match_all":{
}
},
{自我总结500字
"wildcard":{
"message.keyword":"*Error*"
}
}
],
"must_not":[
],
"should":[
]
}
},
"from":11,
"size":20,
"sort":[
],
"aggs":{
}
}
⾼级检索语法：term, wildcard, prefix, fuzzy, range, query_string, text, missing
term：严格匹配条件，所查询的字段内容要与填⼊查询框搜索值⼀致；
wildcard：通配符查询，* 表⽰全匹配，？表⽰单⼀匹配，etc： aaa* 或者 a?b；
prefix：前缀匹配，搜索框如果输⼊aa，那么可能匹配到的字段值为 aab,aavb等；
公式法公式fuzzy min_similarity：弹性模糊匹配，有两个搜索框，第⼀个搜索框为搜索匹配值，会⾃动纠错，⽐如输⼊ ggjk，那么可能会匹配到ggjo，第⼆个框为最⼩相似度，采⽤的算法是Damerau-Levenshtein（最佳字符串对齐）算法，不建议填写这个框，我到发稿前也是被搞的头⽪发⿇，等我完全吃透再更新；
fuzzy max_expansions：弹性模糊匹配，有两个搜索框，第⼀个搜索框为搜索匹配值，会⾃动纠错，⽐如输⼊ ggjk，那么可能会匹配到ggjo，第⼆个框是最⼤扩展匹配数，⽐如是1，那么ggjk只会随机模糊匹配到⼀种可能结果，即使它会出现2种或者更加多，也只会搜索⼀种；range：范围查询，gt为⼤于，gte为⼤于等于，lt⼩于，lte⼩于等于，所搜索的字段值在两个搜索框标识数值之间；
query_string：字符⽚段查询，如果是数字，则严格匹配数字，如果是字符串，则按照⾃⾝或者分⽚词匹配；
text：分⽚词查询，等确定后更新；
missing：查询没有定义该字段或者该字段值为null的数据。
1. term query - 索引词检索
(1) term query - 不分词检索
term query: 把检索串当作⼀个整体来执⾏检索, 即不会对检索串分词.
term是完全匹配检索, 要⽤在不分词的字段上, 如果某个field在映射中被分词了, term检索将不起作⽤.
所以, 不分词的field, 要在mapping中设置为不分词.
—— ES 5.x之后, 为每个text类型的字段新增了名为keyword的⼦字段, 是不分词的, 默认保留256个字符.
—— 可以使⽤keyword字段进⾏term检索.
⽰例:
GET shop/_arch
{
"query": {
"term": {
"name.keyword": "Java编程思想"
}
}
}
(2) terms query - in检索
terms, 相当于多个term检索, 类似于SQL中in关键字的⽤法, 即在某些给定的数据中检索:
GET shop/_arch
{
"query": {
"terms": {
"name.keyword": [
"Java编程思想", "Java并发编程的艺术"
]节衣缩食
}
}
}
2. prefix query - 前缀检索
prefix query, 就是前缀检索. ⽐如商品name中有多个以"Java"开头的document, 检索前缀"Java"时就能检索到所有以"Java"开头的⽂档.—— 扫描所有倒排索引, 性能较差.
GET shop/_arch
{
"query": {
"prefix": { "name": "java" }
}
}
3. wildcard query - 通配符检索
扫描所有倒排索引, 性能较差.
GET shop/_arch
{
"query": {
"wildcard": { "name": "ja*" }
}
}
4. regexp query - 正则检索
扫描所有倒排索引, 性能较差.
GET shop/_arch
{
"query": {
"regexp": { "name": "jav[a-z]*" }
}
}
5. fuzzy query - 纠错检索
fuzziness的默认值是2 —— 表⽰最多可以纠错两次.
说明: fuzziness的值太⼤, 将削弱检索条件的作⽤, 也就是说纠错次数太多, 就会导致限定检索结果的检索条件被改变, 失去了限定作⽤.⽰例: 检索name中包含"Java"的⽂档, Java中缺失了⼀个字母a:
GET shop/_arch
{
"query": {
"match": {
"name": {
"query": "Jav",
"fuzziness": 1,
"operator": "and"
}
}
}
}
6. boost评分权重 - 控制⽂档的优先级别
通过boost参数, 令满⾜某个条件的⽂档的得分更⾼, 从⽽使得其排名更靠前.
GET shop/_arch
{
"query": {
"bool": {
"must": [
{ "match": { "name": "编程思想"} }
],
"should": [
{
"match": {
"name": {
"query": "艺术",
"boost": 2 // 提升评分权重
}女孩怎么画
}
}
]
}
}
}
奶油培根意面
7. dis_max的⽤法 - best fields策略
(1) dis_max的提出
如果我们希望检索结果中 (检索串被分词后的) 关键字匹配越多, 这样的⽂档就越靠前, ⽽不是多个⼦检索中匹配少量分词的⽂档靠前.
⇒此时可以使⽤dis_max和tie_breaker.
tie_breaker的值介于0~1之间, Elasticarch将 bool检索的分数 * tie_breaker的结果与dis_max的最⾼分进⾏⽐较, 除了取dis_max的最⾼分以外, 还会考虑其他的检索结果的分数.
(2) 使⽤⽰例
为了增加精准度, 常⽤的是配合boost、minimum_should_match等参数控制检索结果.
GET shop/_arch
{
"query": {
"dis_max": {
"queries": [
{ "match": { "name": "虚拟机" } },
{ "match": { "desc": "经典" } }
],
"tie_breaker": 0.2 // 对同时满⾜的⽂档的分值进⾏提升
}
}
}
GET shop/_arch
{
"query": {
"dis_max": {
"queries": [
{
"match": {
"name": {
"query": "虚拟机",
"minimum_should_match": "50%",
"boost": 2
}
}
},
{
"match": {
"desc": {
"query": "经典",
"minimum_should_match": "50%",
"boost": 3
}
}
}
],
"tie_breaker": 0.3
}
}
}
三、复杂检索的使⽤范例
1. 多条件过滤 - 包含
检索出版时间在2012-07之后, 且⾄少满⾜下述条件中⼀个的⽂档:
a. 名称(name)中包含"并发";
b. 描述(desc)中包含"java";
c. 出版社(publisher)名称中不包含"电⼦".
GET shop/_arch
{
"query": {
"bool": {
"filter": { // 按时间过滤
"range": {
"date": {"gte": "2012-07"}
}
},
"should": [ // 可匹配, 可不匹配
{
"match": { "name": "并发" }
},
韩国男星图片{
"bool": {
"must": { // 必须匹配
"match": { "desc": "java" }
},
"must_not": { // 不能匹配
"match": { "publisher": "电⼦" }
}
}
}
],
"minimum_should_match": 1 // ⾄少满⾜should中的⼀个条件
}
},
// ⾃定义排序
"sort": [
{ "price": { "order": "desc" } }
]
}
注意: 排序的字段最好是数字, 或⽇期, 因为字符串字段会被分词, ES会通过分词后的某个词去排序, 结果难以预测.
2. 多条件拼接 - 包含+范围+排序
匹配检索: name中包含"java"却不包含"虚拟机";
范围检索: 价格⼤于50、⼩于80;
结果排序: 按照价格升序排序.
GET shop/_arch
{
"query": {
"bool": {
"must": { // 必须匹配
"match": { "name": "java" }
},
"must_not": { // 必须不匹配
"match": { "name": "虚拟机" }
},
"filter": {
"range": {
"price": {
"gte": 40,
"lte": 80,
"boost": 2.0 // 设置得分的权重值(提升值), 默认是1.0
}
}
}
}
}
}
关于范围检索的使⽤, 请参考下篇⽂章: ES 22 - Elasticarch对数值或⽇期类型进⾏范围检索
3. 定制检索结果的排序规则
(1) 默认排序规则:
ES默认是按检索结果的分值(_score)降序排列的.
某些情况下, 可能存在⽆实际意义的_score, ⽐如filter时所有_score的值都相同:
GET website/_arch
{
"query": {
"bool": {
"filter": {
"term": {
"author_id": 5520 // 此时所有符合条件的_score都为0
}
}
}
}
}
