由于没有人提到它，让我补充一下，MongoDB是无模式的，而Solr强制使用模式。因此，如果文档的字段可能会发生变化，这是选择MongoDB而不是Solr的一个原因。

由于没有人提到它，让我补充一下，MongoDB是无模式的，而Solr强制使用模式。因此，如果文档的字段可能会发生变化，这是选择MongoDB而不是Solr的一个原因。

这是一个很好的问题，我已经思考了很久。我将总结我的经验教训:

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

@mauricio-scheffer提到了Solr 4——对于那些对此感兴趣的人，LucidWorks将Solr 4描述为“NoSQL搜索服务器”，在http://www.lucidworks.com/webinar-solr-4-the-nosql-search-server/上有一个视频，他们详细介绍了NoSQL(有点)特性。(ish代表他们版本的无模式实际上是一种动态模式。)

我们同时使用MongoDB和Solr，它们的性能很好。你可以在这里找到我的博客文章，我描述了我们如何一起使用这些技术。以下是节选:

[...] However we observe that query performance of Solr decreases when index size increases. We realized that the best solution is to use both Solr and Mongo DB together. Then, we integrate Solr with MongoDB by storing contents into the MongoDB and creating index using Solr for full-text search. We only store the unique id for each document in Solr index and retrieve actual content from MongoDB after searching on Solr. Getting documents from MongoDB is faster than Solr because there is no analyzers, scoring etc. [...]