SOLR search adoption - the power of sane defaults?
March 27, 2008
Tonight I met someone from a (largish) local company and learned they’re migrating their search functionality to SOLR. This is the second largish company in the area I know that’s migrating to SOLR. I’m not naming names only because I’m not sure they’d want me to do so. Suffice it to say these are names fairly well known in the marketing and communications industries.
I’m not surprised at all by the adoption, as SOLR makes it pretty easy to get started using the power of Lucene without requiring you to do a lot of setup or administration up front. These ’sane defaults’, as I believe Erik Hatcher put it to me, are what give projects like SOLR a competitive advantage against even commercial offerings. Whether technology is good or bad is often secondary to whether it’s easy to get it to a testing stage.
If you’re using SOLR, what was the deciding factor? Ease of setup? Flexibility? Compatibility with existing Lucene data?
If you’re not using SOLR for your data search needs, what are you using? Raw Lucene? Xapian? Sphinx? A commercial product? If so, which one?
P.S If you’re not sure how to go about implementing search for your site and have some questions, email me - mgkimsal@gmail.com.
Did you like this post? Buy me a hot chocolate!
Posted in Development, SOLR, Search, Software, Web, opensource
March 31st, 2008 at 5:29 am
We’ve recently implemented a Solr based solution at IPC (the UK’s largest magazine publisher). We were originally using a Nutch based tool developed in house, but had quite a few problems with it. Decided on Solr for a number of reasons.
- It’s easy to get up and running very quickly.
- It’s incredibly configurable, if you’re willing to spend the time.
- It has lots of features and a simple plugin architecture.
- Vibrant community and good documentation.
- It’s very easy to scale (wit the replication tools).
For larger projects I don’t think anything else really comes close. Some of the other major tools such as Xapian and Sphinx perform well in some areas and have some nice features but when you look at the whole package Solr wins hands down. I would only choose not to go with Solr when resources are tight and load is going to be relatively low. In this case I would probably go with Xapian as it’s very easy to get a search engine up and running very quickly. Xapian is, in fact, what I use for my blog (http://www.roryoung.co.uk).
If you want an easy way to implement search without having to make a descision about the backend early then look into Forage (http://code.google.com/p/forage). One method I find quite useful is to prototype the application with a simple to install backend like Zend Search Lucene so that you can start coding while the sysadmins are setting up Solr and then just switch the backend when your Solr server’s up. This is turning into a post all in itself but I this is the last point, honestly. I’m giving a talk at PHPLondon this Thursday about what your should be looking for when evaluating a search tool. I’ll stick the slides up afterwards.
March 31st, 2008 at 8:42 pm
Hey Rob!
Thanks for the great post! It seems to back up my original gut - SOLR is a good combination of power and simplicity that we don’t (yet) see in the other options. I bet we’ll see more competition in this space in the next year or so, but SOLR doesn’t seem to have been a bad choice for many people so far.
Best of luck at your London talk. Wish I was able to be there!
April 28th, 2008 at 9:59 am
Hi Michael,
Very nice piece on SOLR. With SOLR 1.3 (in development), the feature set would expand even further with Distributed Search for large data-sets and the DataImportHandler for indexing databases and other data sources (http://wiki.apache.org/solr/DataImportHandler)