elastic 的基本总结
目录
1 filter 比 must 快的原因：
2 elastic 写入的时候的锁
1 scroll 每次查询快照数据，
2 结构性搜索
3 全局搜素
（1）基于词项的查询：
（2） 单个词查询
(2) 多个词的查询
（3）组合查询
评分计算编辑
（4） 多字段搜索
（5） 短语匹配
（6） 部分匹配
4 分数计算的相关度
5 聚合
1 filter 比 must 快的原因：
1 不用分数计算， 2 用bitset 进行缓存；
其核心实际是采用一个 bitset 记录与过滤器匹配的文档。
2 elastic 写入的时候的锁
，用的乐观锁并发控制。mvcc?
1 scroll 每次查询快照数据，
游标查询会取某个时间点的快照数据。 查询初始化之后索引上的任何变化会被它忽略。 它通过保存旧的数据文件来实现这个特性，结果就像保留初始化时的索引 视图 一样。
深度分页的代价根源是结果集全局排序，如果去掉全局排序的特性的话查询结果的成本就会很低。 游标查询用字段 _doc 来排序。 这个指令让 Elasticsearch 仅仅从还有结果的分片返回下一批结果。
启用游标查询可以通过在查询的时候设置参数 scroll 的值为我们期望的游标查询的过期时间。 游标查询的过期时间会在每次做查询的时候刷新，所以这个时间只需要足够处理当前批的结果就可以了，而不是处理查询结果的所有文档的所需时间
2 结构性搜索
探索找内部具有结构的过程，比如日期、时间和数字都是结构化的：它们有精确的格式，我们可以对这些格式进行逻辑操作。比较常见的操作包括比较数字或时间的范围，或判定两个值的大小。
3 全局搜素
（1）基于词项的查询：
如term 不要分析，对单个词进行搜索，准确搜索， TF/IDF 进行score， term 查询只对倒排索引的词项精确匹配，这点很重要，它不会对词的多样性进行处理（如， foo 或 FOO ）
基于全文的搜索：像match，
（2） 单个词查询
GET /my_index/my_type/_search
{
"query": {
"match": {
"title": "QUICK!"
}
}
}
(2) 多个词的查询
GET /my_index/my_type/_search
{
"query": {
"match": {
"title": "BROWN DOG!"
}
}
}
因为 match 查询必须查找两个词（ ["brown","dog"] ），它在内部实际上先执行两次 term 查询，然后将两次查询的结果合并作为最终结果输出。为了做到这点，它将两个 term 查询包入一个 bool 查询中，详细信息见 布尔查询。
其中可以提高精度和控制精度 "operator": "and" ；"minimum_should_match": "75%"
（3）组合查询
GET /my_index/my_type/_search
{
"query": {
"bool": {
"must": { "match": { "title": "quick" }},
"must_not": { "match": { "title": "lazy" }},
"should": [
{ "match": { "title": "brown" }},
{ "match": { "title": "dog" }}
]
}
}
}
评分计算编辑
bool 查询会为每个文档计算相关度评分 _score ， 再将所有匹配的 must 和 should 语句的分数 _score 求和，最后除以 must 和 should 语句的总数。
must_not 语句不会影响评分； 它的作用只是将不相关的文档排除。
（4） 多字段搜索
{
"query": {
"bool": {
"should": [
{ "match": { "title": "Brown fox" }},
{ "match": { "body": "Brown fox" }}
]
}
}
}
{
"hits": [
{
"_id": "1",
"_score": 0.14809652,
"_source": {
"title": "Quick brown rabbits",
"body": "Brown rabbits are commonly seen."
}
},
{
"_id": "2",
"_score": 0.09256032,
"_source": {
"title": "Keeping pets healthy",
"body": "My quick brown fox eats rabbits on a regular basis."
}
}
]
}
多个字段是如何进行评分的
为了理解导致这样的原因， 需要回想一下 bool 是如何计算评分的：
-
它会执行 should 语句中的两个查询。
-
加和两个查询的评分。
-
乘以匹配语句的总数。
-
除以所有语句总数（这里为：2）。
文档 1 的两个字段都包含 brown 这个词，所以两个 match 语句都能成功匹配并且有一个评分。
文档 2 的 body 字段同时包含 brown 和 fox 这两个词，但 title 字段没有包含任何词。这样， body 查询结果中的高分，加上 title 查询中的 0 分，然后乘以二分之一，就得到比文档 1 更低的整体评分。
在本例中， title 和 body 字段是相互竞争的关系，所以就需要找到单个 最佳匹配 的字段。
如果不是简单将每个字段的评分结果加在一起，而是将 最佳匹配 字段的评分作为查询的整体评分，结果会怎样？这样返回的结果可能是： 同时 包含 brown 和 fox 的单个字段比反复出现相同词语的多个不同字段有更高的相关度。
（5） 短语匹配
找邻近搜索词的查询方法时，就会想到 match_phrase 查询 。
GET /my_index/my_type/_search
{
"query": {
"match_phrase": {
"title": "quick brown fox"
}
}
}
（6） 部分匹配
1 前缀匹配
GET /my_index/address/_search
{
"query": {
"prefix": {
"postcode": "W1"
}
}
}
2 通配符匹配
GET /my_index/address/_search
{
"query": {
"wildcard": {
"postcode": "W?F*HW"
}
}
}
3 正则表达式的匹配
GET /my_index/address/_search
{
"query": {
"regexp": {
"postcode": "W[0-9].+"
}
}
}
4 分数计算的相关度
(1) 背后理论
使用 bool 模型 查找匹配的文档，使用评分函数计算相关度，评分函数包含 了 TF和IDF， 空间向量模型， 以及引进了 协调因子和字段归一话
bool 模型，就是 or and 语句
TF 词频， doc 出现查询词的次数越多，
5 聚合
桶 group by
指标 sum,avg,max
嵌套桶：
{
"size":0,
"query":{
},
"aggregations":{
"total_count":{
"terms":{
"field":"statusId",
"missing":"-1",
"size":500,
"min_doc_count":1,
"shard_min_doc_count":0,
"show_term_doc_count_error":false,
"order":[
{
"_term":"desc"
}
]
},
"aggregations":{
"avg_caseId":{
"avg":{
"field":"caseId"
}
},
"creatorId" : {
"terms" : {
"field" : "creatorId"
}
}
}
}
}
}