Making 768 Servers Look Like One: The Future of Database Scaling
Making 768 servers look like 1
Scaling relational databases beyond a few terabytes requires moving past simple read-replicas to complex sharding. I explain how distributing data across hundreds of servers solves write bottlenecks and storage limits. By using a sophisticated proxy layer like Neki or Vitess, we can route queries intelligently, making 768 distinct servers appear as a single cohesive database to your application.
The most difficult infrastructure component to scale is almost always the database.
- drdexebtjl
What about sequences? The example shows an auto-incrementing user ID. How’s that possible without contention between all shards? Is the proxy responsible for sequences?
What about foreign keys? Do they all have to live on the same shard? How do you do distributed transactions?
On cross-shard reads: how do you do sorting? And cross-shard joins?
I’d love to be proven wrong, but I suspect the 768 servers look like 1 only on the very surface, and you’ll get wildly different characteristics from cross-shard and single-shard queries.
I personally would prefer if they _didn’t_ look like 1 if they can’t behave like 1.
- groundzeros2015
I disagree with the opening premise:
> A single database server cannot handle such demand, so we must spread the queries and data out across many servers with database sharding
Did you max out the capacity of the best server you can buy?
Such a database can serve millions of customers (the numbers given).
You always want to scale up the other parts first, request handlers, caching, etc. The day you can no longer inspect the essential state of your system is the day your company better be included in NASDAQ and ready to pay a few hundred engineers 300k salaries.
- jdw64
Looks like the GIF is fully built out in code. It's really nice to look at, well made, and easy to understand too.
I wonder what program or code they used. I'd love to know.
p.sI thought it was a GIF, but it's an iframe. That was a nice little surprise.
- zinodaur
Sibling post has author answering questions in comments: https://news.ycombinator.com/item?id=48925420
- themgt
Even with a large database servers (10s of CPU cores, 100s of gigabytes of RAM) bottlenecks arise pretty quickly.
Err, do they? For what percent of real world use cases?
The database can scale to handle more traffic by adding replicas. An extreme example of this is OpenAI's use of 50 replicas on a single Primary.
So an extreme example is OpenAI needing 50 replicas, but we're doing five blades ... err, we're doing 768 servers because the need arose "pretty quickly"?
When we needed to store a petabyte of data (one million gigabytes), we'd need many more shards
For who? The United States government? How many end-users are running 1PB Postgres database on DBaaS?