在一个新项目中，我需要努力使用lucene来实现搜索器。这个搜索者将是该项目的一个非常重要（和大）的部分。使用MongoDb替换Relational Database + Lucene是否有效或方便？
编辑：好的，我会澄清：我不是在询问风险，我可以在这个项目中支付这个价格。我的观点是：MongoDB是否面向这种事情？我可以制作一个完整的搜索引擎，具有与Lucene相同的性能吗？一位朋友指出MongoDB是另一种选择，但我不知道Lucene性能是否带有文档备选（然后，我也会在MongoDB中看到它），或者，另一方面，反向索引和优化是完全的独立于文档方向。
答案 0 :(得分：19)
从技术上讲，您可以使用MongoDB进行全文搜索，但是您错过了全文搜索提供商必须提供的功能。我喜欢MongoDB，但如果时间紧迫，我会将它与全文搜索提供商（如Lucene或Sphinx）结合起来。我认为MongoDB索引字数组的便捷能力最好留给标记而不是全文搜索进行标记和搜索。
搜索（信息检索）不只是抓取任何匹配的文档，如果您希望搜索结果具有任何相关性，那么您将需要TF-IDF，短语匹配（单词）在序列得分更高）或任何数量的其他IR技术，以提高搜索精度。如果你使用MongoDB，你需要从头开始实现它。
如果你真的想从头开始实现它，而不是原始存储方面的麻烦，MongoDB非常接近你可以在其上实现它的最好的数据库存储（不能想到很多其他的） ，但这仍然不是一个很好的选择。
答案 1 :(得分：3)
CouchDb似乎是（另一种）可能alternative使用Lucene via couchdb-lucene项目。
答案 2 :(得分：2)
看起来可能但速度较慢（see here）
答案 3 :(得分：2)
MongoDb是一个NOSQl，Lucene和SOLR是搜索引擎，并且在比较中添加另一个东西是像Terracota和EhCache这样的缓存。所有人都有自己的目的。
如果需要使用全文搜索进行搜索，则需要使用相关性设置，例如在产品标题排名中显示文本匹配的结果，而不是在desctription中显示文本匹配，以及许多此类基于文本的功能。还有排名，相关性，声音相似的macthing，部分单词匹配等。所有这些都最好由SOLR和Lucene等基于搜索的存储系统来处理。
如果您的标准仅适用于检索并且您不需要您的演示数据对象持久，那么只需使用缓存lke Terracota。
如果您需要更快的检索并且还需要在一个数据源中进行协作和聚合数据，并且还需要聚合数据持久，那么请使用像Mongodb这样的NOSQL。
答案 4 :(得分：1)
我不熟悉MongoDB所以我不能直接回答这个问题，但是我想要注意的是，与Lucene（大约十年前）和关系数据库（已经存在了几十年）不同，MongoDB不那么容易超过三岁。
在游戏的这个阶段，它可能仍在成熟。它可能适合您的需求（我很想知道是否有人熟悉使用它会在这里发出声响），但您需要将其纳入您的等式中。您是否愿意为使用尖端技术付出代价？
即使它足够稳定和高效，您也可能会遇到网站/教程等形式的有限支持问题（由于用户群较小）。你也有机会停止它。
抓住这个机会是值得的，但你需要睁着眼睛这样做，不要被“哦，看看闪亮的新玩具”效果所蒙蔽。
答案 5 :(得分：1)
另一种选择是使用elasticsearch（在lucene中支持）width couchdb：http://www.elasticsearch.org/blog/2010/09/28/the_river_searchable_couchdb.html
答案 6 :(得分：0)
Lucene是一个成熟稳定的产品。对于MongoDB来说，情况并非如此。所以我认为Lucene加上RDBMS的风险要低得多。
当然，在某种程度上，这取决于项目的性质：“非常重要（和大）”有多重要？另一件事是，你有MongoDB的经验（我猜不是）？如果您可以访问具有某些专业知识的人员，那么可以降低风险。
答案 7 :(得分：-1)
参加Devoxx 2011并参加10Gen的演讲后，我写了一篇比较MongoDB和RDBMS数据库的博客。 MongoDB是流行的Nosql dbs之一。如MongoDB之前的回复中所述的NoSQL数据库，与现有的主流rdbms数据库不同。
答案 8 :(得分：-1)
对于全文搜索解决方案，我使用过Lucene＆amp; Sphinx较早，但它们对于提供的关键字获取最佳结果并不好。所以我使用了mongodb全文搜索插件MongoLantern，它非常擅长。此外，在性能方面，它使用MongoDB作为后端引擎，因此根本没有性能问题。在MongoLantern的生产可用性方面等待更多评论。
答案 9 :(得分：-7)
不，不是，因为MongoDB不是关系型的。