Overview and Application Scenarios

Overview

Shard configuration is a core function of DDM. With this function, you can increase data nodes or shards to improve database storage and concurrency as services grow. Shard configuration has little impacts on your services, so you do not need to worry about database scaling and subsequent O&M as your services are burst.

Application Scenarios

1. Keep shards unchanged and increase data nodes.

This method does not change the number of shards and only increases the number of data nodes. Some shards are migrated from original data nodes to new data nodes. The shard data is not redistributed, so this method is the fastest one among all three methods is recommended.

This method meets rapid service growth after horizontal sharding and can reduce costs at the beginning stage of services.

It is also suitable if RDS for MySQL instances cannot meet storage space and read/write performance requirements.

Figure 1 Adding RDS for MySQL instances with shards unchanged

2. Increase shards with data nodes unchanged.

This method increases the shards, but not data nodes. It changes total shards, total table shards, and table sharding rules. Data is redistributed to different shards, and broadcast tables are increased.

This method is suitable if the associated RDS for MySQL instance has sufficient storage space but one of its tables contains a large amount of data, with query performance limited.

Figure 2 Increasing shards with RDS for MySQL instances unchanged

3. Increase both shards and data nodes.

This method increases both shards and data nodes. It changes total shards, total table shards, and table sharding rules. Data is redistributed to different shards, and broadcast tables are increased.

This method is suitable if RDS for MySQL instances cannot meet storage space and read/write requirements and there is a physical table containing a large amount of data with query performance limited.

Figure 3 Increasing shards and RDS for MySQL instances