elasticsearch搜索引擎设计方案

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管理模块，进行索引的增删改成维护。因为作为平台都应该是可控的，这样可以大大的降低风险，所以我们一定要预留一些能够处理突发情况的接口。技术一定要和业务相结合，绝对不能因为技术而用技术，业务需要什么技术我们就用什么技术。

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