Solr--02.Solr中Core详解

àì夳堔傛蜴生んèń 2022-04-14 06:55 320阅读 0赞

## 一、Core概述 ##

### **1、Core概述** ###

在Solr中、每一个Core、代表一个索引库、里面包含索引数据及其配置信息、
    Solr中可以拥有多个Core、也就是同进管理多个索契库、就像mysql中可以有多个数据库一样。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70][]

### **2、Core目录结构** ###

Core中有二个重要目录：conf和data

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 1][]

conf目录中有两个非常重要的配置文件：schema.xml和solrconfig.xml

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 2][]

## 二、Core的配置文件   ##

### **1、core.properties** ###

Core的属性文件，记录当前core的名称、索引位置、配置文件名称等信息，也可以不写

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 3][]

一般要求Core名称跟Core的文件夹名称一致！这里都是Collection1，可以手动修改这个属性，把Core的名字改成我们喜欢的。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 4][]

此时重启Tomcat，可以看到core的名字已经改变！

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 5][]

**1.1、添加多个Core**

1）在solr目录下复制collection并重新命名为collection2,作为新的core目录、如下图

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 6][]

2）在collection2下创建conf目录和data目录，并且创建文件core.properties，添加属性：name=collection2

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 7][]

3）、重启Tomcat，访问管理页面

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 8][]

### **2、schema.xml** ###

Schema.xml配置详解：Solr中会提前对文档中的字段进行定义，
    并且在schema.xml中对这些字段的属性进行约束，例如：字段数据类型、字段是否索引、是否存储、是否分词等

**2.1、<field>标签**

<field>标签：  通过Field字段 定义字段的属性信息：

![20181125211658626.png][]

语法：

属性及含义：
    		name：字段名称
    		type：字段类型，指向的是本文件中的<fieldType>标签
    		indexed：是否创建索引
    		stored：是否被存储
    		multiValued：是否可以有多个值，如果字段可以有多个值，设置为true，false为单个值。
    多个值：对应JSON的数组格式。 对应java的List格式。

注意：

在本文件中，有两个字段是Solr自带的字段，绝对不要删除：_version节点、_root节点和id节点。

![20181125211800680.png][]

扩展：

•omitNorms：是否忽略掉Norm，可以节省内存空间，只有全文本field和need an index-time boost的field需要norm。
    默认就是true，即忽略标准因子。如果一个域要使用得分激励因子，必须要手动的设置omitNorm= false，否则会报错。
    •termVectors：当设置true，会存储 term vector。当使用MoreLikeThis，用来作为相似词的field应该存储起来。
    •termPositions：存储 term vector中的地址信息，会消耗存储开销。
    •termOffsets：存储 term vector 的偏移量，会消耗存储开销。

**2.2、<FieldType>标签**

过FieldType指定数据类型

![20181125212009385.png][]

语法：

name：字段类型的名称，可以自定义，<field>标签的type属性可以引用该字段，来指定数据类型
    class：字段类型在Solr中的类。StrField可索引不可分词。TextField字段可索引，可以分词，所以需要指定分词器
    <analyzer>：这个子标签用来指定分词器

扩展：

precisionStep：
    用于数值范围搜索，进行分词 通过设置precisionStep的值可以提高检索速度，8是solr的推荐值。
    设定一个PrecisionStep (默认4)，对数值类型每次右移（n-1）* PrecisionStep 位。
    每次移位后，从左边开始每7位存入一个byte，组成一个byte[]，
    并且在数组第0位插入一个特殊byte，标识这次的偏移量。
    每个byte[]可以转成一个lexicographic sortable string。
    lexicographic sortable string 的字符按字典序排列后，和偏移量，
    数值的大小顺序是一致的。这个是NumericRangeQuery 范围查找的关键。
    
    positionIncrementGap：
    一个doc中的属性有多个值时候，设置每个属性之间的增量值和multiValued属性配合使用(避免错误匹配)。
    其作用就是在对Multivalue Field进行处理的时候，给两个field中相隔的词人为的插入一段固定的distance
    然后在使用Lucene/Solr做Phrase query的时候，如果没有指定Slop(对slop的介绍，可以参
    考:http://blog.csdn.net/rick_123/article/details/6708527)，会默认Slop为0，即查询的短语之间应该紧紧挨着，
    这样对很多情况下都得不到用户想要的结果。解决的办法就是使用phrase query，同时设置一个适当的Slop值，
    
    然后为了不让lucene的搜索跨越多个Field Value，
    设置一个远大于slop的positionIncrementGap，就可以达到目标。
    
    sortMissingLast：设置成true没有该field的数据排在有该field的数据之后，而不管请求时的排序规则, 默认是true。
    sortMissingFirst：跟sortMissingLast相反。默认是false。
    
    analyzer：字段类型指定的分词器。
    type：当前分词器用于分词的操作。index 代表生成索引时使用的分词器。query 代表在查询时使用的分词器。
    tokenizer：分词器使用具体的分词器类。

**2.3、<uniqueKey>标签**

唯一主键
    Lucene中本来是没有主键的。删除和修改都需要根据词条进行匹配。
    而Solr却可以设置一个字段为唯一主键，这样增删改操作都可以根据主键来进行！

![201811252123569.png][]

**2.4、<dynamicField>标签**

动态字段

![20181125212559231.png][]

**2.5、引入IK分词器**

（1）、引入依赖、	在schemal.xml中自定义fieldType，引入IK分词器

![20181125212657715.png][]

（2）、让字段使用我们的自定义数据类型，引入IK分词器

![20181125212806136.png][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 9][]

**2.6、schema.xml简化**

<?xml version="1.0" encoding="UTF-8" ?>
    
    <schema name="example" version="1.5">
        
      
    
        
       <field name="_version_" type="long" indexed="true" stored="true"/>
       
       
       <field name="_root_" type="string" indexed="true" stored="false"/>
    
          
       <field name="id" type="string" indexed="true" stored="true" required="true" multiValued="false" /> 
            
      
      <uniqueKey>id</uniqueKey>
    
     
       
      
    
     
     
    	<field name="title" type="text_ik" indexed="true" stored="true" multiValued="false"/>
    	<field name="content" type="text_ik" indexed="true" stored="true"/>
       
        <field name="text" type="text_ik" indexed="true" stored="false" multiValued="false"/>
        <field name="price"  type="float" indexed="true" stored="true"/>  
     
       
      
    
     
     
       <dynamicField name="*_s"  type="string"  indexed="true"  stored="true" />
       
       <copyField source="title" dest="text"/>
       <copyField source="content" dest="text"/>
    
       
    
    
     
     
        
    	
    	 <fieldType name="text_ik" class="solr.TextField">
    			<analyzer class="org.wltea.analyzer.lucene.IKAnalyzer" />
    	</fieldType>
    	
        <fieldType name="string" class="solr.StrField" sortMissingLast="true" />
    
      
        <fieldType name="int" class="solr.TrieIntField" precisionStep="0" positionIncrementGap="0"/>
        <fieldType name="float" class="solr.TrieFloatField" precisionStep="0" positionIncrementGap="0"/>
        <fieldType name="long" class="solr.TrieLongField" precisionStep="0" positionIncrementGap="0"/>
        <fieldType name="double" class="solr.TrieDoubleField" precisionStep="0" positionIncrementGap="0"/>
    
    
        <fieldType name="text_general" class="solr.TextField" positionIncrementGap="100">
          <analyzer type="index">
            <tokenizer class="solr.StandardTokenizerFactory"/>
            <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" />
    			
            <filter class="solr.LowerCaseFilterFactory"/>
          </analyzer>
          <analyzer type="query">
            <tokenizer class="solr.StandardTokenizerFactory"/>
            <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" />
            <filter class="solr.SynonymFilterFactory" synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
            <filter class="solr.LowerCaseFilterFactory"/>
          </analyzer>
        </fieldType>
     
         
    
    </schema>

### **3、solrconfig.xml** ###

solrconfig.xml:这个配置文件主要配置跟索引库和请求处理相关的配置。solr服务的优化主要通过这个配置文件进行：

**3.1、索引库的相关配置**

**<lib/>****标签：**

•用途：配置插件依赖的jar包 
    •注意事项：
                o如果引入多个jar包，要注意包和包的依赖关系，被依赖的包配置在前面
                o这里的jar包目录如果是相对路径，那么是相对于core所在目录、如下图

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 10][]

我们发现这些配置是在找两个文件夹下的jar包：contrib和dist。这两个文件夹其实在Solr的安装目录中有

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 11][]

而<lib dir=””>标签中的dir是相对目录，默认相对于core目录。
    我们的core在D:\\test\\solr\\core1位置，我们把这两个文件夹复制到solr下

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 12][]

然后修改相对路径，只留下一个 ../  即可

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 13][]

**3.2、请求处理相关的配置**

**<requestHandler/>** **标签：**

•用途：配置Solr处理各种请求（搜索/select、更新索引/update、等）的各种参数
    •主要参数：
                o name：请求类型，例如：select、query、get、update
                o class：处理请求的类
                o initParams：可选。引用<initParams>标签中的配置
                o <lst name="defaults">：定义各种缺省的配置，比如缺省的parser、缺省返回条数

例子：负责搜索请求的Handler

![20181125231430217.png][]

这里有一个默认选项：rows=10 ，就是设置默认查10条数据
    <str name=”df”> text</str> 这个是设置默认搜索的字段为：text，我们可以设置为title,因为我们没有text字段

![2018112523145115.png][]

**<initParams/>标签：**

•用途：为一些requestHandlers定义通用的配置，以便在一个地方修改后，所有地方都生效
    •主要参数：
            o path：指明该配置应用于哪些请求路径，多个 的话用逗号分开，可以用通配符（*表示一层子路径，**表示无限层）
            o name：如果不指定path，可以指定一个name，然后在<requestHander>配置中可以引用这个name。

例子: （配置一个缺省的df）

**<updateHandler/>标签：**

•	用途：定义一些更新索引相关的参数，比如定义commit的时机
    •	主要参数：
        o	autoCommit：定义自动commit的触发条件。如果没配置这个参数，则每次都必须手动commit
            	maxDocs
            	maxTime（毫秒）
            	openSearcher：autoCommit结束后，是否开启一个新的searcher让更改生效。缺省为false
        o	autoSoftCommit：定义自动softCommit的触发条件。相关参数同autoCommit
        o	listener：配置事件监听器
            	event：监听哪个事件，比如：event="postCommit", event="postOptimize"
            	class：处理的类，可以是自己的实现类。如果是RunExecutableListener，可以配置下面的参数：
            	exe：可执行文件，包括Solr Home的相对路径和文件名
            	dir：工作目录，缺省是“.”
            	wait： 调用者是否等待可执行文件执行结束，缺省是true
            	args：传递给可执行文件的参数
            	env：其他所需要的环境变量
        o	updateLog：配置log的保存路径、等
            	dir：保存路径
            	numRecordsToKeep：一个log保存的记录数，缺省为100
            	maxNumLogsToKeep：log的数量，缺省为10
            	numversionBuckets：追踪max version的bucket数量（？），缺省为65535
    
    配置这些参数要考虑到搜索的准确度和性能的平衡。
    注：commit和softCommit：
    •	commit：正式提交、对索引的修改会被保存到永久存储中（比如磁盘），会比较耗时
    •	softCommit：软提交，对索引的修改会被立即应用到工作中的索引中，即立即生效，但没有保存进磁盘

** <query/>标签：**

•	用途：配置Solr如何处理和返回搜索的相关参数
    •	主要参数：
        o	filterCache：当搜索带有“fq”参数时，使用这个配置，它保存未经过排序的所有文档
            	class：实现类，有三种：solr.search.LRUCache, solr.search.FastLRUCache, solr.search.LFUCache
            	size：最大保存的记录数量
            	initialSize：初始数量
            	autowarmCount：新Index Searcher启动的时候从旧的Index Searcher缓存拷贝过来的数据量
        o	queryResultCache：存储最终的搜索结果（排序后的、有范围的文档id）
            	class：实现类，有三种：solr.search.LRUCache, solr.search.FastLRUCache, solr.search.LFUCache
            	size：最大保存的记录数量
            	initialSize：初始数量
            	autowarmCount：新Index Searcher启动的时候从旧的Index Searcher缓存拷贝过来的数据量
            	maxRamMB：最大分配的容量（兆）
        o	documentCache：缓存Lucene Document对象（就是每个文档的fields）
            	class：实现类，有三种：solr.search.LRUCache, solr.search.FastLRUCache, solr.search.LFUCache
            	size：最大保存的记录数量
            	initialSize：初始数量
            	autowarmCount：因为Lucene的内部文档 id 是临时的，所以这个缓存不应该被auto-warm，这个值应该为“0”
        o	cache：配置自定义的缓存，通过SolrIndexSearcher类的getCache()方法和name参数调用这个缓存
            	name：被调用时的标识
            	其他参数同上
        o	maxBooleanClauses：BooleanQuery的最大子句数量
        o	enableLazyFieldLoading：没有知道被请求的field是否懒加载，true/false
        o	useFilterForSortedQuery：如果不是按照score排序，是否从filterCache中获取数据
        o	queryResultWindowsize：配合queryResultCache使用，缓存一个超集。如果搜索请求第10到19条记录，
    而这个参数是50，那么会缓存0到49条记录
        o	queryResultMaxDocsCached：queryResultCache缓存的最大文档数量
        o	useColdSearcher：但一个新searcher正在warm-up的时候，新请求是使用旧是searcher（true）还是等待新的search（false）
        o	maxWarmingSearchers：定义同时在warm-up的searcher的最大数量
        o	listener：监听一些事件并指定处理的类，比如在solr启动时加载一些数据到缓存中，相关参数：
            	event：被监听的事件，比如：firstSearcher是第一个searcher启动、
                也就是solr启动的事件，newSearcher是当已经有searcher在运行的时候有新searcher启动的事件
            	class：处理类
            	name：="queries"就是需要处理的是query
            	lst, name：针对哪些搜索条件需要处理

扩展：

缓存的清空策略一共有三种：
    LRU（Least Recently Used）：最近最少使用
    LFU（Leats Frequently Uesd）：最不经常使用
    FIFO（First in First Out）：先进先出

**<requestDispatcher/>标签：**

•用途：控制Solr HTTP RequestDispatche r响应请求的方式，比如：是否处理/select url、
    是否支持对流的处理、上传文件的大小、如何处理带有cache头的HTTP请求、等等
    •主要参数：
        o handleSelect：true/false，如果是false，则由requestHandler来处理/select请求。
    因为现在的requestHandler中/select是标配，所以这里应该填false
        o requestParsers：
             enableRemoteStreaming：是否接受流格式的内容，缺省为ture
             multipartUploadLimitInKB：multi-part POST请求，上传文件的大小上限（K）
             formdataUploadLimitInKB：HTTP POST的form data大小上限（K）
             addHttpRequestToContext：原始的HttpServletRequest对象是否应该被包含在
    SolrQueryRequest的httpRequest中……一般自定义的插件使用这个参数……
        o httpCaching：如何处理带有cache control头的HTTP请求
             nerver304：如果设为true（开发阶段），则就算所请求的内容没被修改，也不会返回304，并且下面两个参数会失效
             lastModFrom：最后修改时间的计算方式，openTime：Searcher启动的时刻；dirLastMod：索引更新的时刻
             etagSeed：HTTP返回的ETag头内容
             cacheControl：HTTP返回的Cache-Control头内容

**<updateProcessor/>****和<updateProcessorChain/>****标签：**

•	用途：配置处理update请求的处理器、处理器链。如果不配置的话，Solr会使用缺省的三个处理器：
        o	LogUpdateProcessorFactory：追踪和记录日志
        o	DistributedUpdateProcessorFactory：分流update请求到不同的node，
    比如SolrCloud的情况下把请求分配给一个shard的leader，然后把更新应用到所有replica中
        o	RunUpdateProcessorFactory：调用Solr的内部API执行update操作
    •	如果需要自定义update处理器：
        o	updateProcessor：
            	class：负责处理的类
            	name：名字，给updateProcessorChain引用是使用
        o	updateProcessorChain：
            	name：自己的名字标记
            	processor：指定updateProcessor的name，多个的话用逗号“,”分开

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70]: /images/20220414/e60f39441a0e4163a08122b69a0776fb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 1]: /images/20220414/b2eaec413aba465ab997188fcea025fa.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 2]: /images/20220414/74b263aec2e54fe599fc530ea9310668.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 3]: /images/20220414/aa74ceb4cee948d09e86498f05fc3120.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 4]: /images/20220414/7b305e516ff74be4980d95341a5be310.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 5]: /images/20220414/028c781aed2849ce9e07bae403957a3e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 6]: /images/20220414/96be3f05390d4e0fa4c800a75b0c43e1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 7]: /images/20220414/ef48c405f0fc4019aec36592a3e5b3c7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 8]: /images/20220414/add300bf3c1c451995af9d5477a1b9b5.png
[20181125211658626.png]: /images/20220414/889b49c5da6b432b81e95d4eef422b8b.png
[20181125211800680.png]: /images/20220414/0c9cdaa10b88470b89468606f449da46.png
[20181125212009385.png]: /images/20220414/4cd1cee789c548dcb2e24d7b03b24ea7.png
[201811252123569.png]: /images/20220414/9b8eb086a81943ff9a300c3b23f7afe8.png
[20181125212559231.png]: /images/20220414/d7c0422446a244568ad5f1d159d78a47.png
[20181125212657715.png]: /images/20220414/1c43aa97ba8741db8ab307856c7514f5.png
[20181125212806136.png]: /images/20220414/7e3d4d135abc421a8a73ce33fffdc171.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 9]: /images/20220414/be7cc464a38f4ed6bcd7b1ec2fcc6fbb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 10]: /images/20220414/97eaa8499430424b90b0968655515f71.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 11]: /images/20220414/47db7a7943d24610bb1cde06b5dbc4d4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 12]: /images/20220414/ef820355149a4d328a8aeb0123cb5194.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nzd3F6eA_size_16_color_FFFFFF_t_70 13]: /images/20220414/9feeb9bc7dfd4f96a132c011723d0496.png
[20181125231430217.png]: /images/20220414/4978257059d549da926c6c1e330a833d.png
[2018112523145115.png]: /images/20220414/067889ea6a514a3c9ca23a8801bbe5c0.png