1. 为啥Elasticsearch 6.x要砍掉映射类型（mapping type）？ #

这个决策真不是拍脑袋来的，全是早期设计埋下的坑倒逼出来的：

• 字段映射冲突的噩梦：Lucene底层是把同一索引下所有类型的文档混存的，要是不同类型里有同名字段（比如两个类型都有id），但映射规则不一样（一个是字符串、一个是数字），Lucene根本没法处理，轻则查询结果乱套，重则数据写入失败，复杂业务场景里这坑踩一次够头疼好久。
• 概念混淆误导人：早期为了贴近关系型数据库的认知，把索引类比成数据库、类型类比成表，但实际上Elasticsearch的索引更像一个“同类数据容器”，多类型混放完全违背了它的设计初衷——很多新手被这个类比带偏，花大量时间解决本来不该存在的问题。
• 拖垮性能&增加复杂度：维护多类型需要Elasticsearch额外处理元数据管理、查询过滤等逻辑，既增加了代码复杂度，又拖累了索引和查询的性能，长期来看就是个不必要的累赘。

所以官方从6.x开始逐步移除映射类型，本质是从根源上梳理设计逻辑，让Elasticsearch更高效、更易用。

2. 升级到6.x后，现有映射类型会咋样？有没有直接升级的选项？ #

直接升级是可行的，但得搞清楚后续的变化和风险：

现有多类型索引的状态 #

• 6.x保留了兼容过渡模式：你之前创建的多类型索引完全能正常用，读写、查询都不受影响，官方不会强制你立刻修改。
• 但新建索引有严格限制：6.x里新创建的索引最多只能有一个映射类型（默认是_doc），再也不能像以前那样一个索引下塞好几个类型了。

直接升级的注意事项 #

如果选择直接升级不做迁移，得记好这两点：

• 兼容模式只是临时过渡，到7.x就彻底砍掉映射类型支持了，到时候你的多类型索引会直接失效，所以趁着6.x的窗口期迁移才是长远之计。
• 要是你的多类型索引里本来就有同名字段映射冲突的情况，升级后之前隐藏的问题可能会直接暴露出来（比如查询结果不符合预期），最好提前排查一遍。

官方推荐的迁移方案 #

更合理的做法是把多类型结构转换成贴合Elasticsearch设计的模式：

• 拆成多个单类型索引：比如原来一个索引下有user和order两个类型，现在拆成user_index和order_index两个独立索引，每个索引只用默认的_doc类型。这种方式最贴合Elasticsearch的设计，性能和维护性都最优。
• 用自定义字段替代类型：如果不想拆索引，可以给每个文档加一个自定义字段（比如doc_type）来区分原来的类型，查询时通过这个字段过滤。比如原来的user类型文档，现在加上doc_type: "user"，查询时用doc_type:user筛选。可以用_reindex API批量修改现有数据：

  POST _reindex
  {
    "source": {
      "index": "old_index",
      "type": "user"
    },
    "dest": {
      "index": "new_index"
    },
    "script": {
      "source": "ctx._source.doc_type = 'user'"
    }
  }
  

内容的提问来源于stack exchange，提问作者Amit Jayee