vlambda博客
学习文章列表

数据库与elasticSearch,大数据查询性能PK

每天早上七点三十,准时推送干货


一、介绍

在这篇文章中 ,我们介绍了 SpringBoot 整合 ElasticSearch 开发,以及一些基础的 CRUD。

我们都知道,ElasticSearch 真正的强大的地方在于面对海量数据,依然能实现高效搜索,既然如此,本篇就以此为基础,将数据库查询与 Elasticsearch 进行查询性能对比,看看谁的查询速度更快!

废话不多说,先新建一张学生表student,字段内容如下:

数据库与elasticSearch,大数据查询性能PK

为了贴近海量数据这一特性,小编特意在学生表student中造了 1千万条数据,本来是想造 1个亿的,但是造数据实在太耗时了,挑战比较大,当一张表的数据量到达1千万时,查询性能查询已经很明显了,所以造 1 个亿的梦想暂且搁置!

数据库与elasticSearch,大数据查询性能PK

下面,我们就一起来看看两者之间的性能差别!

  • 数据库版本:mysql-8.0.18
  • ElasticSearch 版本:6.1.0

二、数据库性能测试

可能有些同学很好奇,当一张表的数据量到达 1千万之后,单表的增删改查是否如往常一样高效?

今天我们就一起来实战观察,先直接利用数据库工具来测试一下!

2.1、CRUD测试

2.1.1、查询测试
  • 通过主键id,搜索信息
数据库与elasticSearch,大数据查询性能PK
数据库与elasticSearch,大数据查询性能PK
  • 通过非主键id,搜索姓名 张三1的信息
数据库与elasticSearch,大数据查询性能PK
数据库与elasticSearch,大数据查询性能PK

可以很清晰的看到,搜索花费时间6s,可能有些同学不信,一条查询结果无法令人信服,那我换别的名称测试一下!

数据库与elasticSearch,大数据查询性能PK
数据库与elasticSearch,大数据查询性能PK
数据库与elasticSearch,大数据查询性能PK

从数据上,可以很清晰的看到,如果通过主键ID查询会非常快,但是如果通过非主键字段查询比较慢,一个单表查询平均耗时 6s!

2.1.2、新增测试
  • 插入一条数据,姓名 赵云
数据库与elasticSearch,大数据查询性能PK
数据库与elasticSearch,大数据查询性能PK

从数据上看,插入耗时比较短!

2.1.3、修改测试
  • 通过主键id,修改信息
数据库与elasticSearch,大数据查询性能PK
数据库与elasticSearch,大数据查询性能PK
  • 通过非主键,修改信息
数据库与elasticSearch,大数据查询性能PK
数据库与elasticSearch,大数据查询性能PK

可以很清晰的看到,如果通过主键ID来修改会非常快,如果是通过非主键修改会非常慢!

2.4、删除测试
  • 通过主键id,删除数据
数据库与elasticSearch,大数据查询性能PK
数据库与elasticSearch,大数据查询性能PK
  • 通过非主键字段,删除数据
数据库与elasticSearch,大数据查询性能PK
数据库与elasticSearch,大数据查询性能PK

从数据上可以看出,当通过主键ID进行删除非常快,但通过非主键删除超级慢!

总结:从curd测试结果来看,一张单表数据超过1千万时,增删改查效率会逐渐变慢!一般情况下,我们的接口请求都会设置超时时间,例如,频繁的查询功能都需要耗时6秒,接口请求基本百分之百的报超时错误!

2.2、为字段添加索引

面对这种情况应该如何应对呢?首先我们试试给关键字段name添加索引!

数据库与elasticSearch,大数据查询性能PK

再来,搜索姓名张三1的信息,结果如下:

数据库与elasticSearch,大数据查询性能PK

搜索姓名张三88的信息,耗时结果如下:

数据库与elasticSearch,大数据查询性能PK

搜索姓名张三8888的信息,耗时结果如下:

数据库与elasticSearch,大数据查询性能PK

从结果上看,整体耗时:0.003s!

从这里,我们可以很清晰的看出:创建索引,可以大大提高表的性能!

这也说明了,为什么我们在创建表的时候,明确规定,对于关键的查询字段,一定要加索引的原则!

当然创建过多的索引也有缺点!

  • 第一:创建索引和维护索引比较耗费时间,当对表中的数据进行增加、删除和修改的时候,索引也要动态的维护,这样就降低了数据的维护速度,同时随着数据量的增加,维护索引的耗时也会更长。

  • 第二:索引需要占用物理空间,随着表数据不断的增大,索引需要空间也会变大。

因此,在实际开发中,还需要根据具体的业务场景来确定哪些字段需要创建索引!

三、Elasticsearch 性能测试

说完数据库,我们接着来看看 Elasticsearch 的表现如何!

为了跟数据库中的数据量保持一致,小编也花了一些时间,将数据库中学生表的数据全部迁移到了 Elasticsearch 中!

我们可以通过Elasticsearch-head插件登录 Elasticsearch 的 Web 管理页面查看结果!

数据库与elasticSearch,大数据查询性能PK
数据库与elasticSearch,大数据查询性能PK

3.1、CRUD测试

3.1.1、查询测试,默认每页最多查询10条
数据库与elasticSearch,大数据查询性能PK
数据库与elasticSearch,大数据查询性能PK
数据库与elasticSearch,大数据查询性能PK

从数据结果上看,耗时基本在0.5s之内,可以说吊打从数据库直接查询数据的耗时!

3.1.2、新增测试

插入一条数据,耗时0.2s左右,结果如下:

数据库与elasticSearch,大数据查询性能PK

批量插入,耗时在0.1s左右,结果如下:

数据库与elasticSearch,大数据查询性能PK
3.1.3、修改测试

修改时,只需要传入ID即可,Elasticsearch 会根据ID作为索引,判断是否存在,如果存在,就进行更新,如果不存在,就将其插入!

数据库与elasticSearch,大数据查询性能PK
数据库与elasticSearch,大数据查询性能PK

修改不存在的ID,进行请求!

数据库与elasticSearch,大数据查询性能PK

查询王小贱信息!

数据库与elasticSearch,大数据查询性能PK
3.1.4、删除测试

传入指定ID,即可删除信息!

数据库与elasticSearch,大数据查询性能PK

四、总结

本文内容,主要围绕数据库与 elasticSearch,在大数据查询方面,性能的实测比较!

总的来看,elasticSearch 在大数据查询方面要远优于从数据库中直接查询,因此,如果所在项目的数据库容量已经超过千万,建议将数据迁移到 elasticSearch 上进行全文搜索,或者合理的使用索引,性能会明显翻倍!

本文可能也有遗漏的地方,欢迎网友点评、吐槽!

由于公号不能直接点击外链,关注「Java极客技术」,回复「202007018」,即可获取 Springboot 整合 elasticSearch 源码项目~

最后说两句(求关注)

所以看完文章,哥哥姐姐们给阿粉来个在看吧,让阿粉拥有更加大的动力,写出更好的文章,拒绝白嫖,来点正反馈呗~。

如果想在第一时间收到阿粉的文章,不被公号的信息流影响,那么可以给Java极客技术设为一个星标。

最后感谢各位的阅读,才疏学浅,难免存在纰漏,如果你发现错误的地方,由于本号没有留言功能,还请你在后台留言指出,我对其加以修改。

最后谢谢大家支持~

最最后,重要的事再说一篇~

快来关注我呀~
快来关注我呀~
快来关注我呀~

< END >

如果大家喜欢我们的文章,欢迎大家转发,点击在看让更多的人看到。也欢迎大家热爱技术和学习的朋友加入的我们的知识星球当中,我们共同成长,进步。