Sharding Yandex StoreDoc collections

When sharding a Yandex StoreDoc cluster, the following service hosts are automatically created, billed separately from the main DBMS hosts:

• either MONGOS and MONGOCFG
• or MONGOINFRA

It makes sense to shard collections when splitting data into shards significantly helps improve DBMS performance or data availability. To increase availability, each shard should consist of 3 or more database hosts.

Ease of use and actual performance improvements significantly depend on the shard key you choose: make sure that the collection data is logically distributed across shards and is not linked to data in different shards.

You should use sharding for:

• Data of significant size: if the collection takes up more than 200 GB.
• Collections with non-uniform contents. For example, data can be clearly classified as frequently queried and rarely queried.
• Collections requiring high read and write speeds. Sharding helps distribute workloads among hosts to bypass technical limitations.

For more information about sharding, see Sharding in Yandex StoreDoc.

Required paid resourcesRequired paid resources

The support cost includes the fee for additional service hosts in the Yandex StoreDoc cluster (see Yandex StoreDoc pricing).

How to enable collection shardingHow to enable collection sharding

1. Enable sharding for the cluster.

2. Connect to the MONGOS or MONGOINFRA host via the mongosh CLI and enable sharding:

   sh.enableSharding("<DB_name>")
   

   You can request the host type with the list of hosts in the cluster.

3. Define an index for the sharded collection:

   db.getSiblingDB("<DB_name>").<collection_name>.createIndex( { "<index>": <index_type> } )
   

4. Enable collection sharding:

   sh.shardCollection( "<DB_name>.<collection>", { "<index>": <index_type> } )
   

5. Modify the applications accessing your database to use only the MONGOS or MONGOINFRA hosts.

Sharding heterogeneous dataSharding heterogeneous data

If a collection includes documents with heterogeneous data types, we recommend sharding based on the _id key values of the same type using Type Bracketing. This will make sharding and document searching faster than with _id values of different types.

Example of shardingExample of sharding

Let's say you already have a sharded Yandex StoreDoc cluster with a billing database. You need to enable sharding for the payment and addresses collections. In the example, the payment index hash and the addresses field value are used as the shard key.

Sequence of operations:

1. Connect to the billing database. Make sure that the user connecting to the database has the mdbShardingManager role in the admin database.

2. Enable sharding for the billing database:

   sh.enableSharding("billing")
   

3. Define the index for the sharded collection:

   db.payments.ensureIndex( { "_id": "hashed" } )
   

4. Create the required number of shards in the management console.

5. Shard the collection based on its namespace:

   sh.shardCollection( "billing.payments", { "_id": "hashed" } )
   

Sharding is now enabled and configured. To check this, try listing the available shards using the sh.status() command.