ElasticSearch 与 MySQL 在大数据环境下两者查询效率真实表现，到底如何？

一、大数到底背景介绍

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

废话不多说，查询先新建一张学生表student，效率字段内容如下：

图片

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

图片

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

数据库版本：mysql-8.0.18ElasticSearch 版本：6.1.0

二、数据库性能测试

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

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

2.1、CRUD测试

2.1.1、查询测试通过主键id，搜索信息

图片

图片

通过非主键id，搜索姓名张三1的信息

图片

图片

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

图片

图片

图片

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

2.1.2、新增测试插入一条数据，姓名赵云

图片

图片

从数据上看，插入耗时比较短！

2.1.3、修改测试通过主键id，修改信息

图片

图片

通过非主键，修改信息

图片

图片

可以很清晰的看到，如果通过主键ID来修改会非常快，如果是b2b供应网通过非主键修改会非常慢！

2.4、删除测试通过主键id，删除数据

图片

图片

通过非主键字段，删除数据

图片

图片

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

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

2.2、为字段添加索引

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

图片

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

图片

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

图片

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

图片

从结果上看，整体耗时：0.003s！

从这里，我们可以很清晰的看出：创建索引，可以大大提高表的服务器托管性能！

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

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

第一：创建索引和维护索引比较耗费时间，当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，这样就降低了数据的维护速度，同时随着数据量的增加，维护索引的耗时也会更长。第二：索引需要占用物理空间，随着表数据不断的增大，索引需要空间也会变大。

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

三、Elasticsearch 性能测试

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

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

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

图片

3.1、CRUD测试

3.1.1、查询测试，默认每页最多查询10条

图片

图片

图片

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

3.1.2、新增测试

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

图片

批量插入，耗时在0.1s左右，结果如下：

图片

3.1.3、修改测试

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

图片

图片

修改不存在的ID，进行请求！

图片

查询王小贱信息！

图片

3.1.4、删除测试

传入指定ID，即可删除信息！

图片

四、总结

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

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

本文地址：http://www.bhae.cn/html/64f9599840.html