Comments on: The Seven Deadly Sins of Solr

By: On Solr « sowmyawrites ….

On Solr « sowmyawrites …. — Wed, 31 Aug 2011 13:09:21 +0000

[...] “Seven Deadly Sins of Solr” on LucidImagination pages, was another one, which helped me a lot during the initial days. [...]

By: Fuad Efendi

Fuad Efendi — Tue, 28 Dec 2010 17:22:08 +0000

This article is funny… and the best.

By: Fuad Efendi

Fuad Efendi — Tue, 28 Dec 2010 17:14:34 +0000

And another comment: “A good starting place is a blog by my colleague Mark Miller of Lucid Imagination. Another good resource is this document put out by Sun.”

I don’t think references to SUN are bullet proof, and (sorry Mark!)…
Consider URL class… synchronized HashTable behind the scenes… many multithreaded content retrieval frameworks depend on it, but only Tomcat (by IBM b.t.w.) rewrote this class.

Lucid, can you not to refer “best industry practices”?

By: Fuad Efendi

Fuad Efendi — Tue, 28 Dec 2010 17:08:32 +0000

Oh no…

I especially applaud to this sentense: “Too much attention on the JVM and garbage collection”
- this is exactly what I was constantly posting in SOLR lists!

By: Fuad Efendi

Fuad Efendi — Tue, 28 Dec 2010 17:05:34 +0000

Looks funny… but I don’t have time to read it… especially under SOLR subject.

By: Jay Hill

Jay Hill — Mon, 13 Dec 2010 19:50:25 +0000

That approach makes sense to me. Ideally you should have a master/slave(s) architecture so constant re-indexing on the master can go on without having any impact on your end users searches. If you’ve separated the indexing and searching processes there shouldn’t be any other downsides. Regular re-indexing is a fairly common use case at many sites.

By: Randy Harmon

Randy Harmon — Fri, 10 Dec 2010 20:14:00 +0000

Sweet article – it was just the kind of thing we were looking for when it comes to understanding the high-level overall impact of a proposed Solr deployment.

We’re looking to solve the re-indexing problem and hoped you’d give any quick feedback on our thinking. In our environment, it’s a user’s own personal data that’s going to be searched. We can keep the index normally up-to-date with application hooks (we’re using Sunspot in Rails) – but because things can happen that cause the index to go out of sync with reality, we’re considering re-indexing each user’s search on a rotating basis. With this method, we would spread the re-indexing load out across 2 weeks or a month, doing a certain number of users each night.

Would you expect that this approach will cause undesired performance impact? Any other downsides such as index fragmentation or cumulative effects over time? or ??

Any thoughts appreciated.

By: Solr – Great Article on Solr Guidelines for any Web Presence | Me Like Dev

Thu, 08 Jul 2010 16:23:49 +0000

[...] A friend linked me the following article; http://www.lucidimagination.com/blog/2010/01/21/the-seven-deadly-sins-of-solr/. [...]

By: Blogs From The Geeks » Blog Archive » Solr – incremental commit strategies and configuration - Intermittent insightful nuggets

Wed, 07 Jul 2010 12:23:24 +0000

[...] “Googling” the answers to our problems I came across Jay Hill’s post which details some of the most common pitfalls around using Solr. Some of these stem from using the [...]

By: hossman

hossman — Wed, 19 May 2010 18:29:53 +0000

FYI: This article has been translated to spanish…

http://www.linebee.com/?p=434&lang=es