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移动互联网 搜索架构师，关注实时搜索，搜索广告，以及大数据的存储、索引、搜索和可视化。