By default, when {prodname} detects a change in a data collection, the change event that it emits is sent to a topic that uses a single Apache Kafka partition.
As described in {link-prefix}:{link-topic-auto-creation}#customizing-debezium-automatically-created-topics[Customization of Kafka Connect automatic topic creation], you can customize the default configuration to route events to multiple partitions, based on a hash of the primary key.
To configure a {prodname} connector to route events to a specific partition, configure the `PartitionRouting` SMT in the Kafka Connect configuration for the {prodname} connector.
Based on the preceding configuration, whenever the SMT receives a message that is bound for a topic with a name that begin with the prefix, `fulfillment`, it redirects the message to a specific topic partition.
The SMT computes the target partition from a hash of the value of the `name` field in the message payload.
By specifying the`allTopic` predicate, the configuration selectively applies the SMT.
The `change` prefix is a special keyword that enables the SMT to automatically refer to elements in the payload that describe the `before` or `after` states of the data.
If a specified field is not present in the event message, the SMT ignores it.
If none of the fields exist in the message, then the transformation ignores the event message entirely, and delivers the original version of the message to the default destination topic.
The number of partitions specified by the `topic.num` setting in the SMT configuration must match the number of partitions specified by the Kafka Connect configuration.
For example, in the preceding configuration example, the value specified by the Kafka Connect property `topic.creation.default.partitions` matches the `topic.num` value in the SMT configuration.
Suppose you have different data collections (t1, t2) routed to same topic (my_topic), and you want to partition events from data collection t1 using field f1
and events from data collection t2 using field f2.
Note that in this configuration we omitted the part to configure the re-routes of events from different topic to a specific one. See {link-prefix}:{link-topic-routing}[Topic Routing SMT].
// Type: concept
// Title: Migrating from the {prodname} ComputePartition SMT
Assuming that the configuration sets the same number of partitions for all topics, replace the following `ComputePartition`configuration with the `PartitionRouting` SMT.
The following examples provide a comparison of the two configuration.
If the SMT emits events to topics that do not share the same number of partitions, you must specify unique `partition.num.mappings` values for each topic.
For example, in the following example, the topic for the legacy `products` collection is configured with 3 partitions, and the topic for the `orders` data collection is configured with 2 partitions:
|Specifies the fields in the event payload that the SMT uses to calculate the target partition.
Use dot notation if you want the SMT to add fields from the original payload to specific levels in the output data structure.
To access fields related to data collections, you can use: `after`, `before`, or `change`.
The 'change' field is a special field that results in the SMT automatically populating content in the 'after' or 'before' elements, depending on type of operation.
If a specified field is not present in a record, the SMT skips it.