On a new project I need a hard use of lucene for a searcher implementation. This searcher will be a very important (and big) piece of the project. Is valid or convenient replaci
After attending Devoxx 2011 and attending a presentation from 10Gen, I have written a little blog comparing MongoDB to RDBMS databases. MongoDB is one of the popular Nosql dbs.As stated in the replies before MongoDB is a NoSQL db, which is different to the exising mainstream rdbms databases.
http://blog.iprofs.nl/2011/11/25/is-mongodb-a-good-alternative-to-rdbms-databases-like-oracle-and-mysql
MongoDb is an NOSQl, Lucene and SOLR are search engines, and adding another thing to the comparison is caches like Terracota along with EhCache. All have thier own purpose.
If searching along with full text search is required with stemming, relevancy settings like showing results with text matching in product title ranking more than text matching in desctription, and many such text based features. Also ranking, relevancy, sound alike macthing, partial word matching etc etc . All this things are best handled by search based storage systems like SOLR and Lucene.
If your criteria is fater retrieval only and you dont need your presentation data objects to be durable then simply use a cache lke Terracota.
If you need faster retrieval and also need to colloborate and aggregate data in one datasource and also need that aggregated data to be durable then use NOSQL like Mongodb.
Technically you can do full text search with MongoDB, but you're missing out on a lot that a full text search provider has to offer. I love MongoDB, but I'd couple it with a full text search provider (such as Lucene or Sphinx) if time to implementation is at all a concern. I think MongoDB's convenient ability to index word arrays is better left to tagging and searching based on tagging than full text search.
Search (Information Retrieval) isn't just about grabbing any documents that match, if you want your search results to have any relevance at all you're going to need something along the lines of TF-IDF, phrase matching (words in a sequence score higher) or any number of other IR techniques to improve search precision. If you use MongoDB you'll need to implement it all from scratch.
If you really want to implement it all from scratch but not bother with the raw storage side of things, MongoDB is pretty close to the best DB store that you could implement it on top of (can't think of many others), but that still doesn't make it a great option.
No, it isn't, since MongoDB is not relational.
I'm not familiar with MongoDB so I can't directly answer the question but I would like to note that unlike Lucene (which is about ten years old) and relational databases (which have been around for decades) MongoDB is less than three years old.
At this stage of the game it is likely still maturing. It may be suitable to your needs (and I'm curious to see if anyone familiar with using it will chime in here) but you'll need to factor this into your equation. Are you willing to pay the price to use cutting edge technology?
Even if it winds up being stable and efficient enough, you may run into issues with limited support in the form of websites/tutorials etc. (due to the small user base). You are also taking the chance that it will be discontinued.
It can be worthwhile to take this chance, but you need to do so with your eyes open and not blinded by the "oh, look at the shiny new toy" effect.
Lucene is an established and stable product. Alas the same is not yet true of MongoDB. So I would think that Lucene plus an RDBMS is a much less risky option.
Of course, to a certain extent it depends on the nature of the project: just how important is "very important (and big)"? The other thing is, do you have prior experience of MongoDB (I'm guessing not)? If you can get access to people who have some expertise then that would mitigate the risk.