结构化搜索
非黑即白。结构化查询不关心文件的相关度，简单的对文档包括或排除处理
精确值查找
尽可能多的使用过滤式查询（容易被缓存）
1、term查询数字
可以用来处理数字、布尔值、日期以及文本
{
"term" : {
"price" : 20
}
}
通常当查询一个精确值的时候，我们不希望对他进行评分。
可以是用constant_score查询以非评分的方式来执行term
GET /my_store/products/_search
{
"query" : {
"constant_score" : {
"filter" : {
"term" : {
"price" : 20
}
}
}
}
}
2、term查询文本
只有设置成not_analyzed的文本字段才来精确查找
内部过滤器的操作
1、查询匹配文档
term查询在倒排索引中查找字段（没有设置成not_analyzed的文本会分析拆成多个字段，导致在倒排索引中查询不到）
2、创建bitset（一个只包含0和1的数组）
表示哪个文档会包含该term。文档存储是有顺序的，包含term的文档会被bitset标记成1
3、迭代bitset(s)
一旦为每个查询生成了bitsets，es就会循环迭代bitsets找到满足所有过滤条件的匹配文档的集合。
执行顺序是启发式的，但一般来说先迭代稀疏的bitset
4、增量使用计数
es能够缓存非评分查询，但它也会缓存一些极少使用的东西。
非评分查询因为倒排索引已经非常快了，所以我们只想缓存那些我们“在将来会被再次使用的查询”
es会跟踪保留查询使用的历史状态，查询在最近的256次查询中会被用到，就会被缓存
当bitset被缓存后，缓存会在那些低于10000个文档（或少于3%的总索引数）的segment中被忽略。
这些小的segment将会消失，所以为它们分配缓存是一种浪费
实际情况并非如此（执行有它的复杂性，这取决于查询计划是如何重新规划的，有些启发式的算法是基于查询代价的），理论上非评分查询 先于 评分查询执行。非评分查询任务旨在降低那些将对评分查询计算带来更高成本的文档数量，从而达到快速搜索的目的。
组合过滤器
1、布尔过滤器
must：必须匹配
must_not：都不能匹配
should：至少有一个语句要匹配
GET /my_store/products/_search
{
"query" : {
"filtered" : {
"filter" : {
"bool" : {
"should" : [
{ "term" : {"price" : 20}},
{ "term" : {"productID" : "XHDK-A-1293-#fJ3"}}
],
"must_not" : {
"term" : {"price" : 30}
}
}
}
}
}
}
注意：
仍然需要一个filtered查询将所有东西抱起来
should语句块里面的两个term过滤器与bool过滤器是父子关系，需要匹配其一
2、嵌套布尔过滤器
GET /my_store/products/_search
{
"query" : {
"filtered" : {
"filter" : {
"bool" : {
"should" : [
{ "term" : {"productID" : "KDKE-B-9947-#kL5"}},
{ "bool" : {
"must" : [
{ "term" : {"productID" : "JODL-X-1937-#pV7"}},
{ "term" : {"price" : 30}} (2)
]
}}
]
}
}
}
}
}
term和bool过滤器是兄弟关系时，返回的文档至少必须匹配其中一个过滤器的条件。
查找多个精确值
GET /my_store/products/_search
{
"query" : {
"constant_score" : {
"filter" : {
"terms" : {
"price" : [20, 30]
}
}
}
}
}
包含，而不是相等
例如使用过滤器{ "term" : { "tags" : "search" } }会得到以下文档
{ "tags" : ["search"] }
{ "tags" : ["search", "open_source"] }
term工作原理：es会在倒排索引中茶盅包括某term的所有文档，然后构造一个bitset。
| Token | DocIDs |
|---|---|
| open_source | 2 |
| search | 1,2 |
因此匹配到两个文档
精确相等
如果一定要做到精确相等，最好的方法时增加并索引另一个字段，存储该字段包含词项的数量
{ "tags" : ["search"], "tag_count" : 1 }
{ "tags" : ["search", "open_source"], "tag_count" : 2 }
之后构造constant_score查询
GET /my_index/my_type/_search
{
"query": {
"constant_score" : {
"filter" : {
"bool" : {
"must" : [
{ "term" : { "tags" : "search" } }, (1)
{ "term" : { "tag_count" : 1 } } (2)
]
}
}
}
}
}
范围
GET /my_store/products/_search
{
"query" : {
"constant_score" : {
"filter" : {
"range" : {
"price" : {
"gte" : 20,
"lt" : 40
}
}
}
}
}
}
日期范围
"range" : {
"timestamp" : {
"gt" : "2014-01-01 00:00:00",
"lt" : "2014-01-07 00:00:00"
}
}
支持日期计算
"range" : {
"timestamp" : {
"gt" : "now-1h"
}
}
||后面跟着数学表达式
"range" : {
"timestamp" : {
"gt" : "2014-01-01 00:00:00",
"lt" : "2014-01-01 00:00:00||+1M" (1)
}
}
字符串范围
字典顺序和字母顺序
"range" : {
"title" : {
"gte" : "a",
"lt" : "b"
}
}
数字和日期字段的索引方式使得范围计算很高校
字符串的范围计算实际上是在为范围内的每个词项都执行term过滤器，唯一词项越多字符串范围计算越慢
处理Null值
null,[]和[null]所有这些都是等价的，无法存入倒排索引中
GET /my_index/posts/_search
{
"query" : {
"constant_score" : {
"filter" : {
"exists" : { "field" : "tags" }
}
}
}
}
GET /my_index/posts/_search
{
"query" : {
"constant_score" : {
"filter": {
"missing" : { "field" : "tags" }
}
}
}
}
null代表的意思：一种是被置为null，另一种是没有值
设置映射时可以为之设置空值，用以处理显式null值的情况（仍然不会存入倒排索引）
关于缓存
bitset是以增量的方式更新的。
一个bitsets是独立与它所属搜索请求其他部分的，一旦被缓存，bitset可以被用作多个搜索请求
早期的es默认是缓存已切可以缓存的对象，这就意味着系统缓存bitsets太富侵略性，从而给清理缓存带来性能压力。
倒排索引非常快，但是绝大多数查询组件却很少使用它，例如term过滤字段user_id。
上百万用户，每个用户ID出现的概率都很小。那么使用bitsets就不是很合算，因为缓存的结果很可能在重用之前就被剔除了
为了解决这个问题，es会基于使用频次自动缓存查询。
一个非评分查询在最近的256次查询中被使用过（次数取决于查询类型），那么这个查询就会作为缓存的候选。
只有那些文档数量超过10000或者超过总文档数量的3%才会缓存bitset。
一旦被缓存了，非评分计算的bitset会一直驻留在缓存中，直到它被剔除（LRU）
