# False Sharing versus Perfect Placement

DevFeed: [False Sharing versus Perfect Placement](<https://devfeed.tech/articles/false-sharing-versus-perfect-placement-12534.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2023/03/07/false-sharing.html>)

Author: Marc Brooker

Published: 2023-03-07T00:00:00Z

Content type: article

Language: en

Sources: [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog.md>), [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog-2.md>)

Topics: [Database](<https://devfeed.tech/topics/database.md>), [Scalability](<https://devfeed.tech/topics/scalability.md>)

Tags: [database](<https://devfeed.tech/tags/database.md>), [scalability](<https://devfeed.tech/tags/scalability.md>), [scale](<https://devfeed.tech/tags/scale.md>), [simulation](<https://devfeed.tech/tags/simulation.md>)

## AI overview

This article examines false sharing in sharded databases when changing key popularity makes perfect placement difficult. It compares uniformly distributed and Zipf-distributed keys using simulation runs and shows that biased distributions can concentrate traffic unevenly across shards.

## Source excerpt

False Sharing versus Perfect Placement This is part 3 of an informal series on database scalability. The previous parts were on NoSQL, and Hot Keys. In the last installment, we looked at hot keys and how they affect the theoretical peak scale a database can achieve. Hidden in that post was an underlying assumption: that can successfully isolate the hottest key onto a shard of its own. If the key distribution is slow moving (hot keys now will still be hot keys later) then this is achievable. The system can reshard (for example by splitting an merging existing shards) until heat on shards are balanced. Unfortunately for us, this nice static distribution of key heat doesn't seem to happen often. Instead, what we see is that popularity of keys changes over time. Popular products come and go. Events come and go. The 1966 FIFA world cup came and went1. If the distribution of which keys are popular right now changes often enough, then moving around data to balance shard heat becomes rather difficult and expensive to do. Even Sharding and False Sharing At the extreme end, where there is no stability in the key heat distribution, we may not be able to shard our database better than evenly (or, somewhat equivalently, randomly). This might work out well, with the hottest key on one shard, the second hottest on another, third hottest on another, and so on. It also might work out poorly, with the hottest and second hottest keys on the same shard. This leads to a kind of false sharing problem, where shards are hotter than they strictly need to be, just by getting unlucky. How likely are we to get unlucky in this way? Let's start with uniformly distributed keys, and think about a database with 10,000 keys, sharded into 2, 5 or 10 different shards. Ideally, for the 2 shard database we'd like to see the hottest shard get 50% of the traffic. For the 10 shard database 10%. This is what the distribution looks like with 50,000 simulation runs (solid lines are simulation results, dotted