分类目录归档：译文

这是译文,原文地址:http://xapian.org/docs/termgenerator.html 翻译:一米六二(renlu.xu@gmail.com) Xapian 1.0索引/查询时的term处理方式 简介 在Xapian 1.0，默认的索引方式已发生了重大变化(这些都是来自旧的索引方式在真实世界 中的实际经验教训).本文档介绍了新计划，并跟过去的旧方式做对比. 词干处理 最明显的区别是抽取词干后term的处理。 在此之前,所有的词都是词干后再索引,但是没有前缀;所有大写词都并不做词干抽取处理(但是会变小写),并加一下”R”前缀.这样做的理由是，人们希望能够搜索准确的名字（比如像英语词干提取就合并了Tony和Toni 。但当然，这也使得句子开头的一个词，标题文字，另外德语所有名词都是大写，这些都是会这样编入索引。无论是正常的和带R的前缀都会带着位置信息被索引。 现在，我们索引所有词的小写形同时带上位置信息,以及词语未做词干抽取状态加上”Z”的前缀,但这时不带位置信息.默认情况下会使用一个Xapian::Stopper 以避免索引stopwords的词根（测试表明，这会省下数据库1％的大小）。 新的索引方式允许精确短语搜索（这是旧的方式所不支持的）。现在NEAR 操作符只能应用在词语的未取词干的形式上，不过这也够了.我们还可以禁用对查询中大写词语的词根抽取，以在对物定名词搜索时获得更好的效果。现在Omega的$topterms 总是能正确建议一个未抽取词根的形式! 为词根形式添加前缀的主要理由是，他们的量比较少！另外,一个附带好处是，它开创了一种多种语言的词根形式,如Z:en ,Z:fr: 或其他的随便什么语言. QueryParser中对.结尾的特殊处理(这会因为人们粘贴过来的一段文字而错误地被触发)已经去掉了.此功能之所以出现,主要是为了支持欧米茄的topterms加入词根形式;但是现在Omega已经可以建议未取词干的形式,因此就不再需要这个功能了. 成词字符(能组成词的字符,比如英文中26个字符就是,而|符号和:号就不是) 默认情况下，Unicode字符的CONNECTOR_PUNCTUATION 分类下的字符(_和其他常见的一些字符)不用做其他形式的处理就是成词字符了,这样可以更好地索引一些标识符.以前像time_t这种就需要一个短语搜索了. 尾部的+和＃仍然可以包含在Term中（尾部最多可以有3个这样的字符），但-默认不可以了。把他们包含有进来会有益的例子(nethack–,cl-),好处并不十分明显,相反,他们作为连字符更常见更有用.这些例子并不引人注目的好处是它（ 的nethack -和 Cl -），它往往胶连字符到条款。 嵌入的单引号’（(撇号)现在可以包含在Term中了.以前版本中这会使得短语搜索变慢,同时索引中会被带进来垃圾Term(didn’t 会变成ditn 和t）。各种Unicode使用的撇号都映射到了ASCII的形式。 其他很少量的字符（这些字符取一个词的Unicode的定义中）如果是包含在两个成词字符中的话也可以视为是Term的一部分;，。，，和少量其他字符在出现在两个十进制字符之间时会视为Term的一部分. 本文由蝌蚪安尼友情赞助.

这是译文,原文地址:http://xapian.org/docs/sorting.html 搜索结果的排序 简介 默认情况下，Xapian按相关性递减的原则来排序搜索结果.然而，它也可以让搜索结果按其他指标，或其他指标和相关性的混合排序。 如果两个搜索结果从排序标准来判断是相同的分值,那他们的返回顺序就取决于它们的文档ID了.默认情况下，他们会按文档ID的升序排序（这样,一个较小的文档ID就会排前面），但可以设置为降序排列enquire.set_docid_order（enquire.DESCENDING）;。如果你无所谓，你可以告诉Xapian随便使用任何一种排序都有序enquire.set_docid_order（enquire.DONT_CARE）;。 按相关性排序 默认情况下Xapian使用的是BM25加权公式,它有许多参数可以设置。其中的部分参数我们使用默认值,在应付一般的工作时,它们工作得很好。这些参数的最佳值取决于数据被索引的方式和要运行的查询的类型，所以你也许可以改善一下，通过调整这些值来使搜索系统更有效，但它是一个繁琐的过程,人们通常懒得这么干。 去BM25文件了更多的细节。 其他权重方式包括TradWeight和BoolWeight. TradWeight实现了原来的概率加权公式，基本上是BM25的一种特殊情况（它就是BM25在K2 = 0，K3= 0，b = 1和min_normlen = 0的加权，只不过用一个常量线性缩放鸟）。 BoolWeight给所有文档，因此排序完全取决于其他因素。 您也可以实现自己的权重系统，只要用一个数值的形式来量化匹配的条件的(减去不匹配的条件),再考虑一些跟查询term无关的统计资料(比如说,标准化文件长度),就大功靠成鸟。 例如，这里有一个“几何匹配法” – 每个匹配就给一分： class CoordinateWeight : public Xapian::Weight { public: CoordinateWeight * clone() const { return new CoordinateWeight; } CoordinateWeight() { … 继续阅读 →

这是对http://www.flax.co.uk/blog/2009/04/02/xapian-search-architecture/ 的简单翻译. 严格意义上,这篇投递跟flax无关,只是为向直接使用Xapian的人们介绍一下Xapian搜索的体系结构。这不是给有经验的Xapian hacker提供的，也不是介绍如何使用Xapian的入门文章（入门文章请访问这里）。 Xapian API是相当复杂的，而且在索引和搜索时,QueryParser,Term,document values 经常困惑着人们.要特别指出的是,Xapian本身并无一个”field”的概念,field这东西是flax的组件做的更高层次的抽象和封装.Xapian只是有Document ，包含一个整数标识ID，document包含： Terms （通常是词或短语，可以带位置信息,带位置信息的叫POST）， VAlue （通常是一个简短的字符串，也可能是包含的二进制数据），以及 data （可以是任何数据，但往往是一些适合显示的文本）。 这三种类型的对象是完全独立的，虽然在一个应用程序级相关（terms经常是从document data中切分得到的）。在索引时,Term会由一个文本处理器生成,当然也可能是单独地直接给出.term一般是专为字串搜索设计的 –比如一个特定的词是否在某个文档中出现？Value被用于其他多种用途，例如如范围搜索（如日期），排序，以及其他一些跟应用程序相关的方面。document data不能被用于搜索，它主要被搜索程序在得到搜索结果后使用,像是在搜索结果列表中显示文件的信息等. 当document被添加到一个Xapian数据库时，term，value和document data会单独存储在专门为了查询而优化的不同的数据结构里.如下图显示： 这是搜索过程的一个相当简化的说明.但从根本上来说，查询就是对term和value的匹配.一个典型的查询可以是如下示例: llamas和yaks Xapian匹配器查找数据库中的词条，并收集一个含有这个词条的document的列表。如果查询只包括terms，那么这个列表就构成了一个搜索结果并作为一个MSet返回给客户端代码。 但是，如果查询包含range组件（如范围2009年1月1日- 2009年4月2日 ），那将会需要一个寻第二查询阶段。匹配器会检查候选MSet中每个document中相应的value，并与查询范围比较。如果它不属于查询范围，该document就被弹出结果集，否则该document就被返回到客户端。 最后，通过自定义一个MatchDecider类的子类,还可以定制Xapian的搜索过程.这些子类可以访问document的任何属性，但因为性能方面的原因，通常只使用value。比如说,一个典型的应用是,根据用户的权限来过滤搜索结果:匹配器会比较用户的权限等级和候选文档的ACL设置,并决定是否在查询结果中返回该文档. 搜索优化 虽然这个模型过于简单，它仍然可以帮助我们改进数据库设计和搜索规划。在一般情况下，在磁盘上,term和postion list比value要远大得多,因此基于term的搜索一般受限于IO.这就是为什么有足够的RAM来提供磁盘缓存（数据库大小的10％或以上）时，搜索性能可以大大提高的原因。 相比之下，value range的搜索和匹配器的计算更密集，往往是受CPU限制。在查询没有指定任何term以限制候选MSet的大小时，单儿的value搜索会一个个地碾过所有的文档集(documents),在大型数据库上这个会灰常灰常地慢. 如果需要range查询搜索，添加一个term条件以给数据库分区,可以大大减轻性能压力.例如，日期可能由一个合适的索引前缀+YYYYMM构成的term来描述。然后，一个对日期范围的搜索就可以由一个term搜索来完成,这能大大减少要处理的document数量.例如,，2009年1月16日- 2009年4月2日的日期范围搜索可以由： （XD200901或XD200902或XD200903或XD200904）的term搜索来限定. 这包括1月到4月的数据,超过必要的数据了，但是随后的范围子搜索中我们会去掉多余的数据。这时这个term搜索会大大减少需要处理的文件的数量，进而提高搜索速度。 不过，必须选择适当级别的粒度.如果我们按单天产生term而不是按月,日期term将产生76个，在IO方面可能就会有性能风险。 所有这一切都是相当复杂的，这就是为什么我们添加到flax中来处理的原因。我们搞flax的目标是针对数据源输入的各式的数据文档,能自动地产生优化的规划.而用户不太需要去关注这个过程请继续关注这里的消息以获得更新的消息:http://www.flax.co.uk/ 本文由蝌蚪安尼友情赞助.