关于java:ElasticSearch系列初识弹性搜索小姐姐你该和Like模糊查询说再见了

年底跳槽涨薪技术哪家强，还得和靓仔学 Java！

邻近年关，作为程序员离不开的是跳槽涨薪的话题，而最近也在公司负责搭建 ElasticSearch 作为 Hbase 二级索引的架构。在此以 ElasticSearch 作为一个系列与大家分享。

何为弹性搜寻

是不是很好奇为啥叫弹性搜寻。这是咱们家可恶的测试小姐姐，第一次见 ElasticSearch 就给他起了个好听的中文名：弹性搜寻，挺可恶的样子。步入正题，ElasticSearch 的官网自我介绍是这样的：Elasticsearch 是一个分布式、RESTful 格调的搜寻和数据分析引擎。 而通常咱们会给 ElasticSearch 贴上上面的标签：全文检索、倒排索引、搜索引擎。

踏出 MySQL 的第一步

MySQL 作为大家接触最多，也最相熟的数据库，他的重要性是不容置疑的。兴许你用他解决所有数据存储都挺好，兴许你应用 MySQL 曾经遇到了一些问题，无论如何，都无妨来试一试用 ElasticSearch 来开始代替 MySQL 做一些数据存储。

在应用 MySQL 的时候，肯定写过这样的语句:

select * from tableName where name like "%XX%";

你也肯定常常看到这样的倡议: MySQL 含糊查问不要将 % 写在左侧，这样会导致索引生效! 这句话并没有任何谬误，然而当产品小姐姐给的需要就是含糊查问呢？你敢大声通知他这个需要不合理，索引会生效吗？我想你不会回绝这样的需要的，那么你脑海里闪现的解决方案有哪些呢？

1. 随缘

可能做完了性能，应用感觉没有任何故障，什么索引生效不生效的，我齐全感觉不到，查问速度也没有感觉到升高。那么我能够大胆的猜想，表中的数据量可能也就几万高低。数据量增长也非常低。这样的状况上来思考性能也的确不太人道，先思考产品是否生存才是王道！

1. 禁用含糊搜寻

当我的项目运行一段时间，数据量下来了，慢 SQL 日志一天跑不停，遂查找到起因是因为含糊搜寻引起，经磋商，砍掉~！！ 当你无奈用技术解决的时候，砍掉一部分性能以保障可用性也是一种抉择

1. 以 MySQL 的形式进行优化

在网上看到很多优化的例子，这里咱们间接应用 MySQL 来做验证，看最终的优化成果!
首先应用 Java 代码造数 5000 万条，造数代码已收录至 MySQL 造数

在 MySQL 应用如下两条 SQL 语句进行查问，查问后果一点都不出乎意料

select * from emp where age > 15 and user_name like "张 %" limit 100;
select * from emp where age > 15 and user_name like "% 朔 %" limit 100;

家喻户晓，MySQL 的 Like 含糊查问，当 % 处于含糊匹配左侧时，无奈应用到索引，会进行全表检索，因而效率低，而第一条语句左侧没有 %，则能够应用到索引。

发问：这里如果只应用 user_name 作为条件，效率其实还是能够承受的，聪慧的你，晓得是为什么吗？

MySQL 在 5.6 提供了全文检索对 InnoDB 的的反对，全文检索能够了解为一种索引形式，称作为倒排索引，前面具体讲 ElasticSearch 的时候会讲到，这里临时略过。

上面测试通过 email 字段不同状况下的含糊查问。

select * from emp where email like "5291%" and age = 15 ;
#fulltext 语法
select * from emp where MATCH(email) AGAINST("5921*" IN BOOLEAN MODE) and age = 15

通过后果，能够看到 fulltext 对于含糊查问的优化还是有较大的晋升，但 89 秒任然是业务不可能承受的查问工夫，上面就让咱们见识以下 ElasticSearch 的魔力吧。

ElasticSearch 查问

首先装置好 ElasticSearch, 本案例抉择的是 ES7.10.1，是目前最新的公布版本，可视化界面抉择 cerebro。同时，须要从文件中将后面写好的数据导入到 ElasticSearch, 这里抉择应用 Datax 进行数据导入, 如果不分明如何应用 Datax, 可移步 Datax 根本应用。

沒有比照就没有挫伤，同样的数据量，同样的数据，同样的查问，同样的后果，而耗时的确天差地别，从图中看到，应用 ElasticSearch 查问 email 以 5921 结尾且年龄为 15 岁的数据，总条数 45 条，耗时 491ms，没有通过测试，你都不肯定置信这是实在产生的，MySQL 最慢有 400 多秒，而 ElasticSearch 仅破费 400 多毫秒，足足差了近 1000 倍！

技术选型

下面的查问效率比照，毫无疑问，MySQL 完败，但这并不代表你就能够摈弃 MySQL 而全面拥抱 ElasticSearch。
MySQL 是属于关系型数据库，长于解决结构化数据，同时对于关联查问也有很好的反对，在 5.6 之后，在数据量不是很大的状况下，基本上能很好的应答除全文检索以外的场景。而 ElasticSearch 是 NoSQL, 存储非结构化数据，尽管可能进行关联、聚合等操作，但通常都不会倡议应用 ElasticSearch 来解决这些场景，咱们对 ElasticSearch 和 MySQL 做以下比照。

写在最初

无论你以后数据量如何，场景如何，我都倡议你能够将 ElasticSearch 利用起来，你会发现另外一片天地。you know，for search！