根对象 | Elasticsearch: 权威指南 | Elastic

根对象编辑

映射的最高一层被称为 根对象 ，它可能包含下面几项：

• 一个 properties 节点，列出了文档中可能包含的每个字段的映射
• 各种元数据字段，它们都以一个下划线开头，例如 _type 、 _id 和 _source
• 设置项，控制如何动态处理新的字段，例如 analyzer 、 dynamic_date_formats 和 dynamic_templates
• 其他设置，可以同时应用在根对象和其他 object 类型的字段上，例如 enabled 、 dynamic 和 include_in_all

属性编辑

我们已经在 核心简单域类型 和 复杂核心域类型 章节中介绍过文档字段和属性的三个 最重要的设置：

type

字段的数据类型，例如 string 或 date

index

字段是否应当被当成全文来搜索（ analyzed ），或被当成一个准确的值（ not_analyzed ），还是完全不可被搜索（ no ）

analyzer

确定在索引和搜索时全文字段使用的 analyzer

我们将在本书的后续部分讨论其他字段类型，例如 ip 、 geo_point 和 geo_shape 。

元数据: _source 字段编辑

默认地，Elasticsearch 在 _source 字段存储代表文档体的JSON字符串。和所有被存储的字段一样， _source 字段在被写入磁盘之前先会被压缩。

这个字段的存储几乎总是我们想要的，因为它意味着下面的这些：

• 搜索结果包括了整个可用的文档——不需要额外的从另一个的数据仓库来取文档。
• 如果没有 _source 字段，部分 update 请求不会生效。
• 当你的映射改变时，你需要重新索引你的数据，有了_source字段你可以直接从Elasticsearch这样做，而不必从另一个（通常是速度更慢的）数据仓库取回你的所有文档。
• 当你不需要看到整个文档时，单个字段可以从 _source 字段提取和通过 get 或者 search 请求返回。
• 调试查询语句更加简单，因为你可以直接看到每个文档包括什么，而不是从一列id猜测它们的内容。

然而，存储 _source 字段的确要使用磁盘空间。如果上面的原因对你来说没有一个是重要的，你可以用下面的映射禁用 _source 字段：

PUT /my_index
{
    "mappings": {
        "my_type": {
            "_source": {
                "enabled":  false
            }
        }
    }
}

在一个搜索请求里，你可以通过在请求体中指定 _source 参数，来达到只获取特定的字段的效果：

GET /_search
{
    "query":   { "match_all": {}},
    "_source": [ "title", "created" ]
}

这些字段的值会从 _source 字段被提取和返回，而不是返回整个 _source 。

Stored Fields 被存储字段

为了之后的检索，除了索引一个字段的值，你 还可以选择 存储 原始字段值。有 Lucene 使用背景的用户使用被存储字段来选择他们想要在搜索结果里面返回的字段。事实上， _source 字段就是一个被存储的字段。

在Elasticsearch中，对文档的个别字段设置存储的做法通常不是最优的。整个文档已经被存储为 _source 字段。使用 _source 参数提取你需要的字段总是更好的。

元数据: _all 字段编辑

在 轻量 搜索 中，我们介绍了 _all 字段：一个把其它字段值 当作一个大字符串来索引的特殊字段。 query_string 查询子句(搜索 ?q=john )在没有指定字段时默认使用 _all 字段。

_all 字段在新应用的探索阶段，当你还不清楚文档的最终结构时是比较有用的。你可以使用这个字段来做任何查询，并且有很大可能找到需要的文档：

GET /_search
{
    "match": {
        "_all": "john smith marketing"
    }
}

随着应用的发展，搜索需求变得更加明确，你会发现自己越来越少使用 _all 字段。 _all 字段是搜索的应急之策。通过查询指定字段，你的查询更加灵活、强大，你也可以对相关性最高的搜索结果进行更细粒度的控制。

relevance algorithm 考虑的一个最重要的原则是字段的长度：字段越短越重要。 在较短的 title 字段中出现的短语可能比在较长的 content 字段中出现的短语更加重要。字段长度的区别在 _all 字段中不会出现。

如果你不再需要 _all 字段，你可以通过下面的映射来禁用：

PUT /my_index/_mapping/my_type
{
    "my_type": {
        "_all": { "enabled": false }
    }
}

通过 include_in_all 设置来逐个控制字段是否要包含在 _all 字段中，默认值是 true`。在一个对象(或根对象)上设置 `include_in_all 可以修改这个对象中的所有字段的默认行为。

你可能想要保留 _all 字段作为一个只包含某些特定字段的全文字段，例如只包含 title`，`overview`，`summary 和 tags`。 相对于完全禁用 `_all 字段，你可以为所有字段默认禁用 include_in_all 选项，仅在你选择的字段上启用：

PUT /my_index/my_type/_mapping
{
    "my_type": {
        "include_in_all": false,
        "properties": {
            "title": {
                "type":           "string",
                "include_in_all": true
            },
            ...
        }
    }
}

记住，_all 字段仅仅是一个 经过分词的 string 字段。它使用默认分词器来分析它的值，不管这个值原本所在字段指定的分词器。就像所有 string 字段，你可以配置 _all 字段使用的分词器：

PUT /my_index/my_type/_mapping
{
    "my_type": {
        "_all": { "analyzer": "whitespace" }
    }
}

元数据：文档标识编辑

文档标识与四个元数据字段 相关：

_id

文档的 ID 字符串

_type

文档的类型名

_index

文档所在的索引

_uid

_type 和 _id 连接在一起构造成 type#id

默认情况下， _uid 字段是被存储（可取回）和索引（可搜索）的。 _type 字段被索引但是没有存储， _id 和 _index 字段则既没有被索引也没有被存储，这意味着它们并不是真实存在的。

尽管如此，你仍然可以像真实字段一样查询 _id 字段。Elasticsearch 使用 _uid 字段来派生出 _id 。 虽然你可以修改这些字段的 index 和 store 设置，但是基本上不需要这么做。

Getting Started Videos

• Starting Elasticsearch
• Introduction to Kibana
• Logstash Starter Guide