我正在开发一个每天迎合大约100,000次搜索的应用程序。我们可以安全地假设每天在数据库中有大约相同数量的更新/插入/删除。当前的应用程序使用本机SQL，我们打算将其迁移到Hibernate并使用Hibernate Search。
由于数据库记录不断变化，我们需要启用自动索引。管理层担心自动索引可能导致的性能影响。
无法进行预定的批量索引，因为记录中的更改必须在更改后立即可用于搜索。
我已经搜索过某种性能统计信息，但没有找到。
任何已经参与过Hibernate Search并遇到类似情况的人都可以分享他们的想法吗？
感谢您的帮助。
此致
Shardul。
答案 0 :(得分：0)
它可能工作正常，但没有基线就很难猜到。我有更多搜索/天的经验，经过一些微调后它运作良好，但是如果不尝试它就不可能知道这是否适用于你的场景。 如果正常调整失败并且NRT不能足够快地证明，您可以始终对索引进行分片，使用多主配置并插入分布式二级缓存，例如Infinispan：所有组合架构都可以实现线性可扩展性，前提是您有设置它的时间和合理的硬件。
很难说你需要什么样的硬件，但可以肯定它会比原生SQL解决方案更有效率。我建议制作一个POC，看看你可以在一个节点上走多远;如果您拥有的查询类型非常适合Lucene，则可能不需要多个服务器。请注意Lucene在查询中比在更新中快得多，所以既然你估计你将有相同数量的写入和搜索，那么问题不一定是在搜索量/秒内，而是在写入（更新）/秒中和总数据（索引）大小。最新的Hibernate Search引入了一个NRT索引管理器，它可以很好地适应这些用例。