Thanks Amrit ,

Actually we have huge amount of data so that's why thinking to index data into particular shard accept it's looks difficult but need to achieve the performance using document routing for huge data.

With configuration of  4 shard and 4 replica  is it better to distribute the one project data in multiple shard or in one shard which one is  feasible using document routing because needs the best performance while insertion & retrieval of document. And there would be the multiple projects of client which has huge amount of data.

I also taken the reading with 4 shard and 4 replica where without routing data are distribute among all 4 shard  and with routing its distributes in 1 shard because of used 1 bit of shard key like projectId/1!DocumentId.my reading looks as below.
1:inserting data in 4 shard without document routing  time taken ( in millisecond)  =325108  
Inserting data in 1 shard with document routing time time taken ( in millisecond)  =251835

2: retrieving data from 4 shard without document routing time taken( in millisecond)  = 234242
And retrieving data from 1 shard with document routing time taken ( in millisecond)= 94562

As per above reading getting  performance in local  while data in 1 shard but in production there will be huge data so is it need to distribute in 2 shard or in 1 shard which one is feasible for achieve better performance.
 

Regards,
Ketan

-----Original Message-----
From: Amrit Sarkar [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 13, 2017 8:52 PM
To: [EMAIL PROTECTED]
Subject: Re: How to routing document for send to particular shard range

Surely someone else can chim in;

but when you say: "so regarding to it we need to index the particular
You can / should create different collections for different client data, so that you can for surely improve performance as per need. There are multiple configurations which drives indexing and querying capabilities and incorporating everything in single collection will hinder that flexibility.
Also if you need to add new client in future, you don't need to think about sharding again, add new collection and tweak its configuration as per need.

Still if you need to use compositeKey to acheive your use-case, I am not sure how to do that honestly. Since shards are predefined when collection will be created. You cannot add more shards and such. You can only split a shard, which will divide the index and hence the hash range. I will strongly recommend you to reconsider your SolrCloud design technique for your use-case.

Amrit Sarkar
Search Engineer
Lucidworks, Inc.
415-589-9269
www.lucidworks.com
Twitter http://twitter.com/lucidworks
LinkedIn: https://www.linkedin.com/in/sarkaramrit2
Medium: https://medium.com/@sarkaramrit2

On Mon, Nov 13, 2017 at 7:31 PM, Ketan Thanki <[EMAIL PROTECTED]> wrote:
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB