Compass---Search Engine (3)

七所有支持

当索引一个对象，xml或一个简单Resource，它们各自的属性将被添加到索引。这些属性稍后将可以被明确地搜索，比如说title:fang.大多数时间用户希望在所有不同的属性上搜索。由于这个原因，默认情况下，支持一个“所有”属性。这个属性其实就是为了匹配搜索引擎的不同属性的化合物。
    所有属性提供高级特征，比如说使用所给属性的声明映射。举个例子，如果一个属性用一个特定的分析器标识了，这个分析器将用于将属性加入到所有属性。如果它不被分词，它将无分析添加。如果配置了一个特定的boost值，所有属性的部分，当“hit”时，将导致结果的高排名。
    所有属性允许全局配置和每个映射配置。全局配置允许完全失效所有特征（compass.property.all.enabled=false）.它可以排斥来自所有属性的别名（compass.property.all.excludeAlias=true）,并且可以为所有属性设置长期载体（compass.property.all.termVector=yes）
    每个映射配置定义可以以映射级别配置上面的设置（他们覆盖全局设置的），他们包含在一个all标签里，
应该是在不同映射里的第一项，下面是一个osem的例子：

<compass-core-mapping>
<[mapping] alias="test-alias">
<all enable="true" exclude-alias="true" term-vector="yes" omit-morms="yes"/>
<[mapping]>
</compass-core-mapping>

八子索引散列发

可搜索内容使用Compass不同的映射定义（OSEM/XSEM/RSEM）映射到搜索引擎。Compass提供将搜索内容分割为不同的子索引的能力，在下一张图里显示：

上面图表里的A,B,C和D代表别名，一次代表可搜索内容的映射定义，A1,B2等等，上面提到的可搜索内容的真实实例。图表显示映射可搜索内容到不同子索引的不同选项。

1 常值子索引哈希法
一种匹配别名的简单方式是通过映射所有它的可搜索内容到同一个子索引，定义如何将可搜索内容映射到搜索引擎（OSEM/XSEM/RSEM）已经在各自的映射定义文件完成。下面是定义一个常值映射到子索引的两种方法，第一个是:

<compass-core-mapping>
<[mapping] alias="test-alias" sub-index="test-subindex">
<!-- ... -->
</[mapping]>
</compass-core-mapping>

提到的[mapping]是由别名test-alias代表的将映射它的实例到test-subindex.注意，如果sub-index没有定义，将默认是alias的值。
另一种选项，可能不习惯用于定义常值子索引散列法，但是显示在这里是为了完整性，是通过在映射定义里指定SubIndexHash的常值实现完成的。

<compass-core-mapping>
<[mapping] alias="test-alias">
<sub-index-hash type="org.compass.core.engine.subindex.ConstantSubIndexHash">
 <setting name="subIndex" value="test-subindex"/>
</sub-index-hash>
</[mapping]>
</compass-core-mapping>

2 模子索引哈希法（Modulo Sub Index Hashing）
常值子索引哈希法允许将一个别名（与它代表的所有可搜索实例）映射到同一个子索引中。以子索引为模的散列法允许将一个别名分割到多个子索引中。分割是通过用所有可搜索内容id的字符串值散列别名值，然后使用一个特定的大小值来进行模操作来完成的。也允许为产生的子索引值设置一个常值前缀，将在下面的图表里显示：P49

3 自定义子索引哈希法
ConstantSubIndexHash 和 ModuloSubIndexHash实现了Compass的SubIndexHash接口，是Compass自带的。自然地，一个实现SubIndexHash接口的自定义实现能在映射定义里配置。

一个SubIndexHash接口的实现类必须提供两个操作。第一个，getSubIndexes,必须返回子索引哈希实现能产生的所有可能的子索引。第二个，mapSubIndex(String alias,Property[] ids) 使用所提供的别名和id计算所给的子索引。如果子索引哈希实现类也实现了CompassConfigurable接口，不同的设置参数就可以注入。这里是一个用自定义子索引哈希实现映射定义的例子：

<compass-core-mapping>
<[mapping] alias="A">
 <sub-index-hash type="eg.MySubIndexHash">
  <setting name="param1" value="value1"/>
  <setting name="param2" value="value2"/>
 </sub-index-hash>
<[mapping]>
</compass-core-mapping>

九优化器

    随着在read_committed部分提到的，每个成功提交的脏事务在各自的子索引里创建另一个片段。所有包含的片段越多，获取操作就会越慢。这就是为什么保持索引优化并且在一个控制的片段数量里是重要的了。我们通过合并小片段到大片段里完成的。

    优化过程工作在子索引级别，为每个执行优化。在优化进程中，优化器将为脏操作锁定子索引（只有要求优化时候）。为了体谅其他的脏操作，这将导致在保持一个已优化的索引和花费更少的实际在优化过程中之间的一个权衡。
    Compass伴随着一个默认的优化器实现。默认的优化器将尽力维持不会比所配置的片段的最大数量大（默认为10）。当使用optimize()和optimizer(subIndex)接口是应用，也应与于优化器被定时运行的时候。它也提供特定的支持，接口级别，用提供的片段的最大数量优化。
    这里是一个运行最大片段数量为20的默认优化器的配置的例子，并且运行在一个间隔为90秒预定方式（默认为10秒）

<compass name="default">
<connection>
 <file path="target/test-index"/>
</connection>
<searchEngine>
 <optimizer scheduleInterval="90" schedule="true" maxNumberOfSegments="20" />
</searchEngine>

compass.engine.connection=target/test-index
compass.engine.optimizer.schedule=true
compass.engine.optimizer.schedule.period=90
compass.engine.optimizer.maxNumberOfSegments=20

十合并
在特定操作执行之后，Lucene将对索引执行不同片段的合并。你执行的合并越少，搜索就越快。你做的合并越多，指定的操作将越慢。Compass将对何时发生合并有一个很好的控制。这极大地依赖于事务隔离级别和所使用的优化器以及他们如何配置。

1 合并政策控制着哪个合并将被作为是发生的确定索引上。Compass允许简单配置两个伴随着Lucene的合并策略，LogByteSize（默认）和LogDoc,也可以配置自定义实现类。配置类型可以使用compss.engin.merge.policy.type来完成并且包含logbytesize，logdoc，或全限定类名MergePolicyProvider的可能值。
LogByteSize可以使用compass.engine.merge.policy.maxMergeMB和compass.engine.merge.policy.minMergeMB进行进一步配置。

2 合并调度
合并调度控制一旦需要一个合并，合并操作时怎么发生的。Lucene伴随着内置的ConcurrentMergeScheduler(在最新创建的线程上执行并发合并)和SerialMergeScheduler(在同一个线程执行合并操作)。Compass扩展Lucene并且提供ExcutorMergeScheduler，可以利用Compass内部的执行器池（或并发或后台运行管理）没有创建新的线程的开销。这是伴随着Compass的默认合并调度。
配置合并调度的类型可以使用compass.engine.merge.scheduler.type来完成，有下列可能值：executor(默认)，concurrent(Lucene并发合并调度)，和serial(lucene序列合并调度)。他也可以有一个MergeSchedulerProvider实现类的全限定名。

Compass---Search Engine (3)

猜你喜欢