目前MongoDB的全文搜索与Lucene相比如何？问题的原因是由于我的不确定性：
a）在生产中使用mongo的FTS实现，因为它在6个月前仍处于测试阶段
和
b）因为lucene使用Java，这将引入另一个移动部分。
答案 0 :(得分：38)
如果没有徘徊在一个可能不适合编程论坛的长篇主题中，我会尝试基本覆盖这一点，但仍尝试覆盖这些要点。
进行广泛比较时要考虑的主要问题是：＆＃34;＆＃39; XYZ＆＃39;关系数据库引擎全文搜索堆栈反对Lucene＆＃34; 。
因此，如果您考虑到这一点，并且已经拥有内置的全文＆＃34;全文＆＃34;那些产品的功能那些是你应该与MongoDB进行比较的苹果＆＃34;全文＆＃34;苹果。
简而言之，MongoDB提供基本的全文功能，与关系产品中的功能差别不大。正如 a：）中提到的那样，设施是新的，但比以前更好，没什么。
在 b：）上，Lucene和衍生品/对应物（Solr / ElasticSearch等）应该被视为完全不同的动物。 需要高级标记化和词干化的内容，＆＃34;内置的设施＆＃34; 和 facet计数搜索。在这些情况下，单独的产品是必需的。
当然，有几种解决方案可以用来索引Lucene等MongoDB商店的数据，甚至自定义这个过程并不难。但它正在维持你的基础设施中另一个活跃的部分。
所以我并不认为这需要比较 MongoDB文本搜索与Lucene，因为最终他们存在做不同的事情，它＆＃39 ;只是您需要的问题。选择最适合您的解决方案。
唯一要补充的是，Lucene（和衍生品）系列是很棒的产品。不要回避他们，至少要评估。之前的观点是，除了标准数据库文本搜索＆＃34;之外，还有更多的功能。此外，管理和学习曲线通常不会像你想象的那么难以及＃34;。有戏，可能值得实施。
答案 1 :(得分：15)
简而言之：是的，Lucene（Solr / ElasticSearch）是另一个活跃的部分。你必须知道，我讨厌在我的系统中添加移动部件。我做任何事来避免它。但是，如果你想在你的应用程序中支持一个超越简单（简单！）全文搜索的搜索，那么你需要Lucene 。我向你保证，当你习惯了它时，你永远不会（永远！）再次错过它。
所以简单的建议是：试一试！你不会后悔的。