随着基于基于文档的数据库的 NoSQL 运动不断发展，我最近研究了 MongoDB。我注意到与如何将项目视为“文档”有惊人的相似之处，就像 Lucene（和 Solr 的用户）所做的那样。
那么问题来了： 为什么要使用 NoSQL（MongoDB、Cassandra、CouchDB 等）而不是 Lucene（或 Solr）作为“数据库”？
我（我相信其他人）在答案中寻找的是对它们的一些深入比较。让我们一起跳过关系数据库讨论，因为它们有不同的目的。
Lucene 提供了一些重要的优势，例如强大的搜索和权重系统。更不用说 Solr 中的方面（Solr 很快就会集成到 Lucene 中，耶！）。您可以使用 Lucene 文档来存储 ID，并像 MongoDB 一样访问文档。将它与 Solr 混合，您现在可以获得基于 WebService 的负载平衡解决方案。
在谈论 MongoDB 的类似数据存储和可扩展性时，您甚至可以比较 Velocity 或 MemCached 等进程外缓存提供程序。
MongoDB 周围的限制让我想起了使用 MemCached，但我可以使用 Microsoft 的 Velocity，并且比 MongoDB 拥有更多的分组和列表收集能力（我认为）。无法比在内存中缓存数据更快或可扩展。甚至 Lucene 也有内存提供程序。
MongoDB（和其他）确实有一些优势，比如 API 易于使用。新建一个文档，创建一个 id 并存储它。完毕。好，易于。
这是一个很好的问题，我已经思考了很多。我将总结我的经验教训：
在几乎所有情况下，您都可以轻松地使用 Lucene/Solr 代替 MongoDB，但反之则不然。Grant Ingersoll 的帖子在这里进行了总结。
MongoDB 等似乎服务于不需要搜索和/或分面的目的。对于摆脱 RDBMS 世界的程序员来说，这似乎是一个更简单且可以说更容易的过渡。除非人们习惯了 Lucene 和 Solr 的学习曲线更陡峭。
使用 Lucene/Solr 作为数据存储的例子并不多，但 Guardian 已经取得了一些进展，并在一个优秀的幻灯片中总结了这一点，但他们也没有完全加入 Solr 的潮流并“调查”结合 Solr与 CouchDB。
最后，我将提供我们的经验，遗憾的是不能透露太多关于商业案例的信息。我们在几 TB 的数据规模上工作，这是一个近乎实时的应用程序。在研究了各种组合之后，决定坚持使用 Solr。到目前为止没有遗憾（6 个月和计数），并且没有理由切换到其他人。
摘要：如果您没有搜索要求，Mongo 提供了一种简单而强大的方法。但是，如果搜索是您产品的关键，那么您最好坚持使用一种技术（Solr/Lucene）并优化它——减少活动部件。
我的 2 美分，希望对您有所帮助。
