Elastic Search学习系列05-映射和分析

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

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

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

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

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

现在你可以理解在前面的查询为什么返回那样的结果：

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

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

curl -X GET "localhost:9200/_analyze?pretty" -H 'Content-Type: application/json' -d'
{
  "analyzer": "standard",
  "text": "Text to analyze"
}
'

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

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

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

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

analyze API是一个有用的工具，它有助于我们理解Elasticsearch索引内部发生了什么。

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

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

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

Elasticsearch 支持如下简单域类型：

• 字符串: string
• 整数 : byte,short,integer,long
• 浮点数: float,double
• 布尔型: boolean
• 日期: date

当索引一个包含新域的文档—​之前未曾出现–Elasticsearch会使用动态映射，通过JSON中基本数据类型，尝试猜测域类型，使用如下规则：

这意味着如果你通过引号("123")索引一个数字，它会被映射为string类型，而不是long。但是，如果这个域已经映射为long，那么Elasticsearch会尝试将这个字符串转化为long ，如果无法转化，则抛出一个异常。

通过/_mapping，我们可以查看Elasticsearch在一个或多个索引中的一个或多个类型的映射。

错误的映射，例如将age域映射为string类型，而不是integer，会导致查询出现令人困惑的结果。

尽管在很多情况下基本域数据类型已经够用，但你经常需要为单独域自定义映射，特别是字符串域。自定义映射允许你执行下面的操作：

• 全文字符串域和精确值字符串域的区别
• 使用特定语言分析器
• 优化域以适应部分匹配
• 指定自定义数据格式
• 还有更多

域最重要的属性是type。对于不是string的域，你一般只需要设置type：

{
    "number_of_clicks": {
        "type": "integer"
    }
}

默认，string类型域会被认为包含全文。就是说，它们的值在索引前，会通过一个分析器，针对于这个域的查询在搜索前也会经过一个分析器。

string域映射的两个最重要属性是index和analyzer 。

index

index属性控制怎样索引字符串。它可以是下面三个值：

• 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"
    }
}

当你首次创建一个索引的时候，可以指定类型的映射。你也可以使用/_mapping为新类型（或者为存在的类型更新映射）增加映射。

尽管你可以增加一个存在的映射，你不能修改存在的域映射。如果一个域的映射已经存在，那么该域的数据可能已经被索引。如果你意图修改这个域的映射，索引的数据可能会出错，不能被正常的搜索。

我们可以更新一个映射来添加一个新域，但不能将一个存在的域从analyzed改为not_analyzed。

在tweet映射增加一个新的名为tag的not_analyzed的文本域，使用_mapping：

curl -X PUT "localhost:9200/gb/_mapping/tweet?pretty" -H 'Content-Type: application/json' -d'
{
  "properties" : {
    "tag" : {
      "type" :    "string",
      "index":    "not_analyzed"
    }
  }
}
'

注意，我们不需要再次列出所有已存在的域，因为无论如何我们都无法改变它们。新域已经被合并到存在的映射中。

你可以使用analyze API测试字符串域的映射。

很有可能，我们希望tag域包含多个标签。我们可以以数组的形式索引标签：

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

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

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

当你从Elasticsearch得到一个文档，每个数组的顺序和你当初索引文档时一样。你得到的_source域，包含与你索引的一模一样的JSON文档。

但是，数组是以多值域索引的—可以搜索，但是无序的。在搜索的时候，你不能指定“第一个”或者“最后一个”。更确切的说，把数组想象成装在袋子里的值。

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

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

"null_value":               null,
"empty_array":              [],
"array_with_null_value":    [ null ]

对于一个JSON原生数据类是对象–在其他语言中称为哈希，哈希map，字典或者关联数组。

内部对象经常用于嵌入一个实体或对象到其它对象中。例如，与其在tweet文档中包含user_name和user_id域，我们也可以这样写：

{
    "tweet":            "Elasticsearch is very flexible",
    "user": {
        "id":           "@johnsmith",
        "gender":       "male",
        "age":          26,
        "name": {
            "full":     "John Smith",
            "first":    "John",
            "last":     "Smith"
        }
    }
}

Elasticsearch会动态监测新的对象域并映射它们为 对象，在properties属性下列出内部域：

{
  "gb": {
    "tweet": { 
      "properties": {
        "tweet":            { "type": "string" },
        "user": { 
          "type":             "object",
          "properties": {
            "id":           { "type": "string" },
            "gender":       { "type": "string" },
            "age":          { "type": "long"   },
            "name":   { 
              "type":         "object",
              "properties": {
                "full":     { "type": "string" },
                "first":    { "type": "string" },
                "last":     { "type": "string" }
              }
            }
          }
        }
      }
    }
  }
}

user和name域的映射结构与tweet类型的相同。事实上，type映射只是一种特殊的对象映射，我们称之为根对象。除了它有一些文档元数据的特殊顶级域，例如_source和_all域，它和其他对象一样。

Lucene不理解内部对象。Lucene文档是由一组键值对列表组成的。为了能让Elasticsearch有效地索引内部类，它把我们的文档转化成这样：

{
    "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]
}

内部域可以通过名称引用（例如，first）。为了区分同名的两个域，我们可以使用全路径（例如，user.name.first）或type名加路径（tweet.user.name.first）。

在前面简单扁平的文档中，没有user和user.name域。Lucene索引只有标量和简单值，没有复杂数据结构。

最后，考虑包含内部对象的数组是如何被索引的。 假设我们有个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]
}