Here is one potential design approach: 1. Create a single collection (instead of two collections). Let your schema have a "RecordType" field which can take the values of either "initial" or "follow-up" for documents that are indexed into this collection.
2. Let there be 30 shards - just like you have it. However - implement a document co-location strategy in your indexing - so that a single customers records (both "initial" and "follow-up") always get indexed into the same single shard. Read up this link on "Document Routing" to learn more on how to implement this - https://cwiki.apache.org/confluence/display/solr/Shards+and+Indexing+Data+in+SolrCloud#ShardsandIndexingDatainSolrCloud-DocumentRouting 3. When your search App queries the Collection - use the _route_=<customer Id / Name> parameter to force searches on the correct shard. Such a design ensures that your queries doesn't get distributed across all nodes / shards on your system - which could cause latency issues of its own. -- View this message in context: http://lucene.472066.n3.nabble.com/shards-as-subset-of-All-Shards-tp4147998p4148038.html Sent from the Solr - User mailing list archive at Nabble.com.
