HN user
databases @ https://planetscale.com
Also benjdd.com
Author here, thank you.
Technically, they are using js + gsap + svg embedded i the article with iframes.
Process-wise, I drafted most of them as static images in excalidraw, passed the images along to cursor for a first draft, applied styling rules, and then did a bunch of fine-tuning.
Very welcome
We have tons of customers who do exactly this. It's great. Sharding is for customers who out grow this path.
A lot of what you're referring to is dictated by the sharding strategy. Vitess and Neki both let you configure this via the VSchema / data topology (That's what I'm getting at here)
https://planetscale.com/blog/making-768-servers-look-like-1#...
This decision matters a ton. I drilled into this specific point on sharding in one of my articles from awhile back:
https://planetscale.com/blog/database-sharding
This is something you face any time you shard data, no matter the system. Single-shard queries are preferred to cross-shard ones. We want 99% of what we do to be single shard, but occasionally cross-shard work is unavoidable.
You should read through those articles.
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"?
If you read the OpenAI article, you'll see that they actually used sharding to offload a bunch of work from their "1 primary 50 replicas setup"
>> "To mitigate these limitations and reduce write pressure, we’ve migrated, and continue to migrate, shardable (i.e. workloads that can be horizontally partitioned), write-heavy workloads to sharded systems such as Azure Cosmos DB..."
The 768 servers and 1PB example is just one of many configurations. A business with 10TB may choose to go from a monolithic database to a 8-shard setup to improve backup times, eliminate single-point-of-failure, have more breathing room for scaling.
Hey, author here.
Technically, they're powered by js + gsap + svg.
Process wise (for most of them) I sketched them out in advance in excalidraw for figure out layout, then passed these along to cursor to have it build out an initial draft from the image, then used some styling rules to get all the styles inline, then did a bunch of fine-tuning.
Spreading requests out across hundreds, thousands, and in some cases even more is precisely what is done in the industry for big databases! Good examples:
cashapp: https://code.cash.app/planetscale-metal github: https://github.blog/engineering/infrastructure/partitioning-... etsy: https://www.etsy.com/codeascraft/migrating-etsyas-database-s...
These companies could not realistically operate off a single database server.
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.
Hey, I wrote this!
Sharding is cool and foundational to making the internet work. I'm around to answer Qs.
It may not have the popularity it once did, but MySQL still powers a huge % of the internet.
What about spanner specifically benefits from random ids over sequential ones?
Simple sequential IDs are great. If you want UUID, v7 is the way to go since it maintains sequential ordering.
+1
I've also written about sharding.
B+trees combined with sequential IDs are great for writes. This is because we are essentially just appending new rows to the "linked list" at the bottom level of the tree. We can also keep a high fill % if we know there isn't a lot of data churn.
If you're sharding based purely on sequential ID ranges, then yes this is a problem. Its better practice to shard based on a hash of your ID, so sequential id assignments turn into non-sequential shard keys, keeping things evenly distributed.
It's really just a matter of tradeoffs. B-trees are great, but are better suited for high read % and medium/low write volume. In the opposite case, things like LSMs are typically better suited.
If you want a comprehensive resource, I'd recommend reading either Designing Data Intensive Applications (Kleppman) or Database Internals (Petrov). Both have chapters on B-trees and LSMs.
I've read this paper and it's a neat idea. It hasn't been introduced into popular oss databases like postgres and mysql, and my understanding is it has some drawbacks for real prod use vs ths simplistic benchmarks presented in the paper.
Would love to know if anyones built something using it outside of academic testing.
Oh hey, I wrote this! Happy to chat more about the article here. Databases are kinda my thing.
epic
Yep. Its a wonderful capability to have for some situations, but for 90% of applications SERIALIZABLE isolation is overkill.
These are still transactions! It's not uncommon for a large % of transactions in an OLTP workload to be only one query without explicit BEGIN / COMMIT; This is called an autocommit transactions or implicit transaction.
Thanks, fixed!
Author here. You're right! I'm fixing now.
I appreciate this feedback, and then you read through it with enough rigor to notice.
Notation is useful. Citations are nice for further reading. But I don't agree more of this makes for a better article!
Author here. Thank you! These visuals are built with js + gsap (https://gsap.com)
Author here. This is good feedback.
The combination of transactions, isolation levels, and MVCC is such a huge undertaking to cover all at once, specially when comparing how it's done across multiple DBs which I attempted here. Always a balance between technical depth, accessibility to people with less experience, and not letting it turn into an hour-long read.
This is changing soon with Neki.