标签：doc solr 长度 version storage 没有 solrcloud 过程 end
一.索引提交
当一个文档被添加到Solr中，但没有提交给索引之前，这个文档是无法被搜索的。换句话说，从查询的角度看，文档直到提交之后才是可见的。Solr有两种类型的提交：软提交和正常提交【也称硬提交】。
1.正常提交
Solr正常提交是将所有未提交的文档写入磁盘，并刷新一个内部搜索器组件，让新提交的文档能够被搜索。搜索器实际上可以看作索引中所有已提交文档的只读视图。可以这样说，硬提交是花销很大的操作，由于硬提交需要开启一个新搜索器，所以会影响到查询性能。
当正常提交成功后，新提交的文档被安全保存在持久存储器上不会因为正常的维护操作或服务器崩溃重启而丢失。出于高可用性考虑，如果磁盘发生故障，就需要一套故障转移方案，这一点在以后接着讨论。
2.软提交
软提交支持近实时搜索【Near Real-Time NRT】。软提交作为近乎实时可被搜索到的一种机制，跳过了硬提交的高消耗，例如，刷新到持久存储器就是花销较大的操作。软提交相对而言花销较低，可以每一秒都执行一次软提交，使得新近被索引的文档在添加到Solr之后很快被搜索到。但要记住，在某一时刻仍然需要执行硬提交操作，以确保文档最终被写入到持久化存储器中。
综上所述：
》硬提交让文档可被搜索，由于需要将其写入到持久化存储器中，所以花销较大
》软提交也可以让文档被搜索，不需要将其写入到持久化存储中
3.自动提交
不管是正常提交还是软提交，都可以采用以下三种策略中的一种来自动提交文档：
》在指定时间内提交文档
》一旦达到用户指定的未提交文档数阈值，就提交那么未提交的文档
》每隔特定时间间隔提交所有文档
4.配置
Solr硬提交与软提交的自动提交需要在solrconfig.xml中进行配置。
1 <!-- AutoCommit 2 3 Perform a hard commit automatically under certain conditions. 4 Instead of enabling autoCommit, consider using "commitWithin" 5 when adding documents. 6 7 http://wiki.apache.org/solr/UpdateXmlMessages 8 9 maxDocs - Maximum number of documents to add since the last 10 commit before automatically triggering a new commit. 11 12 maxTime - Maximum amount of time in ms that is allowed to pass 13 since a document was added before automatically 14 triggering a new commit. 15 openSearcher - if false, the commit causes recent index changes 16 to be flushed to stable storage, but does not cause a new 17 searcher to be opened to make those changes visible. 18 19 If the updateLog is enabled, then it‘s highly recommended to 20 have some sort of hard autoCommit to limit the log size. 21 --> 22 <autoCommit> 23 <maxTime>${solr.autoCommit.maxTime:15000}</maxTime> <!-- 上一次提交到自动提交的最长时间间隔 --> 24 <openSearcher>false</openSearcher> <!-- 提交后是否开启一个新的搜索器 --> 25 </autoCommit>
执行自动提交时通常会打开一个新搜索器。在默认情况下【未开启】，某文件自动提交，该文件将被写入到磁盘，但在搜索结果中不可见。Solr之所以提供这个选项，是为了减少未提交更新的事务日志大小，并避免在大规模索引过程中打开太多搜索器。
在solrconfig.xml中使用autoSoftCommit元素也可以自动配置软提交。
1 <!-- softAutoCommit is like autoCommit except it causes a 2 ‘soft‘ commit which only ensures that changes are visible 3 but does not ensure that data is synced to disk. This is 4 faster and more near-realtime friendly than a hard commit. 5 --> 6 7 <autoSoftCommit> 8 <maxTime>${solr.autoSoftCommit.maxTime:-1}</maxTime> <!-- -1表示无限大 --> 9 </autoSoftCommit>
二.事务日志
Solr使用事务日志来确保提交到索引并已接受的更新保存在持久化存储器中。事务日志用来避免因提交过程中的异常情况而导致提交的文档丢失的情况。具体来说，事务日志主要有三个作用：
》支持近实时获取和原子更新【下面具体讲解】
》解除提交过程中写入的持久性
》通过solrcloud的分片代表支持副本的同步
在solrconfig.xml中的一个Solr内核的事务日志配置如下：
1 <!-- Enables a transaction log, used for real-time get, durability, and 2 and solr cloud replica recovery. The log can grow as big as 3 uncommitted changes to the index, so use of a hard autoCommit 4 is recommended (see below). 5 "dir" - the target directory for transaction logs, defaults to the 6 solr data directory. 7 "numVersionBuckets" - sets the number of buckets used to keep 8 track of max version values when checking for re-ordered 9 updates; increase this value to reduce the cost of 10 synchronizing access to version buckets during high-volume 11 indexing, this requires 8 bytes (long) * numVersionBuckets 12 of heap space per Solr core. 13 --> 14 <updateLog> 15 <str name="dir">${solr.ulog.dir:}</str> <!-- 默认目录是data目录下的tlog --> 16 <int name="numVersionBuckets">${solr.ulog.numVersionBuckets:65536}</int> 17 </updateLog>
每次提交情况都会被记录到事务日志中。直到发起提交之前，事务日志会持续增长。在提交期间会处理活动的事务日志，之后将打开一个新的事务日志。一个更新执行步骤如下：
执行步骤解释如下：
1.客户端应用程序使用HTTP POST方式发送一个更新请求，可以是JSON/XML或者Solr内部二进制javabin格式
2.Jetty【Solr内部自带的WEB服务器】将此请求发送给Solr的Web应用程序
3.Solr的请求调度器通过请求路径中的collection名称确定调用的solr内核。接下来调度器定位到/update请求处理器
4.更新请求处理器对该请求进行处理，且该请求处理器将调用一个可配置的更新处理器链，在索引时为每个文档进行额外的处理
5.ADD请求写入到事务日志中
6.一旦更新请求被安全地保存到持久存储器，就会通过响应读写器回应客户端应用。这时，客户端应用得知更新请求成功执行，就可以继续执行下面的请求
注意，事务日志的关键在于权衡事务日志的长度与硬提交的执行频率。如果事务日志变得很庞大，重启就需要更长时间来处理更新，也会造成恢复过程缓慢。
标签：doc solr 长度 version storage 没有 solrcloud 过程 end
原文地址：https://www.cnblogs.com/yszd/p/11967413.html
