类型和映射

类型 在 Elasticsearch 中表示一组相似的文档。类型 由一个 名称（比如 user 或 blogpost）和一个类似数据库表结构的映射组成，描述了文档中可能包含的每个字段的 属性，数据类型（比如 string, integer 或 date），和是否这些字段需要被 Lucene 索引或储存。

在【文档】一章中，我们说过类型类似关系型数据库中的表格，一开始你可以这样做类比，但是现在值得更深入阐释一下什么是类型，且在 Lucene 中是怎么实现的。

Lucene 如何处理文档

Lucene 中，一个文档由一组简单的键值对组成，一个字段至少需要有一个值，但是任何字段都可以有多个值。类似的，一个单独的字符串可能在分析过程中被转换成多个值。Lucene 不关心这些值是字符串，数字或日期，所有的值都被当成 不透明字节

当我们在 Lucene 中索引一个文档时，每个字段的值都被加到相关字段的倒排索引中。你也可以选择将原始数据 储存 起来以备今后取回。

类型是怎么实现的

Elasticsearch 类型是在这个简单基础上实现的。一个索引可能包含多个类型，每个类型有各自的映射和文档，保存在同一个索引中。

因为 Lucene 没有文档类型的概念，每个文档的类型名被储存在一个叫 _type 的元数据字段上。当我们搜索一种特殊类型的文档时，Elasticsearch 简单的通过 _type 字段来过滤出这些文档。

Lucene 同样没有映射的概念。映射是 Elasticsearch 将复杂 JSON 文档映射成 Lucene 需要的扁平化数据的方式。

例如，user 类型中 name 字段的映射声明这个字段是一个 string 类型，在被加入倒排索引之前，它的数据需要通过 whitespace 分析器来分析。

"name": {
    "type":     "string",
    "analyzer": "whitespace"
}

预防类型陷阱

事实上不同类型的文档可以被加到同一个索引里带来了一些预想不到的困难。

想象一下我们的索引中有两种类型：blog_en 表示英语版的博客，blog_es 表示西班牙语版的博客。两种类型都有 title 字段，但是其中一种类型使用 english 分析器，另一种使用 spanish 分析器。

使用下面的查询就会遇到问题：

GET /_search
{
    "query": {
        "match": {
            "title": "The quick brown fox"
        }
    }
}

我们在两种类型中搜索 title 字段，首先需要分析查询语句，但是应该使用哪种分析器呢，spanish 还是 english？Elasticsearch 会采用第一个被找到的 title 字段使用的分析器，这对于这个字段的文档来说是正确的，但对另一个来说却是错误的。

我们可以通过给字段取不同的名字来避免这种错误 —— 比如，用 title_en 和 title_es。或者在查询中明确包含各自的类型名。

GET /_search
{
    "query": {
        "multi_match": { <1>
            "query":    "The quick brown fox",
            "fields": [ "blog_en.title", "blog_es.title" ]
        }
    }
}

<1> multi_match 查询在多个字段上执行 match 查询并一起返回结果。

新的查询中 english 分析器用于 blog_en.title 字段，spanish 分析器用于 blog_es.title 字段，然后通过综合得分组合两种字段的结果。

这种办法对具有相同数据类型的字段有帮助，但是想象一下如果你将下面两个文档加入同一个索引，会发生什么：

• 类型: user

 { "login": "john_smith" }

• 类型: event

 { "login": "2014-06-01" }

Lucene 不在乎一个字段是字符串而另一个字段是日期，它会一视同仁的索引这两个字段。

然而，假如我们试图 排序 event.login 字段，Elasticsearch 需要将 login 字段的值加载到内存中。像我们在 【字段数据介绍】中提到的，它将 任意文档 的值加入索引而不管它们的类型。

它会尝试加载这些值为字符串或日期，取决于它遇到的第一个 login 字段。这可能会导致预想不到的结果或者以失败告终。

提示：为了保证你不会遇到这些冲突，建议在同一个索引的每一个类型中，确保用同样的方式映射同名的字段