项目简介

Ossean   Solrcloud   索引  接口 

21069?1479794125
发帖时间:2017-04-10 21:38
更新时间:2017-04-10 21:38

1:毕业设计任务书上前两个点均已完成并优化,现构建排序工具并展示

2:目前已经使用本机部署solrcloud导入50万项目,返回效果还不错

下一步:

1:熟知ossean的从爬虫之后开始的每一部分的代码

2:用java写一个前端显示界面作为展示项目搜索和帖子搜索,预计项目条数有300万,帖子条数有300万

3:大约下周可以开始撰写论文

回复 ︿
0?1470885445
登录后可添加回复
21069?1479794125
发帖时间:2017-04-10 21:15
更新时间:2017-04-10 21:15

项目最终排序分值 = 项目文本相关度 * 项目影响力 

1:项目影响力的计算

项目影响力的计算来自于与该项目相关联的各个帖子关注度之和,帖子关注度中考虑了评论数、浏览数、创建时间三个属性,问题如下:

(1)有些项目由于关联了很多个帖子,会导致影响力很大,会导致最终的排序分值影响远远大于项目的文本相关度,应该在此处设置最大阀值;

(2)有些处于程序bug或者项目自身原因,未关联帖子,项目影响力结果为0,相乘之后导致最终结果为0,应该设置最小阀值;

(3)创建时间和浏览数存在的关系并不是之前单纯的线性,数据统计和论文介绍,平均来看,帖子的浏览量是随着时间往后推移浏览量增长率变得越来越大,最后趋于平缓。

2:其他

(1)项目表中存在synonyms字段,应该做进一步细的处理,才可以更好的返回结果

(2)项目表中有关联帖子数值存在,但是影响力为0的情况,可能是程序bug,还未发现原因

回复 ︿
0?1470885445
登录后可添加回复
21069?1479794125
发帖时间:2017-04-02 12:01
更新时间:2017-04-02 12:01
搜索项目与帖子相比,不同之处在于项目与帖子的匹配,剩下可以一以贯之,可以考虑引入项目自身的关注度
回复 ︿
0?1470885445
登录后可添加回复
21069?1479794125
发帖时间:2017-04-02 11:18
更新时间:2017-04-02 12:10

搜索“帖子”工作总结

本文通过建索引和搜索两个阶段来比对原ossean和现已完成的solrcloud工作

一、建索引:

   1:时间效能
     
经过使用solrcloud,和调优(tomcat调优、对所建索引字段在solr中存储形式调优、建索引时合并及存取策略调优)对比如下:


版本

建索引

Ossean使用solr1.8

平均270/

 

 

Solrcloud5.2.1

节点

服务器性能

 

 

平均4300/

服务器1

可用内存:45G

jvm3G

服务器2

可用内存:1G

jvm0.5G

服务器3

可用内存:20G

jvm3G

 

2:原ossean建索引时间过长,且solr单机支持定期增量建索引和全量更新很麻烦;

现有采用solr5.2.1+tomcat7.0+zookeeper3.4.6,构建solrcloud。

①Solrcloud可以一边建索引一边查询;

②创建索引时间大大减少,且定时增量建索引可以通过配置和编程实现




二、搜索:

发现ossean相关问题:

1:搜索算法需要改进:
①:仅采用文本相关度搜索,未结合帖子业务本身

②:文本相关度的搜索策略过于简单

2:同义词设置有问题:

关键性词语设置了同义如mysql postgresql是同义词,但是搜索时会返回很多用户并不想要且靠前的数据。

3:使用solr默认解析处理器,未加修改,导致用户查询词可能会作为solr内置参数,会出现bug

4:采用or查询,搜索结果集较大,造成查询累赘;

 

现已解决的相关问题:

1搜索算法

关键词为文本相关度,关注度,二次排序

1)根据文本相关度打分(RelScore)返回结果集(Result)的顺序(Ranki)分两部分处理:Rankii<=20) 和Ranki(i>20)

Ranki(i<=20)的结果集重新排序,按照Score=帖子文本相关度打分(RelScore+帖子关注度(InfScore)的搜索策略,生成ReRanki的集合,返回结果集Result ReRankii<=20ResultRankii>20

2)文本相关度打分:具体策略可查看附件中edismax

帖子关注度打分:

①获取当前文档的solrfieldvalue:评论数review,浏览数view_num,创建时间t

②对t进行处理,转化为当前时间与创建时间天数之差t0

T = t0 / r0, r0为控制时间衰减因子,控制衰减在某一范围内;

InScore = min((review + 1 × view_num + 1 × eT / r1r2


r2为根据文档查询权重遍布的影响力阀值,r1,r2共同降低影响力影响最终分值权重,review1view_num1的目的是为了防止由于爬取错误,或者新数据为0的情况。

其中,r0 = 500r12r20.3

2:修改同义词配置,同义词增加在一些不必要的形式和行为上,如variablevariables,connectconnected

3:修改solr默认解析处理器,采用solredismax方式代替布尔查询。

4:采用and查询,多域搜索,设置权重

①减少结果集的返回

②保证了搜索的多样性

③保证了结果的准确性

爬虫建议:

1stackoverflow帖子的comments内容并未爬取,显然,这是必要的,上面有很多有用的搜索信息

2:帖子在社区中处于动态变化的,评论数、回复数、浏览数都是爬取一次后一成不变的,这样对搜索策略有影响

目前问题

接口的搜索算法代码均已实现和部分测试,但是部署接口至测试服务器,由于有一系列问题(安全协议,接口访问,外网配置)暂未完成接口的实现 


( 121.5 KB) 李耀宗, 2017-04-02 11:16
回复 ︿
0?1470885445
登录后可添加回复
21069?1479794125
发帖时间:2017-03-31 13:06
更新时间:2017-03-31 13:06

solrcloud部署为整个接口的描述

solrcloud安装步骤为具体实现

edismax打分为当前打分

( 16.609 KB) 李耀宗, 2017-03-31 13:00
( 121.5 KB) 李耀宗, 2017-03-31 13:00
( 13.563 KB) 李耀宗, 2017-03-31 13:01
回复 ︿
0?1470885445
登录后可添加回复
21069?1479794125
发帖时间:2017-03-15 03:43
更新时间:2017-03-15 03:43

一:stackoverflow

1:在使用搜索时候有一下几种方案:

(1)”info“,此方式只针对比较主流的“特殊关键查询词”,(事先定义一个“特殊关键查询词库”比如:“mysql”,“github”返回功能类似“百度百科”。——该方式在ossean主界面有体现。

(2)当且仅当搜索词没有命中“特殊关键查询词库”时,会出现“relevance”字段,此显示方式主要由于“文本关联度“。大体算法:

  搜索三个字段:title,tags,content;

  搜索方式:AND;

  多词搜索时:

        a:字段设置权重title>tags>>body;

        b:如果输入”张三  李四“,要求”张三和李四词汇“必须同时出现在某一个字段中,字段权重大的优先返回;

        c:若未同时出现在同一个字段中,返回零结果集;

  此处其实可以后期考虑增加votes,评论数,点击率

(3)“newest”,对同时命中一个字段的所有文档进行时间排序,返回最新时间;

(4)此外还有“votes”,“frequent”等类似。

二:现有搜索

(1)对Title,Tags,Body字段建索引并搜索;

(2)采用AND搜索;

(3)字段设置权重:Title:2.0,Tags:1.0 Body:0.1

(4)在三个字段中采用“or”的搜索方式:如果输入”张三  李四“,要求”张三“和”李四“词汇必须出现在这三个字段(哪个均可)中,字段权重

大的优先返回;

(5)对于一个字段中同时命中“张三 李四”的情况,solr中coord分值给的要高。

三:跟stackoverflow对比

优点:

(1)由于title(标题)和tags(标签)大都反应了文档中心,即使出现搜索”张三 李四“时,”张三“出现在Title,“李四”出现在“Tags”中也基本符合情况,保证了结果集的返回;

(2)Body权重设置较小。有两点优点:

        a:保证部分标签或主题并未给全文档描述信息,给予补充;

        b:保证结果集的返回;

    没有采用or的方式,其实感觉对帖子搜索使用or或者and差别不大,因为title和tags里面信息提取都精确,而且body设置权重较低,不会出现常用词匹配过多的问题,而且采用suggest的方式,用户搜索的时候可以提示搜索词的正确性和多量性,具体带研究。

(3)打分排序时,coord给的分值参与决定排序,所以跟stackoverflow中同时命中一个字段的效果一样。

四:下步想法

(1)大规模测试数据集,现在数据源较少(爬虫只取了700万stackoverflow),想要使用测试版服务器进行初步建索引尝试比对结果。

(2)定义查询语法,如用户输入”+“关键词,则相应的在用户输入的短语查询中,对应的词给予权重加成。此处也可以事先针对计算机领域的一些关键词建库加权重,先对用户搜索短语检索是否出现在库中,然后进行搜索。

(3)加入评论、创建或更新时间、投票数,觉得这三点没必要加入文本相关度打分中,这三点影响不够大,可以单独劈出一块,让用户手动选择,然后返回结果。

(4)在打分中加入点击率,url链接数,觉得这两点是可以考虑加入打分系统的。

(5)针对计算机领域,手工或者根据用户搜索设置一些扩展词,主要是解决一些分词不准确的问题。

(6)设置同义词,解决比如用户输入中文,但是相关信息在stackoverflow中也有体现。

(7)根据用户检索词建立搜索记录,对搜索关键词缓存建表,关键词之间又建立关系,给用户返回另一种体验,也可以考虑加入搜索排序中(就像百度一样那样的,一个是最下方提示相关,一个是直接在返回结果中体现)。

(8)情感分析,自然语言处理了吧,这一块其实可以往后放一下。

(9)关于集成问题,还有很多方面待研究,比如xml(其他格式也行,看前端要求)返回至前端,其中包括suggest、高亮、返回排序、统计数等。

回复 ︿
0?1470885445
登录后可添加回复
21069?1479794125
发帖时间:2017-03-13 23:09
更新时间:2017-03-13 23:09

之前遗留的问题:

采用and查询,如在两个字段内搜索张三李四,某个字段同时出现张三李四才会返回结果,而不是字段一出现张三,字段二出现李四也能返回,减少了结果集的返回

解决:

1:编译IK源码,解决结果集数量的返回问题。

2:分词问题,添加基本扩展词库、停用词库、同义词库,并进行了相关测试,后续还待补充。

3:debug模式下调试每条记录搜索对应的总打分,总分是lucenc评分机制。


现对Title,Tags,Body三个字段建立索引并设置权重为10,8,2

现有问题:

由于分词原因和lucene评分机制问题,返回最优结果不是完全匹配度高的文档,而是分词加权后分值高的文档

预计解决方案:

第一种:多次调试,设置最优分值

第二种:修改lucene评分机制,先进行完全匹配设置相关权重,其次再进行分词匹配,保证最优结果

预计解决时间:

周三之前

回复 ︿
0?1470885445
登录后可添加回复
21069?1479794125
发帖时间:2017-03-13 01:02
更新时间:2017-03-13 01:02

今日和雅蓉学姐验证了搜索输入到返回的效果,并讨论了ossean目前的一些问题。

solrcloud配置模糊查询还需再行处理,关于之前提的要在用户搜索词设置权值的功能由于solr的封装性,仍需一点时间。

回复 ︿
0?1470885445
登录后可添加回复
21069?1479794125
发帖时间:2017-03-07 22:42
更新时间:2017-03-07 22:42

工作:

感谢王涛老师昨日的指导和鞭策

1:完成了对stackoverflow表的索引的建立,以及cloud和单机solr的对比

2:完成增量索引的测试

3:对数据表对多词查询有了基本认识

规划:

明日之前可以初步完成多词简单搜索匹配的完成,由于牵扯词库、算法可能后期还要对搜索进行优化

观ossean:

之前本地装了ossean版本,但是只导入了一个表,今日与帅气的老师、学长,漂亮的学姐讨论,具体观察了在线版的ossean:

构架超前、合理

界面布局规整又不乏精美

设计资源丰富而又具有代表性

针对开源又别有新意

深深的震撼感。。

回复 ︿
0?1470885445
登录后可添加回复
21069?1479794125
发帖时间:2017-03-01 00:13
更新时间:2017-03-01 00:13

开始对mysql中较大数据进行建索引,出现问题,查摆过程中,服务器内存使用率过高。师兄在跑python程序,调配了tomcat和对部分数据进行优化,发现不是内存影响的问题,主要是因为同时对mysql数据访问的问题,后来继续查摆问题发现:建索引若是通过mysql数据表建的话比较麻烦,费时,可以用solr API 接口solrj直接对xml文件解析建索引。明日开始编程实现。


回复 ︿
0?1470885445
登录后可添加回复

© Copyright 2007~2021 国防科技大学Trustie团队 & IntelliDE 湘ICP备 17009477号

问题和建议
还能输入50个字符 提交

加入QQ群

关注微信APP


×