elasticsearch transportclient count 很慢_Elasticsearch各版本比较

由于最近在做B2B的一个商城，打算搜索和商品详情页都使用ES来进行关键词搜索和数据查询减少对数据库的压力。所以首先要对ES的各个版本有一个了解认识。这是一个敏锐的架构师首先要开工的第一步。下面是7.0版本的新特性：

1. 集群连接变化：TransportClient被废弃

以至于，es7的java代码，只能使用restclient。然后，个人综合了一下，对于java编程，建议采用 High-level-rest-client 的方式操作ES集群

2. ES数据存储结构变化：去除了Type

es6时，官方就提到了es7会删除type，并且es6时已经规定每一个index只能有一个type。在es7中使用默认的_doc作为type，官方说在8.x版本会彻底移除type。

api请求方式也发送变化，如获得某索引的某ID的文档：GET index/_doc/id其中index和id为具体的值

3. High-level REST client 改变

已删除接受Header参数的API方法；Cluster Health API默认为集群级别；

4. ES程序包默认打包jdk：以至于7.x版本的程序包大小突然边300MB+

对比6.x发现，包大了200MB+， 正是JDK的大小

5. 默认配置变化：默认节点名称为主机名，默认分片数改为1，不再是5。

6. 查询相关性速度优化：Weak-AND算法

啥是weak-and算法？

核心原理：取TOP N结果集，估算命中记录数。

简单来说，一般我们在计算文本相关性的时候，会通过倒排索引的方式进行查询，通过倒排索引已经要比全量遍历节约大量时间，但是有时候仍然很慢。

原因是很多时候我们其实只是想要top n个结果，一些结果明显较差的也进行了复杂的相关性计算，

而weak-and算法通过计算每个词的贡献上限来估计文档的相关性上限，从而建立一个阈值对倒排中的结果进行减枝，从而得到提速的效果。

7. 间隔查询(Intervals queries)：

某些搜索用例(例如，法律和专利搜索)引入了查找单词或短语彼此相距一定距离的记录的需要。

Elasticsearch 7.0中的间隔查询引入了一种构建此类查询的全新方式，与之前的方法(跨度查询span queries)相比，使用和定义更加简单。

与跨度查询相比，间隔查询对边缘情况的适应性更强。

8. 引入新的集群协调子系统

移除 minimum_master_nodes 参数，让 Elasticsearch 自己选择可以形成仲裁的节点。

典型的主节点选举现在只需要很短的时间就可以完成。

集群的伸缩变得更安全、更容易，并且可能造成丢失数据的系统配置选项更少了。

节点更清楚地记录它们的状态，有助于诊断为什么它们不能加入集群或为什么无法选举出主节点。

时间戳纳秒级支持，提升数据精度

不再内存溢出

新的 Circuit Breaker 在JVM 堆栈层面监测内存使用，Elasticsearch 比之前更加健壮。

设置indices.breaker.fielddata.limit的默认值已从JVM堆大小的60％降低到40％。