SOLR autoCommit vs autoSoftCommit

Question

我很困惑和.这是我的理解

• autoSoftCommit - 在autoSoftCommit之后,如果SOLR服务器出现故障,autoSoftCommit文件将丢失.

• autoCommit - 对磁盘进行硬提交,并确保将所有autoSoftCommit提交写入磁盘并提交任何其他文档.

我的以下配置似乎只与autoSoftCommit一起使用.autoCommit本身似乎没有做任何提交.有什么我想念的吗？

<updateHandler class="solr.DirectUpdateHandler2">
    <updateLog>
        <str name="dir">${solr.ulog.dir:}</str>
    </updateLog>
   <autoSoftCommit>
        <maxDocs>1000</maxDocs>
        <maxTime>1200000</maxTime>
    </autoSoftCommit>
    <autoCommit>
        <maxDocs>10000</maxDocs>
        <maxTime>120000</maxTime> 
        <openSearcher>false</openSearcher>
    </autoCommit>
</updateHandler>

为什么autoCommit会自己动手？

Answer 1

我认为这篇文章对你有用.它详细解释了硬提交和软提交的工作原理,以及在调整系统时应该考虑的权衡.

我总是对此感到不寒而栗,因为在某些情况下任何建议都是错误的.我的第一个建议是不要过度思考这个问题.一些非常聪明的人试图使整个过程变得强大.首先尝试简单的事情,只在必要时调整一下.特别是,查看事务日志的大小并调整硬提交间隔以保持这些"合理大小".请记住,如果在JVM崩溃后重新启动,那么惩罚主要是重播时间.15秒可以忍受吗？为什么要小一点？

我们已经看到硬提交间隔比软提交间隔短得多的情况,请参阅下面的批量索引位.

这些都是开始的地方.

重(大)指数

这里的假设是,您有兴趣在将来的某个时间尽快为索引获取大量数据.我在想数据源的原始负载等.

将软提交间隔设置得相当长.在10分钟.软提交是关于可见性的,我的假设是批量索引不是近实时搜索,所以不要做任何类型的搜索器的额外工作.将硬提交间隔设置为15秒,openSearcher = false.再次假设您将在Solr处爆炸数据.这里最糟糕的情况是你重新启动你的系统并且必须从你的tlog中重放15秒左右的数据.如果您的系统比这更频繁地上下跳动,请先解决原因.只有在你尝试过简单的事情之后,你应该考虑改进,它们通常只在特殊情况下才需要.但它们包括:完全关闭tlog以进行批量加载操作使用某种map-reduce进程脱机索引只有每个分片有一个领导者,没有负载的副本,然后再打开副本并让他们进行旧式复制以赶上.请注意,这是自动的,如果节点发现它与领导者"太远"不同步,则会启动旧式复制.在它赶上之后,它将获得文档,因为它们被索引到领导者并保留自己的tlog.等等 它会获取文件,因为它们被索引到领导者并保留自己的tlog.等等 它会获取文件,因为它们被索引到领导者并保留自己的tlog.等等

INDEX-HEAVY,QUERY-LIGHT

我的意思是说,搜索日志文件.在这种情况下,您可以在系统中随时获得大量数据.但查询负载非常轻,通常用于排除故障或分析使用情况.

将软提交间隔设置得相当长,直到可以看到文档可见的最大延迟.这可能只需几分钟或更长时间.甚至可能需要几小时才能发出硬提交(openSearcher = true)或软提交.将您的硬提交设置为15秒,openSearcher = false INDEX-LIGHT,QUERY-LIGHT或HEAVY

这是一个相对静态的索引,有时会获得一小段索引.比如每5-10分钟(或更长时间)进行一次更新

除非需要NRT功能,否则在这种情况下我会省略软提交,并且使用openSearcher = true每5-10分钟进行一次硬提交.在这种情况下,如果您使用单个外部索引进程进行索引,则让客户端发出硬提交可能是有意义的.

INDEX-HEAVY,QUERY-HEAVY

这是近实时(NRT)案例,实际上是最棘手的.这个将需要实验,但这是我开始的地方

只要您能够站立,就可以设置软提交间隔.不要听你的产品经理说"我们需要不超过1秒的延迟".真.向后推,看看用户是否得到最好的服务,或者甚至会注意到.软提交和NRT非常惊人,但它们并不是免费的.将硬提交间隔设置为15秒.

在我的情况下(索引很重,查询繁重),复制主从的时间太长,减慢了查询到从属.通过将softCommit增加到15min并将hardCommit增加到1min,性能提升很好.现在复制没有问题,服务器每秒可以处理更多的请求.

这是我的用例,但我意识到我并不需要实时在主服务器上提供这些项目,因为主服务器仅用于索引项目,并且每个复制周期都可以在从服务器中使用新项目(5分钟) ),这对我的情况完全没问题.你应该根据你的情况调整这些参数.

Answer 2

对于硬提交,您有openSearcher = false.这意味着即使提交发生,搜索者也没有重新启动,也看不到更改.尝试更改该设置,您将不需要软提交.

SoftCommit会重新打开搜索者.因此,如果您同时拥有这两个部分,则软提交会显示新的更改(即使它们不是硬提交的),并且 - 按照配置 - 硬提交将它们保存到磁盘,但不会更改可见性.

这允许将软提交设置为1秒,并且文档快速显示并且难以进行硬提交.