随着基于文档数据库的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)，并对其进行优化——减少移动部件。
我的两分钱，希望能有所帮助。
这是一个很好的问题，我已经思考了很久。我将总结我的经验教训:
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)，并对其进行优化——减少移动部件。
我的两分钱，希望能有所帮助。
第三方解决方案，比如mongo op-log尾巴是有吸引力的。假设从开发/体系结构的角度来看，仍然存在一些关于解决方案是否可以紧密集成的想法或问题。我不希望看到这些功能的紧密集成解决方案，原因有几个(有些推测和有待澄清，并且没有跟上开发进度):
mongo is c++, lucene/solr are java
maybe lucene could use some mongo libs
maybe mongo could rewrite some lucene algorithms, see also:
http://clucene.sourceforge.net/
http://lucy.apache.org/
lucene supports various doc formats
mongo is focused on JSON (BSON)
lucene uses immutable documents
single field updates are an issue, if they are available
lucene indexes are immutable with complex merge ops
mongo queries are javascript
mongo has no text analyzers / tokenizers (AFAIK)
mongo doc sizes are limited, that might go against the grain for lucene
mongo aggregation ops may have no place in lucene
lucene has options to store fields across docs, but that's not the same thing
solr somehow provides aggregation/stats and SQL/graph queries
