lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From adfel70 <>
Subject Re: solr as a service for multiple projects in the same environment
Date Sun, 01 Dec 2013 07:41:00 GMT
The risk is if you buy mistake mess up a cluster while doing maintenance on
one of the systems, you can affect the other system.
Its a pretty amorfic risk.
Aside from having multiple systems share the same hardware resources, I
don't see any other real risk.

Are your collections share the same topology in terms of shards and
Do you manually configure the nodes on which each collection is created so
that you'll still have some level of seperation between the systems?

michael.boom wrote
> Hi,
> There's nothing unusual in what you are trying to do, this scenario is
> very common.
> To answer your questions:
>> 1. as I understand I can separate the configs of each collection in
>> zookeeper. is it correct? 
> Yes, that's correct. You'll have to upload your configs to ZK and use the
> CollectionAPI to create your collections.
>>2.are there any solr operations that can be performed on collection A and
somehow affect collection B? 
> No, I can't think of any cross-collection operation. Here you can find a
> list of collection related operations:
>>3. is the solr cache separated for each collection? 
> Yes, separate and configurable in solrconfig.xml for each collection.
>>4. I assume that I'll encounter a problem with the os cache, when the
different indices will compete on the same memory, right? how severe is this
> Hardware can be a bottleneck. If all your collection will face the same
> load you should try to give solr a RAM amount equal to the index size (all
> indexes)
>>5. any other advice on building such an architecture? does the maintenance
overhead of maintaining multiple clusters in production really overwhelm the
problems and risks of using the same cluster for multiple systems? 
> I was in the same situation as you, and putting everything in multiple
> collections in just one cluster made sense for me : it's easier to manage
> and has no obvious downside. As for "risks of using the same cluster for
> multiple systems" they are pretty much the same  in both scenarios. Only
> that with multiple clusters you'll have much more machines to manage.

View this message in context:
Sent from the Solr - User mailing list archive at

View raw message