django-haystack在Solr 4.0中的局限性

Question

我们计划在我们的web应用中使用django-haystack和Solr4.0 (具有近乎实时的搜索)，我想知道是否有人可以建议使用haystack的限制(与直接使用solr相比)。也就是说，使用django-haystack是否会产生性能影响/开销？我们大约有3个million+文档需要索引，而且每天需要额外(估计)增加100k。

理想情况下，我认为我们需要一个简单的Solr4上的API --但是我发现很难找到任何特定于python的东西，而且还在积极维护(当然除了django-haystack )。我将非常感谢您对此的任何指导。

Answer 1

看起来你的问题可以换个说法：“干草堆是怎么烧掉你的？”干草堆在某些方面很不错，但也让我在工作中感到头疼。这里有一些我不得不编码的东西。

你提到了索引。Haystack具有用于重建索引的管理命令。我们将在测试期间使用这些来重建核弹和铺路，但是为了重新索引我们的生产内容，我们有点碰壁了。该命令将永远花费时间，您将不知道它在进度方面处于什么位置，如果它失败了，您就完蛋了，必须重新开始。我们达到了一个点，我们有太多的内容，它将足够可靠地失败。我们切换到批量制作内容，并在芹菜任务中对这些内容进行重新索引。我们执行了一个管理命令来执行批处理并启动所有这些任务。这在面对部分故障时更加健壮，而且，更好的是，它实际上finishes.The底层任务将使用干草堆调用将数据库对象转换为ORMiness文档--这个solr很不错，而且还没有耗尽我的精力。不过，我们手动编辑我们的solr模式。

query API适用于简单的东西。如果您正在进行更复杂的solr查询，您可能会发现自己只是在输入原始查询。这可能会导致意式代码。我们最终将未加工的意大利面条放入solrconfig文件中的请求处理程序中。我们仍然使用haystack来打开高亮显示或选择特定的请求处理程序，但同样，我更高兴的是，我们保持简单，我们确实修改了一个方法，以便根据需要添加任意参数。

关于如何使用solr，还有其他一些假设，这些假设似乎已经包含在代码中。Haystack是唯一一个我对代码比较熟悉的开源项目。我不确定这是不是一件好事，因为它并不总是出于选择。我们有大量的层蛋糕代码来扩展一个干草堆类，并覆盖它来做正确的事情。这并不可怕，但当你还必须将堆积如山的代码复制并粘贴到这些被覆盖的方法中时，情况就会变得更加可怕。

所以..。它不是完美的，但部件很方便。如果您对编写自己的API犹豫不决，使用haystack可能会省去一些麻烦，特别是当您想要获取所有solr结果并将它们传递回django模板或其他东西时。听起来像是随着文档的不断涌入，您无论如何都会想要编写一些批处理索引作业。从这个开始，准备好有点焦头烂额，然后看看发生这种情况时的源代码，它实际上是非常可读性的。