一、介绍
在这篇文章中 利用springboot+elasticSearch，实现数据高效搜索，实战开发，我们介绍了 SpringBoot 整合 ElasticSearch 开发，以及一些基础的 CRUD。
我们都知道，ElasticSearch 真正的强大的地方在于面对海量数据，依然能实现高效搜索，既然如此，本篇就以此为基础，将数据库查询与 Elasticsearch 进行查询性能对比，看看谁的查询速度更快！
废话不多说，先新建一张学生表student，字段内容如下：
为了贴近海量数据这一特性，小编特意在学生表student中造了 1千万条数据，本来是想造 1个亿的，但是造数据实在太耗时了，挑战比较大，当一张表的数据量到达1千万时，查询性能查询已经很明显了，所以造 1 个亿的梦想暂且搁置！
下面，我们就一起来看看两者之间的性能差别！
- 数据库版本：mysql-8.0.18
- ElasticSearch 版本：6.1.0
二、数据库性能测试
可能有些同学很好奇，当一张表的数据量到达 1千万之后，单表的增删改查是否如往常一样高效？
今天我们就一起来实战观察，先直接利用数据库工具来测试一下！
2.1、CRUD测试
2.1.1、查询测试
- 通过主键id，搜索信息
- 通过非主键id，搜索姓名
张三1的信息
可以很清晰的看到，搜索花费时间6s，可能有些同学不信，一条查询结果无法令人信服，那我换别的名称测试一下！
从数据上，可以很清晰的看到，如果通过主键ID查询会非常快，但是如果通过非主键字段查询比较慢，一个单表查询平均耗时 6s！
2.1.2、新增测试
- 插入一条数据，姓名
赵云
从数据上看，插入耗时比较短！
2.1.3、修改测试
- 通过主键id，修改信息
- 通过非主键，修改信息
可以很清晰的看到，如果通过主键ID来修改会非常快，如果是通过非主键修改会非常慢！
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 上进行全文搜索，或者合理的使用索引，性能会明显翻倍！
本文可能也有遗漏的地方，欢迎网友点评、吐槽！
