B,
My thoughts are coming from experience while writing and using stitches.  
Stitches is a java-based project that allows local and remote java clients 
(using hessian for java, xfire for dotnet) to search, store and retrieve images 
and image meta data.  We are using it to store 10 Gb's of images and the search 
is wicked fast.  We use it to allow users to associate images to galleries, 
events, etc..  It's using compass/lucene right now.  The API is a lot like 
amazon S3, but this is just a coincidence of solving the same problem.  We are 
using it in dotnet and java.

I was thinking that one of the benefits of solr is that of replication.  
Currently, there is only one production instance of stitches, and we are using 
it to power image serving, image thumbnails for 5 major sites.   If stitches 
goes down, these sites would not have images, and I would be in trouble.

By using solr, I was hoping I could get more scalability by leveraging the 
rsync/replication so my search index and it's data (image binary files) would 
be clustered across multiple machines. 

Thanks!


-----Original Message-----
From: Norberto Meijome <[EMAIL PROTECTED]>
Sent: Thursday, May 8, 2008 3:37am
To: solr-user@lucene.apache.org
Subject: Re: using solr as master for data storage/retrieval?

On Wed, 7 May 2008 11:26:50 -0400 (EDT)
"Phillip Rhodes" <[EMAIL PROTECTED]> wrote:

> I currently have a java-based application that stores all objects on the file 
> system (text, blobs) and uses lucene to search the objects.  If I can store 
> these objects in solr, I would greatly increase the scalability of my 
> application.

Hi Phillip,
I'm interested in why you think that SOLR would be more scalable than FS for 
retrieving files.I am not saying it isn't. For my use cases, it wouldn't be, 
but your case may be different.

Do you have any numbers / theories that make you think that would be the case? 

How big are the files you intend to store? What file types? how many queries / 
sec do you expect to serve?

cheers,
B
_________________________
{Beto|Norberto|Numard} Meijome

Intelligence: Finding an error in a Knuth text.
Stupidity: Cashing that $2.56 check you got.

I speak for myself, not my employer. Contents may be hot. Slippery when wet. 
Reading disclaimers makes you go blind. Writing them is worse. You have been 
Warned.


Reply via email to