elasticsearch的性能影响因素

elasticsearch的性能优化

1 简单概念理解

使用版本：elasticsearch5.5.0。从5系列版本开始，相关性评分使用的是bm25。

1.1 es关键词理解

对比mysql和elasticsearch
mysql是关系型数据库，有数据库–表--行–列--字段
es是一个面向文档数据库，有索引–类型–文档–fields
索引（index），es中的索引相当于mysql的数据库的概念
类型（type），es中的类型相当于mysql的表的概念
文档（document）,es中的文档相当于mysql的列的概念，就是一条数据是一个json格式的就是一个文档，存数据的最小单位就是文档，文档的长度就是该类型的文档数量
字段（fields）,es中的字段相当于mysql的字段

1.2 TF-IDF理解

TF（term frequency） (词语频率)
以搜索 explain 为例：
TF score=某个词在文档中出现的次数/文档的长度
文档的长度为200，explain出现了2次，那就是TF score=2/200=0.01
如果是一个词组 explain的中文 ，那么就是TF之和。

explain 出现了2次； 的 出现了20次； 中文 出现了3次；
那么 explain的中文的IF
score=2/200+20/200+3/200=0.01+0.1+0.015=0.125

一个文档中 的 属于停用词 就是出现次数很多。去掉停用词得分就是0.025。
停用词在创建索引的时候也会去掉，用户在搜索的时候也会去掉。可以减少存储。
英文停用词 http://www.ranks.nl/stopwords
中文停用词 http://www.ranks.nl/stopwords/chinese-stopwords
IDF（Inverse document frequency）逆文本文档频率
IDF score=log(N/n)
log是以2为底的对数，非10

可以使用excel的log公式计算

N表示全部文档数，假如全部文档数为100亿

explain 在1万个文档中出现过 log(100亿/1万)=19.93
的 在所有文档中都出现过 log(1)=0 中文
在2亿个文档中出现过 log(100亿/2亿)=5.64

短语 explain的中文 与文档的相关性最终结果

0.01*19.93+0.1*0+0.015*5.64=0.2839

其中
explain的权重为0.01*19.93/0.2839=0.7，中文权重为0.3。

1.3 BM25理解

参考文章：https://www.jianshu.com/p/1e498888f505

默认BM25公式系数k1=1.2，b=0.75。
BM25公式适用场景，海量文档中，根据关键词找到最符合要求的文档。BM25根据逆文档频率，词频对关键词和文档的相关度做了一个打分，单个词在所有文档中出现的次数越少，在匹配文档中出现的次数越多，该项得分越高。
参考文章：https://www.cnblogs.com/hdflzh/p/4034602.html

2 修改jar对查询效率的影响

实际工作中需要对ES的jar包的BM25算法做修改。
修改一：参数b设置b=1(默认b=0.75)；
修改二：默认对文档的映射值为真实的文档长度；
修改三：修改了config下的jvm.option 的-Xms2g -Xmx2g 为6g
修改过后发现在查询效率和结果上有很大的影响，查询200万数据。原jar在1000ms内有相应，但是修改后5000ms也有出不来的情况，且查询出的结果跟预期不一样，及相关性排序不对。

2.1 关于修改参数b=1

b为0时即不考虑文档长度的影响，经验表明b=0.75左右效果比较好。但是也要根据相应的场景进行调整。b越大对文档长度的惩罚越大。此处因为主要要考虑文档长度的影响更改为b=1。没有查到更改参数会对效率的影响，暂不考虑。

2.2 关于修改使用真实的文档长度

参考文章：
https://www.bbsmax.com/A/ZOJPXOVaJv/
这篇文章中提到在lucene为了降低存储的空间，在存储field的长度时，没有存储实际长度，而是存储了一个byte类型的值(0-255),每个值对应了BM25Similarity有NORM_TABLE中的index,在BM25Similarity有NORM_TABLE的float数组，实现了一个区间映射的功能。
使用文档的真实长度，不在使用映射的值，不存在精度方面的丢失，从而影响了查询效率，具体影响多少，不清楚。因为在优化过程中还发现一个关于给es分配JVM空间大小的影响。在原jar里面默认分配为2g。

2.3 关于修改jvm的内存空间

Xms表示总堆空间的初始大小
XMX表示总堆空间的最大大小

参考文章：https://www.jianshu.com/p/93f25c1f138c
其中提到lucene的性能是严重依赖于底层的os的，但是如果我们给了过多的内存到es的jvm heap，那么就没有足够的内存留给lucene。这会极大的影响性能。
所以修改jvm的内存为原来默认的2g。查询效率有提高，且发现查询结果方面，也有很大的改善。按照参考文章https://www.bbsmax.com/A/ZOJPXOVaJv/提到ElasticSearch在建立index的时候，默认自动回建立5个分片，在插入数据的时候，会根据一致性算法将文档分配到某一个shard上，在进行搜索的时候，每个shard上独自进行搜索评分，然后汇总后，根据_score进行排序，然后在返回给前端。可见在汇总之后返回前端之前并未进行二次排序。可能之前也是lucene的内存影响了并未二次排序。