ES-基础知识之三

1.映射和分析

GET /megacorp_employee/_mapping //获取映射

a.精确值VS全文

精确值 如它们听起来那样精确。例如日期或者用户 ID，但字符串也可以表示精确值，例如用户名或邮箱地址。对于精确值来讲，Foo 和 foo 是不同的，2014 和 2014-09-15 也是不同的

另一方面，全文 是指文本数据（通常以人类容易识别的语言书写），例如一个推文的内容或一封邮件的内容。

b.倒排索引

Elasticsearch 使用一种称为 倒排索引 的结构，它适用于快速的全文搜索。一个倒排索引由文档中所有不重复词的列表构成，对于其中每个词，有一个包含它的文档列表。

例如，假设我们有两个文档，每个文档的 content 域包含如下内容：

1. The quick brown fox jumped over the lazy dog
2. Quick brown foxes leap over lazy dogs in summer

为了创建倒排索引，我们首先将每个文档的 content 域拆分成单独的 词（我们称它为 词条 或 tokens ），创建一个包含所有不重复词条的排序列表，然后列出每个词条出现在哪个文档。结果如下所示：

Term      Doc_1  Doc_2

-------------------------

Quick   |       |  X

The     |   X   |

brown   |   X   |  X

dog     |   X   |

dogs    |       |  X

fox     |   X   |

foxes   |       |  X

in      |       |  X

jumped  |   X   |

lazy    |   X   |  X

leap    |       |  X

over    |   X   |  X

quick   |   X   |

summer  |       |  X

the     |   X   |

------------------------

现在，如果我们想搜索 quick brown ，我们只需要查找包含每个词条的文档：

Term      Doc_1  Doc_2

-------------------------

brown   |   X   |  X

quick   |   X   |

------------------------

Total   |   2   |  1

两个文档都匹配，但是第一个文档比第二个匹配度更高。如果我们使用仅计算匹配词条数量的简单 相似性算法 ，那么，我们可以说，对于我们查询的相关性来讲，第一个文档比第二个文档更佳。

但是，我们目前的倒排索引有一些问题：

• Quick 和 quick 以独立的词条出现，然而用户可能认为它们是相同的词。
• fox 和 foxes 非常相似, 就像 dog 和 dogs ；他们有相同的词根。

• jumped 和 leap, 尽管没有相同的词根，但他们的意思很相近。他们是同义词。

使用前面的索引搜索 +Quick +fox 不会得到任何匹配文档。（记住，+ 前缀表明这个词必须存在。）只有同时出现 Quick 和 fox 的文档才满足这个查询条件，但是第一个文档包含 quick fox ，第二个文档包含 Quick foxes 。

我们的用户可以合理的期望两个文档与查询匹配。我们可以做的更好。

如果我们将词条规范为标准模式，那么我们可以找到与用户搜索的词条不完全一致，但具有足够相关性的文档。例如：

• Quick 可以小写化为 quick 。
• foxes 可以 词干提取 --变为词根的格式-- 为 fox 。类似的， dogs 可以为提取为 dog 。

• jumped 和 leap 是同义词，可以索引为相同的单词 jump 。

现在索引看上去像这样：

Term      Doc_1  Doc_2

-------------------------

brown   |   X   |  X

dog     |   X   |  X

fox     |   X   |  X

in      |       |  X

jump    |   X   |  X

lazy    |   X   |  X

over    |   X   |  X

quick   |   X   |  X

summer  |       |  X

the     |   X   |  X

------------------------

这还远远不够。我们搜索 +Quick +fox 仍然 会失败，因为在我们的索引中，已经没有 Quick 了。但是，如果我们对搜索的字符串使用与 content 域相同的标准化规则，会变成查询 +quick +fox ，这样两个文档都会匹配！

这非常重要。你只能搜索在索引中出现的词条，所以索引文本和查询字符串必须标准化为相同的格式。

分词和标准化的过程称为 分析 ， 我们会在下个章节讨论。

c.分析与分析器

分析 包含下面的过程：

• 首先，将一块文本分成适合于倒排索引的独立的 词条 ，
• 之后，将这些词条统一化为标准格式以提高它们的“可搜索性”，或者 recall

分析器执行上面的工作。 分析器 实际上是将三个功能封装到了一个包里：

字符过滤器：首先，字符串按顺序通过每个 字符过滤器 。他们的任务是在分词前整理字符串。一个字符过滤器可以用来去掉HTML，或者将 & 转化成 and。

分词器：其次，字符串被 分词器 分为单个的词条。一个简单的分词器遇到空格和标点的时候，可能会将文本拆分成词条。

Token 过滤器：最后，词条按顺序通过每个 token 过滤器 。这个过程可能会改变词条（例如，小写化 Quick ），删除词条（例如， 像 a， and， the 等无用词），或者增加词条（例如，像 jump 和 leap 这种同义词）。

Elasticsearch提供了开箱即用的字符过滤器、分词器和token 过滤器。 这些可以组合起来形成自定义的分析器以用于不同的目的。我们会在 自定义分析器 章节详细讨论。

内置分析器：

"Set the shape to semi-transparent by calling set_trans(5)"

标准分析器

标准分析器是Elasticsearch默认使用的分析器。它是分析各种语言文本最常用的选择。它根据 Unicode 联盟 定义的 单词边界 划分文本。删除绝大部分标点。最后，将词条小写。它会产生

set, the, shape, to, semi, transparent, by, calling, set_trans, 5

简单分析器

简单分析器在任何不是字母的地方分隔文本，将词条小写。它会产生

set, the, shape, to, semi, transparent, by, calling, set, trans

空格分析器

空格分析器在空格的地方划分文本。它会产生

Set, the, shape, to, semi-transparent, by, calling, set_trans(5)

语言分析器

特定语言分析器可用于 很多语言。它们可以考虑指定语言的特点。例如， 英语 分析器附带了一组英语无用词（常用单词，例如 and 或者 the ，它们对相关性没有多少影响），它们会被删除。 由于理解英语语法的规则，这个分词器可以提取英语单词的 词干 。

英语 分词器会产生下面的词条：

set, shape, semi, transpar, call, set_tran, 5

注意看 transparent、 calling 和 set_trans 已经变为词根格式。

测试分析器

GET /_analyze

{

  "analyzer": "standard",

  "text": "Text to analyze"

}

指定分析器

当Elasticsearch在你的文档中检测到一个新的字符串域，它会自动设置其为一个全文 字符串 域，使用 标准 分析器对它进行分析。

你不希望总是这样。可能你想使用一个不同的分析器，适用于你的数据使用的语言。有时候你想要一个字符串域就是一个字符串域—不使用分析，直接索引你传入的精确值，例如用户ID或者一个内部的状态域或标签。

要做到这一点，我们必须手动指定这些域的映射。

d.映射

为了能够将时间域视为时间，数字域视为数字，字符串域视为全文或精确值字符串， Elasticsearch 需要知道每个域中数据的类型。这个信息包含在映射中。

如 数据输入和输出 中解释的，索引中每个文档都有 类型 。每种类型都有它自己的 映射 ，或者 模式定义 。映射定义了类型中的域，每个域的数据类型，以及Elasticsearch如何处理这些域。映射也用于配置与类型有关的元数据。

我们会在 类型和映射 详细讨论映射。本节，我们只讨论足够让你入门的内容。

核心简单域类型

Elasticsearch 支持如下简单域类型：

• 字符串: string
• 整数 : byte, short, integer, long

• 浮点数: float, double
• 布尔型: boolean

• 日期: date

域最重要的属性是 type 。对于不是 string 的域，你一般只需要设置 type ：{ "number_of_clicks": { "type": "integer" } }默认， string 类型域会被认为包含全文。就是说，它们的值在索引前，会通过一个分析器，针对于这个域的查询在搜索前也会经过一个分析器。string 域映射的两个最重要属性是 index 和 analyzer 。indexindex 属性控制怎样索引字符串。它可以是下面三个值：analyzed首先分析字符串，然后索引它。换句话说，以全文索引这个域。not_analyzed  索引这个域，所以它能够被搜索，但索引的是精确值。不会对它进行分析。no不索引这个域。这个域不会被搜索到。string 域 index 属性默认是 analyzed 。如果我们想映射这个字段为一个精确值，我们需要设置它为 not_analyzed ：

{

    "tag": {

        "type":     "string",

        "index":    "not_analyzed"

    }

}

analyzer

对于 analyzed 字符串域，用 analyzer 属性指定在搜索和索引时使用的分析器。默认， Elasticsearch 使用 standard 分析器， 但你可以指定一个内置的分析器替代它，例如 whitespace 、 simple 和 english：

{

    "tweet": {

        "type":     "string",

        "analyzer": "english"

    }

}

更新映射

创建指定映射

PUT /megacorp_employee

{

 "mappings":{

   "properties":{

     "name":{

       "type": "keyword",

       "index": true

     },

     "userid":{

       "type": "integer"

     },

     "age":{

       "type": "integer"

     },

     "assets":{

       "type": "double"

     },

     "birthday":{

       "type": "date"

     },

     "longbirthday":{

       "type": "long"

     },

     "isdelete":{

       "type": "boolean"

     },

     "desc":{

       "type": "text",

       "analyzer": "english"

     }

   }

 }

}

//在现有索引映射中添加新的属性，已有属性不可修改和删除

PUT /megacorp_employee/_mapping

{

 "properties" : {

   "desctwo" : {

     "type" :    "keyword"

   }

 }

}

测试映射

GET /megacorp_employee/_analyze

{

 "field": "desctwo",

 "text": "Black-cats"

}

e.复杂核心域类型

除了我们提到的简单标量数据类型， JSON 还有 null 值，数组，和对象，这些 Elasticsearch 都是支持的

对于数组，没有特殊的映射需求。任何域都可以包含0、1或者多个值，就像全文域分析得到多个词条。

这暗示 数组中所有的值必须是相同数据类型的 。你不能将日期和字符串混在一起。如果你通过索引数组来创建新的域，Elasticsearch 会用数组中第一个值的数据类型作为这个域的 类型

空域

当然，数组可以为空。这相当于存在零值。 事实上，在 Lucene 中是不能存储 null 值的，所以我们认为存在 null 值的域为空域。

下面三种域被认为是空的，它们将不会被索引：

"null_value":               null,

"empty_array":              [],

"array_with_null_value":    [ null ]

多层级对象

我们讨论的最后一个 JSON 原生数据类是 对象 -- 在其他语言中称为哈希，哈希 map，字典或者关联数组

对象映射---object

PUT /megacorp_employee/_mapping

{

 "properties" : {

   "descthree" : {

     "type" :    "object",

     "properties":{

       "aaa":{

         "type":"keyword"

       },

       "bbbb":{

         "type":"integer"

       }

     }

   }

 }

}

对象如何被索引

{

    "tweet":            [elasticsearch, flexible, very],

    "user.id":          [@johnsmith],

    "user.gender":      [male],

    "user.age":         [26],

    "user.name.full":   [john, smith],

    "user.name.first":  [john],

    "user.name.last":   [smith]

}

内部对象数组

最后，考虑包含内部对象的数组是如何被索引的。 假设我们有个 followers 数组：

{

    "followers": [

        { "age": 35, "name": "Mary White"},

        { "age": 26, "name": "Alex Jones"},

        { "age": 19, "name": "Lisa Smith"}

    ]

}

这个文档会像我们之前描述的那样被扁平化处理，结果如下所示：

{

    "followers.age":    [19, 26, 35],

    "followers.name":   [alex, jones, lisa, smith, mary, white]

}

{age: 35} 和 {name: Mary White} 之间的相关性已经丢失了，因为每个多值域只是一包无序的值，而不是有序数组。这足以让我们问，“有一个26岁的追随者？”

但是我们不能得到一个准确的答案：“是否有一个26岁 名字叫 Alex Jones 的追随者？”

相关内部对象被称为 nested 对象，可以回答上面的查询，我们稍后会在嵌套对象中介绍它。

2.请求体查询

a.查询与过滤

查询有评分机制，过滤没有评分机制，性能上过滤性能会更高，相关性上需要选择查询

Elasticsearch 使用的查询语言（DSL）拥有一套查询组件，这些组件可以以无限组合的方式进行搭配。这套组件可以在以下两种情况下使用：过滤情况（filtering context）和查询情况（query context）。

当使用于 过滤情况 时，查询被设置成一个“不评分”或者“过滤”查询。即，这个查询只是简单的问一个问题：“这篇文档是否匹配？”。回答也是非常的简单，yes 或者 no ，二者必居其一。

• created 时间是否在 2013 与 2014 这个区间？
• status 字段是否包含 published 这个单词？

• lat_lon 字段表示的位置是否在指定点的 10km 范围内？

当使用于 查询情况 时，查询就变成了一个“评分”的查询。和不评分的查询类似，也要去判断这个文档是否匹配，同时它还需要判断这个文档匹配的有 多好（匹配程度如何）。 此查询的典型用法是用于查找以下文档：

• 查找与 full text search 这个词语最佳匹配的文档
• 包含 run 这个词，也能匹配 runs 、 running 、 jog 或者 sprint

• 包含 quick 、 brown 和 fox 这几个词 — 词之间离的越近，文档相关性越高
• 标有 lucene 、 search 或者 java 标签 — 标签越多，相关性越高

一个评分查询计算每一个文档与此查询的 相关程度，同时将这个相关程度分配给表示相关性的字段 _score，并且按照相关性对匹配到的文档进行排序。这种相关性的概念是非常适合全文搜索的情况，因为全文搜索几乎没有完全 “正确” 的答案。

过滤查询（Filtering queries）只是简单的检查包含或者排除，这就使得计算起来非常快。考虑到至少有一个过滤查询（filtering query）的结果是 “稀少的”（很少匹配的文档），并且经常使用不评分查询（non-scoring queries），结果会被缓存到内存中以便快速读取，所以有各种各样的手段来优化查询结果。

相反，评分查询（scoring queries）不仅仅要找出匹配的文档，还要计算每个匹配文档的相关性，计算相关性使得它们比不评分查询费力的多。同时，查询结果并不缓存。

多亏倒排索引（inverted index），一个简单的评分查询在匹配少量文档时可能与一个涵盖百万文档的filter表现的一样好，甚至会更好。但是在一般情况下，一个filter 会比一个评分的query性能更优异，并且每次都表现的很稳定。

过滤（filtering）的目标是减少那些需要通过评分查询（scoring queries）进行检查的文档

通常的规则是，使用查询（query）语句来进行 全文 搜索或者其它任何需要影响 相关性得分 的搜索。除此以外的情况都使用过滤（filters)。

b.最重要的查询

match_all 查询

match_all 查询简单的匹配所有文档。

{ "match_all": {}}

match 查询

无论你在任何字段上进行的是全文搜索还是精确查询，match 查询是你可用的标准查询

如果你在一个全文字段上使用 match 查询，在执行查询前，它将用正确的分析器去分析查询字符串：

{ "match": { "tweet": "About Search" }}

如果在一个精确值的字段上使用它，例如数字、日期、布尔或者一个 not_analyzed 字符串字段，那么它将会精确匹配给定的值

{ "match": { "age":    26           }}

{ "match": { "date":   "2014-09-01" }}

{ "match": { "public": true         }}

{ "match": { "tag":    "full_text"  }}

multi_match 查询

multi_match 查询可以在多个字段上执行相同的 match 查询

{

    "multi_match": {

        "query":    "full text search",

        "fields":   [ "title", "body" ]

    }

}

range 查询

range 查询找出那些落在指定区间内的数字或者时间

{

    "range": {

        "age": {

            "gte":  20,

            "lt":   30

        }

    }

}

gt大于gte大于等于lt小于lte小于等于

term 查询

term 查询被用于精确值匹配，这些精确值可能是数字、时间、布尔或者那些 not_analyzed 的字符串

{ "term": { "age":    26           }}

{ "term": { "date":   "2014-09-01" }}

{ "term": { "public": true         }}

{ "term": { "tag":    "full_text"  }}

terms 查询

terms 查询和 term 查询一样，但它允许你指定多值进行匹配。如果这个字段包含了指定值中的任何一个值，那么这个文档满足条件

{ "terms": { "tag": [ "search", "full_text", "nosql" ] }}

exists 查询和 missing 查询

exists 查询和 missing 查询被用于查找那些指定字段中有值 (exists) 或无值 (missing) 的文档。这与SQL中的 IS_NULL (missing) 和 NOT IS_NULL (exists) 在本质上具有共性

{

    "exists":   {

        "field":    "title"

    }

}

c.组合多查询

你可以用 bool 查询来实现你的需求。这种查询将多查询组合在一起，成为用户自己想要的布尔查询。它接收以下参数：

must文档 必须 匹配这些条件才能被包含进来。

must_not文档 必须不 匹配这些条件才能被包含进来。

should如果满足这些语句中的任意语句，将增加 _score ，否则，无任何影响。它们主要用于修正每个文档的相关性得分。

filter必须 匹配，但它以不评分、过滤模式来进行。这些语句对评分没有贡献，只是根据过滤标准来排除或包含文档。

如果没有 must 语句，那么至少需要能够匹配其中的一条 should 语句。但，如果存在至少一条 must 语句，则对 should 语句的匹配没有要求。

组合查询默认多个查询规则之间是并且的关系

{

    "bool": {

        "must":     { "match": { "title": "how to make millions" }},

        "must_not": { "match": { "tag":   "spam" }},

        "should": [

            { "match": { "tag": "starred" }}

        ],

        "filter": {

          "bool": {

              "must": [

                  { "range": { "date": { "gte": "2014-01-01" }}},

                  { "range": { "price": { "lte": 29.99 }}}

              ],

              "must_not": [

                  { "term": { "category": "ebooks" }}

              ]

          }

        }

    }

}

constant_score 查询

尽管没有 bool 查询使用这么频繁，constant_score 查询也是你工具箱里有用的查询工具。它将一个不变的常量评分应用于所有匹配的文档。它被经常用于你只需要执行一个 filter 而没有其它查询（例如，评分查询）的情况下。

可以使用它来取代只有 filter 语句的 bool 查询。在性能上是完全相同的，但对于提高查询简洁性和清晰度有很大帮助。

{

    "constant_score":   {

        "filter": {

            "term": { "category": "ebooks" }

        }

    }

}

d.验证查询

//错误的查询

GET /megacorp_employee/_validate/query?explain

{

  "query": {

     "desc" : {

        "match" : "really powerful"

     }

  }

}

3.排序与相关性

a.排序

es默认是以_score进行降序排序的

按照字段的值排序

在这个案例中，通过时间来对 tweets 进行排序是有意义的，最新的 tweets 排在最前。 我们可以使用 sort 参数进行实现：

GET /_search

{

    "query" : {

        "bool" : {

            "filter" : { "term" : { "user_id" : 1 }}

        }

    },

    "sort": { "date": { "order": "desc" }}

}

多级排序

假定我们想要结合使用 date 和 _score 进行查询，并且匹配的结果首先按照日期排序，然后按照相关性排序：

GET /_search

{

    "query" : {

        "bool" : {

            "must":   { "match": { "tweet": "manage text search" }},

            "filter" : { "term" : { "user_id" : 2 }}

        }

    },

    "sort": [

        { "date":   { "order": "desc" }},

        { "_score": { "order": "desc" }}

    ]

}

多值字段的排序

一种情形是字段有多个值的排序， 需要记住这些值并没有固有的顺序；一个多值的字段仅仅是多个值的包装，这时应该选择哪个进行排序呢？

对于数字或日期，你可以将多值字段减为单值，这可以通过使用 min 、 max 、 avg 或是 sum 排序模式 。 例如你可以按照每个 date 字段中的最早日期进行排序，通过以下方法：

"sort": {

    "dates": {

        "order": "asc",

        "mode":  "min"

    }

}

字符串排序与多字段

被解析的字符串字段也是多值字段， 但是很少会按照你想要的方式进行排序。如果你想分析一个字符串，如 fine old art ， 这包含 3 项。我们很可能想要按第一项的字母排序，然后按第二项的字母排序，诸如此类，但是 Elasticsearch 在排序过程中没有这样的信息。

映射的时候对text做子集处理

"tweet": {

    "type":     "text",

    "analyzer": "english",

    "fields": {

        "raw": {

            "type":  "text",

            "index": "not_analyzed"

        }

    }

}

GET /_search

{

    "query": {

        "match": {

            "tweet": "elasticsearch"

        }

    },

    "sort": "tweet.raw"

}

4.执行分布式检索

游标查询 Scroll

scroll 查询 可以用来对 Elasticsearch 有效地执行大批量的文档查询，而又不用付出深度分页那种代价。

游标查询允许我们 先做查询初始化，然后再批量地拉取结果。 这有点儿像传统数据库中的 cursor 。

游标查询会取某个时间点的快照数据。 查询初始化之后索引上的任何变化会被它忽略。 它通过保存旧的数据文件来实现这个特性，结果就像保留初始化时的索引 视图 一样。

深度分页的代价根源是结果集全局排序，如果去掉全局排序的特性的话查询结果的成本就会很低。 游标查询用字段 _doc 来排序。 这个指令让 Elasticsearch 仅仅从还有结果的分片返回下一批结果。

启用游标查询可以通过在查询的时候设置参数 scroll 的值为我们期望的游标查询的过期时间。 游标查询的过期时间会在每次做查询的时候刷新，所以这个时间只需要足够处理当前批的结果就可以了，而不是处理查询结果的所有文档的所需时间。 这个过期时间的参数很重要，因为保持这个游标查询窗口需要消耗资源，所以我们期望如果不再需要维护这种资源就该早点儿释放掉。 设置这个超时能够让 Elasticsearch 在稍后空闲的时候自动释放这部分资源。

GET /old_index/_search?scroll=1m

{

    "query": { "match_all": {}},

    "sort" : ["_doc"],

    "size":  1000

}

这个游标查询返回的下一批结果。 尽管我们指定字段 size 的值为1000，我们有可能取到超过这个值数量的文档。 当查询的时候， 字段 size 作用于单个分片，所以每个批次实际返回的文档数量最大为 size * number_of_primary_shards 。