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: https://cwiki.apache.org/confluence/display/solr/Collections+API >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 issue? 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. ----- Thanks, Michael -- View this message in context: http://lucene.472066.n3.nabble.com/solr-as-a-service-for-multiple-projects-in-the-same-environment-tp4103523p4103537.html Sent from the Solr - User mailing list archive at Nabble.com.
