Question

我有一个使用太阳黑子的Rails应用程序，它正在生成大量的个人更新，这会在Solr上产生不必要的负载。将这些更新批量发送给Solr的最佳方法是什么？

Answer 1

假设Rails应用程序的更改还会更新持久性存储，您可以检查Data Import Handler (DIH)处理程序，该处理程序可以定期调度以更新Solr索引。
因此，不是在Solr上触发每个更新和提交，而是可以决定频率批量更新Solr 但是，预计搜索结果会出现延迟。

此外，您是否更新个人记录并提交？如果使用Solr 4.0，您也可以检查Soft and Hard Commits。

Answer 2

太阳黑子使一批文件的索引非常简单：

Sunspot.index(array_of_docs)

这将发送您正在寻找的Solr批量更新。

您的Rails应用程序的技巧是为这些批次的文档找到合适的范围。它们是作为大量用户请求的结果而创建的，并且分散在您的不同应用程序进程周围？或者您是否有自己控制的批处理过程？

GitHub上的sunspot_index_queue项目看起来是一种合理的方法。

或者，您可以随时关闭Sunspot的“自动索引”选项，该选项会在您的文档更新时触发更新。在您的模型中，您可以将auto_index: false传递给searchable方法。

searchable auto_index: false do
  # sunspot setup
end

然后您可以更自由地批量控制索引。您可以编写一个独立的Rake任务，该任务迭代在最后 N 分钟内创建和更新的所有对象，并以1,000个docs左右的批量对其进行索引。无限循环应该能够经得起非常可靠的更新。

在真正大规模的情况下，您确实希望所有更新都通过某种队列。将文档数据插入到Kafka或AWS Kinesis这样的队列中，以便以后通过另一个独立的索引过程批量处理，对于这种情况来说非常理想。

Answer 3

我在这里使用了稍微不同的方法：

我已经在使用auto_index: false并使用sidekiq在后台处理solr更新。因此，我没有建立额外的队列，而是使用sidekiq-grouping gem将Solr更新作业组合为批处理。然后，我在作业中使用Sunspot.index在单个请求中为分组对象编制索引。