Elasticsearch 6.0 一个索引只允许有一个type

「爱情、让人受尽委屈。」 2024-04-17 16:10 134阅读 0赞

**一，单index,单type**  
未来发布的elasticsearch 6.0.0版本为保持兼容，仍然会支持单index，多type结构，但是作者已不推荐这么设置。在elasticsearch 7.0.0版本必须使用单index,单type，多type结构则会完全移除。  
针对这一问题，elasticsearch 作者的讨论：  
[https://github.com/elastic/elasticsearch/pull/24317][https_github.com_elastic_elasticsearch_pull_24317]  
[https://www.elastic.co/guide/en/elasticsearch/reference/5.6/removal-of-types.html][https_www.elastic.co_guide_en_elasticsearch_reference_5.6_removal-of-types.html]  
   
**二，单index，多type结构弊端**  
人们经常会谈到index类似传统sql数据库的“database”,而type类似于"table"。现在想想，这是一个非常糟糕的比喻，而这个比喻会造成很多错误的假设。  
在传统的sql数据库中，各个"table"之间是互相独立的，在一个表中的列都与另一个表相同名称的列无关。  
①，而在我们elasticsearch中同一 Index 下，同名 Field 类型必须相同，即使不同的 Type；  
②， 同一 Index 下，TypeA 的 Field 会占用 TypeB 的资源（互相消耗资源），会形成一种稀疏存储的情况。在同一索引中存储具有很少或没有共同字段的不同实体会导致**稀疏数据**并干扰Lucene有效压缩文档的能力。尤其是 doc value ，为什么这么说呢？doc value为了性能考虑会保留一部分的磁盘空间，这意味着 TypeB 可能不需要这个字段的 doc\_value 而 TypeA 需要，那么 TypeB 就被白白占用了一部分没有半点用处的资源；  
③，Score 评分机制是 index-wide 的，不同的type之间评分也会造成干扰。  
④，索引元数据本身是放在主节点中维护的，CP 设计。意味着涉及到大量字段变更及元数据变更的操作，都会导致该 Index 被堵塞或假死。我们应该对这样的 Index 做隔离，避免影响到其他 Index 正常的增删改查。甚至当涉及到字段变更十分频繁且无法预定义 schema 的场景时，是否要使用 ES 都应该慎思熟虑了！

文章来源：[https://elasticsearch.cn/article/337][https_elasticsearch.cn_article_337]

[https_github.com_elastic_elasticsearch_pull_24317]: https://github.com/elastic/elasticsearch/pull/24317
[https_www.elastic.co_guide_en_elasticsearch_reference_5.6_removal-of-types.html]: https://www.elastic.co/guide/en/elasticsearch/reference/5.6/removal-of-types.html
[https_elasticsearch.cn_article_337]: https://elasticsearch.cn/article/337