升级es到6.0之后, 像往常一样创建索引, es可能会返回错误信息

Rejecting mapping update to [INDEXNAME] as the final mapping would have more than 1 type

这意味着, 从6.0开始, es不支持一个索引内存在多个doc_type.

来看看官方博客怎么说

一年多前, 我们就”indices和types的区别”发了一篇博文, 提到两者之间如何去选择的问题. 如果你懒得去翻阅之前的资料, 我可以直接说结论, 那就是: 同一索引中的多个类型实际上不应该被经常使用，父子关系只是少数用例之一. 遗憾的是, 并非所有人关注了我们的博客, 意味着我们很多用户在错误使用了”类型”而不自知. 这向我们提出了一个挺好的工程问题: 我们应该继续这种令人困惑的“类型”结构吗? 我们是否应该（继续）推荐它? 我们应不应该为Elasticsearch提供真正的父-子关系结构? 好消息是, 我们正朝更清晰明了的方向改变, 代价是这将产生不兼容改动, 尽管我们实在已尽可能努力减轻您的负担, 您还是需要尽快修改你的应用程序. 那么首先, 咱们还先谈谈为什么会有这个改变

为什么

Elastic(elasticsearch背后的公司)接手过数以千计来自客户的帮助请求, 正因为如此, 我们得以处于一种独特的境地，看看人们在Elasticsearch遇到什么样的常见问题. 在”类型”这方面, 主要有3点:

用户对此概念的理解可能是最突出的问题，很不幸, 在这一点上Elastic逃不了干系. 一个糟糕的比拟一旦被接受, 就很难纠正过来. 在此之前, 我们说过ES的index与传统关系型数据库中的db相似, 而type则与table类似. 但这真的是一个过于简单化的描述, 导致很多人简单的以为两者就是同样的东西. 事实上, 对ES底层而言, 整个索引的数据结构都是相同的. 用户最常见的误区就是以为字段在不同类型之间是独立的, 事实并非如此. /my-index/type-a/my-field字段, 必须与/my-index/type-b/my-field字段拥有同样的数据类型.

数据稀疏本应避免. 虽然Lucene 7提高了稀疏数据处理能力, 但我们还是应尽可能避免数据稀疏化. “类型”系统因为容许不同类型有不同字段, 因此总会导致你的数据稀疏化. 因此, 移除”类型”没准就能让你少踩一个坑

评分机制. 文档按索引而不是按类型打分, 因此将不同实体存储在同一索引中会干扰每种实体类型的相关性计算. 再说这有点违反直觉, 许多用户忽略了这一点, 这是另一个潜在的缺陷。

也就是说, types这个概念的引入和描述本身就是一个失误. 这东西一方面会影响评分和数据索引, 另一方面可能还会因为用户误解误用而导致其他问题, 因此决定将types废弃. 但是既然现在报导已经出了偏差, 就需要给多一点时间让用户去适应. 具体来说就是

  1. 从5.x开始, 增加了个index.mapping.single_type开关
  2. 6.0开始, 限制一个索引最多只能拥有一个type. 不过从5.x迁移过来的索引不受此限制. 提供不含type的URLs(接口)
  3. 7.0 彻底移除type