最近笔者在测试elasticsearch和mysql的查询效率的时候竟然意外的发现es查询效率比mysql还慢.
es查询一个简单的语句,竟然要四五百毫秒,而mysql只需要一百多毫秒.
最初的判断:
1.es的服务器硬件资源不足:内存不够,搭建的是两台es,用作日志收集存储,每台的es内存设置的是2g(最后查到es的内存最好设置为服务器内存的一半以内.然后查看服务器内存为16g,然后我就设置了es的内存为7g,发现查询效率还是不如mysql)
2.es服务器的系统负载比较高.四核的cpu,竟然负载到了5到6,想着应该是两台服务器都搭建了es,kafka,kibana,logstash,zookeeper导致的负载变高 的.然后询问阿里云得知我的ubuntu系统内核查询如下:
该内核存在一个bug,就是https://www.mail-archive.com/[email protected]/msg5697979.html
发现Ubuntu官方有发布过一个BUG,目前ubuntu18系统有将usleep以及nanosleep统计计算到cpu load中,因此会存在这种问题现象(也就是系统负载比较高,即使啥也没运行,也会很高),但是不影响使用.想要升级的话只能自己手动升级内核.
3.采用的spring-data-elastisearch进行的复杂查询(不认为有多复杂啊),如下:难道是排序造成的(测试了没啥大改变)
4.难道是存进es的数据字段设置问题?搜索百度说字段尽量不要设置index,也就是分词.但是不分词发现查询的时候查不出来
5.最后才发现问题:自己傻了
傻的原因有以下几点:
一,es给单独建立了model,采用dubbo远程调用进行测试的.(所以远程传输本身就耗时几十到一百多毫秒),这是其一
二,观察第一张图片里面,加了事物注解.该注解本身也比较耗时这是其二
三,第一张图片里面方法内部还进行了lists.newArrayList和beancopy,这个测试耗时竟然达到了一百到两百毫秒.罪恢祸首
实际调用es的地方的代码如下:(下面注释的代码打开就是调用的es.)
再次测试两者的耗时比较如下:
es | 69 | 34 | 2939 | 27 | 68 |
mysql | 90 | 101 | 118 | 101 | 153 |
发现es的数据总体来说还是mysql低很多的...唯一的一个2939毫秒不知道咋回事.可能es网络原因吧.
总结:
1.mysql采用通用mapper进行查询,而es是分布式搜索引擎和redis一样是分布式的,可以让每个model项目进行集成.然后像mapper一样进行使用.这样就解决了dubbo远程调用的耗时.
2.es的内存设置一般是服务器内存的一半.比如服务器是32g,那么内存设置为16g或者15g.不能超过16g.
3.es存储时尽量存储结构简单一点.并采用主键形式进行查询.这样搜索的出来的耗时比较快.
所以综合下来,es查询比mysql慢吗?不存在的