在具有多个Web服务器的现有.NET/SQL Server堆栈上实现Lucene

我想看看如何使用Lucene为我目前管理的网站提供全文搜索解决方案。该网站完全基于SQLServer2008/C#.NET4技术构建。我要索引的数据实际上非常简单，每个记录只有几个字段，其中只有一个字段是可搜索的

我不清楚我需要使用的最佳工具集是什么，或者我应该使用的体系结构是什么。具体而言：

我应该把索引放在哪里？我见过有人建议把它放在Web服务器上，但这对很多Web服务器来说似乎是浪费。在这里，中央集权肯定会更好吗

如果索引是集中的，那么如果它只存在于文件系统中，我将如何查询它？我是否必须有效地将它放在所有Web服务器都能看到的网络共享上

是否有任何预先存在的工具可以按计划增量填充Lucene索引，从SQL Server数据库中提取数据？我在这里提供自己的服务会更好吗

当我查询索引时，我应该只提取一组记录id，然后返回DB以获取实际记录，还是应该直接从索引中提取搜索所需的所有内容

在这个环境中尝试实现类似Solr的东西有价值吗？如果是这样，我可能会给它自己的*nix虚拟机，并在Tomcat中运行它。但我不确定索尔在这种情况下会给我买什么

---

我将根据我们选择实施的方式以及我在实施过程中学到的一些经验来回答：

我应该把索引放在哪里？我见过有人建议把它放在Web服务器上，但这对很多Web服务器来说似乎是浪费。在这里，中央集权肯定会更好吗

• 这取决于您在这里的目标，我们有一个严重利用率不足的web层（约10%的CPU），和一个超负荷的数据库进行全文搜索（大约60%的CPU，我们希望它更低）。在每个web层上加载相同的索引让我们利用这些机器并拥有大量冗余，我们仍然可以丢失10个web服务器中的9个，并在需要时保持Stack Exchange网络正常运行。这有一个缺点，它对我们来说是非常IO（读取）密集的，购买web层时没有考虑到这一点（大多数公司通常都是这样）。虽然它工作正常，但我们仍然会将web层升级到SSD，并实现.Net端口中的其他一些位，以弥补这个硬件缺陷（

  NIOFSDirectory

  ）
• 另一个缺点是，如果我们为web层索引所有数据库

  n

  次，但幸运的是，我们并不缺乏网络带宽和SQL server缓存，结果每次都使这成为一个非常快速的增量索引操作。对于大量的web服务器，仅此一项就可能消除此选项

如果索引是集中的，那么如果它只存在于文件系统中，我将如何查询它？我是否必须有效地将它放在所有Web服务器都能看到的网络共享上

• 您可以在文件共享上查询它，只需确保一次只有一个索引（

  write.lock

  ，目录锁定机制将确保这一点，并且在一次尝试多个IndexWriter时出错）
• 请记住我上面的说明，当大量读者四处奔波时，这是IO密集型的，因此您的商店需要足够的带宽，至少缺少iSCSI或光纤SAN，在高流量（每天数十万次搜索）使用时，我会对这种方法持谨慎态度
• 另一个需要考虑的问题是如何更新/提醒web服务器（或任何查询它的层）。完成索引过程后，您需要重新打开

  IndexReader

  s以获取包含新文档的更新索引。我们使用一个警告来提醒任何关心索引已更新的人…任何消息传递机制都可以在这里工作

是否有任何预先存在的工具可以按计划增量填充Lucene索引，从SQL Server数据库中提取数据？我在这里提供自己的服务会更好吗

• 不幸的是，我不知道有什么，但我可以告诉你我是如何做到这一点的
• 在索引特定表（类似于Lucene中的文档）时，我们向该表添加了一个索引。当我们索引时，我们根据最后一行版本（一个数据类型，作为一个数据类型向后拉）进行选择。我选择通过一个简单的.txt文件将上一个索引日期和上一个索引行版本存储在文件系统中，原因之一是：Lucene中的所有其他内容都存储在那里。这意味着，如果出现大问题，您只需删除包含索引的文件夹，下一个索引过程将恢复，并具有完全最新的索引，只需添加一些代码来处理任何内容，即“索引所有内容”

当我查询索引时，我应该只提取一组记录id，然后返回DB以获取实际记录，还是应该直接从索引中提取搜索所需的所有内容

• 这实际上取决于您的数据，对于我们来说，将所有内容存储在索引中并不切实可行（也不建议这样做）。我建议您将搜索结果的字段存储在索引中，我的意思是，在用户单击进入完整[此处插入类型]之前，您需要在列表中显示搜索结果
• 另一个需要考虑的问题是数据更改的频率。如果许多未搜索的字段正在快速更改，则需要对这些行（文档）重新编制索引以更新索引，而不仅仅是在搜索的字段更改时

在这个环境中尝试实现类似Solr的东西有价值吗？如果是这样，我可能会给它自己的*nix虚拟机和