乐趣区

关于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
索引 耗费工夫
无索引 383 秒
btree 索引 588 秒
fulltext 索引 89 秒

通过后果,能够看到 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 做以下比照。

MySQL ElasticSearh 阐明
实时性 实时 近实时 ElasticSearch 的写入效率比 MySQL 低,如果对实时性要求十分高,那么优先选择 MySQL
数据结构 齐全结构化数据 非结构化数据 这没什么好说的,结构化数据优选 MySQL, 但如果同时有搜寻的要求,能够思考 ElasticSearch
事务 反对 不反对 ElasticSearch 是不反对事务的,对事务有严格要求,请应用 MySQL
查问性能 数据量增大后性能升高 反对较大数据量 ElasticSearch 更实用于搜寻场景,如果有搜寻场景,毫不犹豫抉择 ElasticSearch

写在最初

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

退出移动版