Andy, You asked about other full text indexes for Ruby/Rails. I am using both AAF/Ferret and Sphinx in my app.
I haven't had any problems with Ferret or acts_as_ferret so far. I am using the DRb server and it is being hit with 200-250,000 requests a day from dozens of clients (Mongrel instances). My index isn't huge - it is about 600 MB. I'm using Sphinx (http://www.sphinxsearch.com/) wherever I don't need realtime updates. A large portion of my site requires search indexes to be always up-to-date but in many places, I can live with an index that may be 5 minutes old. Sphinx trades realtime indexing for performance - both search and indexing speed is blazingly fast. Sphinx comes with a server component that speaks a simple protocol and there are several rails plugins available. Sphinx (and acts_as_sphinx or whatever plugin you choose) and acts_as_ferret are very different animals, but I'm very pleased with the combination. Casey On Sun, 18 Nov 2007, Andreas Korth wrote: > Hi everyone! > > This is a very interesting thread, because it raises the question as > to whether Ferret is something you would want to use in a production > environment - or not. > > I've been using Ferret in two applications and my experiences were > quite disappointing. I chose Ferret because it's fast and it's got a > Ruby API. Everything else about it is just annoying and potentially > hazardous. > > What worries me most is the fact that Ferret is effectively an > abandoned project. The original author, who is the sole owner of the > code, hasn't been posting to this list for about six months. He hasn't > introduced any improvements in about the same period of time and many > bugs still remain unfixed. New bugs can't be submitted (let alone > patches) because the project Trac is offline. > > There is no other component in my applications which behaves as badly > as Ferret. If you don't treat it _very_ carefully it will throw > segfaults as if this was an established way of indicating an error > condition. > > The ActsAsFerret plugin _does_ treat ferret quite carefully and it's > the only reason why many people are able to use Ferret at all. > However, AAF is one approach and for some applications it might not be > the right one. Especially if you want to put multiple models in one > index - it's possible, but not really a flexible solution. > > The most sensitive point of Ferret is concurrency and many people > actually use Ferret in distributed environments (which is usually a > Rails app that scales across several machines). AAF introduces a DRb > server to work around this problem, but with many concurrent read/ > write requests, performance quickly degrades. > > With the advent of JRuby, a myriad of Java-based solutions is now > accessible to Ruby developers, including many full-text indices. There > are very mature solutions readily available for production use and > many next-generation search engines currently in development. > > For the next application that needs full text search, I'm most > definitely not going to use Ferret. I agree with Erik and give Solr a > shot. > > I would like to encourage everyone, who is already using another full > text index for Ruby/Rails to share his/her experiences on this list. > Because I have the feeling that many people would like to get rid of > Ferret for exactly the same reasons I've pointed out above. > > Andy > > > On 16.11.2007, at 22:13, Erik Hatcher wrote: > >> >> On Nov 16, 2007, at 3:35 PM, Scott Davies wrote: >>> Am I a fool for wondering whether it might ultimately be less painful >>> to try an index server that runs Lucene under a JRuby process? >> >> Or, rather, an index server that runs Solr accessed with a pure Ruby, >> solr-ruby, API (which works with MRI or JRuby)? :) >> >> Erik >> >> _______________________________________________ >> Ferret-talk mailing list >> [email protected] >> http://rubyforge.org/mailman/listinfo/ferret-talk > > _______________________________________________ > Ferret-talk mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/ferret-talk > _______________________________________________ Ferret-talk mailing list [email protected] http://rubyforge.org/mailman/listinfo/ferret-talk
