Single-instance sharded deployment

A single-instance, sharded deployment is another version of a single-instance deployment, but with multiple database shards.

In this type of deployment, an enterprise is associated to a single colony. The colony for an enterprise can be different from that of another enterprise. Each enterprise shares a common Configuration shard, Statistics shard, and Metadata shard, but it can have its own dedicated shard for Master and Transaction data. A colony can be identified by using the Enterprise Code.

Following are the advantages and limitations of sharded deployment.

Advantages

  • Central point of control because it is a single-instance deployment.
  • You can run one agent server that will process data across colonies. For example, you can run the Order Monitor enterprise agent to process data across enterprises. If the enterprise’s stores are located in different colonies, multiple threads will be spawned to process the data.
  • You do not need to synchronize Configuration data, such as hub-level pipelines, that is shared by two colonies.
  • Colonies can upgrade independently. However, if an enterprise that was inheriting rules from another enterprise is upgrading, the Configuration shard of both enterprises needs to be upgraded. If an enterprise upgrades, its participating organizations should also upgrade. These include nodes, capacity organization, catalog organization, and so on.
  • Enterprises in different colonies can share the same Configuration shard, but because they are in different colonies, they can still be upgraded independently.
  • Enterprises in different shards can inherit rules from a common organization.
  • Two different Transaction shards can inherit some configuration rules.
  • Enterprises can benefit from the isolated Configuration shard when using the Configuration Deployment Tool (CDT), and at the same time, be able to deploy Configuration data across multiple colonies.

Limitations

  • Cross-version data synchronization capabilities for the user interface are not supported. For example, if a Retailer deployment is running on a different version from a Web deployment, you cannot synchronize the data between these two clusters of application servers.
  • Resharding is not supported.

  • Enterprises that belong to different colonies cannot share capacity.
  • In the Configuration Deployment Tool (CDT), you can compare and migrate Configuration data all at once. But to migrate Master data, you must point the CDT to each colony and migrate on a per-colony basis.
  • Enterprises that belong to different colonies cannot participate with the same ship node. All participating organizations, including ship nodes must belong to same colony and hence, have to share the same Transaction schema.