admin管理员组

文章数量:1530085

ES技术本身其实不是很难,难的是怎么和业务想挂钩起来,这几天一直在思考怎么将ES技术融入到项目中去,替换以前用SQL来查询数据。下面是我思考大致思路和结果,当然肯定还有很多问题在里面,在后面具体实施的时候,我也会一步步详细介绍的。废话不多说,马上开始今天的内容。

1.项目应用场景

我们做的是一个社交app,里面有两个模块需要用到搜索引擎功能。一个是趣物(实际是商品)、第二个是小队模块(类似QQ群这样的角色)。现在这两个地方还是用SQL中like语句来实现查询的功能。我们先看一下这两个模块的界面。

2.项目app界面

趣物搜索界面

小队搜索界面

小队列表界面

趣物列表界面

3.目前存在的问题

这些数据全部都是直接从数据库里面拿的,因为刚开始使用app用户比较少,所以搜索速度和搜索精准度还可以接受,后来随着数据量的变大这种方式漏洞越来越大了。一方面是数据量大的情况下like查询太慢了,另一方面是查询太单一,鉴于这两种情况,我们准备加上ES模块。

 

4.ES方案设计

首先得先了解一下ES特性,ES检索速度特别快,而且查询的API丰富,还有聚合等等的功能,天生分布式框架。所以从框架的性能来说,选择ES作为我们项目的搜索模块是毫无问题的。现在重点就是设计ES中索引字段、索引字段的属性、数据同步方案、确定需要设置权重的字段等。下面我们来一个个说明理清一下思路。

4.1索引字段:

首先是确定索引字段,为什么样将这个放在第一个呢。因为ES的索引是一旦确定下来就不能做任何的修改了,只能删除重新创建索引。所以选择好索引字段是非常重要的。我们创建索引的时候要注意以下几点:

1.经常变动的数据且要一变动就马上显示的数据,这种数据不要放在ES中。

2.不要将不需要的数据库表字段添加到ES索引中,浪费资源。

3.不要将经常变动的状态字段放在ES中。

4.为了同步数据方便,不要轻易将多张表的字段放在同一个索引中去。

5.第五点可能会和第四点相互矛盾,就是尽可能只通过查询ES就可以将数据查询出来,而不是需要二次查询数据库,因为这样很容易照成n+1次查询的出现。

4.2索引字段属性:

ES的所有字段也是有一套自己的属性的,基本和Java的类型差不多。既然有类型肯定就会有各种类型之间的差别,比容商品价格的时候,我们就可以将价格这个字段设置为Numeric类型。所以基于项目需求,我们需要注意以下几点内容:

1.趣物的名称、分类不需要进行分词,因为我们需要的是精确查询。

2.趣物的内容要设置分词,因为我们需要大范围的关键字检索。

3.趣物的点赞、收藏、分享数目就可以设置为Numeric类型,方便统计。

4.3数据同步方案:

数据的同步方案有两种:

1.工具同步:如果索引和数据库表一一对应,索引的字段没有超出数据库表的范围,就可以采用第三方框架来同步数据。这种方式的好处是对代码没有侵入性,直接同步数据库数据到索引中就可以了,缺点是不够灵活,功能被框架限制死。

2.代码同步:如果索引和数据库表不是一一对应,甚至还需要进行一些处理。这种情况下我们可以采用跑定时任务的模式,进行程序同步。好处是可控性大大增加了,缺点是对代码的侵入性太大,定时任务出问题不好处理。

数据同步千万不要时时刻刻同步,这样的设计会搞死ES服务,所以一般都是在凌晨或者特定的时间同步一次。

4.4确定权重字段:

什么是权重呢,这就要和排序相挂钩了,相当于SQL中order by类似。大家想一下淘宝的排序规则就知道了,可以根据发布时间,浏览人数等等进行排序,我们这个项目也一样。所以要预留设置权重的字段,然后可以在后台进行权重配置。这样可以大大的提高程序的扩展性,比如我们可以将发布时间、修改时间、点赞数目、收藏数目、分享数目进行权重设置,这样可以很自由的进行排序规则设置。甚至比如我们平台自己的商品想要放在首页就可以通过权重设置,设置在到第一个中。

5.经验总结:

设计的时候还要注意,因为趣物模块我们这边分为三种类型,所以ES索引中一定要设置状态这个字段,而且不能进行分词,必须精确查询才可以。后台需要一个ES管理模块,进行索引的增删改成维护。因为作为平台都应该是可控的,这样可以大大的降低风险,所以我们一定要预留一些能够处理突发情况的接口。技术一定要和业务相结合,绝对不能因为技术而用技术,业务需要什么技术我们就用什么技术。

想要更多干货、技术猛料的孩子,快点拿起手机扫码关注我,我在这里等你哦~

                                                       

本文标签: 设计方案搜索引擎Elasticsearch