应对海量数据检索分布式局部索引架构.docVIP

应对海量数据检索分布式局部索引架构 　　摘 要： 通过理论分析对全局和分布式索引架构进行了比较，分析了分布式全局索引架构所能够应对的数据规模的上界和分布式局部索引架构在特定数据规模下相应最优的机群规模等。可以证明，在海量数据背景条件下，由于需要求交集的查询结果数据量过大，会导致全局索引架构在查询结果求交集阶段处理时间过长，以致信息检索系统不能满足用户对系统响应时间的需求，因此局部索引架构会成为在面对海量数据时信息检索系统的必然选择。 　　关键词： 分布式索引； 局部索引； 全局索引； 海量数据 　　中图分类号：TP392 文献标志码：A 文章编号：1006-8228（2013）08-01-04 　　0 引言 　　信息检索系统（IRS：Information Retrieval System）已成为人们日常生活和学习中经常会使用到的工具（如文献检索、网页检索等）。随着数据规模的增大，信息检索系统开始采用分布式系统架构来解决所面临的大数据问题。由此而引出的索引如何在分布式系统之中组织与分布的问题即是分布式索引架构问题。全局索引架构（Global Index）与局部索引架构（Local Index）是两种最主要的分布式索引架构，几十年以来，大量的研究和实验对它们的优缺点进行了详细分析与比较。 　　全局索引架构针对整个数据集建立一个统一的索引，然后根据索引关键字的顺序将索引切分成多个索引片段，每个索引片段存放在一个单独的索引节点上。全局索引架构在执行一个检索时所需要访问的索引节点相对较少，但这也导致其每次读取的数据量较大；由于数据的处理需要集中在中间节点上进行，全局索引架构网络传输的数据量更大；所有的数据处理操作集中在中间节点上执行，在面对海量数据时这将成为全局索引架构不能满足用户需求的关键瓶颈；由于是针对整个数据集建立倒排索引，因此在全局索引架构在面对索引的更新与增量时相比局部索引架构难度更大。 　　分布式局部索引架构即是将大的数据集随机或者按照一定的规则划分成多个小数据集，针对每个小数据集建立单独的索引块，一般一个索引块会存放在一个单独的索引节点上。局部索引架构的每个索引节点独立的完成检索，因此具??较好的容灾容错性能；在索引更新及增量时，由于其每个索引节点相互独立，因此更新与增量的影响范围较小；由于索引节点返回给中间节点的数据都是经过处理的，因此相比全局索引架构而言局部索引架构网络传输的数据量更小。局部索引架构的缺点在于检索的开销较大，其每一个检索条件都会被发送到所有索引节点上去执行。 　　混合索引架构结合了全局索引架构与局部索引架构的优点，但高度的数据冗余造成了极大的数据膨胀，在大多数的应用当中这一点通常无法被用户接受；同时副本数量过多也导致数据的更新与增量难度更大。由于混合索引架构的明显缺陷，我们在后面的文章中将不再对其进行分析。 　　1 相关工作 　　分布式索引架构的研究从上世纪九十年代初开始，但早期有关分布式索引架构[1，2，5，7，9]的研究由于存在数据量较少、硬件环境限制、应用场景不同等问题，导致大家的研究结果有很大的分歧，对于当前海量数据背景下分布式索引架构研究的参考意义不大。Cambazoglu等在2006年通过实验结果[8]说明局部索引架构有较快的响应速度，而全局索引架构的吞吐率较好，这和我们的观点是一致的，但实验的结果是在较少的数据集上取得的（30GB），因此没有说明全局索引架构在响应时间上问题的严重性。 　　文献[3，4，7]等都是针对全局索引架构进行优化，他们或者考虑如何减少网络传输的数据量[3，6]，或者使用新的数据处理方式[4]，但都没有从根本上解决全局索引架构的时间延迟问题，而且用于实验的数据量都相对偏小，没有以海量数据为应用背景。 　　2 理论及分析 　　在介绍本文方法之前，先说明将用到的数据结构。倒排索引记录是Key-Value结构的，其中Key是检索关键字，Value是由数据项组成的有序集合。数据项的格式为（ID，score），其中ID表示某个检索对象的编号（例如文档编号），该检索对象中含有检索关键字Key，Value中的数据项都是依据ID排序的；score表示检索关键字Key在该检索对象中相关性的大小。实际应用之中检索关键字在一个检索对象中的相关性信息比较复杂，我们在模拟实验中简单的使用一个浮点型的非负数值score表示。 　　2.1 实现全局索引的关键步骤 　　在全局索引架构下对用户检索的处理步骤如下。 　　⑴ 用户提交检索条件，检索条件中含有一个或多个检索关键字Key，中间节点分析检索条件并将各个不同的检索关键字Key发到其相对应的索引节点； 　　⑵ 收到检索关键字Key的索引节点即在倒排索引中检索对应的倒排记录并将检索结果返回给中间节点，检索结果即是