我正在研究针对我们的数据库更好的搜索功能的机制。当前这是一个巨大的瓶颈(导致持久的查询会损害我们的数据库性能)。

我的老板希望我研究Solr，但仔细检查一下，看来我们实际上实际上希望与Lucene本身建立某种DB集成机制。

他们从Lucene常见问题解答中推荐Hibernate Search，Compass和DBSight。

作为当前技术堆栈的背景，我们在Tomcat上使用直接JSP，没有Hibernate，也没有在其之上的其他框架...只是针对DB2数据库的直接Java，JSP和JDBC。

鉴于此，似乎将Hibernate Search集成到我们的系统中可能会有些困难，尽管在这种集成之后可以选择使用Hibernate可能会很好。

任何人都可以使用这些工具之一(或者其他类似的基于Lucene的解决方案)分享任何经验，这些经验可能有助于选择正确的工具？

它必须是一个FOSS解决方案，并且理想情况下将自动(尽管有效)管理数据库中的更改来自动更新Lucene，而无需付出额外的努力在更改完成后通知该工具(否则，滚动我自己的Lucene解决方案只是一样好)。另外，我们有多个应用程序服务器，其中只有1个数据库(+故障转移)，因此如果可以轻松地无缝使用所有应用程序服务器中的解决方案，那就太好了。

我现在正在继续检查这些选项，但是利用其他人的经验确实会有所帮助。

解决方案

回答

对于搜索Lucene而言，纯粹的性能提升肯定会帮上大忙。只索引我们关心/需要的东西，我们应该会很好。如果愿意，可以使用Hibernate或者其他工具，但我认为这不是必需的。

回答

好吧，看来DBSight无法满足FOSS要求，因此，除非它是绝对出色的解决方案，否则我现在就无法选择它。

回答

我在Compass上有很好的经验。它具有与hibernate的良好集成，并且可以通过其GPS设备http://www.compass-project.org/docs/1.2.2/reference/html/gps-将通过hibernate和jdbc进行的数据更改直接镜像到Lucene索引。 jdbc.html。

在所有应用程序服务器上维护Lucene索引可能是一个问题。如果我们有多个App服务器更新数据库，则在使索引与所有更改保持同步方面可能会遇到一些问题。指南针现在可能具有替代机制来处理此问题。

Alfresco项目(CMS)也使用Lucene，并具有一种在服务器之间复制Lucene索引更改的机制，这对于处理这些问题可能很有用。

我们在Hibernate Search真正起步之前就开始使用Compass，因此我无法提供任何比较。

回答

当我们说"针对数据库进行搜索"时，意思是什么？

关系数据库和信息检索系统有充分的理由使用非常不同的方法。我们要搜索什么样的数据？我们执行哪种查询？

如果我要像Compass一样在数据库之上实现反向索引，我不会使用它们的方法，即通过BLOB实现Lucene的" Directory"抽象。相反，我将实现Lucene的IndexReader抽象。

关系数据库非常有能力维护索引。 Lucene在此上下文中带来的价值是其分析功能，这对于非结构化文本记录最有用。一个好的方法将利用每个工具的优势。

随着索引的更新，Lucene将创建更多的段(其他文件或者BLOB)，这会降低性能，直到使用昂贵的"优化"过程为止。大多数数据库将在每次索引更新时分摊此费用，从而为我们提供更稳定的性能。

回答

LuSql http://code.google.com/p/lusql/允许我们将可访问JDBC的数据库的内容加载到Lucene中，从而使其可搜索。它是高度优化和多线程的。我是LuSql的作者，下个月将发布一个新版本(使用新的可插拔体系结构进行重新架构)。