Live data from Hacker News

Making 768 servers look like 1

planetscale.com

1–9 of 9 posts

Re: Making 768 servers look like 1

#3
Thanks for a well written article!

When spec'ing a signle database host, I've been told to select the highest L1/L2 cache possible (allowing O(n^2) loads to complete with the least IO delay) with IOPs and RAM also being desirable. Does this hold when selecting hardware for shards?

Do you ever see unusual ratios between egress bandwidth and shard count? For instance, do you ever see 128 shards under heavy load not managing to saturate a 1GbE link?

Would love to see more of your writing on this topic.

Re: Making 768 servers look like 1

#4

Thanks for a well written article! When spec'ing a signle database host, I've been told to select the highest L1/L2 cache possible (allowing O(n^2) loads to complete with the least IO delay) with IOPs and RAM also being desirable. Does this hold when selecting hardware for shards? Do you ever see unusual ratios between egress bandwidth and shard count? For instance, do you ever see 128 shards under heavy load not man…

Caching at all levels is key to good db performance (cpu cache ram disk). CPU cache optimization is not my area of expertise, but I did write another fun article on io devices and how it related to databsae perf:

https://planetscale.com/blog/io-devices-and-latency

Network saturation, and just resource saturation broadly, is a huge reason to shard. If/When the network, cpu, or disk for a subset of shards becomes a bottleneck, add more shards.

Re: Making 768 servers look like 1

#7
post #5
post #2

Hey, I wrote this! Sharding is cool and foundational to making the internet work. I'm around to answer Qs.

Very interesting piece! Does Vitess support xshard joins? How does it compare to things like TiDB?

Yep! https://vitess.io/docs/reference/features/distributed-transa...