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