11879?1461414358

曾雅蓉 (Student)

RongEr

国防科学技术大学

Ta在确实 over 3 years

  • 湖南-长沙
  • 2016-01-21开始使用
  • 6380次访问(自2016年5月)
Ta的动态
11879?1461414358
指派给   未指派
发布时间: 09/05/2017 11:00
更新时间:09/28/2017 16:34

SolrCloud是基于Solr和Zookeeper的分布式搜索方案。在分布式索引中,原来的大索引,将会分成多个小索引,solr可以将这些小索引返回的结果合并,然后返回给客户端。


SolrCloud优势:


  1. 集中式的配置信息,使用ZK进行集中配置。启动时可以指定把Solr的相关配置文件上传Zookeeper,多机器共用。这些ZK中的配置不会再拿到本地缓存,Solr直接读取ZK中的配置信息。
  2. SolrCloud对索引分片,并对每个分片创建多个Replication。每个Replication都可以对外提供服务。一个Replication挂掉不会影响索引服务。
  3. 近实时搜索:立即推送式的replication(也支持慢推送),可以在秒内检索到新加入索引。
  4. 查询时自动负载均衡:SolrCloud索引的多个Replication可以分布在多台机器上,均衡查询压力,如果查询压力大,可以通过扩展机器,增加Replication来减缓。
  5. 自动分发的索引和索引分片:发送文档到任何节点,SolrCloud都会转发到正确节点。
  6. 事务日志:事务日志确保更新无丢失,即使文档没有索引到磁盘。



搭建流程:

服务器:42(测试版:48)

版本信息:zookeeper3.4.8 + solr 5.2.1 + tomcat7

1.下载solr

2.下载zookeeper,solrcloud的所有配置需要zookeeper统一管理

3.下载tomcat,solr需要搭载在容器中提供服务

具体配置可参考: http://blog.csdn.net/l1028386804/article/details/52090099

4.服务器solrcloud集群现搭载包含三个solr节点,每个节点包含3个分片。

暂时是在服务器搭建伪分布式集群solrcloud集群,后期数据规模扩大后,会扩展到真实的分布式机器上。




回复 ︿ (1)
  • 用户头像
    余跃 1年前

    Due date set to 09/30/2017

0?1470885445
登录后可添加回复
11879?1461414358
指派给   曾雅蓉
发布时间: 09/05/2017 11:19
更新时间:09/28/2017 16:34

一、分别对项目数据和帖子数据构建collection:

项目:TestCollection,对应本地配置文件为ConfOsp

帖子:TestMemos,对应本地配置文件为MemosOsp

建索引步骤(以建立项目索引为例)


1.上传配置文件

java -classpath .:/root/solr/solrcloud/solrhome1/server/solr/WEB-INF/lib/* org.apache.solr.cloud.ZkCLI -cmd upconfig -zkhost 127.0.0.1:2181,127.0.0.1:2182,127.0.0.1:2183 -confdir /root/solr/solrcloud/cloud_conf_osp -confname ConfOsp
2.创建collection:


 curl "http://localhost:8080/solr/admin/collections?action=CREATE&name=TestCollection&numShards=3&replicationFactor=1&collection.configName=ConfOsp"


3.查看collection:

curl "http://localhost:8080/solr/admin/collections?action=LIST&wt=json"


4.建立索引



curl "http://localhost:8080/solr/TestCollection/dataimport?command=full-import&clean=false&commit=true"


5.查看索引状态
curl "http://localhost:8080/solr/TestCollection/dataimport?command=status"

6.索引查询示例


curl "http://localhost:8080/solr/TestCollecition/select?q=rails"


二、整合到前端rails中

1.搭建一个java webservice服务,使用solrcloud集群检索关键字,返回检索结果。

2.在rails中调用soup包的wsdlDriver访问该webservice服务,在前端展示返回结果。

回复 ︿ (2)
  • 用户头像
    余跃 1年前

    Due date set to 09/28/2017

  • 用户头像
    曾雅蓉 1年前

    Description updated (diff)

    % Done changed from 0 to 100

0?1470885445
登录后可添加回复
11879?1461414358
指派给   未指派
发布时间: 08/02/2017 23:26
更新时间:08/02/2017 23:26

1.现在已处理的可利用信息有:项目间贡献者(提交过commit信息)的交集、pull request核心开发者交集(pr的合并或关闭,重开)、issue核心开发者交集(issue的合并或关闭,重开)、项目owner的follow关系

其中项目owner的follow关系数量极少,只有20条关系,而且大都不准确直接忽略。

  • 贡献者交集数量>=5的关系数量:1152    >=1 :  275844
  • pr核心开发者交集数量>=5的关系数量 :145   >=1 : 2509
  • issue核心开发者交集数量>=5的关系数量 :102  >=1 : 715


2.两种做法:

  • 选出和原项目A有依赖关系的多个项目B、C,采取投票制,训练回归模型确定项目影响权重。Acc(A) = W0 * H(B) + W1 * H(C) ,H(B)表示B的模型对A的数据的分类结果。W0、W1又可以通过pr和issue交集等信息确定,即W0 = X0 * Count(Pr) + X1 * Count(Issue) + X2 * Count(Contributors),整个可以看做是线性回归问题,最终确定权重X0,X1,X2。
  • 根据依赖关系强度按比例抽取各个项目的issue数据,最终综合数据训练模型对原项目A进行预测


3.先采取第一种做法

  • 由于数据计算量较大,首先将所有项目的模型和vocab存储下来
  • 采取随机抽一个项目对原项目进行跨项目预测作为baseline,之后通过引入项目依赖关系等先验知识,再次对原项目预测分类比较结果

回复 ︿
0?1470885445
登录后可添加回复
11879?1461414358
指派给   未指派
发布时间: 07/23/2017 17:31
更新时间:07/25/2017 17:04

1. 实验数据:issue > 400  bug_ratio 在(0.2-0.8):  874个项目。


2. 目标: 目前项目内的bug分类已经有了结果,下一步工作是找到多种方法构建项目依赖关系网络,对某一个项目,找到相关联的项目族群,并使用项目族群的issue训练的模型对该项目issue分类,看最终得到的结果能否逼近使用项目本身的数据进行分类的准确度。


3. 如何构建项目间的关系网络?

  • 参考论文MSR15:【Ecosystems in GitHub and a Method for Ecosystem Identification using Reference Coupling 】

1. issue, pull request, and commit 的评论信息中对其他项目的交叉引用(文本链接)反映了项目间的技术依赖,关联权重为项目间交叉引用的数量。

2.项目的核心成员(owner)的开发行为能够反映项目的技术依赖。     

【a】项目 Aowner follow 项目 Bowner,则A & B有关联,关联权重0表示没有关联,1表示单向follow2表示双向follow

b】任意一个项目的owner star了项目AB,则A & B有关联,关联权重有同时star这两个项目的owner数量决定。

3.项目的外围贡献者(Contributors )不能反映项目间的技术关联。

  • 从某一类入手,比如ruby的或python的项目,另外现在github上ruby的项目有直接dependents数据,显示前100页依赖于该项目的项目数据,可以直接爬下来分析一下,看能否构建关系网络,但是874个项目中ruby的项目只有43个,可能会很稀疏。
  • 关于comment信息,ghtorrent中有commmit的comment信息,但是只有前256个字符,可能还是需要重新爬取,issue和pr也需要重新爬,现在可以利用爬取的时间先分析owner的开发行为。
  • 其他可以考虑的还有编程语言,项目描述的文本相似度等。


回复 ︿ (1)
  • 用户头像
    余跃 2年前

    怎么只有1万多个项目呢?你是不是限制语言了啊?

    这样的话,生态系统建立起来会不会特别稀疏?

0?1470885445
登录后可添加回复
11879?1461414358
指派给   未指派
发布时间: 07/17/2017 19:23
更新时间:07/22/2017 13:14

1.初步筛选项目并爬取issue数据

  • 选取带labelissue>100 的项目12797个
  • 爬虫爬取得数据最终包含11675个项目,有一些项目有错误已不存在,对应带标签的帖子数为6414872条。


2.网页数据预处理

    Github api接口中的issue idproject id和后台数据库中的id没有联系。通过issues表单的repo_idissue_id匹配爬虫数据,且一个issue可能有多个标签,将issue_id和label插入新表

issues_labels。


3.进一步筛选项目

    [a]处理issue标签:
  • 选取表示issue类型的标签格式比如'kind:*','type: *'等8种格式
  • 截取后半段指示具体issue类型的标签,选出公有目录类型(前半段,比如'type:','kind:'等)大于5的作为issue具体类型标签(比如'bug','feature'等),对于一些不是指示类型的标签直接人工过滤掉(比如'duplicate','test','support')
  • 然后扩展到包含该具体类型标签的所有实际标签。包含大概4222个。
  • 统计覆盖这些标签的issue数量(2493903条),得出取前40个标签(2214117条)可以覆盖88.8%的帖子数。
  • 将这40个标签划分为'bug'和'non-bug',然后对issue进行标注。
  • 对于既是'bug'又是'non-bug'的数据大概64378条,占比2.9%,影响不大所以全部归为'bug'类型。

    最终得到1106332条bug,1107785条non-bug。


    [b]统计项目带标签的issue数量及bug比率


  • 有带标注的issue:10564个项目
  • issue>500 : 722个项目
  • issue > 500  bug_ratio 在(0.2-0.8):611个项目
  • issue > 400  bug_ratio 在(0.2-0.8):  874个项目


错误记录:


1.Incorrect string value: '\xF0\x9F\x98\x84\xF0\x9F

对应UTF-8编码格式中的4字节编码。正常的汉字一般不会超过3个字节,这里出现4个字节实际上是它对应的是智能手机输入法中的表情。如果想存储4个字节的必须用utf8mb4类型。不而要使用utf8mb4类型,首先要保证Mysql版本要不低于 MySQL 5.5.3。

更改mysql表格字段编码格式,并且在python处理脚本中读取数据时也要设置为utf8mb4。

conn = pymysql.connect(host='127.0.0.1', port=3306, user='root', passwd='123456', db='ghtorrent_2017_5', charset='utf8mb4')


ALTER TABLE issues CHANGE body body MEDIUMTEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL;


2.python解析网页数据时,ast.literal_eval()能将数据还原成它本身或者是能够转化成的数据类型。并且相较于eval(),会进行类型安全检查




回复 ︿ (1)
  • 用户头像
    曾雅蓉 2年前

    Tracker changed from 缺陷 to 任务

    Description updated (diff)

0?1470885445
登录后可添加回复
11879?1461414358
【功能】 ossean前端相关配置说明 正常
指派给   未指派
发布时间: 07/08/2017 13:32
更新时间:07/20/2017 18:33
回复 ︿ (1)
  • 用户头像
    曾雅蓉 2年前

    attachment 前端部署.pdf added

0?1470885445
登录后可添加回复
11879?1461414358
【周报】 曾雅蓉周报-2017/4/22 正常
指派给   未指派
发布时间: 04/22/2017 19:05
更新时间:04/22/2017 19:06

1. ossean :本地搭建solrcloud环境,准备前端整合solrcloud索引

2.熟悉tensorflow(高软作业+为实现deep learning算法打基础)

3.自然辩证法考试

回复 ︿ (1)
  • 用户头像
    曾雅蓉 2年前

    Tracker changed from 缺陷 to 周报

    Description updated (diff)

0?1470885445
登录后可添加回复
11879?1461414358
【周报】 曾雅蓉周报_2017-4-15 正常
指派给   未指派
发布时间: 04/15/2017 10:12
更新时间:04/15/2017 10:12
1.ossean github版本推进:

    进程:已有初步测试版本结果(ossnudt.trustie.net)

    现有问题:

  •  现在搜索功能无效,前端搜索功能建索引太慢,跑了两天才建了1.36%;希望尽快整合李耀宗师弟的SolrCloud
  • 29上汇总帖子之前出错了,断流了一段时间,所以现在匹配帖子没有更新,具体的乾坤在跟进,会尽快解决。

 

2.论文阅读:

    Toward Deep Learning Software Repositories(MSR 2015)


3.自然辩证法考试+高软大作业。

回复 ︿
0?1470885445
登录后可添加回复
点击展开更多
问题和建议
还能输入50个字符 Submit

加入QQ群

关注微信APP


×