Warning: file_get_contents(/data/phpspider/zhask/data//catemap/9/solr/3.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
使用solrJ的就地更新_Solr_Solrj_In Place_Solr5 - Fatal编程技术网

使用solrJ的就地更新

使用solrJ的就地更新,solr,solrj,in-place,solr5,Solr,Solrj,In Place,Solr5,我正在尝试实现文档的就地更新 Solr版本-5.5.2 Schema.xml- <dynamicField name="store_*" type="int" indexed="false" stored="false" docValues="true"/> <field name="_version_" type="long" index

我正在尝试实现文档的就地更新

Solr版本-5.5.2

Schema.xml-

<dynamicField name="store_*" type="int" indexed="false" stored="false" docValues="true"/>
<field name="_version_" type="long" indexed="false" stored="false" docValues="true" multiValued="false"/>

solrconfig.xml-

<updateHandler class="solr.DirectUpdateHandler2">
  <updateLog>
    <str name="dir">${solr.ulog.dir:}</str>
    <int name="numVersionBuckets">${solr.ulog.numVersionBuckets:65536}</int>
  </updateLog>
</updateHandler>`

${solr.ulog.dir:}
${solr.ulog.numVersionBucket:65536}
`
正在使用的UpdateHandler-
DirectUpdateHandler2

根据文章,目标字段是非索引(index=“false”)、非存储(stored=“false”)、单值(multiValued=“false”)数字docValues(docValues=“true”)字段

我只使用
updateHandler.addDoc(addUpdateCommand)添加文档并在使用添加文档后不执行提交-
solrClient.commit()

问题未提交,文档未反映

如果我使用autoSoftCommit并只添加文档,则更改会反映在索引中,但会清除filterCache

我的目标是在不清除过滤器缓存的情况下实现就地更新


这可以实现吗?

简短回答:不,在不清除Solr缓存的情况下,您不能既为文档编制索引(部分或就地更新仍然是索引),又使其可搜索(或更改可见)

详细回答:您可以为文档编制索引并保持缓存填充(openSearcher=false),但是新索引的文档不会出现在搜索结果中,除非您执行硬提交或软提交。要了解为什么您应该了解Solr/Lucene的工作原理:

  • Lucene索引表示为一组段。此外,每个段本身都是一个自动包含的索引,每个段包含多个文件。最后,一旦写入磁盘,数据段基本上是不可变的

  • 每个Solr核心都有一个IndexSearcher实例来执行查询。IndexSearcher具有创建时存在的所有段的静态视图此视图在IndexSearcher的生存期内不会更改,缓存属于IndexSearcher。

  • 每当您发出提交命令时,都会创建一个新的段。此操作将创建新的IndexSearcher以反映新添加(或更新)的文档。虽然新的IndexSearcher正在初始化,但旧的IndexSearcher仍在处理请求。新的IndexSearcher完成后,旧的IndexSearcher(如果未注册(已销毁))和新的IndexSearcher将开始为查询请求提供服务

  • 因此,过滤器缓存被清除,因为它属于新的IndexSearcher。但您可以使用自动预热:使用旧缓存中的值预填充新缓存(请参阅solrconfig.xml中的autowarmCount)。注意,因为预热可能会影响性能——基本上,新的IndexSearcher将使用旧IndexSearcher缓存中的键(查询)重新运行一定百分比(可配置)的过滤器查询——因为IndexSearcher在预热完成之前尚未准备好

    见:


    PS:由于上述原因,通常不建议为每个新文档/更新发布提交。最好依靠自动硬提交和软提交。

    问题在于,筛选器缓存可能包含提交后不应再出现在缓存结果中的文档。有一个可能的黑客攻击-但“可见性有成本”是一个很好的假设。如果可能的话,使用commitWithin来减少提交的数量。挑剔:“最好依靠硬提交和软提交”——我想你是指commitWithin(或与maxTime/maxDocs一起自动提交),因为任何提交,无论何时发出,都将是硬提交或软提交?是的,我是指与maxDocs和/或maxTime一起提交。我将在solrconfig.xml中设置一个openSearcher=false的硬提交加上一个软提交。在我看来,即使commitWithin是一个软提交,但如果间隔不太大,它也会导致显式硬提交(例如破坏缓存)的问题,对吗?显式提交(/update?commit=true)将触发硬提交,afaik。区别在于默认设置-您可以将
    commitWithin
    设置为硬提交,如果参数中添加了
    softCommit=true
    ,则可以将
    commit=true
    设置为软提交。在这种情况下,它们将是相同的,因为缓存将过期(随着新搜索程序的打开)。