我们计划将django-haystack与Solr4.0（近实时搜索）一起用于我们的网络应用程序，我想知道是否有人可以就使用haystack的限制提出建议（与直接使用solr相比）。即使用django-haystack会有性能损失/开销吗？我们有大约300万个文档需要索引+每天额外增加（估计）100k。
理想情况下，我认为我们需要一个比Solr4更简单的API - 但我发现很难找到任何特定于python的东西，它仍然被积极维护（除了django-haystack ofcourse）。我对此有任何指导意见。
答案 0 :(得分：0)
好像你的问题可以改写一下＆＃34; Haystack如何焚烧你？＆＃34;干草堆对某些事情很好，但也让我有些头疼。以下是我必须编写代码的一些内容。
你提到了索引。 Haystack具有用于重建索引的管理命令。我们将在测试期间将这些用于核武器和铺设重建，但是为了重新索引我们的生产内容，我们有点碰壁。这个命令将永远存在，你不会知道它在进步方面的位置，如果它失败了你就被搞砸了，不得不重新开始。我们达到了一个我们有太多内容的地步，它将足够可靠地失败。我们转而制作批量内容，并在芹菜任务中重新编制索引。我们制定了一个管理命令来进行批处理并启动所有这些任务。面对部分失败，这一点更加强大，甚至更好，它实际上已经完成。底层任务将使用haystack调用将数据库对象转换为solr文档 - 这个ORMiness很好并且还没有烧了我。但是，我们手动编辑我们的solr模式。
查询API对于简单的东西是可以的。如果你正在进行更复杂的solr查询，你会发现自己只是在进行原始查询。这可能导致意大利面条代码。我们最终将原始spaghetti推送到solrconfig文件中的请求处理程序中。我们仍然使用haystack打开突出显示或选择一个特定的请求处理程序，但是，当我们保持简单并且我们确实破解了根据需要添加任意参数的方法时，我感到更高兴。
还有其他一些关于如何使用solr的假设，这些假设似乎已经融入代码中。 Haystack是唯一一个我真正熟悉代码的开源项目。我不确定这是不是一件好事，因为它并非一直都是选择。我们有大量的蛋糕代码可以扩展干草堆类并覆盖它以做正确的事情。这并不可怕，但是当你必须将haystack代码复制并粘贴到那些被覆盖的方法中时，它开始变得更加可怕。
所以......它并不完美，但部件很方便。如果您仍在编写自己的API，那么使用haystack可能会省去一些麻烦，特别是当您想要获取所有solr结果并将它们传回django模板或其他任何内容时。听起来随着文件的不断涌入，无论如何你都会想要编写一些批量索引作业。从那开始，准备燃烧一点，看看源头发生的时候，它实际上是非常可读的。