<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: SOLR search adoption &#8211; the power of sane defaults?</title>
	<atom:link href="http://michaelkimsal.com/blog/solr-adoption-power-of-sane-defaults/feed/" rel="self" type="application/rss+xml" />
	<link>http://michaelkimsal.com/blog/solr-adoption-power-of-sane-defaults/</link>
	<description>Web development and new media observations</description>
	<lastBuildDate>Sat, 13 Apr 2013 00:29:46 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>By: Markus</title>
		<link>http://michaelkimsal.com/blog/solr-adoption-power-of-sane-defaults/comment-page-1/#comment-56343</link>
		<dc:creator>Markus</dc:creator>
		<pubDate>Sun, 11 Jan 2009 05:04:27 +0000</pubDate>
		<guid isPermaLink="false">http://michaelkimsal.com/blog/?p=490#comment-56343</guid>
		<description><![CDATA[We originally had Zend_Search_Lucene (our company is mostly PHP backed) but ran into performance issues pretty quick because we needed a better-than-default highlighting without going to the database so we put our complete text into the index which was too much for ZSL.

Naturally we moved to Lucene until we learned and a local open source summit about Solr and there, there was the move. Found a few bugs as usual, wrote a few plugins and we&#039;re very very happy with it. Btw, we&#039;re not large scale, really. But even for small 10.000 Doc index it just a time saver, even over pure Lucene.]]></description>
		<content:encoded><![CDATA[<p>We originally had Zend_Search_Lucene (our company is mostly PHP backed) but ran into performance issues pretty quick because we needed a better-than-default highlighting without going to the database so we put our complete text into the index which was too much for ZSL.</p>
<p>Naturally we moved to Lucene until we learned and a local open source summit about Solr and there, there was the move. Found a few bugs as usual, wrote a few plugins and we&#8217;re very very happy with it. Btw, we&#8217;re not large scale, really. But even for small 10.000 Doc index it just a time saver, even over pure Lucene.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Shalin Shekhar Mangar</title>
		<link>http://michaelkimsal.com/blog/solr-adoption-power-of-sane-defaults/comment-page-1/#comment-33953</link>
		<dc:creator>Shalin Shekhar Mangar</dc:creator>
		<pubDate>Mon, 28 Apr 2008 15:59:25 +0000</pubDate>
		<guid isPermaLink="false">http://michaelkimsal.com/blog/?p=490#comment-33953</guid>
		<description><![CDATA[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)]]></description>
		<content:encoded><![CDATA[<p>Hi Michael,</p>
<p>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 (<a href="http://wiki.apache.org/solr/DataImportHandler" rel="nofollow">http://wiki.apache.org/solr/DataImportHandler</a>)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mgkimsal</title>
		<link>http://michaelkimsal.com/blog/solr-adoption-power-of-sane-defaults/comment-page-1/#comment-32583</link>
		<dc:creator>mgkimsal</dc:creator>
		<pubDate>Tue, 01 Apr 2008 02:42:34 +0000</pubDate>
		<guid isPermaLink="false">http://michaelkimsal.com/blog/?p=490#comment-32583</guid>
		<description><![CDATA[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&#039;t (yet) see in the other options.  I bet we&#039;ll see more competition in this space in the next year or so, but SOLR doesn&#039;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!]]></description>
		<content:encoded><![CDATA[<p>Hey Rob!</p>
<p>Thanks for the great post!  It seems to back up my original gut &#8211; SOLR is a good combination of power and simplicity that we don&#8217;t (yet) see in the other options.  I bet we&#8217;ll see more competition in this space in the next year or so, but SOLR doesn&#8217;t seem to have been a bad choice for many people so far.</p>
<p>Best of luck at your London talk.  Wish I was able to be there!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rob Young</title>
		<link>http://michaelkimsal.com/blog/solr-adoption-power-of-sane-defaults/comment-page-1/#comment-32560</link>
		<dc:creator>Rob Young</dc:creator>
		<pubDate>Mon, 31 Mar 2008 11:29:30 +0000</pubDate>
		<guid isPermaLink="false">http://michaelkimsal.com/blog/?p=490#comment-32560</guid>
		<description><![CDATA[We&#039;ve recently implemented a Solr based solution at IPC (the UK&#039;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&#039;s easy to get up and running very quickly.
- It&#039;s incredibly configurable, if you&#039;re willing to spend the time.
- It has lots of features and a simple plugin architecture.
- Vibrant community and good documentation.
- It&#039;s very easy to scale (wit the replication tools).

For larger projects I don&#039;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&#039;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&#039;s up. This is turning into a post all in itself but I this is the last point, honestly. I&#039;m giving a talk at PHPLondon this Thursday about what your should be looking for when evaluating a search tool. I&#039;ll stick the slides up afterwards.]]></description>
		<content:encoded><![CDATA[<p>We&#8217;ve recently implemented a Solr based solution at IPC (the UK&#8217;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. </p>
<p>- It&#8217;s easy to get up and running very quickly.<br />
- It&#8217;s incredibly configurable, if you&#8217;re willing to spend the time.<br />
- It has lots of features and a simple plugin architecture.<br />
- Vibrant community and good documentation.<br />
- It&#8217;s very easy to scale (wit the replication tools).</p>
<p>For larger projects I don&#8217;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&#8217;s very easy to get a search engine up and running very quickly. Xapian is, in fact, what I use for my blog (<a href="http://www.roryoung.co.uk" rel="nofollow">http://www.roryoung.co.uk</a>).  </p>
<p>If you want an easy way to implement search without having to make a descision about the backend early then look into Forage (<a href="http://code.google.com/p/forage" rel="nofollow">http://code.google.com/p/forage</a>). 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&#8217;s up. This is turning into a post all in itself but I this is the last point, honestly. I&#8217;m giving a talk at PHPLondon this Thursday about what your should be looking for when evaluating a search tool. I&#8217;ll stick the slides up afterwards.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
