hexstore：语义网数据管理六元索引.doc

Hexastore：语义网数据管理中的六元组索引 Cathrin Weiss Panagiotis Karras Abraham Bernsteun摘要 尽管人们对于实现语义网之梦十分热衷，大多数已存在的RDF数据管理模式都在效率及规模上存在着制约。另外，RDF格式的日益流行也使得克服这些缺陷变得尤为迫切。从关系数据库的角度看来，这些制约都是因为RDF数据模型的本性基于三元组格式。近来的研究已尝试通过为每个属性构造两个独立列表的垂直划分方法来减小其制约性。然而，此类方法在未绑定RDF属性值的查询值上仍存在规模的制约。本文中我们提出一种将三元组作为一种优势的存储模式。这种模式强化了垂直划分思想并将其作为一种逻辑上的结论。RDF数据以六种可能方式被索引，每种对应一种三元组三个元素的顺序。每个RDF元素实例都和两个向量相关联；每个向量的元素是由其他类型中的一个构成，同时还包含附于每个向量元素的第三种类型资源的表单。因而产生了sextuple模式。这种格式允许快速和规模化的查询处理，相比之前的RDF数据管理方法尤其重要优势（高达五个数量），代价就是在索引所占空间的最坏情形的五倍。我们通过现实世界和合成数据的实际查询证实了该方法的优势。1. 导论语义网的前景是希望让每个人能像发布网页那样方便的发布互联的机器可处理的信息。其基础是称为资源描述框架的标准逻辑数据模型。RDF数据是状态的集合，称为三元组，形式为，s表示标题，p是断言，o代指对象；每个三元组描述了s与o之间的联系。一个三元组集合可以表示为直接典型的图，图中节点代表s，o，边代表断言，连接起s，o。网络上日益增加的RDF数据要求开发出高效的系统并对这些数据做有效管理。因而在RDF数据的存储和查询方面人们已作出很多颇见成效的努力。然而，大多数现存三元组存储方法要么是有着规模受限的缺陷要么存在对于特殊类型查询要求特殊的结构这样的缺陷。传统方法要么限制在基于内存的存储，要么映射基于三元组的格式到一个关系数据库，于是他们没能关注基于图的三元组存储，检索，更新的优化。尤其因为RDF三元组历来存储在一个大的三元组表中，这带来了了严重的规模问题。一些其他方法试图通过类关系表来缓解这些问题，这些类关系表将许多三元组特性集合作为其属性。然而，此类方法还是不能克服规模化弊端。最近为解决这一问题的努力是关注于克服规模问题，产生了垂直划分法出现。在该方法中一个三元组表（一个三列的关系表，每列代表一种资源）被写到N个两列表格中，其中N是数据中独立特性的数目。在特性表现如同已绑定的变量的查询情形下，该方法有明显优势。然而，垂直划分法是严格特性导向的。另外，特性绑定的查询在RDF数据检索表达中并非一定使用。因而在未绑定特性查询情形下，方法是对一般化查询找到局部最优。这样该模型的特性导向将不再适用。在本文中，我们提出高效的存储模式应该既能满足数据管理上的规模要求又要在存储，处理及表达方面做到一般化。未达到这两个目标，我们提出RDF数据管理新方法。我们的工作框架是基于RDF多索引框架思想。每个RDF数据元素（例如 Subject）有两个向量相关联，这两个向量与另外两个元素分别对应。另外，第三个RDF元素的列表也附加在两个向量中。总共有六种联系来索引RDF数据，包括了RDF数据三元素所有可能排列顺序。事实上，我们的方法采用了垂直划分理念和多索引系统，并进一步得出其逻辑结论。这种模式既允许基于特性的两列表，也支持基于RDF资源和特性重要性顺序的表示。本文提纲 第二章介绍了RDF存储相关工作，讨论了之前一些方法的弊端。 第三章概括了研究目的。 第四章介绍了我们的语义网数据管理方法，hexstore。第五章介绍实验结果第六章讨论了结果并提出未来研究方向第七章对结论做了概括。2. 背景及相关工作本章我们对RDF现存数据管理方法进行概述。2.1. 传统方法人们提出了很多存储和查询海量RDF元数据的构架方案。然而诸如FORTH RDF Suite，Redland ,Sesame ,3store ,Jena ,DLDB ,KAON ,Rstar， Oracle及rdfDB的系统采用传统关系型数据库Berkeley DB作为其基本的永久数据存储。 在这些系统中，RDF数据被分解成大量单一的状态，以直接存储到关系或哈希表中。这些系统对简单的基于状态的查询能够得到较理想的结果。但是这种基于状态缺少了三元组的一部分或是两个部分，其结果是完善了缺失部分的一组资源，而且也不能代表查询RDF数据最重要的方式。一些更复杂的查询，比如包含很多过滤步骤的，相比来讲更重要些。但是传统方法对此无法胜任。 另外，Jena系统尝试在从RDF数据创建出类关系的特性表，这些表将一列主题上的诸多特性信息搜集到一起，但是这种模式在那些无法从一张表中得出结果需要多张表联合的情形上表现不佳，进一步来说，就是这些表把类关系结构强加于半结构化的RDF数据之上。这些并非自然存在的强加结构导致了表中许多NULL值的稀疏表达。处理这样的稀疏表，不同于一般较稠密的表，需要较高的计算代价。目前的研究集中在构建规模化的RDF元数据发布系统以及在其上的连续查询。2.2. 非传统的RDF数据存储模式其他一些论文中提出了不同于传统的RDF数据存储模式。2.2.1 以图方式存储RDF数据一些人致力于研究以图来表示RDf数据的可能性。然而这些研究的最终结论并为充分考虑规模问题。其中一项研究就是提出了基于路径的RDF数据存储，然而这种基于路径方法最终还是在关系数据库基础之上：它是将子图存储在不同关系表中的。因而此类系统无法提供海量RDF数据查询的规模需要。另外一些研究则关注于衡量语义网内部的相似性并使用有选择性的估计方法来优化RDF数据查询；这些方法基于内存的图实现，仍存在着规模上的限制。2.2.2 多索引方案harth与Dexker提出基于多索引存储RDF数据，该方法要考虑数据上下文。在s,p,o,c形式的小块的十六种可访问模式上，建立六种索引将之覆盖，其中C代表上下文。这一模式允许对小块做快速检索，适用于s,p,o,c任意为变量或是具体值的情形。因此，此法也是定位于简单基于状态查询，不适用于更复杂查询的高效处理。Wood在Kowari系统中提出另一种类似方案。Kowari也是以四方块存储数据，前三块存储的是三元组，第四个是元数据，用来描述状态出现在哪个模型。Kowari也区分四种节点可组织的六种排序，这样一到四个节点的任意集合可被用来找出与之匹配的状态或状态组。这样一来，每个序列都表现为一个复合索引，都包含了RDF的所有状态。Kowari使用AVL树存储及排列这些索引的元素。然而其仍打算使用简单状态查询，其所考虑的六种序列遵循同一周期序列，没有考虑四个小块的十六种可能排列，也没考虑到三元组中三元素的六种排序。因而若忽略元节点，所需索引数目将减小到3，由以下三个循环序列spopososp。这些索引不足以提供给定特性的有序主题列表。因而kowari也不适用于更复杂查询的高效处理。然而在我们看来，这种多索引方法是个值得进一步深入研究的思路。在第四章介绍我们的方法时我们还会对其进行探讨。2.2.3 垂直划分方案 abadi最近提出了垂直划分方案，提出将三元组重写到N个两列表中，每个表记录一个特性，N即为RDf中特性个数。每个表包含了主题和对象列。多值的标题（标题通过同一特性与多个对象相关）.通过表中同标题不同对象的多行来表现。每个表都是按主题排序的，这样可以快速定位，并可以用快速合并连接来重建主体子集的特性信息。该法伴随列向的DBMS（即专为垂直划分实例设计的DBMS，较之行向的在压缩性和表现上有其优势）。接下来他讨论了将特性作为绑定变量的优势，认为在规模语义网数据管理方面达到了大师级。Abadi还指出，表中的对象列也可以做选择性索引，或是在该列上做一份聚集拷贝。以此也提出了可在数据管理上的一种多索引。但是这种多索引限制于特性导向的架构上。另外，论文系统中也未将这一提议实现为基准的一部分。事实上，该垂直划分模型意图完成特性未绑定的查询，否则搜索就限制于几个特性上。尽管Abadi等人不赞成特性表的方案，他们的基于特性的二列表方法却存在特性表的多数缺陷。二列表无非是特性表的特殊变形。二列表与多指属性表很相近，也就是说，后者也是存储了主题和对象。这样看来，其最大创新之处在于将二列表整合到列向DBMS中。另外，Wilkinson也注意到了特性表在碰到未知特性查询时的不足。以此，不论是一般的特性表还是特殊的列向的特性表都在存在未知特性或是特性须在运行绑定的情形下都表现不佳。Abadi确实注意到特性未绑定的情形，然而却没能有效解决该问题。其他方案诸如未严格限制特性值或是在执行时才绑定特性的缺点也都在Abadi等的研究中有所体现：所有的二列表都将被查询到，并且结果会有复杂的联合语句或是连接。于是对于不确定特性值的查询都会对该RDF架构带来问题。在研究中典型地基于如下假设：在所研究的图书馆目录集的221个独立特性中的28个构成的集合是感兴趣的地方；没有特性绑定的查询只能在这个被限制集上。不幸的是，这种假设在现实世界中很难实现。因而我们需要不依赖对数据的特性数目或所执行得查询本性（特性绑定的）作出假设的规模化的语义网数据管理。作为一个实例，图一中的原始数据表展示了LUBM式的三元组实例，该三元组表存储了一个四人小组的学术信息。值得注意的是，并非所有属性都对应表中所有主题。一种可能的有趣的查询是询问如果有人与MIT有关，这种关系是什么；另一个有意思的查询则是寻找这样一些人，他们与斯坦福间的关系与某人和耶鲁的之间关系相同。更进一步，还可以查询人们相关的一所大学所涉及的其他学校，或是查询从某所大学获取的任意类型的学位那些人，或是与两所大学都相关的人，等等。所有这些查询都非特性绑定的；而是需要从多个特性中搜集信息。此外，还有一些需要在涉及到几种特性的同某一对象相关的主题列表上做复杂连接。这样的查询既不是来自于主题，也不是特性，而是对象（比如 某个大学）。3. 动机事实上，属性值上的绑定的查询并非最受关注的，也不是现实语义网应用中的常见查询。多数情形下，具体属性往往是查询语句中的未知部分。我们可以不指定而是去查询资源间的关系（比如随社会网络兴起产生的应用）。正如所见，已存的RDF数据存储的设计并未将这类查询考虑在内。而是围绕如何将具有相同属性或是相同主题的三元组聚集在一起。另一些给出了对于不同属性的对象-主题哈希关键字。就是没有一种能做到根据对象找出其一列相关主题或属性。我们认为这一功能不仅仅是必要的，而且由于RDF数据的三元组特性，它也是能够实现的。也就是说，一个六（3！）索引集将覆盖RDF查询所需的所有访问模式。尽管这样的多索引会导致普通关系表的组合性增长，在RDF数据中确实实际可行的。下一章我们将定义Hexstore，实现这一想法。4. Hexstore：六元组语义网数据索引本章中将讨论一种方法，该法不对特性这一属性特殊化，而是将RDF各元素同等对待。4.1. 关于hexstore的描述为克服前面说提及到的困难，我们将垂直划分法作进一步研究，得出其整个逻辑结论。结论未将任何RDF数据元素区别对待。这样每个元素都需在其上构建其专门的索引结构。进一步地，三个元素在一个索引模式中的每种可能的优先顺序都要加以实现。结果意味着一种六元索引模式。Hexstore中的每个索引都围绕于一个RDF元素并定义了在另外两元素上的优先顺序。这样，相当于二列特性表的HexStore可以通过主题索引，允许每个主题对应多个对象条目，反之亦然。这样特性p关联于主题向量S（p）及对象向量O（p）；在前者中，关联对象Os（p）的列表附于向量中的各主题条目之后，后者中，关联主题So（p）附于向量中的各对象条目之后。此外，Hexstore不把三个三元组属性任意优先顺序看作是理所应当的。RDF三元组并为假设存在一个有特性构建的宇宙。因而，Hexstore不仅创建了特性主导的划分，也创建了主题及对象主导的划分。在前者中，一个给定的主题条目S关联于一个特性向量和一个 向量。一列关联对象Op（s）附于特性向量条目之后，相似地，一列关联特性Po（S）附于对象向量之后。有趣的是，对于给定的主题与属性Sx 与 Py，在这一主题主导的索引中的对象列表Opy（Sx）不同于特性主导索引中的对象列表Osx（Py），因而在索引架构中只需要该列别表的单拷贝。对于对象主导的划分也有一致的结论。总而言之，数据中每个三元组的信息都可由六种方式表达，每一种代表了三元素的一种可能的优先顺序。我们一个顺序中三元素的首字母来命名这六种排序。那么，SPO就代表如下含义：该索引是S主导的划分，带有P向量组并且每个向量都带有一列O。我们采用字典编码的方法。我们使用简化后的字串或是关键字而非整个字串或URI来进行存储。我们将字串映射为整数标识。这样一来，除去六个索引里对于RDF元素使用标识，HexStore也存储包含了一个将关键字映射到相关串的映射表。这些映射组成了字串的字典编码。对于上述讨论，六个索引中有三对有着同样的末端列表。SPO与PSO就有着同样的对象列。事实上留个索引较之三元组表所占空间的最坏情形并非变为其六倍，而是五倍。这是因为三元组中的每个资源都出现在两个头组和两个向量组中，但只出现在一个后续列表里。比如S出现在SPO和SOP的头，出现于PSO，OSP的向量，但对于OPS和POS，两者共用同一个S列表。在最坏情形中，假设存在三元组, Si,Pj,Ok中的每个在给定数据集终止出现一次，然而在Hexstore索引中每个资源的关键字都要有五个新条目。因而最坏情形是原来五倍。在实际应用中，由于大多数RDF资源并非只出现一次，因此还有可能将此代价减小。4.2. 论证Hexstore较之较早的RDF数据管理主要优势概括如下：l 对多值资源简明而有效的处理在RDF的关系化翻译中表现为多值属性的任何资源都是为Hexstore所能接受的。即出现在Hexstore索引末端条目中的列表可以包含多值的条目，该方法比使用二列多只特性表的方法更加简明。若一个主题经由同一特性与多个对象相关，则特性的的各个值都列在表的后续行中。这种类型的特性表叫多值特性表，用来存储特性最大成员数多于一或未知。对于同一主题用多行并非最简明的办法。Hexstore用了最简明方案，注意到了对于任何基于关系的体系要包含多值资源是困难的，因而提出了基于运行长度编码的方案。考虑语义网数据的的半结构化特性，专为多值情形设计的方法是必要的。Hexstore提供了这样一种方法。l 空值的避免只有与特定的其他元素相关的那些RDF元素需要存储在特定的索引中。比如，并非为特定对象Oi所定义的特性无需出现在Oi的索引ops中。这样对于RDF数据翻译到关系时就不会有空值的空间浪费。Hexstore也充分的考虑到这点。l 无需特别选择比如判定那些特性一起存储在同一表中，在关系模式中哪条路径表达式需要表示出来。Hexstore回避了这种特殊判定。Hexstore的体系结构是独有的茄汁取决于手边的RDF数据，没有必要做会影响其表现特别判定。l 降低的I/O代价根据查询中的绑定元素，可制定出一个通常高效的计算策略；该策略只访问与查询有关的内容。其它存储方案则会去访问许多跟查询无关的表；比如，基于特性的方法在进行未确定特性的查询时将访问所有的特性表；另外，进行对象绑定的查询对多数目前已存存储也存在着问题。由于Hexstore的六索引，消除了不必要的数据访问。l 所有第一步的成对连接都是快速合并连接Hexstore使用的所有向量和列表中的资源的关键字都是有序的。这样实现了与一个或一对资源相关的所有资源的排序。因而在查询处理第一步中的成对连接都是一种快速线性时间的合并。其他方案则要付出大量计算代价。l 减少联合与连接为了获取在两个指定对象上存在任何相同特性的主题列表，传统方法将需要多个联合和连接操作(比如查询参与两个学校项目的人员)。比如，受限的多索引法不能提供对结果的快速访问，而是需要分别访问为两个对象定义的所有状态并对标题列表结果做交叉连接。相似地，特性导向方案需要访问所有特性来区别匹配两个对象的对的实例，联合各对象的结果，并连接。HexStore则直接以线性合并连接OSP索引中的两个主题向量来直接提供出结果。在其它查询处理情形下也会这样简单。Hexstore的主要缺陷在于存储空间的利用上；尽管已经提到的简洁的优点，相较于三元组表其也仍有最坏多达五倍的空间的增加。初看起来这五倍看起来是冗余的。然而，我们认为用其换取查询处理时间上的高效是值得的。此外，所增加存储量至多只有五倍。不会取决于任意参数，例如资源的出度或是在体系上的特殊选择。这样，数据引擎可以指望Hexstore的可预测的存储需求。进一步来说，我们认为RDF数据的五倍规模的表达有着更为重要的理由；即首先这说明了RDF是一种数据模型。特别是颠覆了从关系数据库管理系统的观点反对RDF的论点。即通常认为RDF有着内在的欠缺，限制了自身作为一种数据模型。然而，将RDF翻译成六元映射使得其具备了关系数据库所没有的性能上的提升。即在RDBMS中查询过程中执行的很多连接都不是合并连接。这产生较高的了性能代价。然而，在Hexstore中通过使用符合的索引，所有第一步的成对连接都是合并连接。这样Hexstore不仅允许半结构化数据高效精简的表达，避免了任何关系导向方案都存在的稀疏化或空值问题，而且在某些情形下能做到比RDBMS更高效。此外，讲关系型数据库转换为许多类似RDF六索引的表示会带来存储的激增。即一个N属性表需要N！的转换数据。这样，我们的六索引在RDF数据模型三元组特性之上创造了的优势；三元组特性常被认为是RDF的不足。模型的负担成了其特色。最坏五倍的代价在我们看来是值得为其性能买单的。另外，这种需求也在存储技术的容量增加幅度之内。Hexstore在处理更新和插入时会存在些问题；这些操作会影响六个索引，因为降低了速度。然而，现存的RDF应用不涉及大量数据更新。4.3. 讨论路径表达式问题 Abadi已注意到查询路径表达式，作为RDF中的常见操作，可能是代价较大且低效的。这种低效是因为路径表达式查询需要主题对象连接，因为每个路径中心节点n都在中作为主题，又在另一三元组中作为对象。在垂直划分方案里，特性的二列表涉及到了需要连接的路径表达式。这些连接发生在一个二列表的主题列和另一个的对象列。然而这种实现里特性表只按主题排序。这表明还可以有按值列排序的另一个拷贝表，却并为这样实现。于是，S-O连接不是合并连接，因而代价较高。一种解决办法是将选择出的路径表达式存储在不同的关系表中。这种方法是基于某些路径是提前选择好这样的假设之上的，没有一般化的解决问题。Abadi则提出使用他们的二列特性表，将选择的路径表达的结果当做附加的常规特性。这样对于那些以实现的路径表达式就避免了连接，但此法也存在不具一般化的缺点。实现所有路径表达式并不是可行的方案。在一个N长度的路径上，将有（n-1）（n-2）/2=O(n2)可能的待计算的附加特性。从图论的观点看，计算所有路径可能是传递闭包的一个实例，此问题上做了很多研究，却鲜有能在大规模数据管理上的可用的规模算法。Hexstore对这个问题也做了有效地解决，不用提前计算和具体化选择路径表达式。由于它包含的PSO和POS的索引，长为N的路径的第一次的N-1个连接实线性的合并连接，余下的N-2是排序合并连接，即需要对每个进行排序。这样路径表达式查询过程序的数目大大减少。5. 试验评价在我们的实验研究中，我们将我们的Hexstore方法同列向垂直划分法（COVP）在性能上作比较。我们通过我们的pso索引来表示COVP方法，该方法相比纯垂直划分方案有了提高，也就是pso索引将经由唯一特性与同一主题相关的多个对象集合放到小组中。然而，在纯垂直划分中则是对特性P的二列特性表中的每个对象都有一个独立的主题条目,另外我们采用了5建议创建了按对象排序的拷贝特性表。事实上，这个建议在5并未被采用，只是在对象列上使用Postgre实现的垂直划分体系创建了非聚集的B+索引，然而当同样的垂直划分体系实现在为5提供最好性能的列向DBMS时，这样的树状索引不会被创建。此外，5也未对对象列进行排序。创建按对象排序的拷贝特性表的建议就相当于我们的同时具有的pso和pos索引，为了让结论更加完整，我们也在这种两个索引的特性导向存储上进行了实验。为了区分，把单索引的特性导向存储称为COVP1，两个索引的叫COVP2，后者表明了较之单索引使用第二个索引的两大优势，也存在着较之Hexstore方法的限制之处。此外，正如我们在2.2.3中讨论那样，5 是基于假设：所研究的图书目录集221条现存特性中只有一个大小为28的预选集是研究所需的。七个查询中有三个为绑定特性值。特性导向体系应该在此类查询上显露缺陷。同样地，5中四个查询只在提前选择好的28个特性集合当中进行。我们的实验中演示了有无假设两种情形下的结果。为区分起见，在限制于预选集的方法前加上后缀28，于是，COVP2 28就是限制在28个特性上的二索引，COVP2就是无限制的。系统配置为AMD速龙双核 2.8G处理器，16G主存，Linux操作系统。使用Python2.5来实现我们的索引模式原型，在主存中存储索引和进行查询。5.1. 数据描述性能评估时我们使用了两组公开数据集。第一组是真实数据，第二组是人工数据。5.1.1 Barton数据集 我们的第一个数据集，也是5所使用的，取自公共MIT Barton图书馆数据集，有MIT的Simile项目所提供，该项目力图在数字资源，模式，词表，方法论，元数据及服务等方面的交互能力的提升。该数据包含了一堆MIT Barton图书馆的目录的记录。这些记录是从旧的图书馆格式标准MARC（机读目录）转换到RDF的。由于数据来源的多样性，以及目录本身的多样特性，数据结构是非常不规则的。和5一样，我们将Barton的原来的RDF/XMl转换为三元组并且去掉重复项。在数据清洗之后，总共余下61233949个三元组，有285个独立特性。大多数特性是不常见的。总之，Barton集是RDF半结构化本质的很好的实例。5.1.2 LUMB数据集LUMB是一个用于综合性研究的人工基准。使用在学术资源用到的信息建模。其生成在23中有介绍。我们创建了一个有十八个不同特性的十所高校的数据集，得到了6865225个三元组。5.2. 查询描述我们的实验在Barton数据集上进行了七个查询，在LUMB上完成了五个。我们高水准的描述这些查询并给出COVP1,COVP2,Hexstore的各种实现细节。5.2.1 Barton查询在我们使用Barton数据集的实验中，目的是评估多索引方案较之单索引二列模式（用COVP1来表示）的优势。同时也关注增加了第二个基于特性的索引到COVP1中的COVP2方案，也关注Hexstore的表现。为了进行公证的比较，我们使用了与【5】相同的数据集，相应地，我们采用了【6】中的描述。这些查询都是基于典型的使用RDF数据探测的Longwell浏览器得浏览对话。因而是真实世界查询的表现。我们将在下面描述这些查询的以图以及实现细节。Query1（BQ1）. 该查询要计算出RDF数据上各个Type的数目。这涉及到Type这一特性的所有三元组以及每个对象值的数目。Hexstore和COVP2只需要报告出Type的关于对象的pos索引的主题的数目，然而COVP1不具备这样的索引，所以在对象上用pso索引需要做自连接集合。Query2（BQ2）. 该查询要列出为资源Type：Text界定的特性，以及该资源的每个特性的出现频率。使用COVP1处理时需要从Type的pso索引中选出所有带有对象值Text的subject，这些subject在临时表t排序，然后与每个特性的subject向量做连接。在连接时，在对象集上会计数，以此来计算每个特性在t的subject中的频率。COVP2中操作也类似，不过由于pos索引的存在，Type：Text选择是直接得到的。Hexstore包含了该优势，并在第二步中也有优势。即，Hexstore只需在spo索引上合并t里的subject的排好序的特性向量并合计出频率。Query3（BQ3）. 与BQ2相同，该查询要列出为资源Type：Text界定的特性。然而，还需要报告某一特定property的object值出现多于一次的情况。需要在predicate-object对的集合上做计数，选出多于一个object的结果。COVP1的表现较之BQ2中多了步分别去计数每个property的object。COVP2在最后使用pos索引，来检索与各property的t的标题相关的各object。Hexstore因为spo索引的使用有其优势，但在最后它无法直接在spo进行各property的object集的计数，而是需要同COVP2一样使用pos索引。Query4（BQ4）. 同3类似，不过还要考虑Language：France，查询过程差不多，但前期选择不一样。COVP1从Type和Language的pso索引中联合选出subjects。而COVP2和Hexastore需要用pos索引来检索和合并连接Type：Text与Language：France的subjects列表。Q