elasticsearch-06映射和分析

最新推荐文章于 2024-01-21 03:38:19 发布

疯狂攻城师

最新推荐文章于 2024-01-21 03:38:19 发布

阅读量146

点赞数

分类专栏： elasticsearch 文章标签： elasticsearch 大数据 big data

本文链接：https://blog.csdn.net/lijunliang2017/article/details/122524059

版权

elasticsearch 专栏收录该内容

8 篇文章 0 订阅

订阅专栏

1、简述

当摆弄索引里面的数据时，我们发现一些奇怪的事情。一些事情看起来被打乱了：在我们的索引中有12条推文，其中只有一条包含日期 2014-09-15 ，但是看一看下面查询命中的 总数 （total）：

GET /_search?q=2014              # 12 results
GET /_search?q=2014-09-15        # 12 results !
GET /_search?q=date:2014-09-15   # 1  result
GET /_search?q=date:2014         # 0  results !

为什么在 _all 字段查询日期返回所有推文，而在 date 字段只查询年份却没有返回结果？为什么我们在 _all 字段和 date 字段的查询结果有差别？

推测起来，这是因为数据在 _all 字段与 date 字段的索引方式不同。所以，通过请求 gb 索引中 tweet 类型的映射（或模式定义），让我们看一看 Elasticsearch 是如何解释我们文档结构的：

GET /gb/_mapping/tweet

{
   "gb": {
      "mappings": {
         "tweet": {
            "properties": {
               "date": {
                  "type": "date",
                  "format": "strict_date_optional_time||epoch_millis"
               },
               "name": {
                  "type": "string"
               },
               "tweet": {
                  "type": "string"
               },
               "user_id": {
                  "type": "long"
               }
            }
         }
      }
   }
}

基于对字段类型的猜测， Elasticsearch 动态为我们产生了一个映射。这个响应告诉我们 date 字段被认为是 date 类型的。由于 _all 是默认字段，所以没有提及它。但是我们知道 _all 字段是 string 类型的。

所以 date 字段和 string 字段索引方式不同，因此搜索结果也不一样。这完全不令人吃惊。你可能会认为核心数据类型 strings、numbers、Booleans 和 dates 的索引方式有稍许不同。没错，他们确实稍有不同。

但是，到目前为止，最大的差异在于代表 精确值 （它包括 string 字段）的字段和代表全文的字段。这个区别非常重要——它将搜索引擎和所有其他数据库区别开来。

2、精确值vs全文

Elasticsearch 中的数据可以概括的分为两类：精确值和全文。

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

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

全文通常是指非结构化的数据，但这里有一个误解：自然语言是高度结构化的。问题在于自然语言的规则是复杂的，导致计算机难以正确解析。例如，考虑这条语句：
May is fun but June bores me.
它指的是月份还是人？

精确值很容易查询。结果是二进制的：要么匹配查询，要么不匹配。这种查询很容易用 SQL 表示：

WHERE name    = "John Smith"
  AND user_id = 2
  AND date    > "2014-09-15"

查询全文数据要微妙的多。我们问的不只是“这个文档匹配查询吗”，而是“该文档匹配查询的程度有多大？”换句话说，该文档与给定查询的相关性如何？

我们很少对全文类型的域做精确匹配。相反，我们希望在文本类型的域中搜索。不仅如此，我们还希望搜索能够理解我们的意图：

搜索 UK ，会返回包含 United Kindom 的文档。

搜索 jump ，会匹配 jumped ， jumps ， jumping ，甚至是 leap 。
搜索 johnny walker 会匹配 Johnnie Walker ， johnnie depp 应该匹配 Johnny Depp 。
fox news hunting 应该返回福克斯新闻（ Foxs News ）中关于狩猎的故事，同时， fox hunting news 应该返回关于猎狐的故事

为了促进这类在全文域中的查询，Elasticsearch 首先分析文档，之后根据结果创建 倒排索引 。在接下来的两节，我们会讨论倒排索引和分析过程。

3、倒排索引

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

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

The quick brown fox jumped over the lazy dog
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 ，这样两个文档都会匹配！

4、分析与分析器

分析包含下面的过程：

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

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

字符过滤器

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

分词器

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

Token 过滤器

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

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

内置分析器

但是， Elasticsearch还附带了可以直接使用的预包装的分析器。接下来我们会列出最重要的分析器。为了证明它们的差异，我们看看每个分析器会从下面的字符串得到哪些词条：

"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 已经变为词根格式。

什么时候使用分析器

当我们索引一个文档，它的全文域被分析成词条以用来创建倒排索引。但是，当我们在全文域搜索的时候，我们需要将查询字符串通过 相同的分析过程 ，以保证我们搜索的词条格式与索引中的词条格式一致。

全文查询，理解每个域是如何定义的，因此它们可以做正确的事：

当你查询一个全文域时，会对查询字符串应用相同的分析器，以产生正确的搜索词条列表。
当你查询一个 精确值 域时，不会分析查询字符串，而是搜索你指定的精确值。

现在你可以理解在开始章节的查询为什么返回那样的结果：

date 域包含一个精确值：单独的词条 2014-09-15。
_all 域是一个全文域，所以分词进程将日期转化为三个词条： 2014， 09，和 15。

当我们在 _all 域查询 2014，它匹配所有的12条推文，因为它们都含有 2014 ：

GET /_search?q=2014              # 12 results

拷贝为 curl在 Sense 中查看

当我们在 _all 域查询 2014-09-15，它首先分析查询字符串，产生匹配 2014， 09，或 15 中任意词条的查询。这也会匹配所有12条推文，因为它们都含有 2014 ：

GET /_search?q=2014-09-15        # 12 results !

拷贝为 curl在 Sense 中查看

当我们在 date 域查询 2014-09-15，它寻找精确日期，只找到一个推文：

GET /_search?q=date:2014-09-15   # 1  result

拷贝为 curl在 Sense 中查看

当我们在 date 域查询 2014，它找不到任何文档，因为没有文档含有这个精确日志：

GET /_search?q=date:2014         # 0  results !

拷贝为 curl在 Sense 中查看

测试分析器

有些时候很难理解分词的过程和实际被存储到索引中的词条，特别是你刚接触Elasticsearch。为了理解发生了什么，你可以使用 analyze API 来看文本是如何被分析的。在消息体里，指定分析器和要分析的文本：

GET /_analyze
{
  "analyzer": "standard",
  "text": "Text to analyze"
}

拷贝为 curl在 Sense 中查看

结果中每个元素代表一个单独的词条：

{
   "tokens": [
      {
         "token":        "text",
         "start_offset": 0,
         "end_offset":   4,
         "type":         "<ALPHANUM>",
         "position":     1
      },
      {
         "token":        "to",
         "start_offset": 5,
         "end_offset":   7,
         "type":         "<ALPHANUM>",
         "position":     2
      },
      {
         "token":        "analyze",
         "start_offset": 8,
         "end_offset":   15,
         "type":         "<ALPHANUM>",
         "position":     3
      }
   ]
}

token 是实际存储到索引中的词条。 position 指明词条在原始文本中出现的位置。 start_offset 和 end_offset 指明字符在原始字符串中的位置。

每个分析器的 type 值都不一样，可以忽略它们。它们在Elasticsearch中的唯一作用在于keep_types token 过滤器。

analyze API 是一个有用的工具，它有助于我们理解Elasticsearch索引内部发生了什么，随着深入，我们会进一步讨论它。