3000 万个不同的短语，而不是文档，从一个单词到 10 个单词的句子，我需要支持单词/短语搜索。基本上是什么contains(phrase, "'book' or 'stack overflow'")提供的。
我有一个 SQL Server 2005 实例（32 位，4 proc，4gb）针对几个全文目录，对于高基数的单词搜索，性能很糟糕。
这是我加快速度的想法，也许有人可以提供指导-
1) 升级到 2008 iFTS，64 位。Sql Server 2005 FTS 的 windows 服务永远不会超过 50mb。根据我收集到的信息，它使用文件系统缓存来查找目录索引。我在磁盘上填充的目录只有大约 300mb，那么为什么不能全部都在内存中呢？iFTS 的新内存架构（它是 sqlserver 进程的一部分）可能在这里有帮助吗？
2) 将目录扩展到多台服务器。对链接的 FTS 服务器的查询会并行运行吗？
3）由于我在这里搜索短语而不是文档，因此可能 Sql Server 的全文搜索不是答案。Lucene.NET？将目录索引放在内存驱动器上？
Lucene.Net 可以为这种应用程序提供非常高的性能以及非常简单的 API。2.3.2 版即将完成，与 2.1 版相比，它提供了额外的性能提升。虽然将 Lucene 索引放入 RAMDirectory（Lucene 的基于内存的索引结构）将提供更好的性能，但即使使用 FSDirectory（基于磁盘的索引），我们也看到了很好的结果。
FTS 在这种负载下吱吱作响，我有点惊讶。但是，如果事实证明确实如此，那么经典的方法（Gary Kildall 开发它是为了搜索 CD！）将是使用反转索引。我已经在一系列应用程序中使用了这种技术很长时间。它通常被称为“倒置”或“倒置”索引技术。（参见http://en.wikipedia.org/wiki/Search_engine_indexing#Inverted_indices）。该技术可以很好地扩展，我已经测试过它可以索引多达 800 万份文档。即使搜索八百万个文档，只要索引正确，它也能在三秒内得到结果。通常它比这快得多。
我使用反转索引来获取（通过 TOP x 最多可承受的数量）可能的候选者池，然后使用正则表达式对这些候选者进行强力搜索。它工作得很好。
作为一个开箱即用的解决方案，我更喜欢使用“Microsoft Office SharePoint Server”在文档内容中进行索引和搜索。如果您想编写自己的索引和搜索服务，一个免费的替代方案是 Lucene.Net 库。使用 Lucene.Net 编写自己的全文搜索服务将为您提供所需的所有灵活性（是的，如果您愿意，可以将索引存储在外部存储中）。
看看Apache Solr。它是一个使用 HTTP 接口包装 Lucene 的搜索服务器。您的每个短语都会映射到 Solr 文档。30M 的文档对于 Solr 来说并不多，因为您的文档会很短。最终性能还取决于您需要多少查询/秒。