Sharding With Zones Based on Compound Shard-Keys on MongoDB 4.4

This article was written with the main purpose of showing you how to determine zones on a shard when using compound shard keys.

Defining Zones in Shards means pre-defining where certain chunks will be stored and amongst which set of particular shards they will be balanced according to the shard key definition.

MongoDB 4.4 brings the possibility to shard a collection and determine zones by compound keys, including mixing a hash key with non-hashed keys.  Hashed keys may be placed in the prefix of the index (shard key) or not. Depending on the method chosen, different settings must be in compliance with the balancer and this article will also show you a couple of examples.

Defining the Index Prior to Sharding

Even though it is not always required to create indexes in advance of running the “shardCollection” command, I am defining it to better illustrate the procedure

• The collections colltest1 will be sharded based on a key containing the hashed key in the prefix

• The collections colltest2 will be sharded based on a key containing the non-hashed key in the prefix

It is important to highlight  a couple of important points about creating the indexes for the shard keys:

• Once the collection is empty or if it is a new one, the command used to get a collection sharded will automatically create the indexes if they are not present yet. This will be described in the upcoming sections.
• If the shard key prefix will not be a hashed value, the indexes shall be created with the option {unique:false}

Creating the Initial Chunks Based on Hashed Key as a Prefix

There are, basically, a couple of requirements to ensure that the collection will be in compliance with the balancer and the initial chunk distribution will be optimally performed. 

• For each non-hashed value, a range of the hashed key must be defined with upper and lower boundaries. 
• The collection must be sharded with the option presplitHashedZones: true if there is a hashed field.

The below example shows how to shard the collection colltest1.

Defining the Zones and Assigning to the Shards (To make things brief, only one zone “LATAM” is used in this example.)

If you check the output of the sh.status(), you will notice that tags were created and assigned to the shards according to the zones definition:

Creating the Zone Ranges

Enabling Shard

In this example, the namespace dbtest.colltest1 will be evenly distributed according to the zone LATAM which will reach the shards shard01 and shard02. Looking at the sh.status() again, you will see that the initial chunks were created following the range defined above.

Creating the Initial Chunks Based on Non-Hashed Key as a Prefix

This example section will be a little bit more complicated to make the shard key compliant with the balancer for the initial chunk distribution.

• You need to specify MinKey for each field in the shard key, which defines the lower boundary of each zone range.
• Every zone must comprise a range, so at least one of the fields in the shard key must have an upper-boundary value larger than its MinKey
• Every combination of values for the fields of the shard key will fall within the range of one of the defined zones.  
• At the moment of sharding the collection, presplitHashedZones must be set to true.
• Not required, but likely desirable: One of the zones should define its upper boundary as MaxKey so it acts as a catchall for out-of-range values.

Defining the Zones and Assigning Them to the Shards

The zones were defined differently for this example:

Creating the Zone Ranges

Enabling Shard

The above example basically describes how to use a non-hashed field on the prefix of a shard key to ensure that certain values of that field will reach certain zones (determined as tags on shards) and the boundaries applied on the hashed field will ensure even distribution. In that case, all the docs of the namespace dbtest2.colltest2 with the minimum _id of location DC01 and the minimum _id of the location DC02, will be placed on the zone LATAM (shard02). And the next docs from the minimum _id of the location DC02 until the rest will be placed on the zone EU (shard 01)

It is very important to highlight that if the collection is not in compliance with the balancer, the migration of the chunks will never happen, though all the chunks will stay on the Primary Shard. It is possible to predict that situation right after enabling the sharding on the collection by looking at the output of the command sh.balancerCollectionStatus

If the balancerCompliant is true, means that the balancer will be able to split and migrate the chunks.

Conclusion

Defining the shard key is the most important step of deploying a healthy sharded cluster. Having a field on the shard key which contains a few distinct values would compromise the shard distribution, and as consequence, the performance. Hence, this is a great improvement coming along in MongoDB 4.4 which makes it possible to have keys with low cardinality defining the boundaries, yet still ensuring that the shard will rely on a hashed distribution based on a very selective key.

Percona Distribution for MongoDB is a freely available MongoDB database alternative, giving you a single solution that combines the best and most important enterprise components from the open source community, designed and tested to work together.

Download Percona Distribution for MongoDB Today!