配置良好的solr实例

配置solrconfig.xml

solrconfig.xml文件是具有影响Solr本身的最多参数的配置文件。

在solrconfig.xml中，您可以配置重要功能，例如：

requestHandlers(请求处理程序)，它将请求处理到Solr，例如向索引添加文档的请求或为查询返回结果的请求。
listeners(侦听器)，“侦听”特定的进程查询相关事件; 侦听器可用于触发特殊代码的执行，例如调用一些常见查询来预热高速缓存。
用于管理HTTP通信的请求分派器。
管理Web界面。
与复制和复制相关的参数（这些参数详细介绍在传统的规模和分配）。

在Solr配置文件中替换属性

JVM系统属性

任何JVM系统属性，通常在启动JVM时使用-D标志指定，可以用作Solr中任何XML配置文件中的变量。

例如，在示例solrconfig.xml文件中，您将看到此值定义要使用的lockType：

1	<lockType>${solr.lock.type:native}</lockType>

这意味着锁定类型默认为“native”，但是当启动Solr时，您可以使用JVM系统属性重新启动它，方法是启动Solr它：

1	bin/solr start -Dsolr.lock.type=name

Config API

可以通过config API去修改solr配置文件，用API修改的文件被命名成configoverlay.json。这个文件可以被API编辑，看起来像这样：

{"userProps":{
  "dih.db.url":"jdbc:oracle:thin:@localhost:1521",
  "dih.db.user":"username",
  "dih.db.pass":"password"}}

core.properties

每个core下的文件夹都有这个文件（core.properties），文件可以使用Java标准属性文件格式包含任意用户定义的属性名称和值,并且这些属性可以用作Solr核心的XML配置文件中的变量。

core.properties文件：

1
2
3

#core.properties
name=gettingstarted
my.custom.prop=edismax

在solrconfig.xml文件中使用例子:

<requestHandler name="/select">
  <lst name="defaults">
  <str name="defType">${my.custom.prop}</str>
  </lst>
</requestHandler>

core隐藏属性

Solr核心的几个属性可用作“隐含”属性，可用于变量替换，独立于基础值初始化的位置或方式。例如：无论特定Solr核心的名称是否在core.properties中显式配置，或者从实例目录的名称推断，隐式属性solr.core.name可用作该核心配置文件中的变量。所有隐式属性都使用solr.core. 名称前缀，并反映等效的core.properties属性的运行时值：

solr.core.name
solr.core.config
solr.core.schema
solr.core.dataDir
solr.core.transient
solr.core.loadOnStartup

DataDir and DirectoryFactory in SolrConfig

Solr存储其索引的位置和方式是可配置的选项。

用参数dataDir指定一个索引数据的位置，例如：

1	<dataDir>${solr.data.dir:}</dataDir>

为索引指定DirectoryFactory

solr.StandardDirectoryFactory是文件系统并尝试挑选当前的最佳实现JVM和平台。
solr.NRTCachingDirectoryFactory，默认，包装solr.StandardDirectoryFactory并将小文件缓存在内存中为了更好的NRT性能。
solr.MMapDirectoryFactory,solr.NIOFSDirectoryFactory或solr.SimpleFSDirectoryFactory可以通过强制实现特定的实现。

solr.RAMDirectoryFactory是基于内存的，而不是持久性，并且不能与复制配合使用。
例子：

<directoryFactory name="DirectoryFactory"
  class="solr.MMapDirectoryFactory">
  <bool name="preload">true</bool>
</directoryFactory>/

Lib Directives in SolrConfig

Solr允许通过在solrconfig.xml中定义指令来加载插件。

插件按照它们在solrconfig.xml中显示的顺序加载。如果有依赖关系，首先列出最低级别的依赖项。正则表达式可用于为同一目录中的其他jar提供依赖的控件加载jar。所有目录都相对于Solr instanceDir解析。

1	<lib dir="${solr.install.dir:../../../..}/contrib/extraction/lib" regex=".*\.jar" />

Schema Factory Definition in SolrConfig

Solr 默认使用manage-shcema

当在solrconfig.xml文件中未明确声明时，Solr会隐式使用ManagedIndexSchemaFactory，默认情况下为“mutable”，并将模式信息保存在managedschema文件中。
一个Solr隐式默认行为的例子，如果没有明确定义schemaFactory。

<schemaFactory class="ManagedIndexSchemaFactory">
  <bool name="mutable">true</bool>
  <str name="managedSchemaResourceName">managed-schema</str>
</schemaFactory>

如果要明确配置ManagedIndexSchemaFactory，可以使用以下选项：

mutable - 控制是否可以对架构数据进行更改。这必须设置为true，以允许使用Schema API进行编辑。
managedSchemaResourceName是一个默认为“managed-schema”的可选参数，并为架构文件定义了一个新的名称，该名称可以是除“schema.xml”以外的其他文件。
使用上面显示的默认配置，您可以使用Schema API根据需要修改模式，然后如果希望将模式“锁定”到位并防止将来更改，那么稍后将mutable的值更改为false。

schema.xml文件

使用managed-schema的另一种方法是显式配置一个ClassicIndexSchemaFactory。 ClassicIndexSchemaFactory需要使用schema.xml配置文件，并且不允许在运行时对模式进行任何程序更改。必须手动编辑schema.xml文件，仅在加载集合时加载。

1	<schemaFactory class="ClassIndexSchemaFactory"/>

配置模式managed-schema换成schema.xml

如果solr core使用ClassicIndexSchemaFactory，并且配置模式换成schema-managed模式，只要简单的吧solrconfig.xml
文件中指定为ManagedIndexSchemaFactory即可。
一旦Solr重新启动并且它检测到schema.xml文件存在，但managedSchemaResourceName文件（即：“managed-schema”）不存在，现有的schema.xml文件将被重命名为schema.xml.bak和内容被重写到managed-schema文件。如果您查看生成的文件，您将在页面顶部看到它：

1	<!-- Solr managed schema - automatically generated - DO NOT EDIT -->

现在，您可以随意使用Schema API进行更改，并删除schema.xml.bak。

配置模式从managed-schema切换到手动编辑的schema.xml

如果已启动managed-schema的Solr，并且要切换到手动编辑schema.xml文件，则应执行以下步骤：

将managed-schema文件重命名为schema.xml。
修改solrconfig.xml以替换schemaFactory类。
- 删除任何ManagedIndexSchemaFactory定义（如果存在）。
- 添加一个ClassicIndexSchemaFactory定义，如上所示，重新加载内核。
  如果您使用SolrCloud，您可能需要通过ZooKeeper修改文件。 bin / solr脚本提供了一种从ZooKeeper下载文件并在编辑后上传它们的简单方法。有关详细信息，请参阅ZooKeeper操作部分。

IndexConfig in SolrConfig

solrconfig.xml的部分定义了Lucene索引编写器的低级行为。默认情况下，Solr中包含的示例solrconfig.xml中的设置被注释掉，这意味着使用默认值。在大多数情况下，默认值是正确的。

1
2
3

<indexConfig>
  ...
</indexConfig>

1	<ramBufferSizeMB>100<ramBufferSizeMB>

一旦累积的文档更新超过了这么多的内存空间（以MB定义），则刷新挂起的更新。这也可以创建新的段或触发一个合并。使用此设置通常比maxBufferedDocs更好。如果在solrconfig.xml中都设置了maxBufferedDocs和ramBufferSizeMB，则在达到任一限制时将会发生刷新。默认值为100Mb。

1	<maxBufferedDocs>1000</maxBufferedDocs>

将文件更新的数量设置为内存中缓冲区的数量，然后再将其刷新为新的段。这也可能触发一个合并。默认的Solr配置设置为通过RAM使用进行刷新（ramBufferSizeMB）。

1	<useCompoundFile>false</useCompoundFile>

控制新写入（尚未合并）索引片段是否应使用复合文件段格式。默认值为false。

合并索引片段

Solr中的默认值是使用TieredMergePolicy，它合并大小相等的段，但必须符合每层允许的段数。其他可用的策略是LogByteSizeMergePolicy和LogDocMergePolicy。

<mergePolicyFactory class="org.apache.solr.index.TieredMergePolicyFactory">
  <int name="maxMergeAtOnce">10</int>
  <int name="segmentsPerTier">10</int>
</mergePolicyFactory>

对于TieredMergePolicy，这是通过设置和选项来控制的，而LogByteSizeMergePolicy有一个选项。

要了解为什么这些选项很重要，请考虑使用LogByteSizeMergePolicy对索引进行更新时会发生什么：文档总是添加到最近打开的段中。当片段填满时，将创建一个新的片段，并将其后续的更新放在那里。

如果创建新段将导致最低级别段的数量超过mergeFactor值，则所有这些段都将合并在一起以形成单个大段。因此，如果合并因子为10，则每个合并导致创建比其十个组成部分中的每一个大约十倍的单个分段。当这些较大的段中有10个时，它们又被合并成一个更大的单个段。这个过程可以无限期地继续下去。
当使用TieredMergePolicy时，该过程是相同的，但是不使用单个mergeFactor值，将segmentPerTier设置用作阈值来决定是否应该进行合并，并且maxMergeAtOnce设置确定合并中应包含多少段。

选择最佳合并因子通常是索引速度与搜索速度的折衷。索引中较少的片段通常会加快搜索速度，因为找不到要查找的地方。它还可以减少磁盘上的物理文件。但是为了保持段数低，合并将更频繁地出现，这可能会增加系统的负载，并减缓对索引的更新。

相反，保留更多细分可以加快索引，因为并发发生的频率较低，使更新不太可能触发合并。但搜索变得更加计算昂贵，可能会更慢，因为搜索字词必须在更多的索引片段中查找。更快的索引更新也意味着更短的提交周转时间，这意味着更及时的搜索结果。

自定义合并策略

如果内置合并策略的配置选项不完全适合您的用例，则可以自定义它们：通过创建在配置中指定的自定义合并策略工厂，或者通过配置使用包装的合并策略wrapped.prefix配置选项来控制如何将其包装的工厂配置：

<mergePolicyFactory class="org.apache.solr.index.SortingMergePolicyFactory">
  <str name="sort">timestamp desc</str>
  <str name="wrapped.prefix">inner</str>
  <str name="inner.class">org.apache.solr.index.TieredMergePolicyFactory</str>
  <int name="inner.maxMergeAtOnce">10</int>
  <int name="inner.segmentsPerTier">10</int>
</mergePolicyFactory>

上面的示例显示了Solr的SortingMergePolicyFactory被配置为通过“timestamp desc”对合并的段中的文档进行排序，并且包裹在配置为通过SortingMergePolicyFactory的“wrapped.prefix”选项定义的内部前缀maxMergeAtOnce = 10和segmentsPerTier = 10的TieredMergePolicyFactory。有关使用SortingMergePolicyFactory的更多信息，请参阅segmentTerminateEarly参数。

mergeScheduler

合并调度程序控制如何执行合并。默认ConcurrentMergeScheduler使用单独的线程在后台执行合并。另一种方法是SerialMergeScheduler，不会与单独的线程执行合并。

1	<mergeScheduler class="org.apache.lucene.index.ConcurrentMergeScheduler"/>

mergedSegmentWarmer

当使用Solr进行近实时搜索合并的分段加热器可以配置为在合并提交之前对新合并的分段进行加热。这对于近实时搜索来说不是必需的，但是在合并完成之后会打开一个新的近实时阅读器会减少搜索延迟。

1	<mergedSegmentWarmer class="org.apache.lucene.index.SimpleMergedSegmentWarmer"/>

复合文件段

每个Lucene段通常由十几个文件组成。 Lucene可以配置为使用.cfs文件扩展名将段的所有文件捆绑到单个复合文件中。它是复合文件段的缩写。

索引锁

1	<lockType>native</lockType>

LockFactory选项指定要使用的锁定实现。该组有效的锁类型选项取决于您配置的DirectoryFactory。下面列出的值由StandardDirectoryFactory（默认值）支持：

native（默认）使用NativeFSLockFactory来指定本地操作系统文件锁定。如果第二个Solr进程尝试访问目录，它将失败。当多个Solr Web应用程序试图共享一个索引时，不要使用。
简单的使用SimpleFSLockFactory指定一个普通文件进行锁定。
single（专家）使用SingleInstanceLockFactory。用于只读索引目录的特殊情况，或者不可能有多个进程尝试修改索引（甚至顺序）。此类型将防止同一个JVM中的多个内核尝试访问相同的索引。警告！如果不同JVM中的多个Solr实例修改索引，则此类型将不会防止索引损坏。
hdfs使用HdfsLockFactory来支持将索引和事务日志文件读取和写入HDFS文件系统。有关使用此功能的详细信息，请参阅在HDFS上运行Solr的部分。

1	<writeLockTimeout>1000</writeLockTimeout>

等待IndexWriter写入锁定的最长时间。默认值为1000，以毫秒表示。

其它索引设置

还有一些其他参数可能对您的实现进行配置很重要。这些设置会影响对索引进行更新的方式或时间。

reopenReaders：控制是否重新打开IndexReaders，而不是关闭然后打开，这通常效率较低。默认值为true。
deletionPolicy：控制在回滚情况下保留提交的方式。默认值为SolrDeletionPolicy，它具有要保留的最大提交数（MAXCommitsToKeep）的子参数，要保留的优化提交的最大数量（maxOptimizedCommitsToKeep）以及要保留的任何提交的最大时间（maxCommitAge），它支持DateMathParser 句法。

infoStream：InfoStream设置指示底层的Lucene类将索引过程中的详细调试信息写入Solr日志消息。

<reopenReaders>true</reopenReaders>
<deletionPolicy class="solr.SolrDeletionPolicy">
  <str name="maxCommitsToKeep">1</str>
  <str name="maxOptimizedCommitsToKeep">0</str>
  <str name="maxCommitAge">1DAY</str>
</deletionPolicy>
<infoStream>false</infoStream>

SolrConfig中的RequestHandlers和SearchComponent

RequestHandlers处理来到Solr的请求。这些可能是查询请求或索引更新请求。您可能需要几个这些定义，这取决于您希望Solr如何处理您将要做的各种请求。
SearchComponent是搜索的特征，例如突出显示或刻面。SearchComponent在solrconfig.xml中定义，与RequestHandlers分开，然后根据需要向RequestHandlers注册。

RequestHandlers

SearchHandlers

默认情况下用Solr定义的主RequestHandlers是“SearchHandler”，它处理搜索查询。定义RequestHandlers，然后默认使用一个列表定义RequestHandlers的默认列表。

<requestHandler name="/select" class="solr.SearchHandler">
  <lst name="defaults">
  <str name="echoParams">explicit</str>
  <int name="rows">10</int>
  </lst>
</requestHandler>

此示例将rows参数定义为要返回的搜索结果的数量为“10”。 echoParams参数定义当返回调试信息时，应该返回查询中定义的参数。还要注意，如果参数是字符串，整数或其他类型，则在列表中定义默认值的方式会有所不同。

搜索部分中描述的所有参数可以被定义为任何SearchHandler的默认值。

UpdateRequestHandlers

ShardHandlers

Search Components(搜索组件)

默认组件

第一组件贺最后组件

可以将某些组件定义为之前（使用第一个组件）或之后（使用最后组件）上面列出的默认组件。

<arr name="first-components">
  <str>mycomponent</str>
</arr>
<arr name="last-components">
  <str>spellcheck</str>
</ar

其它有用的组件

SpellCheckComponent
TermVectorComponent
QueryElevationComponent
TermsComponent

InitParams在SolrConfig

solrconfig.xml的部分允许您在处理程序配置之外定义请求处理程序参数。

例如，如果您希望多个搜索处理程序返回相同的字段列表，则可以创建一个部分，而无需在每个请求处理程序定义中定义相同的参数集。如果您有一个请求处理程序返回不同的字段，那么您可以像往常一样在单个部分中定义覆盖参数。
例如，这里是data_driven_config示例中默认定义的部分之一：

<initParams path="/update/**,/query,/select,/tvrh,/elevate,/spell,/browse">
  <lst name="defaults">
  <str name="df">_text_</str>
  </lst>
</initParams>

UpdateHandlers in SolrConfig

本节中的设置在solrconfig.xml中的元素中进行配置，可能会影响索引更新的性能。这些设置会影响内部更新的完成。配置不影响处理客户端更新请求的RequestHandler的更高级别配置。

Query Settings in SolrConfig

本节中的设置会影响Solr将处理和响应查询的方式。这些设置都在solrconfig.xml中的元素的子元素中进行配置。

1
2
3

<query>
  ...
</query>

高速缓存(Caches)

未完，持续更新。。。

Contents