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