当我（错误）使用索引数据库表作为全文搜索索引时会出现性能问题吗？

Question

在工作中，我们讨论了在我们的产品中添加全文搜索引擎。一种建议是使用 MSSQL 数据库表作为全文搜索索引，如下所示：

Keyword  Document
------------------
This     Doc1
Is       Doc1
A        Doc1
Test     Doc1
And      Doc2
This     Doc2
Too      Doc2

搜索将获取包含按文档分组的单词的所有行。

编辑：此表将包含 > 50 个 Mio。行。

澄清一下：我们不想使用 MSSQL 的全文功能。

坦率地说：我不喜欢这样，我宁愿使用 Lucene，但由于我们的产品是用 VB6 编写的，因此需要一些工作。所以目前我们将按照我的描述去做，除非我拿出一些确凿的事实来反对它。或者也许你可以让我相信这毕竟不是一个坏主意。

Answer 1

您所描述的实际上是许多论坛的工作方式（例如phpBB）。所以是的，这是一种已被其他人采用的方法，并且效果很好。缺点：

• 您不能执行“word NEAR word”之类的操作，只能执行“word AND/OR word”之类的操作
• 表格往往会快速增长。全文搜索引擎通过剥离复数、折叠常用前缀等方式压缩单词，以缩小搜索空间。
• 对这些东西进行拒绝服务攻击相对简单，因为搜索会提取大量数据（至少，对于许多论坛来说，这是一个大问题）。

一个小优化：创建一个单词表，并为每个单词分配一个 ID（32 位 int；英语只有大约 200 万个单词，包括名称等）。然后创建一个 M:N 映射“word-id”到“doc-id”。这将大大减少数据库大小。

Answer 2

如果您使用的是 VB6，并且想要使用 Lucene，请获取 clucene，将其构建为 dll（可能使用 C 包装器来公开 AddDocument 和 SearchFiles 函数）并从您的 VB6 代码中调用它们。 （或者创建一个简单的 COM 对象来做同样的事情并调用它）

然后可以像您的数据库“hack”一样轻松地解析数据并将其呈现给您的用户，并且会少很多麻烦，尤其是当您的数据库表保持最新并添加新内容时。

你会如何处理重复的单词？用每个文档中的每个单词更新数据库会非常慢（如果您期望有 5000 万个唯一性！），以及您将如何处理添加新文件，而不是简单地尝试添加每个单词（除非您会对文档进行差异化，只更新添加的单词，或者删除已删除的单词——真是麻烦！）

您不妨花一天左右的时间让 clucene 运行。