On Nov 17, 2007, at 7:39 AM, Jens Kraemer wrote:
>> I think Ferret is adequate for most search tasks, but if (like me)
>> you're building a dedicated search engine, Solr is currently a
>> stronger candidate.
>
> Well, As Solr uses Lucene internally, the mechanics and performance
> characteristics naturally can't be that different from Ferret. Maybe
> Ferret has a bug or two and a non-working inter-process locking (which
> doesn't matter when you think about building a dedicated search server
> like Solr is, since it's only one process), but the general internal
> handling of the index is the same, i.e. you can also only have one
> Writer open to a Lucene index at a time, and Searchers won't see index
> changes until re-opened, too.
That's all true. However, Solr manages all the IndexWriter/
IndexSearcher stuff for you quite transparently (which I guess is
comparable to Ferret + DRb, eh?). Because it is a single point of
access to the index, it takes care of the single writer situation,
and also handles warming IndexSearchers before coming online so that
caches are built and a search on an updated index is as fast as it
was before being updated.
> Having that said, if my application's main concern would be search, I
> most probably wouldn't choose any pre-cooked solution like aaf or
> Solr,
> but build exactly the thing I need from scratch, basing it either on
> Lucene or Ferret. But maybe that's just me ;-)
You'd be reinventing a lot of wheels doing that, with IndexWriter
synchronization, IndexSearcher warming, caching, and much more.
Erik
_______________________________________________
Ferret-talk mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ferret-talk
