elasticsearch 2.x mapping tips 作者：杨振涛  首发于：Elasticsearch 中文社区  日期：2017-1-10 如果把elasticsearch中的mapping类比为关系型数据库中的schema的话，那么我们可能重点强调了两者之间的共性，而忽略了elasticsearch里mapping很不相同的部分 —— 这恰恰是实践中最容易被坑的地方。这里总结了几点实践中的小心得，希望对你所有帮助。 mapping 基础 创建索引库index

curl -XPOST "http://192.168.9.19:9200/vivo_vimc"

查看指定索引库的mapping:

curl -XGET "http://192.168.9.19:9200/vivo_ ... ot%3B  

PS: 这时你获得的结果为空，因为刚建的库，没有mapping信息。 创建索引类型type并指定mapping :

curl -XPOST http://192.168.9.19:9200/vivo_vmic/apps/_mapping -d '{
  "apps" : {
    "properties" : {
      "appName" : {
        "type" : "string",
        "index" : "not_analyzed",
        "fields" :{
         "cn": {
           "type"  : "string",
           "index" : "analyzed",
           "analyzer": "ik"
          },
          "en": {
           "type"  : "string",
          }
        },
        "store":"yes"
      },
      "status" : {
        "type" : "boolean"
      },
      "type" : {
        "type" : "integer"
      },
      "onsaleDate" : {
        "type" : "date"
      },
    }
  }
}'

更新mapping （只能增加字段，不能删除字段，也不能修改字段类型，或者说无法增加一个不同类型的同名字段）: 增加属性 score：

curl -XPOST "http://192.168.9.19:9200/vivo_ ... ot%3B -d '{
    "apps": {
        "properties": {
            "score":{
                "type":"float"
                }
        }
    }
}'

    更新成功会返回：

{
  "acknowledged" : true
}

删除mapping : 2.4版本开始ES已经不支持mapping的删除了。 tip1 dynamic 模式 动态mapping是ES的一个重要特性，这个配置的可选值及含义如下：

• true  ：支持动态扩展，新增数据有新的属性时，自动添加，索引成功
• false ：不支持动态扩展，新增数据有新的属性时，直接忽略，索引成功
• strict: 不支持动态扩展，新增数据有新的属性时，会报错，索引失败

tip2 主要数据类型及注意事项

• string

    分词和不分词的值都需要，中英文都需要 ，     长度截取，超长过滤 ，     大小写问题（不分词时索引数据不会转小写，搜索都会转小写）         analyzer: analyzed, not_analyzed, no（表示该属性不能用来做搜索和聚合）     properties ： .raw, .en/.cn     

• date :           如果不明确指定，那么默认的date格式是："strict_date_optional_time||epoch_millis"，这是官网的表述，意思是可以是一个字符串类型的输入，也可以是数值类型的输入，前者可以是日期或者日期加上时间，后者则是毫秒数。关于时区信息：不管业务上是否需要时区信息，我们建议依然保存，以防万一。另外，data类型在明确指定 format 参数时，也有很多坑，对于format: epoch_second, epools_millis ,如果你想用来排序，那么为了性能，我们强烈建议你使用 epoc_second，差距很大哟，你可以亲自做一个对比测试。

 

•  long, integer, short, byte, double ,float 希望此类字段参与搜索和聚合的话，就不能设置not_analyzed。

 

• boolean, binaryboolean类型比较特殊，在ES里面只定义了false类的值（ false, "false", "off", "no", "0", "" , 0, 0.0 ），其他所有都认为是true。实践中，我们建议优先使用 0（编程和性能友好），其次使用 true（兼容json默认的类型）。

 

•  ipv4 type:ip 日志分析等最常用的数据类型，注意这里的是ipv4，ipv6目前暂不支持（ES 2.x）；赋值时其实传递的是字符串，但ES内部其实保存的是一个long类型。

 

• geo type:geo_point ， type:geo_shape  LBS服务的必选数据类型，但不建议完全依赖此特性，业务层面要尽可能地缩小范围，或者在使用围栏类功能时，只要业务容忍，使用正方形代替圆形。

 

• 数组，对象，内嵌将一个复杂对象放在一个属性中，其中数组最常用。

 

• completion主要是用来做自动完成和拼写纠错的。

tip3 id设置   在不设置id的情况下，默认的ES会给一个类似HASH串的随机ID；如果业务上需要且可以保证索引数据的唯一性，也可以使用业务ID作为索引ID，好处就是可以根据业务ID轻松地GET到索引数据，而无需维护索引ID和业务ID的关系。 同时，设置mapping的时候也可以指定ID的生成策略，比如UUID：

curl -s -XPUT http://192.168.9.19:9200/vivo_vimc -d '
{
    "mappings": {
        "apps": {
            "_id": {
                "path": "uuid"
            },
            "properties": {
                "cnName": {
                    "type":   "string",
                    "index":  "analyzed"
                }
            }
        }
    }
}'

tip4 index和type规划 index的别名这个特性就不再强调了，不管是否用到，第一时间设置别名是最佳实践！ schema 比较相似的type，放在同一个index里；schema差异非常大的type，建议放在不同的index里；原因是跟搜索引擎的segment以及lucene有关，本质上同一个index里的type底层是同样的存储结构，差异越大意味着type a的属性在type b里大部分都是空值，那么最终会得到一个非常稀疏的矩阵，影响计算效率并浪费存储空间。 关于滚动index的问题，对于日志类的搜索应用，按天或其他维度做滚动index是非常好必要的，这样可以更好地区分冷热数据。比如：

index                        alias vivo_appstore_log_20160108   vivo_appstore_log_20160109  vivo_appstore_log vivo_appstore_log_20160110  vivo_appstore_log vivo_appstore_log_20160111  vivo_appstore_log ...

如果只需要查询最近3天的数据，那么只需要对3天前的index remove alias即可，然后每天循环滚动。一个细节是，对于这种场景下的索引，写入的时候必须使用原始的index name，而不能使用alias；查询的时候则使用alias。 另一个问题，就是index容量的规划，副本数直接决定需要多少冗余空间；另外，索引数据本身也会有膨胀的现象，尤其是基于中文的全文搜索应用，term集可能会比较大。比如有10000个docs，占用100MB空间时，并不能简单认为100000个docs就占用约1GB。 tip5 测试分词器 如果使用的是基于词典的分词器，比如IK这类，那么线上系统可能会需要按需添加自定义词，或者同义词等，技术上我们可以暴露该类功能给搜索引擎运营人员使用。所以，需要提供一个测试分词器的接口，方便对比和验证。ES默认就提供这样的REST接口的。 按指定分词器分词指定文本：

GET /vivo_vimc/apps/_analyze?text=Hello, vivo 移动互联网&analyzer=ik

按指定索引库的属性测试分词效果：

GET /vivo_vimc/apps/_analyze
{
  "field": "appName",
  "text": "Pokemon Go"
}

以上关于 mapping 的几点心得，并非金科玉律，需要根据不同的业务需求场景来区别分析和应对。如果你有更多心得，欢迎回复本文分享。 关于作者： 杨振涛，vivo移动互联网 搜索架构师，关注实时搜索，搜索广告，以及大数据的存储、索引、搜索和可视化。

比如，由logstash打到es中的数据，除了其中一个字段比如message，其余字段都想设置为not analyzed,这种情况如何设置？貌似目前es只支持设置那些具体的字段为not analyzed，而不能反过来设置啊？