elasticsearch之mapping field

Mapping定义了文档是如何被处理并存储在搜索引擎中的，包括可搜索的特点，比如哪些字段是可以被搜索的，字段是否被处理过，如何处理的等方面。es中，可以把文档分在不同的mapping type下。允许多个mapping的定义关联到一个mapping type。

显式的mapping可以定义在index级别或者是type级别。默认情况下，是不需要一个显式的mapping定义的，因为当一个新的type或者field出现并注册到索引的时候，会自动生成对应的mapping，并且设置了合理的默认值，这并不会对es造成什么负载。只有当默认的取值无法满足我们的要求，需要被覆盖的情况下才需要显式的声明一个mapping。

mapping types：是一个逻辑概念，把index中的文档按照不同的type进行逻辑上的分组。类似于数据库中表的概念。尽管types之间是分开的，但并不是完全的分离（最终都会成为同一个索引中的文档）。不同type中的同名的字段名称强烈推荐使用同样的mapping设置（数据类型，分析类型等）。现在es正在努力做到可以通过type.field的形式来选择字段，不过现在还没有完成，有些功能还支持不到（比如facet on the field）。其实，在实际应用中，这几乎不是什么问题。字段名横一般都是带有预示type含义的，比如first_name一般都是string类型。同样应该注意的是：并不适合cross
index case。

mapping api：创建mapping使用 put mapping api。在创建索引过程中可以创建多个mapping

global setting：index.mapping.ignore_malformat这个全局的设定可以应用在index级别上，允许在所有type中忽略mapping的异常信息，比如对一个数字类型应用了一个字符串；

index.mapping.coerce这个全局设定迫使各种看似合法的转换，默认是true，比如数字类型的字段索引了一个字符，带有小数的数字类型在mapping的int/long等的字段的时候会把小数部分去掉。当这种尝试转换失败的情况下，这个数字就当成了异常值，接下来的处理就参照index.mapping.ignore_malformat的设置了。

每一个mapping都有一些列的字段信息，来确定文档的metadata是如何被索引的

_uid：文档会关联到一个type和一个id。内部的_uid字段是文档的唯一标识，由type和id字段组成（这意味着不同的type可以有相同的id）。当type没有被索引并要求执行基于type的过滤时候，_uid字段会自动被使用，并不要求_id一定被索引。

_id：默认_id字段是不被索引也不被存储，当然可以修改mapping来存储并索引_id字段。即使_id字段没有被索引，所有的api仍然可以正常工作（利用_uid字段），即使是要求用id来返回的api，比如term/terms/prefix query(ids query也可以)。_id字段可以从source字段中提取：

{
    "tweet" : {
        "_id" : {
            "path" : "post_id"
        }
    }
}

下边这个doc将使用id=1

{
    "message" : "You know, for Search",
    "post_id" : "1"
}

当然这样会有额外的代价，因为需要提取id字段来决定放在哪一个shard上。

_type：索引过程中，传递的type字段会自动索引到_type这个field中去，但是not_analyzed and not store（同上，可以更改mapping）。这意味着你可以针对_type字段进行查询。

_source：_source字段是自动产生的字段，用来存储文档完整的json信息。not indexed but stored。当执行fetch操作时，该字段内容会自动返回。显然该字段会增加索引的存储空间，当这成为一个瓶颈的时候，可以禁用source。

{
    "tweet" : {
        "_source" : {"enabled" : false}
    }
}

_source存储的时候，可以指定包含哪些字段，排除哪些字段。

{
    "my_type" : {
        "_source" : {
            "includes" : ["path1.*", "path2.*"],
            "excludes" : ["path3.*"]
        }
    }
}

_all：_all字段包含一个或者多个其他字段（把这些字段的值统统作为一个大的string来索引）。当我们想在整个文档内容中进行查询，而不知道具体应该查询哪个field的时候，_all字段十分方便。当然该字段也是以增加cpu周期和索引大小为代价的。默认情况下，所有字段都会包含在_all字段中。也可以修改mapping来决定是否禁用，哪些字段可以包含进来，哪些字段应该排除等等。当禁用_all的时候，最好将index.query.default_field字段设置为其他field（比如，如果索引中有一个主要字段message。）该字段的一个比较好的特性是会考虑特殊字段的boost level。也就是说如果title的boost值如果比content高，则在all字段中，title部分会比content部分高一些。_all字段也是一个字段，因此允许设置store，term_vector，analyzer等。对于有需求要highlighting的字段，要么stored要么是_source的一部分。默认情况下all字段并不能胜任以上两种情况，所以对all进行highlight不会产生任何数据。当然可以通过修改mapping来store all字段，这也仅仅是其他字段的一个简单集合而已，这也意味着冗余存储。如果对all进行高亮，则会产生诡异的结果。

_analyzer：_analyzer设置一个path属性，指定需要的分析器，可以应用在任何没有显式指定过analyzer或者index_analyzer的field上。

{
    "type1" : {
        "_analyzer" : {
            "path" : "my_field"
        }
    }
}

{
    "my_field" : "whitespace"
}

以上type1将会使用定义为whitespace的分析器。

默认情况下_analyzed字段是index的，可以在mapping中设置index：no属性。

_boost：增强document或者field的相关性。

_parent：child mapping中指定parent的字段，指向该字类型关联的父类型。该字段自动存储和索引，可以对_parent字段进行search操作。

_field_names：对document中的字段名称进行的索引，可以应用于exists and missing filter。es1.3.0版本之后，_field_names字段自动创建并索引。

_routing：指定数据的路由。routing mapping的第一件事就是存储并索引routing的值。默认情况下会自动存储routing的值，原因在于：在reindex过程中，如果routing值是外部的，并不来自于document的某一部分，那存储就有意义了。routing mapping的另一个设置项是require。在使用routing的时候，这个设置非常重要，比如在index过程中，如果设置了require为true，任何没有设置routing的index操作将会被拒绝。path属性则可以从指定位置自动提取routing的值，当然这就增加了解析的成本。如果index document指定了自定义的routing，则_id在所有该索引的shard中就不能保证唯一性了。事实上，拥有同样id的doc，如果是不同的routing的话，会存在于不同的shard中。

_index：在document中存储其所属的index，默认是disabled。可以设置为enabled，意义不大。

_size：自动索引_source的大小。默认是disabled,可以设置为enabled

_timestamp：自动索引document的时间戳。可以外部提供也可以从_source中获取（指定path参数，并且可以设置format，增加了parser的成本）。如果没有提供则自动设置为default data。默认设置是disabled状态，可以设为为enable。默认设置store为false，index为not_analyzed。因此可以当作date field来查询。

关于default date---在timestamps没有提供的情况下，可以在index请求或者在_source中设置一个默认值，默认情况下是now（document被处理的时间）。也可以将默认值选项关闭，这样就必须提供一个时间戳，否则，index将失败。

_ttl：一些文档都有过期时间。因此有了ttl的设置，过期之后文档将会自动删除掉。_ttl接受两个参数，其余设置都会被忽略。一个是enabled，默认是disabled。另一个是default，可以在索引级别或者type级别设置一个默认过期时间。如果既没有设置default，也没有给出_ttl时间，则为永远不过期数据。