首页 > 代码库 > solr的索引库core相关配置解析
solr的索引库core相关配置解析
1.core的概念
2.目录结构
conf目录中有两个非常重要的配置文件:schema.xml和solrconfig.xml
3.配置详解
core.properties
schemal.xml
solrconfig.xml
3.1 core.properties
Core的属性文件,记录当前core的名称、索引位置、配置文件名称等信息,也可以不写。主要用于修改名字
3.2 schema.xml
Solr中会提前对文档中的字段进行定义,并且在schema.xml中对这些字段的属性进行约束,例如:字段数据类型、字段是否索引、是否存储、是否分词等等
1)通过Field字段定义字段的属性信息:
属性及含义:
name:字段名称
type:字段类型,指向的是本文件中的<fieldType>标签
indexed:是否创建索引
stored:是否被存储
multiValued:是否可以有多个值,如果字段可以有多个值,设置为true
注意:在本文件中,有两个字段是Solr自带的字段,绝对不要删除:_version节点和_root节点
2)通过FieldType指定数据类型
name:字段类型的名称,可以自定义,<field>标签的type属性可以引用该字段,来指定数据类型
class:字段类型在Solr中的类。StrField可索引不可分词。TextField字段可索引,可以分词,所以需要指定分词器
<analyzer>:这个子标签用来指定分词器
3)唯一主键
Lucene中本来是没有主键的。删除和修改都需要根据词条进行匹配。而Solr却可以设置一个字段为唯一主键,这样增删改操作都可以根据主键来进行!
4)动态字段
用于匹配类型,一般不用
3.3 solrconfig.xml
这个配置文件主要配置跟索引库和请求处理相关的配置。solr服务的优化主要通过这个配置文件进行:
solrconfig.xml配置文件支持使用变量,格式如下:${propertyname[:option default value]}冒号后面的是缺省值,冒号前面的值可以来自于:
1)JVM的-D参数,比如:bin/solr start -Dpropertyname=none
2).properties等配置文件,比如core.properties文件
<lib/>标签:
- 用途:配置插件依赖的jar包
- 注意事项:
- 如果引入多个jar包,要注意包和包的依赖关系,被依赖的包配置在前面
- 这里的jar包目录如果是相对路径,那么是相对于core所在目录
例如,在配置文件中默认有以下配置:
这些是Solr中插件所依赖的Jar包
这里的相对路径其实是相对于 core所在目录。
建议不修改,,,我们把所以来的Jar包复制到solr的HOME中:
然后修改配置文件:
<requestHandler/>标签:
- 用途:配置Solr处理各种请求(搜索/select、更新索引/update、等)的各种参数
- 主要参数:
- name:请求类型,例如:select、query、get、update
- class:处理请求的类
- initParams:可选。引用<initParams>标签中的配置
- <lst name="defaults">:定义各种缺省的配置,比如缺省的parser、缺省返回条数
例子: 负责搜索请求的Handler
这里有一个默认选项:rows=10 ,就是设置默认查10条数据
<str name=”df”> text</str> 这个是设置默认搜索的字段为:text,我们可以设置为title,因为我们没有text字段
<initParams/>标签:
- 用途:为一些requestHandlers定义通用的配置,以便在一个地方修改后,所有地方都生效
- 主要参数:
- path:指明该配置应用于哪些请求路径,多个 的话用逗号分开,可以用通配符(*表示一层子路径,**表示无限层)
- name:如果不指定path,可以指定一个name,然后在<requestHander>配置中可以引用这个name
例子(配置一个缺省的df): <initParams path="/update/**,/query,/select,/tvrh,/elevate,/spell,/browse"> <lst name="defaults"> <str name="df">_text_</str> </lst> </initParams>
如果配置name,在<requestHander>中引用的例子:<requestHandler name="/dump1" class="DumpRequestHandler" initParams="myParams"/>
<updateHandler/>标签:
- 用途:定义一些更新索引相关的参数,比如定义commit的时机
- 主要参数:
- autoCommit:定义自动commit的触发条件。如果没配置这个参数,则每次都必须手动commit
- maxDocs
- maxTime(毫秒)
- openSearcher:autoCommit结束后,是否开启一个新的searcher让更改生效。缺省为false
- autoSoftCommit:定义自动softCommit的触发条件。相关参数同autoCommit
- listener:配置事件监听器
- event:监听哪个事件,比如:event="postCommit", event="postOptimize"
- class:处理的类,可以是自己的实现类。如果是RunExecutableListener,可以配置下面的参数:
- exe:可执行文件,包括Solr Home的相对路径和文件名
- dir:工作目录,缺省是“.”
- wait: 调用者是否等待可执行文件执行结束,缺省是true
- args:传递给可执行文件的参数
- env:其他所需要的环境变量
- updateLog:配置log的保存路径、等
- dir:保存路径
- numRecordsToKeep:一个log保存的记录数,缺省为100
- maxNumLogsToKeep:log的数量,缺省为10
- numversionBuckets:追踪max version的bucket数量(?),缺省为65535
- autoCommit:定义自动commit的触发条件。如果没配置这个参数,则每次都必须手动commit
配置这些参数要考虑到搜索的准确度和性能的平衡。^_^
注:commit和softCommit:
- commit:正式提交、对索引的修改会被保存到永久存储中(比如磁盘),会比较耗时
- softCommit:软提交,对索引的修改会被立即应用到工作中的索引中,即立即生效,但没有保存进磁盘
<query/>标签:
- 用途:配置Solr如何处理和返回搜索的相关参数
- 主要参数:
- filterCache:当搜索带有“fq”参数时,使用这个配置,它保存未经过排序的所有文档
- class:实现类,有三种:solr.search.LRUCache, solr.search.FastLRUCache, solr.search.LFUCache
- size:最大保存的记录数量
- initialSize:初始数量
- autowarmCount:新Index Searcher启动的时候从旧的Index Searcher缓存拷贝过来的数据量
- queryResultCache:存储最终的搜索结果(排序后的、有范围的文档id)
- class:实现类,有三种:solr.search.LRUCache, solr.search.FastLRUCache, solr.search.LFUCache
- size:最大保存的记录数量
- initialSize:初始数量
- autowarmCount:新Index Searcher启动的时候从旧的Index Searcher缓存拷贝过来的数据量
- maxRamMB:最大分配的容量(兆)
- documentCache:缓存Lucene Document对象(就是每个文档的fields)
- class:实现类,有三种:solr.search.LRUCache, solr.search.FastLRUCache, solr.search.LFUCache
- size:最大保存的记录数量
- initialSize:初始数量
- autowarmCount:因为Lucene的内部文档 id 是临时的,所以这个缓存不应该被auto-warm,这个值应该为“0”
- cache:配置自定义的缓存,通过SolrIndexSearcher类的getCache()方法和name参数调用这个缓存
- name:被调用时的标识
- 其他参数同上
- maxBooleanClauses:BooleanQuery的最大子句数量
- enableLazyFieldLoading:没有知道被请求的field是否懒加载,true/false
- useFilterForSortedQuery:如果不是按照score排序,是否从filterCache中获取数据
- queryResultWindowsize:配合queryResultCache使用,缓存一个超集。如果搜索请求第10到19条记录,而这个参数是50,那么会缓存0到49条记录
- queryResultMaxDocsCached:queryResultCache缓存的最大文档数量
- useColdSearcher:但一个新searcher正在warm-up的时候,新请求是使用旧是searcher(true)还是等待新的search(false)
- maxWarmingSearchers:定义同时在warn-up的searcher的最大数量
- listener:监听一些事件并指定处理的类,比如在solr启动时加载一些数据到缓存中,相关参数:
- event:被监听的事件,比如:firstSearcher是第一个searcher启动、也就是solr启动的事件,newSearcher是当已经有searcher在运行的时候有新searcher启动的事件
- class:处理类
- name:="queries"就是需要处理的是query
- lst, name:针对哪些搜索条件需要处理
- filterCache:当搜索带有“fq”参数时,使用这个配置,它保存未经过排序的所有文档
<requestDispatcher/>标签:
- 用途:控制Solr HTTP RequestDispatche r响应请求的方式,比如:是否处理/select url、是否支持对流的处理、上传文件的大小、如何处理带有cache头的HTTP请求、等等
- 主要参数:
- handleSelect:true/false,如果是false,则由requestHandler来处理/select请求。因为现在的requestHandler中/select是标配,所以这里应该填false
- requestParsers:
- enableRemoteStreaming:是否接受流格式的内容,缺省为ture
- multipartUploadLimitInKB:multi-part POST请求,上传文件的大小上限(K)
- formdataUploadLimitInKB:HTTP POST的form data大小上限(K)
- addHttpRequestToContext:原始的HttpServletRequest对象是否应该被包含在SolrQueryRequest的httpRequest中……一般自定义的插件使用这个参数……
- httpCaching:如何处理带有cache control头的HTTP请求
- nerver304:如果设为true(开发阶段),则就算所请求的内容没被修改,也不会返回304,并且下面两个参数会失效
- lastModFrom:最后修改时间的计算方式,openTime:Searcher启动的时刻;dirLastMod:索引更新的时刻
- etagSeed:HTTP返回的ETag头内容
- cacheControl:HTTP返回的Cache-Control头内容
<updateProcessor/>和<updateProcessorChain/>标签:
- 用途:配置处理update请求的处理器、处理器链。如果不配置的话,Solr会使用缺省的三个处理器:
- LogUpdateProcessorFactory:追踪和记录日志
- DistributedUpdateProcessorFactory:分流update请求到不同的node,比如SolrCloud的情况下把请求分配给一个shard的leader,然后把更新应用到所有replica中
- RunUpdateProcessorFactory:调用Solr的内部API执行update操作
- 如果需要自定义update处理器:
- updateProcessor:
- class:负责处理的类
- name:名字,给updateProcessorChain引用是使用
- updateProcessorChain:
- name:自己的名字标记
- processor:指定updateProcessor的name,多个的话用逗号“,”分开
- updateProcessor:
solr的索引库core相关配置解析