略微加速

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

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

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

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

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

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

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

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

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

在 轻量 搜索 中，我们介绍了 _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" }
    }
}

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

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

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