- [[Sharding Key]] - separates large [[Databases]] into "shards" - each shard has the same schema, but each has unique data - for [[NoSQL Databases|NoSQL DBs]] we'd separate by documents, for [[SQL Databases|SQL DBs]] it'd be rows - potential challenges: - too much data for shard - each shard has a limited amount of data it can hold - uneven data distribution can exhaust some [[Sharding|Shards]] faster - this forces you to reshard, meaning you have to update the [[Sharding]] function and move the data around - celebrity problem - when one shard receives too many read operations - if you store Taylor Swift, BTS, Justing Bieber etc all on one shard, you might need to allocate a separate shard for each celebrity - it's hard to perform join operations across [[Sharding|Shards]] - most important consideration for implementing this strategy is picking a good [[Sharding Key]] - in below example, sharding is based on user ID (so that ID is the [[Sharding Key]]) ![[Pasted image 20250126155744.png|300]] ![[Pasted image 20250126155807.png|350]]