Sharding: keys, load and migration

Before and target maps

Required ownership moves

Compare ownership instead of a fresh random drawing

This experiment starts with fifty-two distinct fictional keys and assigns each to exactly one shard. The same inputs always produce the same owners. A target shard count computes a second placement map, and playback examines records in ID order, moving only those whose owner changes. The before and target summaries remain visible while the current shard cards show migration progress. No redraw reshuffles data and no record is silently duplicated or discarded. All state lives in the browser.

Choose the placement rule

Hash modulo uses a deterministic FNV-1a hash of UTF-8 key bytes and takes its remainder by the shard count. Alphabetic range assigns the first uppercase letter A through Z to equally sized alphabet-index intervals; it is not a sampled quantile split. Region-aware hash keeps west records on even-numbered shards and east records on odd-numbered shards, then hashes within that region’s shard pool. Region is an explicit record field, not guessed from the key’s first letter. Adding a shard preserves existing physical region labels. None of these teaching rules is presented as a specific database product’s routing implementation.

Set the old and target layouts

Initial shard count selects two through eight old owners. Target shard count must be at least the initial count and at most eight. This exercise covers expansion or unchanged counts, not shard removal. With equal counts, the before and target maps are identical and no moves are required. New shards are empty at the beginning of an expanded run. Changing any scenario input rebuilds both maps and pauses at the start. Replay changes current ownership one key at a time; it does not instantly replace the old map when you select a larger target.

Expose record skew and a hot-key workload

Key distribution chooses Uniform prefixes or Prefix-skewed. Uniform prefixes include each letter twice. Prefix-skewed places the first forty-two records under A and retains the remaining fixture letters; record IDs still keep keys unique. The region field alternates west and east in both datasets. First-key request weight changes the workload of key A-00 from one to two hundred units, while every other key has one unit. A unit is an illustrative relative request frequency, not measured requests per second. Increasing weight does not duplicate the record or change its hash.

Run two concrete imbalance experiments

Choose range placement, uniform prefixes, initial two and target two. Both shards hold twenty-six records. Increase First-key request weight to two hundred: one shard now carries two hundred twenty-five load units while the other carries twenty-six, despite identical record counts. Next choose prefix-skewed data and target six. Several ranges can be empty while the A range contains most records. The max/min record ratio is reported as undefined when its denominator is zero; an empty shard is not disguised by substituting one. Max/mean request load remains available as a different measure.

Inspect migration cost and stability

Required ownership moves lists each key whose target differs, including its old owner, new owner and request weight. Play spreads fifty-two key examinations across sixty viewing seconds. Pause holds the selected state, Next key examines one, Restart rewinds the same migration, and Show target completes it. Speed selects half, normal or double pace; Inspect time scrubs both ways. Restore defaults reinstates hash placement and a four-to-six expansion. At every step the total remains fifty-two unique records and the total request weight is conserved. The replay is an atomic ownership illustration, not a byte-copy duration estimate.

Understand what an online migration still needs

A real resharding workflow may require copying data, forwarding requests, capturing concurrent writes, reconciling replicas, switching routing metadata and recovering from failure. Those operations are not simulated here, and partially moved maps should not be treated as a deployable routing configuration. There are no row sizes, capacity limits, replicas, consistent-hash virtual nodes, range splitting, cross-region latency or live database calls. Moving one heavily requested key does not divide its workload among several shards. The bars show relative request weight for the current owners, while the key lists and exact evidence expose the underlying assignments.