3

我正在使用 Rails 3 和 Sunspot solr 3.5。我的应用程序使用 Solr 来索引用户生成的内容并使其可供其他用户搜索。目标是让用户从用户上传数据的那一刻起就可以尽快搜索到这些数据。我不知道这是否符合实时搜索的条件。

我的应用程序有两个模型

  1. 帖子
  2. 邮政项目

我通过包含来自帖子项目的数据来索引帖子，以便当用户根据 post_item 记录中提供的特定描述进行搜索时，相应的帖子对象在搜索中可用。

用户经常更新 post_item，所以每次添加新的 post_item 时，我都需要重新索引相应的 post 对象，以便新的 post_item 在搜索期间可用。

所以此刻每当我收到一个新的 post_item 对象时，我都会运行


 post_item.post.solr_index! #

根据本文档，它会立即更新索引并提交。这可行，但这是在这种情况下处理索引的正确方法吗？我在这里读到，在搜索时调用索引可能会破坏 solr。频繁的手动索引调用也不是要走的路。

关于正确方法的任何建议。除了切换到 ElasticSearch 之外，还有其他选择吗

4

2 回答 2

1

尝试使用这个 gem https://github.com/bdurand/sunspot_index_queue

你将能够批量重新索引，比方说，每分钟，它绝对不会破坏索引

于 2012-05-15T11:03:49.497 回答
1

如果您刚刚开始并有幸在 Solr 和 ElasticSearch 之间进行选择，go with ElasticSearch.

我们在生产中使用 Solr，随着索引和搜索量的增长，我们遇到了许多奇怪的问题。结论是 Solr 是为索引大型文档（word/pdf 内容）和大量（数十亿？）而构建/优化的，但每天或几天更新一次索引，而没有人搜索。

对于消费者 Rails 应用程序来说，这是一个错误的选择，因为文档很小，数量很少（以百万计）更新是随机和连续的，并且搜索需要有点实时（延迟 5-10 秒就可以了）。

我们用于调整服务器的一些技巧。

removed all commits (i.e., !) from rails code, 
use Solr auto-commit every 5/20 seconds, 
have master/slave configuration, 
run index optimization(on Master) every 1 hour 
and more.

当提交触发时，我们仍然看到从属服务器上的 CPU 使用率很高。因此，一些搜索需要很长时间（有时> 60 秒）。

我也怀疑批处理索引是否sunspot_index_queue gem可以解决高 CPU 问题。

于 2012-09-02T19:20:34.127 回答