有没有人使用Lucene.NET而不是使用SQL Server附带的全文本搜索？

如果是这样，我将对我们如何实现它感兴趣。

例如，我们是否编写了一个Windows服务，该服务每小时查询一次数据库，然后将结果保存到lucene.net索引中？

解决方案

回答

我认为这篇文章是一个很好的起点：

http://www.aspfree.com/c/a/braindump/working-with-lucene-net/

回答

我尚未针对数据库完成此操作，问题还算开放。

如果我们要搜索数据库，并且可以选择使用Lucene，那么我也猜想我们可以控制何时将数据插入数据库。
如果是这样，则几乎没有理由轮询数据库以查找是否需要重新索引，只需在插入时进行索引，或者创建可用于告诉lucene进行索引的队列表。

我认为我们不需要另一个对它的操作一无所知的索引器，而不必每次都重新索引或者浪费资源。

回答

是的，我已将它完全用于我们所描述的内容。我们有两个服务，一个用于读取，一个用于写入，但这仅是因为我们有多个读者。我敢肯定，仅使用一项服务(编写器)就可以完成此任务，并将阅读器嵌入到Web应用程序和服务中。

我已经将lucene.net用作一般的数据库索引器，所以我得到的基本上是DB ID(用于对电子邮件进行索引)，并且我还使用它来获取足够的信息以填充搜索结果等，而无需触及数据库。在这两种情况下，它都非常有效，但是SQL可能会变慢，因为我们几乎必须获得一个ID，选择一个ID等。我们通过制作一个临时表(其中仅包含ID行)来解决此问题，并且从文件批量插入(这是Lucene的输出)，然后加入到消息表中。快了很多。

Lucene并不是完美的，并且我们必须在关系数据库之外进行一些思考，因为它不是TOTALLY，但是它的作用非常出色。值得一看，而且我听说它没有MS SQL的FTI所存在的"糟糕，抱歉，我们需要再次重建索引"问题。

顺便说一句，我们正在处理205,000万封电子邮件(以及大约100万个唯一附件)，我认为总计约20GB的lucene索引，以及250 + GB的SQL数据库+附件。

性能非常好，至少可以确保我们考虑并调整合并因子(合并索引段时)。一个以上的段没有问题，但是如果我们尝试合并每个段中包含100万个项目的两个段，则可能会出现BIG问题，并且如果观察者线程花费的时间太长，则会有一个监视程序线程将其杀死。 ..(是的，这把我们踢了一会儿)。因此，将每个东西的最大文档数保持为低(即，不要像我们一样将其设置为maxint！)

编辑Corey Trager在此处记录了如何在BugTracker.NET中使用Lucene.NET。

回答

我将Lucene.NET与MySQL一起使用。我的方法是将db记录的主键与索引文本一起存储在Lucene文档中。在伪代码中，它看起来像：

• 存储记录：将文本，其他数据插入表中以获取最新插入的ID将Lucene文档放入(ID，文本)到Lucene文档中更新Lucene索引
• 通过存储的记录的ID从数据库查询结果集中加载数据中每个Lucene文档的搜索Lucene索引

请注意，由于性能出色，我从Lucene切换到Sphinx

回答

我也将lucene.net用作存储引擎，因为它比使用数据库更容易分发和设置具有索引的备用计算机，它只是文件系统副本，我们可以在一台计算机上建立索引，然后将新文件复制到另一台计算机上分发索引。所有搜索和详细信息都从lucene索引中显示，该数据库仅用于编辑。该设置已被证明是可满足我们需求的非常可扩展的解决方案。

关于sql server和lucene之间的区别，sql server 2005全文搜索的主要问题是该服务与关系引擎分离，因此全文结果和关系列之间的联接，订单，聚合和过滤非常昂贵就性能而言，Microsoft声称此问题已在sql server 2008中解决，将全文搜索集成在关系引擎中，但我尚未对其进行测试。它们还使整个全文搜索变得更加透明，在以前的版本中，词干提取器，停用词以及索引的其他几个部分(如黑匣子)难以理解，而在新版本中，则更容易看到它们的工作方式。

以我的经验，如果sql server满足要求，那将是最简单的方法，如果我们期望增长很多，复杂的查询或者需要对全文搜索进行较大的控制，那么我们可能会考虑从一开始就使用lucene将更易于扩展和个性化。