1 / 6 Sharding Strategies & Shard Keys

Windows Without Neighbors

A metrics table is hash-partitioned on its primary key. Almost every dashboard query asks for all rows in a time window. Why do those queries run worse than they would under range partitioning on the timestamp?

A

The hash must be recomputed for every candidate row at read time, and that CPU cost dominates the query

B

Hashing scatters adjacent timestamps across every shard, so a window query becomes a fan-out to all shards instead of hitting one or two

C

Hash-partitioned shards cannot maintain local secondary indexes, so each shard falls back to a full table scan

D

Hash partitioning requires a directory lookup per row before it can be fetched, which adds a network round trip to every single row the query returns