Comparison
Shard keyvsSharding
Shard key
you pick the column that decides which database a row lives on, and every query that does not filter on it now hits all of them.
The field whose value routes a row to a shard. A good one spreads writes evenly and keeps the rows a single request needs together; a bad one creates hot shards or forces scatter-gather on your most common query. It is effectively impossible to change later without a full migration, so it is the decision to spend time on.
Full entry →Sharding
one database stopped being enough, so you split the rows across several of them and now every query has to know which one to ask.
Splitting data across independent database instances so writes and storage scale past one machine. It is the point at which cross-shard joins, distributed transactions and global uniqueness stop being free. Resharding a live system is one of the hardest routine operations in backend engineering, which is why the shard key deserves more thought than the schema.
Full entry →