Time-bucket partitions
One partition for each user grows without limit. A chat account with 10 million messages in 1 partition makes each read of the latest 50 slow. Time buckets keep each partition small.
See it on the board
The same traffic runs on two boards. The simulator measured both when this page was built.
| Measure | Goal | One partition for each user | One partition for each user and day |
|---|---|---|---|
| p99 latency | under 100 ms | 10.1 s Fail | 24 ms Pass |
| Monthly cost | 8 USD/mo | 8 USD/mo | |
| Error rate | 100% | 0% |
Key numbers
| Number | Value |
|---|---|
| Writes per second, one database vCPU | 10,000 writes/s |
| Reads per second, one database vCPU | 30,000 reads/s |
| Read or write, median | 0.3 ms |
Hash ring · 3 to 4 nodes · 8 of 36 keys move
How it works
A wide-column store keeps all rows with the same partition key together. This is fast for reads of one key, because the rows sit close. It is a problem when one key grows without end. A busy chat account adds messages every day, and its partition only gets larger.
In the mini board a large account has 10 million messages. All of them sit in one partition, because the key is the user. Each request asks for the latest 50 messages. The store must work through a huge partition to find them, so p99 passes the 100 ms limit.
A time bucket adds a part of the date to the key: user plus day. A day holds only the messages of that day, so each partition stays small. The latest 50 messages sit in the newest bucket or two. The read touches a small partition, and p99 falls inside the limit.
A bucket has its own rules. Choose the size from the write rate: if a bucket still grows too large, use hours, not days. A read for a long range must ask many buckets. And the newest bucket takes all the writes, so a very busy key may need a second part, such as a shard number, in its key.
Old buckets are easy to move to cheaper storage or to delete.
In the levels you bucket the key by time and check the read time of the latest rows.