结合 DB 和 Lucene 搜索的最佳实践

Question

我正在使用 .Net 开发一个高级搜索引擎，用户可以在其中基于多个字段构建查询：

1. 标题
2. 文档内容
3. 开始日期，结束日期
4. 从修改日期到修改日期
5. 所有者
6. 位置
7. 其他元数据

我正在使用 lucene 来索引文档内容及其对应的 ID。但是，其他元数据驻留在 MS SQL DB 中（以避免扩大索引，并在元数据的任何修改时不断更新索引）。

如何执行搜索？

当任何用户搜索一个词时：

• 通过在 SQL DB 中查找，根据用户选择的条件缩小搜索结果。
• 将匹配的 ID 返回到 lucene searcher Web 服务，该服务搜索在从 Adv Search Web 服务返回的 DocumnentID 中输入的关键字。
• 然后通过再次查看数据库来获取文档 ID 的相关元数据（从 lucence 返回）。

正如您在此处所注意到的，在 DB 中进行了一次查找，然后是 Lucene，最后是 DB，以获取要在 Grid 中显示的值。

问题：

如何克服这种情况？我想开始搜索 lucene，但如果索引的文档达到 200 万，这有一个缺点。 （我认为首先使用 DB 缩小结果范围对性能有很大影响）。

另一个问题是将 ID 传递给 lucene 搜索服务，传递数十万个 ID 的效果如何？什么是替代解决方案？

我欢迎任何想法，所以请分享你的想法。

Answer 1

您当前的解决方案在查询时会产生以下开销：

1) 通过 MS-SQL 缩小搜索空间

• 在您的应用中生成查询
• 通过网络将其发送到 MS-SQL
• SQL 查询的解析/优化/执行
• [!!] 返回 100,000 个 ID 的 I/O 开销

2) 通过 Lucene.NET 执行有界全文搜索

• [!!] 在应用程序中生成/执行包含 100,000 个 ID 子句的大型 BooleanQuery 的 Lucene 内存开销（您需要首先覆盖 1024 个子句的默认限制才能衡量此效果）李>
• 标准 Lucene 全文搜索执行
• 返回匹配的 ID

3) 通过 MS-SQL 实现结果详细信息

• 快速、索引、基于 ID 的搜索结果文档查找（仅显示结果的第一页通常需要大约 10-25 条记录）

---

您可能会做出两个值得重新考虑的假设

A) 对所有元数据（日期、作者、位置等）编制索引将不可接受地增加索引的大小。

• 先试用：这是最佳实践，通过让 Lucene 为您执行除文本搜索之外的所有过滤，您将大大减少查询执行开销。

• 此外，索引的大小主要与每个字段的 基数 有关。例如，如果您只有 500 个唯一的所有者名称，那么只会存储这 500 个字符串，并且每个 lucene 文档将通过符号表查找在内部引用其所有者（4 字节整数 * 2MM 文档 + 500 个字符串 = ）。

B) MS-SQL 查询将是过滤非文本元数据的最快方式。

• 重新考虑这一点：使用适当的 Lucene 类型正确索引元数据后，查询 Lucene 和查询 MS-SQL 不会产生任何额外开销。 （在某些情况下，Lucene 甚至可能更快。）
• 您的情况可能会有所不同，但根据我的经验，在 Lucene 的 2MM 文档集合上执行这种类型的过滤全文搜索通常会在 100 毫秒内运行。

---

总结一下最佳实践：

• 索引您要查询或过滤的所有数据。 （无需存储源数据，因为 MS-SQL 是您的记录系统）。

• 针对 Lucene 运行过滤查询（例如文本和日期范围、所有者、位置等...）

• 返回 ID

• 使用返回的 ID 从 MS-SQL 实现文档。

---

出于多种原因，我还建议探索迁移到独立搜索服务器（Solr 或 Elasticsearch）：

1. 您不必担心搜索索引内存需求会蚕食应用程序的内存需求。
2. 您将利用复杂的过滤器缓存性能提升和基于操作系统的 I/O 优化。
3. 您将能够从广泛使用/支持的主要基于配置的环境中轻松迭代您的搜索解决方案。
4. 您将拥有适当的工具来扩展/调整/备份/恢复搜索，而不会影响您的应用程序。