像关系数据库一样使用 Lucene答案

【问题标题】：Using Lucene like a relational database像关系数据库一样使用 Lucene
【发布时间】：2009-05-06 09:00:24
【问题描述】：

我只是想知道我们是否可以在 lucene 中实现一些 RDBMS 功能。

示例： 1) 我有 10,000 个项目文档（pdf 文件），必须对其内容进行索引，以使它们可供搜索。 2）每个文件都与一个项目有关。项目可以包含项目名称、编号、开始日期、结束日期、位置、类型等详细信息。

我必须在 pdf 文件的内容中搜索给定的关键字，但在显示结果时，我想显示第 (2) 点中提到的项目元数据。

我的想法是在索引时将一个名为 projectId 的字段与每个 pdf 文件相关联。一旦我们得到它，我们将再次触发搜索以获取项目元数据。

这样我们可以避免重复数据。此外，如果我们想更新项目元数据，我们最终只能在一个地方进行更新。否则，如果我们将此元数据与所有 pdf 文档索引一起存储，我们最终将更新所有文档，这不是我想要的方式。

请指教。

【问题讨论】：

您是否试图避免复制以减少重复数据占用的空间量？或者您是否试图避免保持两个系统同步的后勤工作？

标签： search join indexing lucene rdbms

【解决方案1】：

如果我理解正确，你有两个问题：

我可以在 Lucene 中存储项目 ID 并使用它进行进一步搜索吗？是的你可以。这是一种常见的做法。
我可以使用这个项目 ID 在 Lucene 中搜索项目元数据吗？是的你可以。我不知道这是否是个好主意。这取决于您的元数据更新频率和您的访问模式。如果元数据是相对静态的，并且你只能通过 id 访问它，Lucene 可能是一个存储它的好地方。否则，您可以使用项目 ID 作为数据库表的主键，这可能更合适。

【讨论】：

嗨，所有索引都只能使用 lucene。不会有任何数据库通信。但是lucene结构就是这样的。表示 1) 索引目录 1 ：将具有产品 id 的文档的索引 2) 索引目录 2 ：将具有包含产品 id 的产品元数据的索引这背后的主要思想是减少 lucene 索引大小。意味着这 10,000 个文档中的每一个都将具有产品元数据，这是重复的数据，因为我想做一个单独的单个产品元数据索引，需要在文档索引中使用产品 ID。
很好。您可以支持“给我所有具有产品 ID nnn 的文档”或“给我产品 ID aaa、bbb 的元数据”类型的查询。您甚至可以有一个两阶段查询，相当于“给我与这些文档相关的产品的所有元数据”。这不如 RDBMS 灵活，但对于您的用例来说似乎已经足够了。如果你想要范围查询，你可能需要用零填充你的 id。

【解决方案2】：

听起来是一件非常好的事情。您将拥有的唯一限制（通过在 Lucene 中存储对项目的引用而不是项目数据本身）是您将无法同时查询文档文本和项目元数据。例如， "documentText:foo OR projectName:bar" 。如果您没有这样的要求，那么将 ID 存储在引用数据库行的 Lucene 中似乎是一件好事。

【讨论】：

【解决方案3】：

我不确定您的整体设置，但也许Hibernate Search 适合您。它将允许您将关系数据库的优势与 Lucene 等全文搜索引擎的强大功能结合起来。元数据可能与原始 pdf 文档一起存在于数据库中，而 Lucene 文档仅包含可搜索的数据。

【讨论】：

【解决方案4】：

这绝对是可能的。但请始终注意这样一个事实，即您将 Lucene 用于非预期用途。一般来说，Lucene 是为全文搜索而设计的，而不是为映射关系内容而设计的。因此，您的系统越复杂，您的关系内容就越会降低性能。

特别是，有几个方面需要密切关注：

将每个字段的值存储在索引中会降低性能。如果您不太在意亚秒级搜索结果，或者您的索引相对较小，那么这可能不是问题。
此外，请注意，如果您没有使用默认排名算法，并且您的自定义算法需要有关项目的信息来计算每个文档的分数，这也会对搜索性能产生巨大影响。

如果您需要专为关系内容设计的更强大的索引，有一些分层索引工具（由 Apache 开发，称为 Jackrabbit）值得研究。

随着您的项目不断发展，您还可以查看同样由 Apache 开发的 Solr，它提供了一些附加功能，例如多面搜索。

【讨论】：

【解决方案5】：

你可以这样使用 Lucene；

优点：

全文搜索很容易实现，而在 RDBMS 中则不然。

缺点：

参照完整性：您可以在 RDBMS 中免费获得它，但在 Lucene 中，您必须自己实现它。

【讨论】：

我对 Lucene 也不熟悉，但根据stackoverflow.com/questions/1296709/… 看来，使用“文档 ID”作为外键也是用户必须注意的问题。
同意：参照完整性是个问题。