标签:专业 port 规则 ext 前缀 它的 并发 用户 and
Solr 分析器被指定为 schema.xml 配置文件中的<fieldType>元素的子元素(在与 solrconfig. xml 相同的 conf/ 目录中)。
在正常使用情况下,只有类型为 solr.TextField 的字段将指定一个分析器。配置分析器的最简单的方法是使用单个 <analyzer> 元素,它的类属性是一个完全限定的Java 类名。命名的类必须派生自 org.apache.lucene.analysis.Analyzer。例如:
<fieldType name="nametext" class="solr.TextField"> <analyzer class="org.apache.lucene.analysis.core.WhitespaceAnalyzer"/> </fieldType>
在这种情况下,单个类 WhitespaceAnalyzer 负责分析指定文本字段的内容并发出相应的令牌。对于简单的情况,如简单的英文散文,这样的单个分析器类可能就足够了。但是通常需要对字段内容进行更复杂的分析。
即使是最复杂的分析要求,通常也可以分解为一系列离散的、相对简单的处理步骤。正如你很快就会发现的那样,Solr 发行版提供了大量的标记器和过滤器,覆盖了你可能遇到的大多数场景。建立一个分析器链非常简单,您可以指定一个简单的< analyzer >元素(无类属性),使用子元素命名标记器和过滤器的工厂类以使用,按照您希望它们运行的??顺序。
例如:
<fieldType name="nametext" class="solr.TextField"> <analyzer> <tokenizer class="solr.StandardTokenizerFactory"/> <filter class="solr.StandardFilterFactory"/> <filter class="solr.LowerCaseFilterFactory"/> <filter class="solr.StopFilterFactory"/> <filter class="solr.EnglishPorterFilterFactory"/> </analyzer> </fieldType>
请注意,org.apache.solr.analysis 包中的类可能在这里用简写的 solr. 前缀来引用。
在这种情况下,<analyzer> 元素上没有指定分析器类。相反,一系列更专业化的类连接在一起,共同作为该字段的分析器。该字段的文本被传递给list(solr.StandardTokenizerFactory)中的第一个项目,而从最后一个(solr.EnglishPorterFilterFactory)中出现的标记是用于对任何使用 "nametext" fieldType 的字段进行索引或查询的术语。
字段值与索引术语:分析器的输出会影响给定字段中索引的术语 (以及分析对这些字段的查询时使用的术语),但不会影响字段的存储值。例如: “Brown Cow”分成两个索引词 “brown” 和 “cow”,但存储的值仍将是一个字符串: “Brown Cow”。
分析发生在两种情况下:在索引的时候,当一个字段被创建时,分析得到的令牌流将被添加到一个索引中,并为该字段定义一组术语(包括位置、大小等)。在查询时间,分析正在搜索的值,并将结果的条件与存储在字段索引中的条件进行匹配。
在很多情况下,对两个阶段都应该进行相同的分析。例如,当您想要查询精确的字符串匹配时,这可能是不区分大小写的。在其他情况下,您可能希望在索引期间应用略有不同的分析步骤,而不是在查询时使用的分析步骤。
如果您为 <analyzer> 字段类型提供了一个简单的定义(如上例所示),那么它将用于索引和查询。如果您想要为每个阶段使用不同的分析器,则可以包含两个与 type 属性区分的 <analyzer> 定义。例如:
<fieldType name="nametext" class="solr.TextField"> <analyzer type="index"> <tokenizer class="solr.StandardTokenizerFactory"/> <filter class="solr.LowerCaseFilterFactory"/> <filter class="solr.KeepWordFilterFactory" words="keepwords.txt"/> <filter class="solr.SynonymFilterFactory" synonyms="syns.txt"/> </analyzer> <analyzer type="query"> <tokenizer class="solr.StandardTokenizerFactory"/> <filter class="solr.LowerCaseFilterFactory"/> </analyzer> </fieldType>
在这个理论性的例子中,在索引时,文本被标记化,标记被设置为小写,任何未列出的 keepwords.txt 都被丢弃,而保留的那些将被映射到文件 syns.txt 中的同义词规则所定义的替代值。这基本上是从一组受限制的可能值生成索引,然后将它们规范化为可能甚至不会出现在原始文本中的值。
在查询时,唯一发生的规范化是将查询条件转换为小写。在索引时发生的筛选和映射步骤不适用于查询条件。在这个例子中,查询必须非常精确,仅使用在索引时存储的规范化术语
在某些类型的查询中(即:前缀、通配符、正则表达式等等),用户提供的输入不是用于分析的自然语言。诸如同义词或停用词过滤之类的东西在这些类型的查询中不起作用。
则可以明确定义一个要使用的 multiterm 分析器,如下例所示:
<fieldType name="nametext" class="solr.TextField"> <analyzer type="index"> <tokenizer class="solr.StandardTokenizerFactory"/> <filter class="solr.LowerCaseFilterFactory"/> <filter class="solr.KeepWordFilterFactory" words="keepwords.txt"/> <filter class="solr.SynonymFilterFactory" synonyms="syns.txt"/> </analyzer> <analyzer type="query"> <tokenizer class="solr.StandardTokenizerFactory"/> <filter class="solr.LowerCaseFilterFactory"/> </analyzer> <!-- No analysis at all when doing queries that involved Multi-Term expansion --> <analyzer type="multiterm"> <tokenizer class="solr.KeywordTokenizerFactory" /> </analyzer> </fieldType>
标签:专业 port 规则 ext 前缀 它的 并发 用户 and
原文地址:https://www.cnblogs.com/miye/p/9523552.html