`
newspringwork
  • 浏览: 101361 次
  • 性别: Icon_minigender_1
  • 来自: 长沙
社区版块
存档分类
最新评论

第二章、Solr各配置文件说明

    博客分类:
  • Solr
 
阅读更多

一、schema配置文件(schema.xml或managed-schema)

下面这里先贴一段schema.xml配置示例,后面会围绕此示例讲解 

<?xml version="1.0" encoding="UTF-8"?>
<schema name="example-data-driven-schema" version="1.6">
  <!-- 主键 -->
  <uniqueKey>id</uniqueKey>

  <!-- fieldType -->
  <fieldType name="string" class="solr.StrField" sortMissingLast="true" docValues="true"/>
  <fieldType name="text_en" class="solr.TextField" positionIncrementGap="100">
    <analyzer type="index">
      <tokenizer class="solr.StandardTokenizerFactory"/>
      <filter class="solr.StopFilterFactory" words="lang/stopwords_en.txt" ignoreCase="true"/>
      <filter class="solr.LowerCaseFilterFactory"/>
      <filter class="solr.EnglishPossessiveFilterFactory"/>
      <filter class="solr.KeywordMarkerFilterFactory" protected="protwords.txt"/>
      <filter class="solr.PorterStemFilterFactory"/>
    </analyzer>
    <analyzer type="query">
      <tokenizer class="solr.StandardTokenizerFactory"/>
      <filter class="solr.SynonymFilterFactory" expand="true" ignoreCase="true" synonyms="synonyms.txt"/>
      <filter class="solr.StopFilterFactory" words="lang/stopwords_en.txt" ignoreCase="true"/>
      <filter class="solr.LowerCaseFilterFactory"/>
      <filter class="solr.EnglishPossessiveFilterFactory"/>
      <filter class="solr.KeywordMarkerFilterFactory" protected="protwords.txt"/>
      <filter class="solr.PorterStemFilterFactory"/>
    </analyzer>
  </fieldType>

  <!-- fields -->
  <field name="id" type="string" multiValued="false" indexed="true" required="true" stored="true"/>
  <dynamicField name="*_txt_en_split_tight" type="text_en_splitting_tight" indexed="true" stored="true"/>
  <copyField source="*" dest="_text_"/>
</schema>
 

 

1. 配置的基本原则

这一段是官方文件中,一段提高性能的一些原则说明

这里包含了很多实际应用不需要的可选项。 为改善性能,你可以:
  - 尽量将所有仅用于搜索,而不用于实际返回的字段设置stored="false";
  - 尽量将所有仅用于返回,而不用于搜索的字段设置indexed="false";
  - 去掉所有不需要的copyField 语句;
  - 为了达到最佳的索引大小和搜索性能,对所有的文本字段设置indexed="false",
    使用copyField将他们拷贝到“整合字段”name="text"的字段中,使用整合字段进行搜索;
  - 使用server模式来运行JVM,同时将log级别调高, 避免输出所有请求的日志。

 

2. 新版本(5.0+)注意schema配置文件变化

solr-5.0 以上默认对schema的管理是使用managed-schema,允许通过‘Schema API’管理(添加、删除等),通过修改solrconfig.xml可以禁用(只允许手动修改配置)

<!--默认配置-->
<!--
  <schemaFactory class="ManagedIndexSchemaFactory">
    <bool name="mutable">true</bool>
    <str name="managedSchemaResourceName">managed-schema</str>
  </schemaFactory>
-->
<!--禁用Schema API,只允许手动修改-->
  <schemaFactory class="ClassicIndexSchemaFactory"/>

 PS~修改了配置文件,直接在“Core Admin”中重启对应的core即可,不需重启整个tomcat

 

3. fieldType各属性说明

fieldType用来定义字段类型,solr提供了基本的一些类型,如int、float、double、date、string等,我么也可以自定义类型。

fieldType标签对应属性说明如下:

  • name:类型名称,如int、float等
  • class:实现类名,也就是solr中真正的类型的类名
  • sortMissingFirst/sortMissingLast:可选属性,目前支持字符串或数字类型的排序
  • sortMissingLast:该字段没值的doc将排在有值的哪些doc之后
  • sortMissingFirst:与sortMissingLast刚好相反
  • positionIncrementGap:可选属性,定义在同一个文档中此类型数据的空白间隔,避免短语匹配错误(多值字段才有用)

fieldType下面还可以定义Analyzer,关于此后面会用专门的章节介绍

 

4. field各属性说明

  • name: 必须属性 - 字段名(字母、数字、下划线组成,且不能以数字开头。两端为下划线的字段为保留字段,如_version_)
  • type: 必须属性,字段类型(schema中定义)
  • indexed: 如果字段需要被索引(用于搜索或排序),属性值设置为true
  • stored: 如果字段内容需要被返回,值设置为true
  • docValues: 如果这个字段应该有文档值(doc values),设置为true。文档值在门面搜索,分组,排序和函数查询中会非常有用。虽然不是必须的,而且会导致生成索引变大变慢,但这样设置会使索引加载更快,更加NRT友好,更高的内存使用效率。然而也有一些使用限制:目前仅支持StrField, UUIDField和所有 Trie*Fields, 并且依赖字段类型, 可能要求字段为单值(single-valued)的,必须的或者有默认值。
  • multiValued: 如果这个字段在每个文档中可能包含多个值,设置为true
  • termVectors: [false] 设置为true后,会保存所给字段的相关向量(vector),当使用MoreLikeThis时, 用于相似度判断的字段需要设置为stored来达到最佳性能.
  • termPositions: 保存和向量相关的位置信息,会增加存储开销 
  • termOffsets: 保存 offset 和向量相关的信息,会增加存储开销
  • required: 字段必须有值,否则会抛异常
  • default: 在增加文档时,可以根据需要为字段设置一个默认值,防止为空
5. DynamicField
动态字段(Dynamic fields)允许 solr 索引没有在 schema 中明确定义的字段。这个在忘记定义一些字段时很有用,可以让系统更灵活,通用性更强。
动态字段和常规字段类似,除了它名字中包含一个通配符外,在索引文档时,一个字段如果在常规字段中没有匹配时,将到动态字段中匹配。
例如,如果我们的导入SQL有2个字段address、email未定义对应的solr字段,我们可以直接用dynamic字段”address_s“&"email_s" ,会匹配到动态字段"*_s"。我们查询所有的doc时,可以看到返回的文档中包含了address_s、email_s两个字段。
 
6. CopyField
将多个字段复制集中到一个字段,这样我们索引的时候就可以直接查询这个目标字段。例如,我们可能想要查询short_desc,tags两个字段中带有NBA的文档,我们可以使用查询字符串"_text_:NBA",这个"_text_"就是一个查询的目标字段(默认有定义),我们也可以定义自己的。
相关说明:
  • source:待复制的字段,支持通配符
  • dest:要复制到哪个字段,支持通配符
  • maxChars:支持的字符数
7. uniqueKey
文档的唯一标识,可理解为主键
8. 需要注意的地方:
  • 保留字段不能删除,否则报错
  • 对于CopyField,如果dest由多个source构成,就需要将其指定为multiValued

二、配置文件solrconfig.xml

这个配置文件是用来配置对应core的,下面介绍一些主要的配置

1.配置从数据库导入的requestHandler

 

<requestHandler name="/dataimport" class="org.apache.solr.handler.dataimport.DataImportHandler">  
  <lst name="defaults">  
    <str name="config">data-config.xml</str>  
  </lst>  
</requestHandler>
2.配置schema.xml
新版本默认的是managed-schema文件中配置field等信息,并可通过Schema API管理,可在此文件中配置启用schema.xml,请见上章。

 

3.其他

dataDir parameter:<dataDir>/var/data/solr</dataDir>   
用来指定一个替换原先在Solr目录下默认存放所有的索引数据,可以在Solr目录以外的任意目录中。如果复制使用后应该符合该参数。如果这个目录不是绝对路径的话,那么应该以当前的容器为相对路径。   
mainIndex :   
这个参数的值用来控制合并多个索引段。   
<useCompoundFile>:通过将很多 Lucene 内部文件整合到单一一个文件来减少使用中的文件的数量。这可有助于减少 Solr 使用的文件句柄数目,代价是降低了性能。除非是应用程序用完了文件句柄,否则 false 的默认值应该就已经足够。   
mergeFactor:   
决定低水平的 Lucene 段被合并的频率。较小的值(最小为 2)使用的内存较少但导致的索引时间也更慢。较大的值可使索引时间变快但会牺牲较多的内存。   
maxBufferedDocs:   
在合并内存中文档和创建新段之前,定义所需索引的最小文档数。段 是用来存储索引信息的 Lucene 文件。较大的值可使索引时间变快但会牺牲较多的内存。   
maxMergeDocs:   
控制可由 Solr ,000) 最适合于具有合并的 Document 的最大数。较小的值 (< 10大量更新的应用程序。该参数不允许lucene在任何索引段里包含比这个值更多的文档,但是,多余的文档可以创建一个新的索引段进行替换。   
maxFieldLength:   
对于给定的 Document,控制可添加到 Field 的最大条目数,进而截断该文档。如果文档可能会很大,就需要增加这个数值。然而,若将这个值设置得过高会导致内存不足错误。   
unlockOnStartup:   
unlockOnStartup 告知 Solr 忽略在多线程环境中用来保护索引的锁定机制。在某些情况下,索引可能会由于不正确的关机或其他错误而一直处于锁定,这就妨碍了添加和更新。将其设置为 true 可以禁用启动锁定,进而允许进行添加和更新。   
<mainIndex>   
    <!-- lucene options specific to the main on-disk lucene index -->   
    <useCompoundFile>false</useCompoundFile>   
    <mergeFactor>10</mergeFactor>   
    <maxBufferedDocs>1000</maxBufferedDocs>   
    <maxMergeDocs>2147483647</maxMergeDocs>   
    <maxFieldLength>10000</maxFieldLength>   
  </mainIndex>   
  
updateHandler:   
这个更新处理器主要涉及底层的关于如何更新处理内部的信息。(此参数不能跟高层次的配置参数Request Handlers对处理发自客户端的更新相混淆)。   
<updateHandler class="solr.DirectUpdateHandler2">   
  
    <!-- Limit the number of deletions Solr will buffer during doc updating.   
          
        Setting this lower can help bound memory use during indexing.   
    -->   
缓冲更新这么多的数目,设置如下比较低的值,可以约束索引时候所用的内存   
    <maxPendingDeletes>100000</maxPendingDeletes>   
等待文档满足一定的标准后将自动提交,未来版本可以扩展现有的标准   
    <!-- autocommit pending docs if certain criteria are met.  Future versions may expand the available   
     criteria -->   
    <autoCommit>    
      <maxDocs>10000</maxDocs> <!-- maximum uncommited docs before autocommit triggered -->   
触发自动提交前最多可以等待提交的文档数量   
      <maxTime>86000</maxTime> <!-- maximum time (in MS) after adding a doc before an autocommit is triggered -->   
在添加了一个文档之后,触发自动提交之前所最大的等待时间   
    </autoCommit>   
  
这个参数用来配置执行外部的命令。   
一个postCommit的事件被触发当每一个提交之后   
<listener event="postCommit" class="solr.RunExecutableListener">   
      <str name="exe">snapshooter</str>   
      <str name="dir">solr/bin</str>   
      <bool name="wait">true</bool>   
      <!--   
      <arr name="args"> <str>arg1</str> <str>arg2</str> </arr>   
      <arr name="env"> <str>MYVAR=val1</str> </arr>   
        -->   
    </listener>   
exe--可执行的文件类型   
dir--可以用该目录做为当前的工作目录。默认为"."   
wait--调用线程要等到可执行的返回值   
args--传递给程序的参数 默认nothing   
env--环境变量的设置 默认nothing   
  
<query>   
    <!-- Maximum number of clauses in a boolean query... can affect range   
         or wildcard queries that expand to big boolean queries.    
一次布尔查询的最大数量,可以影响查询的范围或者进行通配符的查询,借此来扩展一个更强大的查询。   
         An exception is thrown if exceeded.   
    -->   
    <maxBooleanClauses>1024</maxBooleanClauses>   
  
<query>:   
控制跟查询相关的一切东东。   
  
Caching:修改这个参数可以做为索引的增长和变化。   
  
<!-- Cache used by SolrIndexSearcher for filters (DocSets),   
         unordered sets of *all* documents that match a query.   
在过滤器中过滤文档集合的时候,或者是一个无序的所有的文档集合中将在在SolrIndexSearcher中使用缓存来匹配符合查询的所有文档。   
         When a new searcher is opened, its caches may be prepopulated   
         or "autowarmed" using data from caches in the old searcher.   
当一次搜索被打开,它可以自动的或者预先从旧的搜索中使用缓存数据。   
         autowarmCount is the number of items to prepopulate.   
autowarmCount这个值是预先设置的数值项。   
  For LRUCache,   
         the autowarmed items will be the most recently accessed items.   
在LRUCache中,这个autowarmed 项中保存的是最近访问的项。   
       Parameters: 参数选项   
         class - the SolrCache implementation (currently only LRUCache)实现SolrCache接口的类 当前仅有LRUCache   
              
         size - the maximum number of entries in the cache   
在cache中最大的上限值   
         initialSize - the initial capacity (number of entries) of   
           the cache.  (seel java.util.HashMap)   
在cache中初始化的数量   
         autowarmCount - the number of entries to prepopulate from   
           and old cache.   
从旧的缓存中预先设置的项数。   
         -->   
    <filterCache   
      class="solr.LRUCache"   
      size="512"   
      initialSize="512"   
      autowarmCount="256"/>   
  
   <!-- queryResultCache caches results of searches - ordered lists of   
         document ids (DocList) based on a query, a sort, and the range   
         of documents requested.  -->   
查询结果缓存   
    <queryResultCache   
      class="solr.LRUCache"   
      size="512"   
      initialSize="512"   
      autowarmCount="256"/>   
  
  <!-- documentCache caches Lucene Document objects (the stored fields for each document).   
documentCache缓存Lucene的文档对象(存储领域的每一个文件)   
       Since Lucene internal document ids are transient, this cache will not be autowarmed.  -->   
由于Lucene的内部文档ID标识(文档名称)是短暂的,所以这种缓存不会被自动warmed。   
    <documentCache   
      class="solr.LRUCache"   
      size="512"   
      initialSize="512"   
      autowarmCount="0"/>   
  
    <!-- Example of a generic cache.    
一个通用缓存的列子。   
These caches may be accessed by name   
         through SolrIndexSearcher.getCache().cacheLookup(), and cacheInsert().   
这些缓存可以通过在SolrIndexSearcher.getCache().cacheLookup()和cacheInsert()中利用缓存名称访问得到。   
         The purpose is to enable easy caching of user/application level data.   
这样做的目的就是很方便的缓存用户级或应用程序级的数据。   
         The regenerator argument should be specified as an implementation   
         of solr.search.CacheRegenerator if autowarming is desired.  -->   
这么做的的关键就是应该明确规定实现solr.search.CacheRegenerator接口如果autowarming是比较理想化的设置。   
    <!--   
    <cache name="myUserCache"   
      class="solr.LRUCache"   
      size="4096"   
      initialSize="1024"   
      autowarmCount="1024"   
      regenerator="org.mycompany.mypackage.MyRegenerator"   
      />   
    -->   
  
    <!-- An optimization that attempts to use a filter to satisfy a search.   
一种优化方式就是利用一个过滤器,以满足搜索需求。   
         If the requested sort does not include a score,   
如果请求的不是要求包括得分的类型,filterCache 这种过滤器将检查与过滤器相匹配的结果。如果找到,过滤器将被用来作为文档的来源识别码,并在这个基础上进行排序。   
then the filterCache   
         will be checked for a filter matching the query.  If found, the filter   
         will be used as the source of document ids, and then the sort will be   
         applied to that.   
      -->   
    <useFilterForSortedQuery>true</useFilterForSortedQuery>   
  
    <!-- An optimization for use with the queryResultCache.  When a search   
         is requested, a superset of the requested number of document ids   
         are collected.  For example, of a search for a particular query   
         requests matching documents 10 through 19, and queryWindowSize is 50,   
         then documents 0 through 50 will be collected and cached. Any further   
         requests in that range can be satisfied via the cache.   
    -->   
  
一种优化用于queryResultCache,当一个搜索被请求,也会收集一定数量的文档ID做为一个超集。举个例子,一个特定的查询请求匹配的文档是10到19,此时,queryWindowSize是50,这样,文档从0到50都会被收集并缓存。这样,任何更多的在这个范围内的请求都会通过缓存来满足查询。   
    <queryResultWindowSize>50</queryResultWindowSize>   
  
    <!-- This entry enables an int hash representation for filters (DocSets)   
         when the number of items in the set is less than maxSize. For smaller   
         sets, this representation is more memory efficient, more efficient to   
         iterate over, and faster to take intersections.   
     -->   
    <HashDocSet maxSize="3000" loadFactor="0.75"/>   
  
  
    <!-- boolToFilterOptimizer converts boolean clauses with zero boost   
         cached filters if the number of docs selected by the clause exceeds the   
         threshold (represented as a fraction of the total index)   
    -->   
    <boolTofilterOptimizer enabled="true" cacheSize="32" threshold=".05"/>   
  
    <!-- Lazy field loading will attempt to read only parts of documents on disk that are   
         requested.  Enabling should be faster if you aren't retrieving all stored fields.   
    -->   
    <enableLazyFieldLoading>false</enableLazyFieldLoading>
 

返回目录

>>>未完待续

分享到:
评论

相关推荐

    Solr in action

    在第二章“Getting to know Solr”中,作者从Solr的基本安装配置讲起,逐步介绍如何设置和运行Solr实例。这一章不仅包含了环境搭建的过程,还涉及了如何通过Solr管理界面进行基本的操作和调试。通过本章的学习,读者...

    Java例题源码第二章-solr-in-action:本书的示例代码、数据和配置

    《Java例题源码第二章-solr-in-action》是一个包含本书示例代码、数据和配置的资源包,主要用于帮助读者深入理解Java编程中的Solr搜索引擎应用。Solr是Apache Lucene项目的一个子项目,是一个高性能、全文本搜索...

    大数据技术文档 (2).docx

    第二章详细阐述Hadoop、Nutch、Solr的关键技术和文本检索算法。 总的来说,这篇文档详尽地探讨了如何利用Hadoop、Nutch和Solr构建一个高效、可扩展的分布式搜索引擎,以解决海量信息中精准搜索的问题。通过优化索引...

    Big Data Made Easy

    #### 第二部分:数据收集与处理 - **第3章:使用Nutch和Solr收集数据** 本章重点介绍了网络爬虫工具Nutch和全文搜索引擎Solr的工作原理和实际应用。通过示例展示了如何利用Nutch抓取网页数据,并将这些数据索引化...

    大数据技术文档27.docx

    - **第二章:关键技术** – 详细介绍Hadoop、Nutch、Solr的技术架构及文本检索算法。 通过以上分析可以看出,Hadoop + Nutch + Solr的结合为解决大数据背景下高效信息检索的问题提供了有力的支持。不仅可以显著提升...

    第一章大数据平台概述.pdf

    随着大数据时代的到来,数据已经成为了推动各行各业发展的新动力,它不仅包含了传统的结构化数据,还涵盖了半结构化和非结构化的多元化数据类型。传统的数据库技术在面对PB级别的数据量时显得力不从心,因此,成熟...

    第一章大数据平台概述.docx

    云海 Insight HD 包括众多组件,如用于数据交换的工具、流式数据收集工具、消息系统、分布式文件系统(如HDFS)、资源管理框架(如YARN)、新一代计算框架(如MapReduce2和Tez)、Spark、Storm、Solr、Hive、HBase、...

    第一章大数据平台概述 (3).docx

    随着大数据时代的到来,数据已经成为了推动各行各业发展的新生产资料。传统数据库技术在面对PB级别的数据时显得力不从心,因此,需要专门设计的大数据基础软件产品来满足需求。 浪潮云海Insight HD是一款企业级的...

    搜索引擎技术教程 网络搜索引擎原理-第7章 Xapian简介 共39页.pptx

    - Sphinx 的索引建立更加依赖于配置文件,而Xapian则更为灵活可控。 - Sphinx 的attribute全部在内存中,这在某些情况下可能不如Xapian灵活。 - Xapian作为嵌入式引擎,无需启动额外的服务,更适合于独立应用的...

    Nutch 1.3 学习笔记

    学习笔记第11章提供了OPIC和LinkRank的具体实现细节。 - **Nutch 2.0的主要变化**:学习笔记的最后一章概览了从Nutch 1.3过渡到Nutch 2.0的关键差异和改进,这对于理解Nutch的演进方向至关重要。 综上所述,Nutch ...

Global site tag (gtag.js) - Google Analytics