We have similar date and language based collection.
We also ran into similar issues of having huge clusterstate.json file which
took an eternity to load up.
In our case the search cases were language specific so we moved to multiple
solr cluster each having a different zk namespace per language, s
Hmmm, one thing that will certainly help is the new per-collection
state.json that will replace clusterstate.json. That'll reduce a lot
of chatter.
You might also get a lot of mileage out of breaking the collections
into sub-groups that are distinct thus reducing the number of
collections on each
Hi,
Thanks a lot Erick and Shawn for your answers.
I am aware that it is a very particular issue with not a common use of
Solr. I just wondered if people had the similar business case. For
information we need a very important number of collections with the same
configuration cause of legally reaso
On 7/27/2015 9:16 AM, Olivier wrote:
> I have a SolrCloud cluster with 3 nodes : 3 shards per node and
> replication factor at 3.
> The collections number is around 1000. All the collections use the same
> Zookeeper configuration.
> So when I create each collection, the ZK configuration is pulled
AFAIK, the shareSchema flag which shares
the same internal schema object is _NOT_
honored in SolrCloud mode. Could you raise
a JIRA to the effect of
"Investigate honoring shareSchema in Cloud mode"?
Please add in a note about the case you're seeing.
Not promising to actually work on it, but it wou
