随着基于文档数据库的NoSQL运动的发展，我最近研究了MongoDB。我注意到在如何将项目视为“文档”方面有惊人的相似之处，就像Lucene(以及Solr的用户)所做的那样。
那么，问题来了:为什么你想要使用NoSQL (MongoDB, Cassandra, CouchDB等)而不是Lucene(或Solr)作为你的“数据库”?
我(我相信其他人也一样)想要的答案是对它们进行深入的比较。让我们一起跳过关系数据库的讨论，因为它们有不同的用途。
Lucene提供了一些重要的优势，比如强大的搜索和权重系统。更不用说Solr中的facet了(Solr很快就要被集成到Lucene中了!)你可以使用Lucene文档来存储id，并像MongoDB一样访问这些文档。将它与Solr混合使用，您现在就得到了一个基于webservice的负载均衡解决方案。
在讨论MongoDB类似的数据存储和可伸缩性时，您甚至可以将Velocity或MemCached等进程外缓存提供商进行比较。
MongoDB的限制让我想起了使用MemCached，但是我可以使用微软的Velocity，并且比MongoDB拥有更多的分组和列表收集能力(我认为)。没有比在内存中缓存数据更快或可伸缩的方法了。甚至Lucene也有内存提供商。
MongoDB(和其他)确实有一些优势，比如它们的API易于使用。新建一个文档，创建一个id，并存储它。完成了。很简单。
这是一个很好的问题，我已经思考了很久。我将总结我的经验教训:
You can easily use Lucene/Solr in lieu of MongoDB for pretty much all situations, but not vice versa. Grant Ingersoll's post sums it up here.
MongoDB etc. seem to serve a purpose where there is no requirement of searching and/or faceting. It appears to be a simpler and arguably easier transition for programmers detoxing from the RDBMS world. Unless one's used to it Lucene & Solr have a steeper learning curve.
There aren't many examples of using Lucene/Solr as a datastore, but Guardian has made some headway and summarize this in an excellent slide-deck, but they too are non-committal on totally jumping on Solr bandwagon and "investigating" combining Solr with CouchDB.
Finally, I will offer our experience, unfortunately cannot reveal much about the business-case. We work on the scale of several TB of data, a near real-time application. After investigating various combinations, decided to stick with Solr. No regrets thus far (6-months & counting) and see no reason to switch to some other.
总结:如果你没有搜索需求，Mongo提供了一个简单而强大的方法。然而，如果搜索是你的产品的关键，你最好坚持使用一种技术(Solr/Lucene)，并对其进行优化——减少移动部件。
我的两分钱，希望能有所帮助。
