ホームページ  >  記事  >  データベース  >  高效实现诱导输入及推荐执行人的方法

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

WBOY
WBOYオリジナル
2016-06-07 16:30:211162ブラウズ

最新的项目遇到这样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个或者取完三个集合。

声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。