是否有一套从关系数据库构建 Lucene 索引的最佳实践？
我正在考虑使用 Lucene 和/或 Solr 在 RDBMS 支持的 Web 应用程序中提供搜索。 对我来说不幸的是，我浏览过的所有文档都涉及如何从索引中获取数据； 我更关心如何建立有用的索引。 是否有这样做的“最佳实践”？
I'm looking into using Lucene and/or Solr to provide search in an RDBMS-powered web application. Unfortunately for me, all the documentation I've skimmed deals with how to get the data out of the index; I'm more concerned with how to build a useful index. Are there any "best practices" for doing this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
多个应用程序会写入数据库吗？ 如果是这样，那就有点棘手了； 您必须有某种机制来识别要提供给 Lucene 索引器的新记录。
需要考虑的另一点是您想要一个覆盖所有表的索引，还是每个表一个索引。 一般来说，我推荐一个索引，该索引中有一个字段来指示记录来自哪个表。
Hibernate 支持全文搜索，如果你想搜索持久对象而不是非结构化文档。
您应该了解一个名为 Compass 的 OpenSymphony 项目。 我自己一直远离它，主要是因为它似乎比搜索需要的方式复杂。 另外，正如我从文档中可以看出的那样（我承认我没有时间阅读全部内容），它将 Lucene 段作为 blob 存储在数据库中。 如果您熟悉 Lucene 架构，Compass 在数据库之上实现了 Lucene Directory。 我认为这是错误的做法。 我将利用数据库内置的索引支持并实现 Lucene IndexReader。 同样的批评也适用于分布式缓存实现等。
Will multiple applications be writing to the database? If so, it's a bit tricky; you have to have some mechanism to identify new records to feed to the Lucene indexer.
Another point to consider is do you want one index that covers all of your tables, or one index per table. In general, I recommend one index, with a field in that index to indicate which table the record came from.
Hibernate has support for full text search, if you want to search persistent objects rather than unstructured documents.
There's an OpenSymphony project called Compass of which you should be aware. I have stayed away from it myself, primarily because it seems to be way more complicated than search needs to be. Also, as I can tell from the documentation (I confess I haven't found the time necessary to read it all), it stores Lucene segments as blobs in the database. If you're familiar with the Lucene architecture, Compass implements a Lucene Directory on top of the database. I think this is the wrong approach. I would leverage the database's built-in support for indexing and implement a Lucene IndexReader instead. The same criticism applies to distributed cache implementations, etc.
我根本没有探索过这个，但是看看 LuSql。
使用 Solr 也很简单，但是会存在一些DRY-违反Solr schema.xml 和您的实际数据库架构。 （仅供参考，Solr 确实支持通配符。）
I haven't explored this at all, but take a look at LuSql.
Using Solr would be straightforward as well but there'll be some DRY-violations with the Solr schema.xml and your actual database schema. (FYI, Solr does support wildcards, though.)
今晚我们将推出第一个使用 Solr 的应用程序。 在 Solr 1.3 中，他们包含了 DataImportHandler，允许您指定数据库表（他们称之为实体）及其关系。 定义后，一个简单的 HTTP 请求将触发数据导入。
有关详细信息，请查看 DataImportHandler 的 Solr wiki 页面。
We are rolling out our first application that uses Solr tonight. With Solr 1.3, they've included the DataImportHandler that allows you to specify your database tables (they call them entities) along with their relationships. Once defined, a simple HTTP request will tirgger an import of your data.
Take a look at the Solr wiki page for DataImportHandler for details.
作为介绍：
Brian McCallister 写了一篇不错的博客文章：将 Lucene 与 OJB 结合使用< /strong>。
As introduction:
Brian McCallister wrote a nice blog post: Using Lucene with OJB.