2017年08月31日发布了ElasticSearch 6.0.0-beta2，其中有很多特性值得期待：

稀疏性 Doc Values 的支持：大家知道 es 的 doc values 是列式存储，文档的原始值都是存放在 doc values 里面的，而稀疏性是指，一个索引里面，文档的结构其实是多样性的，但是郁闷的是只要一个文档有这个字段，其他所有的文档尽管没有这个字段，可也都要承担这个字段的开销，所以会存在磁盘空间的浪费，而这块的改进就是这个问题。

如果想及时了解Spark、Hadoop或者Hbase相关的文章，欢迎关注微信公共帐号：iteblog_hadoop

Index sorting：即在索引阶段的排序，即我们查询的时候有时候会根据某个字段的值进行排序，比如时间、编号等等，如果在索引的时候提取排好序，那么搜索或聚合的时候就会非常快，相应的直接走预先排序好的索引就行了。当然索引的时候会要增加额外开销，适合不怎么变化的索引的场景。

顺序号的支持：每个 es 的操作都有一个顺序编号，这个属于 es 内部的一个功能，可以提供：快速的分片副本恢复或同步；跨数据中心的节点恢复；甚至提供一个 Changes API 等等；

无缝滚动升级：使之能够从 5 的最后一个版本滚动升级到 6 的最后一个版本，不需要集群的完整重启。无缝滚动升级，也就是不用停服务，在线升级，补充一下。

Removal of types：在 6.0 里面，开始不支持一个 index 里面存在多个 type 了，所有的新的 index 都将只有一个虚拟的固定的 type： doc 来代替，基于 type 的 parent-child 关系将通过单独的 join 字段来实现， type 会在 7.0 彻底移除。

Index-template inheritance：索引版本的继承，目前索引模板是所有匹配的都会合并，这样会造成索引模板有一些冲突问题， 6.0 将会只匹配一个，索引创建时也会进行验证。

Load aware shard routing： 基于负载的请求路由，目前的搜索请求是全节点轮询，那么性能最慢的节点往往会造成整体的延迟增加，新的实现方式将基于队列的耗费时间自动调节队列长度，负载高的节点的队列长度将减少，让其他节点分摊更多的压力，搜索和索引都将基于这种机制。

已经关闭的索引将也支持 replica 的自动处理，确保数据可靠。