Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making 768 servers look like 1

planetscale.com

Post reply on HN
Print view View original

61–70 of 89 posts

Re: Making 768 servers look like 1

#61

Post by pixl97 »

groundzeros2015 wrote: post #49
don-code wrote: post #41

Earlier quoted context omitted.

Let's hypothesize this is true. I worked at a startup that had _money_ - a lot of it - flowing in. Stakeholders wanted to see growth, which meant features. They did not want to see us making platform improvements; those didn't show well to clients. Best throw money at the problem, rather than sacrifice the all-important features. We had a number of architectural quirks that reflected this. One was that we ran our dat…

What if there was someone involved who had built web applications than run on laptops before and made different architectural decisions than the path your company went down.

And what if they cost more than your entire AWS bill?

You seem to have misunderstanding on what scales some things run at, and expense curves of getting them to run at those levels.

A poorly built app running on hundreds of servers can be massively expensive. A well built app running on a single server can also be massively expensive because people that can build apps like that tend to command whatever price they want under the banner of server cost savings.

Can you build software this efficiently? If you can't, then being an armchair expert about it helps noone. If you can, you're undercharging your clients.

Re: Making 768 servers look like 1

#62

Post by jdw64 »

bddicken wrote: post #58
jdw64 wrote: post #3

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.

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.

Thank you so much.!!!! It can't be easy to put this much care into helping others understand, with that hand drawn feel and everything. I really learn a lot from it. The animations were great and made everything really easy to understand. Have a nice day.!

Re: Making 768 servers look like 1

#63

Post by srcreigh »

bddicken wrote: post #46
groundzeros2015 wrote: post #13

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 insp…

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 serv…

The cashapp post is actually working towards GPs point. It explains that networked storage MySQL was unreliable and expensive. They migrated to $fancytool which offers a db instance with attached local nvme.

While cashapp may actually need sharding, there are so many companies who are overpaying for shitty performing network storage databases.

Not to mention you are subject to cloud provider networking and compute allocation code. They change it. Big slow network storage DB suddenly gets even worse and you don’t have leverage to have it fixed on their end.

Re: Making 768 servers look like 1

#64

Post by chaps »

samlambert wrote: post #54
vkazanov wrote: post #11

Earlier quoted context omitted.

Of course 768 servers NEVER behave as 1. This is physically impossible. Global services using relational dbs typically severely restrict queries that run against the cluster. So no joins, no intervals, no grouping, etc. Transactional queries are usually limited to something like "get a single record, preferably from cache". For many typical web services this can go VERY FAR. Only a handful of global services needs mo…

> Transactional queries are usually limited to something like "get a single record, preferably from cache". simply wrong

Care to explain? Not getting a good vibe from you, Mr. CEO.

Re: Making 768 servers look like 1

#66

Post by marginalia_nu »

hilariously wrote: post #30
anichhangani wrote: post #21

Earlier quoted context omitted.

Surely the cost of running sql server on premium hardware with replication would be more than running on commodity hardware with sharding?

It depends on who you are paying for it, but generally a distributed system is harder to reason about, harder to fix, has weirder edge cases, and much more easily get into situations where it requires even MORE expertise to fix than just having a big honking server. When you start calculating things that are not just the server, the single server looks cheaper and cheaper. How do you get a consistent backup? How do y…

Another thing worth thinking about when running anything in parallel is the rather massive increase in error rate. When you're essentially rolling 768x the number of dice, failure outcomes will happen a lot more often than if you just roll the one or two.

It's a scale that transforms a 10 year MTBF to a ~5 day MTBF.

Re: Making 768 servers look like 1

#67

Post by mike_hearn »

marcosdumay wrote: post #60
mike_hearn wrote: post #59

I should start by disclosing that I work part time in the Oracle Database group, but - of course - my HN account is entirely my own, despite occasional mild shilling. The article itself is shilling for PlanetScale so that seems OK. The author - certainly not deliberately! - says some untrue things about relational databases. The most important one is this: > To understand why sharding is a necessary part of scaling r…

Lol about buying Oracle for performance! But anyway, do you have benchmarks from anybody not related to Oracle showing that performance? Because Oracle forbids talking about it...

Not forbidden. You can email a specific address to share results/setup and get permission to publish if you want. Other commercial databases also do that, because there's so many ways to misconfigure a database to make it slow and competitors are strongly incentivized to do so.

The question is what you'd want to benchmark. For example, imagine testing Postgres with a write load that goes well beyond what a single machine can do. It would collapse and query latencies would go through the roof. A horizontally scaled DB would keep going and process all those queries. Would you accept this as evidence that Postgres is slow or would you say it's not valid to benchmark at traffic loads Postgres physically cannot handle, given it never claimed to scale horizontally? Stuff like this is where benchmarking gets complicated.

I used to work at a different company that sold a kind of database system. It was much faster than our nearest competitor, so we were surprised when that competitor claimed to an important customer they were just as fast as us. Their benchmark counted transactions that failed and rolled back due to overload (optimistic concurrency) as "successful".

Re: Making 768 servers look like 1

#68

Post by groundzeros2015 »

samlambert wrote: post #55
groundzeros2015 wrote: post #48

Earlier quoted context omitted.

> These companies could not realistically operate off a single database server. I want to see it fail first. I suggest their org chart has more to do with their architecture than database performance. Even so you’re in the category I said. Hundreds of expensive engineers maintain this stuff.

> I want to see it fail first. your lack of experience at scale doesn't really invalidate this architecture

You’re selling a database technology without understanding ACID or transactions. You are the one who is naive and inexperienced.

Your sense of scale is entirely artificial and cargo cult. And you’re committed to selling that problem.

Have you tried maxing out the server yet? Got a write up about it?

Re: Making 768 servers look like 1

#69

Post by inigyou »

mike_hearn wrote: post #67
marcosdumay wrote: post #60

Earlier quoted context omitted.

Lol about buying Oracle for performance! But anyway, do you have benchmarks from anybody not related to Oracle showing that performance? Because Oracle forbids talking about it...

Not forbidden. You can email a specific address to share results/setup and get permission to publish if you want. Other commercial databases also do that, because there's so many ways to misconfigure a database to make it slow and competitors are strongly incentivized to do so. The question is what you'd want to benchmark. For example, imagine testing Postgres with a write load that goes well beyond what a single mac…

I suppose Oracle will only allow publication if your benchmark results look good. Can you tell us about a time you did a benchmark that made Oracle look bad, and they still let you publish it?

Re: Making 768 servers look like 1

#70

Post by groundzeros2015 »

pixl97 wrote: post #61
groundzeros2015 wrote: post #49

Earlier quoted context omitted.

What if there was someone involved who had built web applications than run on laptops before and made different architectural decisions than the path your company went down.

And what if they cost more than your entire AWS bill? You seem to have misunderstanding on what scales some things run at, and expense curves of getting them to run at those levels. A poorly built app running on hundreds of servers can be massively expensive. A well built app running on a single server can also be massively expensive because people that can build apps like that tend to command whatever price they wan…

It’s not deep magic or expensive. It’s simply asking hmm, how does my operating systems textbook solve this? Before asking how AWS solves this.
Post reply on HN