views:

936

answers:

6

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 replacing Relational Database + Lucene with MongoDb?

edit: Ok, I will clarify: I'm not asking about risk, I can pay that price in this project. My point is: Is MongoDB oriented to this kind of thing? Can I make a full search engine with the same perfomance as I can get on Lucene?. A friend point me out MongoDB as alternative, but I don't see if the Lucene performance comes with the document alternative (and then, I will see it in MongoDB too), or, in other hand, the inverted index and optimitizations are complety independant of document orientation.

+1  A: 

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.

Kris
Sure Kris, I noticed that, by in this particular case, I can pay that price.Thanks.
Hugo
If the toy gets discontinued, he can always move the data to a RDBMS:)
never_had_a_name
A: 

No, it isn't, since MongoDB is not relational.

Blekk
A: 

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.

APC
+2  A: 

Look's posible but slower (see here)

  • You will have to do word splitting and stemming your self.
  • Ranking of queries 'requires user supplied code to do so'
Echo
+5  A: 

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.

Michael
A: 

CouchDb seems to be a(n other) possible alternative to use Lucene via couchdb-lucene project.

Aito