所以，问题：为什么要使用Nosql(MongoDB，Cassandra，CouchDB等)在Lucene(或Solr)作为你的“数据库”？
我在(和我相信其他人)在寻找答案是一些深入潜水比较他们。让我们一起跳过关系数据库讨论，因为它们服务于不同的目的。
Lucene提供了一些严重的优势，如强大的搜索和体重系统。更不用说Solr中的方面(Solr正在被整合到Lucene，很快，yay！)。您可以使用Lucene文档来存储ID，并像MongoDB一样访问文档。将它与Solr混合，现在您可以获得基于WebService的负载平衡解决方案。
你甚至可以在谈论类似的数据存储和MongoDB的可伸缩性时，抛出一个外部的缓存提供程序比如Velocity或MemCached。
MongoDB的限制使我想起使用MemCached，但我可以使用Microsoft的Velocity和更多的分组和列表收集力量超过MongoDB(我认为)。不能比在内存中缓存数据更快或可伸缩。即使Lucene有一个内存提供程序。
MongoDB(和其他人)确实有一些优点，如易于使用他们的API。新建文档，创建ID并存储它。完成。尼斯和容易。
>你可以很容易地使用Lucene / Solr代替MongoDB几乎所有的情况，但不是反之亦然。格兰特Ingersoll的post sums it up here.
> MongoDB等似乎服务于没有搜索和/或刻面要求的目的。它似乎是一个更简单，可以说是更容易的过渡，程序员从RDBMS世界排毒。除非有人习惯了Lucene& Solr有一个更陡峭的学习曲线。
>没有很多使用Lucene / Solr作为数据存储的例子，但Guardian已经取得了一些进展，并在一个优秀的slide-deck总结，但他们也是不提交完全跳过Solr bandwagon和“调查”结合Solr与CouchDB。
>最后，我会提供我们的经验，不幸的是不能透露很多关于业务案例。我们致力于几TB数据的规模，近乎实时的应用。经过调查各种组合，决定坚持用Solr。没有遗憾到目前为止(6个月和计数)，没有理由改用其他。
摘要：如果你没有搜索要求，Mongo提供一个简单的&强大的方法。然而，如果搜索是你的产品的关键，你可能更喜欢坚持一个技术(Solr / Lucene)和优化它的外观 – 更少的移动部件。
我2美分，希望有帮助。