【问题标题】:SOLR DataImportHanlder (DIH) Full Indexing - sometimes our index shows near-zero documents during importSOLR DataImportHanlder (DIH) 完整索引 - 有时我们的索引在导入期间显示接近零的文档
【发布时间】:2018-10-26 15:39:08
【问题描述】:

我们正在运行 SOLR 7.2.1。
我们通过 DataImportHanlder(clear=true)定期更新我们的索引(完全重新索引)。

大多数时候,我们索引中的正常文档数量(通常约为 250,000)在 DIH 运行时仍然可见(因为它直到导入结束才提交)。

然而,我们偶尔会遇到一个问题,即索引会突然只显示文档的一小部分(例如,可能有 20,000 个)。

我无法追查其来源,但我确实怀疑原因:如果有人修改了我们网站管理区域中的产品,这将触发该文档的 SOLR 更新(带有提交)。这个提交是否有可能通过一个单独的进程导致部分完成的 DIH 数据也被提交?如果是这样,那就可以解释为什么我们有时会在索引中得到更小的文档子集。 DIH 完成后,文档计数恢复正常。

那么,重叠的提交会相互影响吗?换句话说,提交是“全局”的,还是只影响当前进程中正在更改的数据?

如果您对此作出任何澄清,我将不胜感激。

谢谢!

比尔

【问题讨论】:

  • 注意:我想我可以回答我自己的问题,但我会等待比我更了解的人的验证。在我的测试环境中,在运行 DIH 时,如果我从另一个进程添加另一个文档(commit=true),那么我确实看到索引已更新,并且当时 DIH 已完成处理的当前文档数现在是什么在索引中公开可用。那么,下一个问题是,SOLR 能否在 DIH 运行时阻止外部进程向 SOLR 提交更新?我怀疑不是,除了改变其他 procs,但值得一问。

标签: solr dih


【解决方案1】:

事务在 Solr 中不是隔离的——提交或回滚将影响所有为索引排队的文档,而不仅仅是属于线程的文档。这就是你自己发现的,当 DIH 在幕后工作时发出的提交就是正在发生的事情。

解决这个问题的方法通常是放弃使用 DIH,而是自己索引所有文档。这将使您完全控制索引过程。我会尽量避免在开始时必须从索引中删除所有文档 - 如果可能的话,跟踪已删除的文档(并在 Web 界面中删除它们时删除它们)并稍后进行额外的批量删除(如果您怀疑它们由于某种原因没有被删除)。

另一种选择是在单独的索引上执行 DIH 操作,然后使用 collection alias to swap 在索引完成后搜索到的收集点的位置。这允许您对单独的集合执行完整索引,并在完成后将当前集合交换为新集合,并开始从您刚刚构建的集合开始提供查询。

请注意,如果您在通过 DIH 编制索引时更改基础数据,并依靠直接 Solr 更新来完成,您最终会在索引中得到错误的数据,因为直接更新将针对不同的集合/索引。

我的选择是尝试使 Solr 集合与您的数据库保持同步,而不必使用 DIH - 而是依靠直接更新。然后,您可以使用commitWithin 允许多个线程添加文档,而无需在任一线程中发出显式提交。

【讨论】:

  • 感谢 MatsLindh,我们的网站基于购物车解决方案(在 PHP 上),它确实有一些用于索引 SOLR 本身的模块,但效率非常低(需要 2 多个小时才能运行,vs: 3分钟通过 DIH)。有一天我可能会用另一种语言(不是 PHP)自己构建一个自定义索引系统。目前,DIH 是我最好的选择,但我不知道“集合别名”的想法。我喜欢。我将继续探索自定义索引器,但我还将尝试使用集合别名的想法。谢谢!
  • 使用 PHP 将更新推送到 Solr 并没有什么固有的慢。您可能希望使用消息队列,例如基于 RabbitMQ、Apache Kafka 或类似的东西,以及接受从数据库中获取并推送到 Solr 的 id 列表的函数。确保将尽可能多的文档批处理到单个 HTTP POST 中。我们通常会看到 1k 文档的更新时间
猜你喜欢
  • 2016-01-07
  • 2023-03-28
  • 2012-02-20
  • 1970-01-01
  • 2017-07-06
  • 2013-01-16
  • 1970-01-01
  • 1970-01-01
  • 2023-03-10
相关资源
最近更新 更多