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

Use one big server

specbranch.com

Post reply on HN
Print view View original

521–530 of 601 posts

Re: Use one big server

#521

Post by BenoitEssiambre »

lmm wrote: post #452
BenoitEssiambre wrote: post #226

Earlier quoted context omitted.

I'm glad this is becoming conventional wisdom. I used to argue this in these pages a few years ago and would get downvoted below the posts telling people to split everything into microservices separated by queues (although I suppose it's making me lose my competitive advantage when everyone else is building lean and mean infrastructure too). In my mind, reasons involve keeping transactional integrity, ACID compliance…

I've never understood this logic for webapps. If you're building a web application, congratulations, you're building a distributed system, you don't get a choice. You can't actually use transactional integrity or ACID compliance because you've got to send everything to and from your users via HTTP request/response. So you end up paying all the performance, scalability, flexibility, and especially reliability costs of…

Http requests work great with relational dbs. This is not UDP. If the TCP connection is broken, an operation will either have finished or stopped and rolledback atomically and unless you've placed unneeded queues in there, you should know of success immediately.

When you get the http response, you will know the data is fully committed, data that uses it can be refreshed immediately and is accessible to all other systems immediately so you can perform next steps relying on those hard guarantees. Behind the http request, a transaction can be opened to do a bunch of stuff including API calls to other systems if needed and commit the results as an atomic transaction. There are tons of benefit using it with http.

Re: Use one big server

#522

Post by collyw »

nicoburns wrote: post #321
Gigachad wrote: post #306

Earlier quoted context omitted.

Where I work we are looking at it because we are starting to exceed the capabilities of one big database. Several tables are reaching the billions of rows mark and just plain inserts are starting to become too much.

Yeah, the at the billions of rows mark it definitely makes sense to start looking at splitting things up. On the other hand, the company I worked for split things up from the start, and when I joined - 4 years down the line - their biggest table had something like 50k rows, but their query performance was awful (tens of seconds in cases) because the data was so spread out.

Am I missing something?

2 ^ 30 is over 1 billion. So a properly indexed table with 1 billion rows will take a similar effort to search as a 30 row unindexed table.

Or are there other factors coming into play that I haven't thought of.

Re: Use one big server

#523

Post by elijaht »

tempnow987 wrote: post #270
yardie wrote: post #263

Earlier quoted context omitted.

Let me take you back to March, 2020. When millions of Americans woke up to find out there was a pandemic and they would be working from home now. Not a problem, I'll just call up our cloud provider and request more cloud compute. You join a queue of a thousand other customers calling in that morning for the exact same thing. A few hours on hold and the CSR tells you they aren't provisioning anymore compute resources.…

I never had this problem on AWS though I did see some startups struggle with some more specialized instances. Are midsize companies actually running into issues with non-specialized compute on AWS?

The company I was at in March 2020 had no issues getting more general purpose compute, and our growth was massive

Re: Use one big server

#524

Post by yardie »

tempnow987 wrote: post #270
yardie wrote: post #263

Earlier quoted context omitted.

Let me take you back to March, 2020. When millions of Americans woke up to find out there was a pandemic and they would be working from home now. Not a problem, I'll just call up our cloud provider and request more cloud compute. You join a queue of a thousand other customers calling in that morning for the exact same thing. A few hours on hold and the CSR tells you they aren't provisioning anymore compute resources.…

I never had this problem on AWS though I did see some startups struggle with some more specialized instances. Are midsize companies actually running into issues with non-specialized compute on AWS?

Our problem was we had a less than 24 hours to transition to work from home. Someone came down with COVID symptoms and spread it to the office and no one wanted to come in. We didn't have enough laptops for 250+ employees. Developer equivalent 16-core, 32GB RAM , and GPU instances is radically different from general compute web front ends. And we couldn't get enough of them. We had to tell some staff to hang tight while checking AWS+Azure daily.

These weren't the typical cheap scale out, general compute but virtualized workstations to replace physical, in office equivalents.

Re: Use one big server

#525

Post by adrianN »

collyw wrote: post #522
nicoburns wrote: post #321

Earlier quoted context omitted.

Yeah, the at the billions of rows mark it definitely makes sense to start looking at splitting things up. On the other hand, the company I worked for split things up from the start, and when I joined - 4 years down the line - their biggest table had something like 50k rows, but their query performance was awful (tens of seconds in cases) because the data was so spread out.

Am I missing something? 2 ^ 30 is over 1 billion. So a properly indexed table with 1 billion rows will take a similar effort to search as a 30 row unindexed table. Or are there other factors coming into play that I haven't thought of.

A thirty row table fits into the CPU cache, a 1 billion row table doesn't.

Re: Use one big server

#526

Post by neverartful »

rbanffy wrote: post #370

Not to be nasty, but we used to call them mainframes. A mainframe is still a perfectly good solution if you need five nines of uptime, with transparent failover of pretty much every part of the machine, the absolute fastest single-thread performance and the most transaction throughput per million dollars in the market. I would not advise anyone to run them as a single machine, however, but to have it partitioned into…

"absolute fastest single-thread performance"

Can you provide citation?

Re: Use one big server

#527

Post by fleddr »

lukeramsden wrote: post #490
fleddr wrote: post #387

Earlier quoted context omitted.

We're not a very serious industry. Despite uhm, it pretty much running the world. We're a joke. Sometimes I feel it doesn't even earn the term "engineering" at all, and rather than improving, it seems to get ever worse. Which really is a stunning accomplishment in a backdrop of spectacular hardware advances, ever more educated people, and other favorable ingredients.

We're much more like artisans than engineers, in my opinion (maybe with the exception of extremely deep-in-the-stack things like compiler engineering). The problem seems to be that because there's no "right way", only wrong ways, discussions end up being circular. I'm not a civil engineer, but I imagine there is a "best way" to build a bridge in any landscape, where any decisions and tradeoffs have well defined param…

I get what you're saying but I reject the notion that some of these tech choices are 100% subjective and that there's no "right way" at all.

If hardware has increased in speed/capacity by a factor 10-100 in a decade and our "accomplishment" is to actually make software increasingly slow, shitty and bloated with no new added value to the user, you'll have an idea of the absurd waste and efficiency of our stacks.

Re: Use one big server

#528

Post by fleddr »

throwawaylinux wrote: post #430
fleddr wrote: post #331

Our industry summarized: Hardware engineers are pushing the absolute physical limits of getting state (memory/storage) as close as possible to compute. A monumental accomplishment as impactful as the invention of agriculture and the industrial revolution. Software engineers: let's completely undo all that engineering by moving everything apart as far as possible. Hmmm, still too fast. Let's next add virtualization an…

> Software engineers: let's completely undo all that engineering by moving everything apart as far as possible. Hmmm, still too fast. Let's next add virtualization and software stacks with shitty abstractions. That's because the concept which is even more impactful than agriculture and the computer, and makes them and everything else in our lives, is abstraction. It makes it possible to reason about large and difficu…

None of that means anything.

The web is slower than ever. Desktop apps 20 years ago were faster than today's garbage. We failed.

Re: Use one big server

#529

Post by roeles »

> Populated with specialized high-capacity DIMMs (which are generally slower than the smaller DIMMs), this server supports up to 8 TB of memory total.

At work we're building a measurement system for wind tunnel experiments, which should be able to sustain 500 MB/sec for minutes on end, preferably while simultaneously reading/writing from/to disk for data format conversion. We bought a server with 1TB of RAM, but I wonder how much slower these high-capacity DIMMs are. Can anyone point me to information regarding latency and throughput? More RAM for disk caching might be something to look at.

Post reply on HN