共享资源分布式索引

2025-01-20

共享资源分布式索引（共4篇）

共享资源分布式索引篇1

1 工作原理

每个集合节点都维护着自己的一套同节点组中已知集合节点的列表。一个集合节点可能从一套预先定义好的种子集合节点列表中获取其它集合节点的信息。集合节点周期性地选择另外一些随机数量的集合节点, 并向这些集合节点发送其已知集合节点的一个随机列表。同时, 集合节点也周期性的清除掉那些没有响应的集合节点。因而集合节点维护着其已知集合节点的一个大致上连续的网络。

当一个节点发布了一个新的广告后, 这个广告就被SRDI服务使用主键 (比如广告名称或ID) 进行了索引。SRDI只将广告的索引存入集合节点, 从而最小化那些需要存入集合节点的数据量。集合节点也将广告的索引存入另外一些集合节点之中, 这些集合节点是根据广告索引的一个哈希函数计算结果选择的。

本地网络中的查询 (比如在一个子网内) 会借助一个定义为广播或多播方式的传播协议传播到本地网络的节点之中。如果接收到该查询的节点本地缓存中包含要查询的信息, 则该节点会直接响应发出该请求的节点。发往本地网络以外的查询首先被转发到与本地网络相连的集合节点上。该集合节点先在其本地缓存中查找是否有满足查询要求的信息。如果这个集合节点包含请求的信息, 那么它就会直接回复发出该请求的节点, 并且不会再传播这个请求。如果这个集合节点在其SRDI缓存中包含此请求资源的索引, 那么它就会通知发布该资源的节点, 使那个节点可以直接响应发出该请求的节点, 在这种情况下, 集合节点只存储了广告的索引, 而没有存储广告本身, 因而集合节点是不能直接响应请求节点的。

如果集合节点没有包含请求的信息, 那么JXTA网络就会使用一个默认的有范围限制的遍历算法在一套集合节点中遍历寻找包含了请求信息广告索引的集合节点。为了减少一个查询的TTL值, 一个查询的路径可能会被一个网络映射函数修改。为了避免可能导致网络不稳定的Ping-Pong命令的影响, 一个跳跃计数用于指定请求被映射/转发的最大次数。一旦查询到达了节点, 该节点就可以直接回复最初发起该查询的节点。

SRDI使用一个SHA1哈希寻址方案。在这个方案中, 一个160位的哈希地址空间在一个集合节点的有序列表之中分配。当索引被接收后, 哈希函数就会根据这些索引计算出他们的复制地址, 然后将他们复制到这些地址对应的目标集合节点之上。

2 配置实例

图1是一种配置的实例。节点A是一个边缘节点, 并配置为使用R1作为其集合节点 (Rendezvous) 。当节点A生成一个发现或搜索请求后, 该请求就会首先被发送给它的集合节点R1, 在这个实例中, 该请求也会通过多播方式发送给同一子网的其它节点。

3 结语

在SRDI的支持下, JXTA网络可以快速地对一个节点发出的公告查询进行响应, 从而提高了JXTA网络中节点间信息传递的效率, 为基于JXTA框架的应用程序开发提供了方便。

摘要：通过对共享资源分布式索引 (SRDI) 服务的支持, JXSE为JXTA网络中查询请求的传播提供了一个高效的机制。集合节点维护了一个由边缘节点发布的广告的索引。当边缘节点发布了一个新广告, 该节点就会使用SRDI服务, 将新广告的索引保存到集合节点中。通过这种集合-边缘节点的层次体系, 查询只在集合节点之间传播, 从而在很大程度上减少了搜索一个广告所涉及的节点数目。JXTA网络的操作依赖于其解析分布式查询的能力。JXTA使用了一种称为共享资源分布式索引 (SRDI) 的分布式算法, 以创建并维护网络中资源的一个总体索引。论述了SRDI的工作原理和简单应用实例。

关键词：JXTA,SRDI,共享资源分布式索引

参考文献

[1]杨天路, 刘宇宏等.P2P网络技术原理与系统开发案例[M].北京:人民邮电出版社, 2007.

[2]Sing Li.JXTA2:具有高性能、海量伸缩性的P2P网络.

共享资源分布式索引篇2

在文档信息检索中,索引技术是加速检索速度,提升检索效果的重要技术手段。随着大数据时代的到来,需要检索的数据量越来越大,传统的集中式索引结构已经难以满足当前对检索性能的要求。使用分布式索引[1]是解决这一问题的有效手段。在文档信息索引中,倒排索引模型[2,3]是最常用的索引结构。文档分布式索引构建的关键问题在于对倒排索引的分割。分布式索引分割方式主要有两种[4]:基于词表进行分割和基于文档进行分割。基于词表分割方式按一定规则将全局索引的索引项按一定规则分配到不同节点,而基于文档进行分割方式则将文档按一定规则分配到不同节点,然后在相应节点建立局部索引。

分布式索引优化是近年的研究热点之一。文献[5]通过两级索引对基于文档分割的方式进行了改进。该方法中增加了一个额外索引用来存储关键词所在文档的节点信息,检索时依据该索引选择特定的节点检索,无需遍历所有节点。该方式的缺点在于需要建立额外索引记录关键词的分布,并且对于分布比较广泛的关键词,依然需要在大量节点中检索,性能提高有限。文献[6]利用检索日志对索引项进行分割,尽可能的将查询时同时出现几率较高的关键词分配到一个节点上。该方法减少了查询时需要工作的节点数,提升了检索效率。但是该方法存在两个问题:一是需要之前的检索日志,在构建初期可能需要进行大量调整直到索引项分布稳定;二是没有解决基于词项分割导致的系统负载不均衡的问题。文献[7]使用一种3D分布式索引结构将两种分割方式进行了结合,避免了两者各自的缺点,但是该方式没有考虑索引项的内容和文档的相关性等因素,同时需要存储较多副本,其时间复杂度和空间复杂度很高。

文献[8]使用Kmeans聚类算法对文档进行分割,检索时选择与关键词相关性最高的集合进行检索,从而避免了基于文档分割索引导致检索需要遍历所有节点的问题,提升了检索效率。但是,该方法中聚类过程在单一节点进行,在大数据环境下,这个节点会成为整个系统的瓶颈,限制系统性能。另一方面,Kmeans算法聚类结果严重依赖初始点的选择,容易产生较差的聚类结果,从而影响到检索效果。

针对以上两个问题,本文提出一种基于并行的优化Kmeans算法的分布式索引构建方法。通过优化Kmeans聚类算法的初始点选择,消除Kmeans算法对随机初始点选择的依赖性,提升聚类效果,优化了索引分布;通过在分布式系统中并行化Kmeans算法消除系统的瓶颈,提升索引的构建效率。本文建立了包含4台计算机的小型分布式系统,利用MapReduce计算模型实现了该方法,并使用多个领域的大量新闻数据进行了实验,验证了本方法的有效性。

2 聚类算法优化及并行化

2.1 Kmeans聚类算法及其优化

Kmeans聚类算法[9,10]是一种经典的聚类算法。该算法首先确定若干个随机初始点作为初始聚类中心,然后计算每个向量到每个聚类中心的距离,将向量分配到与其距离最小的中心点所属的聚类中,一直重复这一过程直到算法收敛,每个向量所属的聚类都不再变化。

Kmeans聚类算法的缺点是过于依赖初始点的选择,聚类结果容易陷入局部最优状况,从而影响聚类效果。文献[11]提出一个通过在数据集一个维度上刻画初始聚类边界的方式选择初始中心的方法;文献[12]提出了基于量子遗传算法的Kmeans聚类算法;为解决局部最优解的问题,文献[13]提出了通过构造数据集的泰森多边形来辅助选择初始中心的想法。这些优化方法都能比较有效的提升聚类效果,然而这些方法的时间复杂度都很高,并不适合在大数据环境下使用。

文献[14]提出一个基于取样的初始点选择算法,通过对随机取样得到的样本进行聚类操作确定全局聚类的初始中心点。本文对其进行了改进,在原有基础上增加了新一轮聚类操作,通过对样本合集的聚类操作,减少了算法结果对样本分布情况的依赖,并在分布式系统中实现这一算法。新算法的核心在于对少量样本进行两轮多次聚类,选择最优的聚类中心作为全局聚类的初始聚类中心。算法流程如下:①通过随机取样的方式在总体数据中取样若干次,得到若干组样本。②对取样得到的若干组样本分别进行聚类操作,得到若干组聚类中心。③将所有的样本合并在一起,得到一组较大样本,分别以第一次聚类得到的各组聚类中心为初始聚类点对样本合集进行聚类操作,得到第二轮的若干组聚类结果。④对每一组聚类结果,使用样本集中所有文档距其所属聚类的中心点的距离和作为衡量标准,选取距离和最小的一组聚类结果作为最优结果,使用该聚类结果的各聚类中心作为全局聚类的初始聚类中心。

该算法的伪代码如表1所示。其中,输入的Data为数据集,K为聚类个数,N为取样次数。Ri为第一轮聚类操作对每组样本聚类后的聚类中心,SS为样本合集,SRi为以Ri为初始聚类中心对样本总集SS进行聚类的聚类中心点。SRS为第二轮聚类操作的所有聚类结果中心点。BestResultIndex函数计算第二轮聚类结果中样本数据与其所属聚类中心点的距离和,选择距离和最小的一组,将其索引k返回,然后算法将SRk作为最终的结果返回,作为全局聚类的初始聚类中心。

假设该算法共进行m次取样,通过控制样本数量可以保证样本的聚类操作能够在单一节点中使用内存存储完成。假设每次取样数量为n,样本总数为N,则n<N;在Kmeans聚类中,聚类数据较小时,通常迭代次数也会较少,假设t为样本迭代次数,T为全局聚类迭代次数,则t<T;由于样本数量较少,同时使用内存存储完成聚类操作,减少了IO时间,因此每次迭代的时间都将远低于全局聚类的单次迭代时间,即it(Si)<<it(Data)。在n比较小时,合理控制m的大小,样本总集SS的大小依然远低于文档总数,设t’为样本合集聚类迭代次数,则有t’<T,it(SS)<<it(Data)。则初始化中心点的总体时间消耗约为:m×t×it(Si)+m×t’×it(SS)将远低于全局聚类的时间消耗T×it(Data),因此在大数据环境下,通过合理选择样本数量和取样次数,本算法的时间复杂度将处在一个较小的范围内。

2.2 并行化聚类算法的实现

本文使用MapReduce计算模型在分布式系统中实现了该优化的Kmeans聚类算法。文本聚类主要分为两步,一是文本向量模型表示,二是聚类过程。本文针对整个文本聚类过程共设计了4个MapReduce任务,其中两个MapReduce任务完成文本向量模型表示,一个MapReduce任务完成初始点的选择,最后一个MapReduce任务完成全局聚类过程。

(1)第一个MapReduce任务完成文档集特征词信息的统计。该任务中,Map任务以每篇文档的文档Id和文档内容作为输入,对文档进行分词并统计每个词语出现的次数。然后以词语为Key,以输入的文档Id和该词频率为Value输出。Reduce任务将同一词的所有所属文档及频率合并在一起,计算每个词的全局频率,即DF值,然后依据DF算法,对所有的词进行筛选,选择DF值在文档总数的0.5%到90%之间的词作为文档集的特征词,最后以特征词为Key,以该词的分布信息为Value输出。整个过程的输入输出信息如表2所示。

(2)第二个MapReduce任务完成文档的向量模型表示。本文使用TF-IDF算法[8]计算每个特征词的权重。Map任务输入的Key为特征词Id,Value为特征词的DF值和分布信息。Map任务得到每个特征词的DF值后计算其idf值,然后以该词所在的每个文档的文档Id为Key,以特征词Id,idf值以及该词在该文档中的频率ni,j为Value输出。Reduce任务输入的Key为文档Id,Value为该文档包含的所有特征词信息列表。Reduce任务通过idf值和ni,j计算出每个特征词的tf-idf值即该词权重,最后以文档Id为Key,文档包含的特征词及其权重为Value进行输出保存,完成文档的向量模型构建。其具体的输入输出信息如表3所示。

(3)文档向量模型创建完成后,使用一个MapReduce任务完成初始中心点的选择。该MapReduce任务主要用于从HDFS中将样本数据取入内存。执行MapReduce任务之前首先通过随机取样的方式选取若干组样本。然后通过MapReduce任务将Hadoop分布式文件系统(Hadoop Distributed File System,HDFS)中保存的相应的文档的向量数据存入内存相应的向量数组。其输入输出信息如表4所示。

Reduce任务将各组的样本向量数据存入内存相应数组,然后在内存中对样本数据进行聚类操作,经过两轮聚类后得到一组最优的聚类中心作为全局聚类MapReduce任务的起始聚类中心。

(4)最后一个MapReduce任务完成全局聚类过程。Map任务以之前得到的文档向量数据为输入,其Key为文档Id,Value为文档向量数据。在Map任务中计算该文档与每个聚类中心的距离,并选择与其距离最近的中心点所属的聚类作为该文档所属的聚类,随后以聚类号为Key,文档向量数据为Value输出。Reduce任务接收每个聚类的所有文档向量数据,计算出该聚类的最新中心点,然后以聚类号为Key,该聚类包含的所有文档Id为Value输出保存。其具体的输入输出信息如表5所示。

整个ManReduce任务运行一次即为算法的一次迭代,每次迭代完成,检查每个文档所属聚类有没有变化,如果发生了变化则继续下一次迭代,如果不再变化则说明算法已经收敛,输出的结果就是最终的聚类结果。

经过以上4个MapReduce任务,由原始文档得到了若干个聚类,可以依据聚类结果对原始文档进行分割,然后在分布式系统中建立各个集合的局部索引,完成分布式索引的构建。

3 分布式索引构建

经过聚类操作后得到了若干个聚类结果,将原始文档按照聚类结果进行分割后就可以构建分布式索引。

本文使用Lucene结合MapReduce计算模型和HDFS构建分布式索引。Lucene是一个开源的检索工具包,经过多年发展,已经成为一个十分成熟、可靠的检索工具包。由于Lucene不支持在分布式文件系统中读写文件,因此,在构建索引时需要首先在节点本地构建索引,完成后上传到分布式文件系统。

分布式索引的构建过程使用一个MapReduce任务完成。其中Map任务主要负责将文档内容从HDFS中读取,并传递给Reduce任务,索引的构建主要在Reduce任务中进行。Map任务读取每一个文档,将文档中需要建立索引的文档题目、文档内容、文档链接等内容传递给Reduce任务,Reduce任务接收每个文档作为输入,然后根据文档中需要建立索引的域与其内容建立一个HDFSLDocument对象。该类是一个自定义的输出类,实现了Writable接口,拥有一个HashMap成员变量,这个HashMap中存有该文档需要索引的域和内容。然后Reduce任务使用LuceneOutput作为输出格式类,以文档所属聚类为Key,HDFSLDocument为Value输出。LuceneOutput类为自定义的输出格式类,继承自FileoutputFormat类。在该类中重写了wirte函数,该函数中从document对象中提取内容然后使用Lucene在节点本地建立临时索引,最后将索引上传到HDFS中完成分布式索引的构建。其输入和输出如表6所示。

经过以上多个MapReduce任务,构建了基于原始文档的若干个局部索引,每个局部索引所属文档属于同一聚类,相关性高,不同局部索引间则相对独立。进行检索时,可以选择与关键词相关性最高的一个或多个集合索引进行检索,从而避免对所有索引的遍历。

4 实验和验证

4.1 测试环境与数据

本文搭建了包含4台机器的小型集群,使用Hadoop平台构建分布式系统。其中一台机器作为NameNode,其他3台作为DataNode。各节点的操作系统均为Ubuntu 14.04.3,Hadoop版本为2.7.1。

本文采用搜狗实验室提供的包括新闻、体育、时尚等多个频道的810000条左右的新闻数据作为实验数据,每条新闻包括标题、内容和链接,其中每条新闻内容的长度在50字到4000字之间。

4.2 索引构建效率对比实验

本文分别对不同大小的新闻文本数据分别使用基于单节点原始聚类的分布式索引构建方法和基于并行优化聚类的分布式索引构建方法进行索引构建。使用两种方法构建索引所需的时间如图1所示,其中纵轴表示时间,单位是分钟,横轴表示文档数量,单位为万篇。

由图1可见,当文档数量小于200000时,由于单节点聚类方法大部分的计算可以在内存中完成,而并行聚类方法需要进行初始点优化、IO操作和任务调度等额外操作,单节点聚类方法的索引构建时间比并行聚类方法所需的时间更短。随着文档数量的增加,并行聚类方法的优势逐渐体现,即使有额外的优化初始点工作,系统运行时间相比单节点聚类方法仍然有优势。从对比图来看,随着数据量的增加,单节点聚类方法的索引构建时间的增长速度不断增加,索引构建时间趋向于指数型增长,而并行聚类方法的运行时间近乎线性增长。根据这一趋势,数据量继续增大时,两者的差距会进一步扩大。在海量文档环境下,本文提出的基于并行聚类的分布式索引构建方法相比传统的基于单节点聚类的分布式索引构建方法的在性能和效率方面具有较大优势。

4.3 检索结果查全率对比实验

本文对810000条左右的多个领域的新闻数据分别使用基于单节点原始聚类的分布式索引构建方法和基于并行优化聚类的分布式索引构建方法建立分布式索引,并选择多个领域的关键词进行检索。进行检索时,通过CORI算法[15]选择与关键词相关度最高的一个集合进行检索,计算检索结果的总体查全率[16]和Top100查全率。CORI集合选择算法是一种经典的集合选择算法,将关键词的频率信息和贝叶斯推理网络相结合,是一种十分有效的集合选择方法。其计算公式如下:

其中tf指文档集合di中包含特征词ri的文档的数量,df表示包含特征词ri的文档集合的个数,cw表示所有文档集合中所有特征词的数量,avg＿cw是各个文档集合的特征词平均值。|c|是文档集合的数量,b是常数系数,通常取0.4。

检索结果的查全率指检索结果中相关文档的数量与整个文档集中相关文档数量的比值。其计算公式为:

其中M为检索结果中相关文档的数量,N为整个文档集中相关文档的数量。Top100查全率计算方式与全局查全率类似,其公式为:

其中M为某个关键词检索结果排名前100的文档在整个文档集中相关性排名前一百的100个文档中出现的次数。最终的实验结果如图2所示。

由图2可见,采用本文提出的方法创建的索引上的检索总体查全率和Top100查全率都比较高,尤其是Top100查全率,基本可以保持在0.9以上,部分关键词接近1.0。并且由对比图可见,新方法的所有关键词的两个查全率都优于在传统方法建立的索引上的检索结果,说明本文对Kmeans聚类算法的优化取得了很好的效果,最终建立的索引分布比较合理,检索结果更加优秀。

5 结束语

共享资源分布式索引篇3

随着现代科学技术的不断发展, 互联网每天都会产生海量的数据, 怎样高效地对海量数据进行索引已经成为人们越来越关注的问题。传统的基于单机或者集中式的数据索引模型已经不再适合海量数据的索引。为此, 本文设计并实现了一种索引海量数据的平台模型, 该模型利用Solr[1]分布式索引器、Hadoop[2]分布式集群, 以HDFS[3,4]分布式文件系统、Map Reduce[5,6]并行计算模型、Zookeeper[7]同步协同系统以及HBase[8,9]分布式数据库技术作为处理和索引海量数据的方法, 是一种分布式的索引模型。此外, 本文设计的分布式索引模型是利用大量廉价的硬件设备组成的集群来构建一个高可靠性和良好扩展性的并行分布式系统来索引海量数据的。

1 分布式索引模型设计与实现

1.1 Solr分布式部署

本文设计的分布式平台利用三台PC机搭建Hadoop集群, 其中一台PC机为master主节点机器, 另外两台PC机为slaver从节点机器。整个分布式集群环境采用Zookeeper分布式同步协同系统来管理所有节点, 确保写入文件的一致性。

Hadoop集群中PC机的具体配置如下, 三台普通的PC机是位于同一个局域网内的, 硬件配置如下:master机器, 主频是2.93GHz, 内存为2G, 硬盘为160G, IP:10.3.11.26;slave1机器, 主频是2.93GHz, 内存为2G, 硬盘为160G, IP:10.3.11.27;slave2机器, 主频是2.93GHz, 内存为2G, 硬盘为160G, IP:10.3.11.28。

1.2 分布式索引模型实现

1.2.1 Solr配置

通过solrconfig.xml文件, 可以对Solr进行配置, 因为solrconfig.xml文件中默认设置了怎么对索引进行相关的处理、怎样对特殊的文字进行特别的显示以及用户的相关搜索和其他功能方面的请求, 特别的是, 该文件还指定了很多操作方法的各种属性, 比如用于特定缓存的操作方法的属性、用于指定Lucene管理索引的操作方法的属性等等。

1.2.2 中文分词的定制整合

Solr索引器默认有分词的功能, 但是其分词的效果并不是很理想, 也远远达不到用户的检索需求, 为此, 本文采用IKAnalyzer分词器。IKAnalyzer分词器是一个开源的、基于Java语言的轻量级的中文分词器, 它是基于Lucene全文索引工具包的, 功能上来说极其强大, 同时, 它也是一个独立的面向Java的分词工具, 最主要的是还支持用户自定义词典的扩展, 所以本文就将IKAnalyzer分词工具整合到Solr中去。

如图1所示是Solr对文档建立索引的流程。

1.2.3 分布式索引参数优化

在Solr中默认的配置文件在性能上并不能达到最优, 对Solr索引器的索引效率有影响的主要是3个参数:merge Factor、RAMBuffer Size MB和运行Solr的JVM内存。

首先, 第一个参数merge Factor的功能是控制索引合并的一个参数, 具体就是当本地硬盘上的子索引的个数达到设定的参数值时, 所有的子索引就进行合并操作, 释放硬盘空间;第二个参数RAMBufferSize MB的功能是用来控制buffer中索引文档的内存上限, 如果buffer中的索引文档个数到达参数设定的上限值时就写入本地硬盘;最后一个参数是运行Solr的JVM内存, 这个根据PC机的内容情况考虑, 在不影响PC机正常运行的情况下越大越好。最后通过多次实验, 本文对这些参数进行了优化, 优化前的设置为merge Factor=10, RAMBuffer Size MB=32, JVM=256M, 优化后的设置为merge Factor=40, RAMBufferSize MB=300, JVM=1024M。

2 实验结果与分析

2.1 基本准备

准备计算机:一台master, 两台slave, 配置如上。

安装软件:

Hadoop版本1.1.2

Jdk版本1.7.0_25

安装路径:/home/administrator/hadoop-1.1.2

数据目录:/home/administrator/sll

集群信息如表1所示。

2.2 设定三台机器免密码登陆

先是确认已经连上网了, 然后输入命令, 然后在当前目录下会创建.ssh文件夹, 如果没有可以手动创建。然后产生密钥。

然后验证ssh是否安装:

administrator@master:~ssh localhost

上面的最后一步会产生图形的密钥。

2.3 配置和启动Hadoop

修改Hadoop集群的配置文件, 首先修改coresite.Xml中fs.Default.name对应的属性值为hdfs:∥ (主机+端目号) ;接着修改mapred-site.Xml中mapred.Job.tracker对应的属性值为10.3.11.27:9999;然后修改master文件中localhost为Hadoop集群中主节点Namenode的IP地址。最后在master主机中的/etc/hosts文件中添加Hadoop集群中所有从节点Datanode的IP地址。以上的操作完成后, 拷贝master节点上的所有配置过的文件到slave节点上去, 至此, Hadoop集群就配置完成了。

集群在正式启动之前都会检查节点数是否满足启动的最低要求。如果满足要求则会出现如图2所示的画面。

当启动完一段时间后, 检查集群的存活节点, 如图3所示。

2.4 实验设置

本文采用支持实时查询的HBase数据库来存储Solr索引文件, 使用实验室的3台PC机搭建Hadoop集群环境, 然后对比单机环境下和Hadoop集群环境下的写入和读取时间。如图4所示, 显示了单机环境下和集群环境下与不同线程个数的写入时间关系。从图4中可以看出, 当Hadoop集群中的并发线程越多, 数据写入的时间明显低于单机情况下的写入时间, 验证了本文设计的分布式索引模型高效的写入性。如图5所示, 显示了单机环境下和集群环境下与并发线程个数的读取时间关系。从图5中可以看出, 随着集群中线程数的增加, 集群环境下的读取时间明显低于单机环境下的读取时间, 验证了本文设计的分布式索引模型高效的读取性。如图6所示, 读取时间随着集群中线程数的增加而降低, 由此验证了本文设计的分布式索引模型良好的扩展性。

2.5 结果分析

从上面的实验结果可以看出, 由于采用了Hadoop集群平台, 编程过程被大大简化。基于HDFS和HBase的结合的特点, 本索引模型能够快速、高效地索引海量数据, 在简单、经济的同时, 又能很好地满足应用需求。

3 结束语

本文利用Solr分布式索引器设计并实现了基于Hadoop和HBase的分布式索引模型。首先利用Solr分布式索引器对文档建立索引, 同时利用基于HDFS的HBase分布式数据库达到高效的读取和写入数据, 同时使用Zookeeper同步协调系统来确保写入数据的一致性。最后的实验结果显示, 本文设计的分布式索引模型达到了高效索引海量数据的要求, 并且具有良好的扩展性。

本文设计的索引模型也有其不足之处, 整个集群的效率只有在节点数达到很庞大的时候才能真正的体现出来, 由于实验室设备的有限, 还有更多的实验需要进行测试, 这也是下一步的研究内容。

摘要：随着互联网上信息量飞速增长, 海量数据的索引出现了难题, 现行的索引方案已经难以提供高效、可靠的服务, 为此, 设计并实现了一种针对海量数据进行索引的平台模型。该平台模型首先利用Solr分布式索引器生成索引文件, 然后利用Hadoop分布式集群, 以HDFS分布式文件系统、Map Reduce分布式并行计算模型、Zookeeper同步协同系统以及Hbase分布式数据库技术来处理、协调管理索引和存储海量数据, 最后通过实验测试, 该平台模型可以克服现行的海量数据索引时存在的效率低的问题, 同时具有良好的扩展性和可靠性。

关键词：Hadoop集群,Solr,Hbase

参考文献

[1]王小森.基于Solr的搜索引擎的设计与实现[D].北京:北京邮电大学, 2011.

[2]陆嘉恒.Hadoop实战[M].北京:机械工业出版社, 2011.

[3]Tom White.Hadoop权威指南[M].周敏, 等译.北京:清华大学出版社, 2011.

[4]Borthakur D.HDFS Architechture Guide[Z/OL].http:∥hadoop.apache.orgldocs/r1.0.4ihdfs_design.html, February 2013.

[5]Borthakur D.The hadoop distributed file system:Architecture and design[Z/OL].http:∥hadoop.apache.org/common/docs.2007.

[6]郑启龙.基于Map Reduce模型的并行科学计算[J].微电子学与计算机, 2009, 13 (8) :13-17.

[7]Apache Zookeeper maintained by Apache[EB/OL].http:∥zookeeper.apache.org/, 2013.

[8]Apache HBase maintained by Apache[EB/OL].http:∥hbase.apache.org/, 2013.