NoSQL (MongoDB) vs Lucene (or Solr) as your database [closed]

With the NoSQL movement growing based on document-based databases, I’ve looked at MongoDB lately. I have noticed a striking similarity with how to treat items as “Documents”, just like Lucene does (and users of Solr).

So, the question: Why would you want to use NoSQL (MongoDB, Cassandra, CouchDB, etc) over Lucene (or Solr) as your “database”?

What I am (and I am sure others are) looking for in an answer is some deep-dive comparisons of them. Let’s skip over relational database discussions all together, as they serve a different purpose.

Lucene gives some serious advantages, such as powerful searching and weight systems. Not to mention facets in Solr (which Solr is being integrated into Lucene soon, yay!). You can use Lucene documents to store IDs, and access the documents as such just like MongoDB. Mix it with Solr, and you now get a WebService-based, load balanced solution.

You can even throw in a comparison of out-of-proc cache providers such as Velocity or MemCached when talking about similar data storing and scalability of MongoDB.

The restrictions around MongoDB reminds me of using MemCached, but I can use Microsoft’s Velocity and have more grouping and list collection power over MongoDB (I think). Can’t get any faster or scalable than caching data in memory. Even Lucene has a memory provider.

MongoDB (and others) do have some advantages, such as the ease of use of their API. New up a document, create an id, and store it. Done. Nice and easy.

10 Answers

Leave a Comment