Home >Database >Mysql Tutorial >高效实现诱导输入及推荐执行人的方法

高效实现诱导输入及推荐执行人的方法

WBOY
WBOYOriginal
2016-06-07 16:30:211208browse

最新的项目遇到这样2个需求: a. 在输入用户时要求根据输入的字符针对邮箱及昵称进入实时提示,在输入项目时要求根据输入的字符针对项目名称进行实时提示。 b. 在输入执行人[抄送人]时要求可以根据-1.相似标题 2.最常用联系人 3.任务所属项目-进行执行人和抄

最新的项目遇到这样2个需求:
a. 在输入用户时要求根据输入的字符针对邮箱及昵称进入实时提示,在输入项目时要求根据输入的字符针对项目名称进行实时提示。
b. 在输入执行人[抄送人]时要求可以根据—-1.相似标题 2.最常用联系人 3.任务所属项目—-进行执行人和抄送人的推荐,下文将以推荐执行人为例。

解决方案:

一、诱导输入

1.用户输入 ?? 系统中的用户数量较多,自己写程序去实现效果未必好,直接交给elasticsearch(以下简称es)的“PrefixQuery”。PrefixQuery是按前缀对索引进行搜索,吻合这个需求,只要将用户的邮箱、昵称建索引,就能按这两个字段进行匹配,且效率很高。前端使用jquery.fcbkcomplete.js来触发请求。
2.项目输入 ?? 此处有别于用户输入,发任务到项目中时,每个人所能选择的项目仅限于自己参与的项目,因此个数很有限(50个吧?撑死了)。因此大可以简单处理,在redis中维护一个“用户XX的项目”这样一个sorted set(这个缓存对于项目列表依然有意义,比如显示“我的项目”)。在匹配时,直接循环去indexOf。从redis中取也这个有序集合,速度是超快的,对这几十个的项目进行查找,资源消耗很小,整个过程都没有动到数据库,响应依然及时。

二、推荐执行人

推荐规则有三条:1、相似标题,2、常用联系人,3、项目中的成员。分别描述下每条规则的实现方案。
1.相似标题 ? 计算标题的相似度可以使用文本相似度算法(各语言均有各自实现,python中Levenshtein库实现了该算法),效果较好,如: ? In [1]: from Levenshtein import * ? In [2]: ratio(‘min_doc_freq’,'max_doc_freq’) ? Out[2]: 0.8333333333333334 ? 但是做为实时推荐,这种方式不可行,因为性能达不到要求。后台跑的程序可以考虑。es中有个mlt,即”more like this”,可以用于相似文本的查找,轻量级,速度快,缺点是准确度不会很高。es中有一种准确度更高的计算方式 ,是根据文本向量进行计算 ,前提是在建索引时需存储相应的向量值 ,这种方式准确度更多高,但性能却很差,且影响建索引的速度,显然也不适合做实时推荐 ,综上,采用es的more like this进行相似文本查询是最合适 ,开发维护难度也低,从各个角度来看,都比较划算.
2.常用联系人(按使用频度排序,这里频度的定义是使用越多频度越高) 采用redis计数器hincrby,维护某个用户执行人的字典,数据结构如下:
redis 127.0.0.1:6379> hgetall Account:50ab539ae00d39114400079d:execnt
1) “50ab53bde00d391144000d36″
2) “1″
3) “50ab53bee00d391144000d5b”
4) “4″
这笔数据表示用户50ab539ae00d39114400079d发给用户50ab53bde00d391144000d36发过一次任务,发给用户50ab53bee00d391144000d5b发过四次任务。redis中的hash字典占用空间很小,速度也快,居家旅行必备。有了这些基础数据,就可以将平常的联系人按使用频度进行排序。只要将取到的字典key 与value逆置, 就能很容易得到排序结果,包括前边使用es查询的相似标题得到的执行人,也可以使用这个字典来排序 ,多取几个相似标题也不怕了(太多也无益,暂时取10个)。key与value逆转会碰到一个问题,即多个value相同的情况,这么一来字典的key岂不不唯一了吗?这时pythonpaste实现的MultiDict就派上用场,MultiDict允许出现同名的key,对于处理url参数也相当实用。 总之,取出来,排序之。
3.根据所属项目的成员进行推荐 ??? 在项目中发起任务,或者发起任务时带有项目信息就有此需求。如自然语言发起任务进文本中带有#项目名#,自然语言输入的信息除了解析出时间、人物、标题外,还会得到项目名。当然,得到的标题会被拿去作相似度查询,好强大。。。 ??? 得到项目名就好办了,project.members就是项目成员,members作为一个内嵌文档存在project表中,这也是mongodb的特色,并且整个project对像放在memcached中,过程中资源开消很小。
通过以上三个步骤,得到了三组的用户若干s1(相似)、s2(常用)、s3(项目)但最终推荐人数最多只要6个,这里还涉及到排序填充去重问题。将三组用户分别根据基础数据以使用次数由高到低排序之。s1赋于最高优先级,s2次之,s3最后。开始填充:从s1开始填充,取两个,不足再从s2、s3中取,取足两个,则接着往s2、s3中取,s1不足使用s2、s3填充,s2不足使用s1、s3填充,s3不足使用s1、s2填充,排除已经加入的,直到取满6个或者取完三个集合。

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn