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

161–170 of 601 posts

Re: Use one big server

#161

Post by altdataseller »

zasdffaa wrote: post #108
altdataseller wrote: post #93

Earlier quoted context omitted.

What if your product simply stores a lot of data (ie a search engine) How is that weird?

Depends what you mean by a database I guess. I take it to mean an RDBMS. RDBMSs provide guarantees that web searching doesn't need. You can afford to lose a pieces of data, provide not-quite-perfect results for web stuff. It's just wrong for an RDBMS.

What if you are using the database as a system of record to index into a real search engine like Elasticsearch? For a product where you have tons of data to search from (ie text from web pages)

Re: Use one big server

#162

Post by darkr »

oceanplexian wrote: post #140
andrepew wrote: post #32

Earlier quoted context omitted.

This is a huge one -- value in outsourcing blame. If you're down because of a major provider outage in the news, you're viewed more as a victim of a natural disaster rather than someone to be blamed.

I hear this repeated so many times at my workplace, and it's so totally and completely uninformed. Customers who have invested millions of dollars into making their stack multi-region, multi-cloud, or multi-datacenter aren't going to calmly accept the excuse that "AWS Went Down" when you can't deliver the services you contractually agreed to deliver. There are industries out there where having your service casually g…

> Customers who have invested millions of dollars > … > an hour of outage would lose us $1M+ in business

Given (excluding us-east-1) you’re looking at maybe an hour a year on average of regional outage, sounds like best case break even on that investment?

Re: Use one big server

#163

Post by 1500100900 »

markandrewj wrote: post #88
cfors wrote: post #56

Yep, there's a premium on making your architecture more cloudy. However, the best point for Use One Big Server is not necessarily running your big monolithic API server, but your database. Use One Big Database. Seriously. If you are a backend engineer, nothing is worse than breaking up your data into self contained service databases, where everything is passed over Rest/RPC. Your product asks will consistently want t…

Just FYI, you can have one big database, without running it on one big server. As an example, databases like Cassandra are designed to be scaled horizontally (i.e. scale out, instead of scale up). https://cassandra.apache.org/_/cassandra-basics.html

Cassandra may be great when you have to scale your database that you no longer develop significantly. The problem with this DB system is that you have to know all the queries before you can define the schema.

Re: Use one big server

#164

Post by clairity »

cfors wrote: post #56

Yep, there's a premium on making your architecture more cloudy. However, the best point for Use One Big Server is not necessarily running your big monolithic API server, but your database. Use One Big Database. Seriously. If you are a backend engineer, nothing is worse than breaking up your data into self contained service databases, where everything is passed over Rest/RPC. Your product asks will consistently want t…

> "Use One Big Database."

yah, this is something i learned when designing my first server stack (using sun machines) for a real business back during the dot-com boom/bust era. our single database server was the beefiest machine by far in the stack, 5U in the rack (we also had a hot backup), while the other servers were 1U or 2U in size. most of that girth was for memory and disk space, with decent but not the fastest processors.

one big db server with a hot backup was our best tradeoff for price, performance, and reliability. part of the mitigation was that the other servers could be scaled horizontally to compensate for a decent amount of growth without needing to scale the db horizontally.

Re: Use one big server

#165

Post by 1500100900 »

bartread wrote: post #151
cfors wrote: post #56

Yep, there's a premium on making your architecture more cloudy. However, the best point for Use One Big Server is not necessarily running your big monolithic API server, but your database. Use One Big Database. Seriously. If you are a backend engineer, nothing is worse than breaking up your data into self contained service databases, where everything is passed over Rest/RPC. Your product asks will consistently want t…

Not to mention, backups, restores, and disaster recovery are so much easier with One Big Database™.

How is backup restoration any easier if your whole PostgreSQL cluster goes back in time when you only wanted to rewind that one tenant?

Re: Use one big server

#166

Post by pclmulqdq »

PeterCorless wrote: post #125

We have a different take on running "one big database." At ScyllaDB we prefer vertical scaling because you get better utilization of all your vCPUs, but we still will keep a replication factor of 3 to ensure that you can maintain [at least] quorum reads and writes. So we would likely recommend running 3x big servers. For those who want to plan for failure, though, they might prefer to have 6x medium servers, because…

I think this is the right approach, and I really admire the work you do at ScyllaDB. For something truly critical, you really do want to have multiple nodes available (at least 2, and probably 3 is better). However, you really should want to have backup copies in multiple datacenters, not just the one.

Today, if I were running something that absolutely needed to be up 24/7, I would run a 2x2 or 2x3 configuration with async replication between primary and backup sites.

Re: Use one big server

#167

Post by pclmulqdq »

porker wrote: post #23

I like One Big (virtual) Server until you come to software updates. At a current project we have one server running the website in production. It runs an old version of Centos, the web server, MySQL and Elasticsearch all on the one machine. No network RTTs when doing too many MySQL queries on each page - great! But when you want to upgrade one part of that stack... we end up cloning the server, upgrading it, testing…

Containers are your friend here. The sysadmin tools that have grown out of the cloud era are actually really helpful if you don't cloud too much.

Re: Use one big server

#168

Post by bob1029 »

mathisonturing wrote: post #159
bob1029 wrote: post #83

> 1 million IOPS on a NoSQL database I have gone well beyond this figure by doing clever tricks in software and batching multiple transactions into IO blocks where feasible. If your average transaction is substantially smaller than the IO block size, then you are probably leaving a lot of throughput on the table. The point I am trying to make is that even if you think "One Big Server" might have issues down the road,…

> batching multiple transactions into IO blocks where feasible. If your average transaction is substantially smaller than the IO block size, then you are probably leaving a lot of throughput on the table. Could you expand on this? A quick Google search didn't help. Link to an article or a brief explanation would be nice!

Sure. If you are using some micro-batched event processing abstraction, such as the LMAX Disruptor, you have an opportunity to take small batches of transactions and process them as a single unit to disk.

For event sourcing applications, multiple transactions can be coalesced into a single IO block & operation without much drama using this technique.

Surprisingly, this technique also lowers the amount of latency that any given user should experience, despite the fact that you are "blocking" multiple users to take advantage of small batching effects.

Re: Use one big server

#169

Post by pclmulqdq »

abrax3141 wrote: post #139

I may be misunderstanding, but it looks like the micro-services comparison here is based on very high usage. Another use for micro-services, like lambda, is exactly the opposite. If you have very low usage, you aren't paying for cycles you don't use the way you would be if you either owned the machine, or rented it from AWS or DO and left it on all the time (which you'd have to do in order to serve that randomly-arri…

If you have microservices that truly need to be separate services and have very little usage, you probably should use things like serverless computing. It scales down to 0 really well.

However, if you have a microservice with very little usage, turning that service into a library is probably a good idea.

Re: Use one big server

#170

Post by cal85 »

WJW wrote: post #85
cal85 wrote: post #35

> In comparison, buying servers takes about 8 months to break even compared to using cloud servers, and 30 months to break even compared to renting. Can anyone help me understand why the cloud/renting is still this expensive? I'm not familiar with this area, but it seems to me that big data centers must have some pretty big cost-saving advantages (maintenance? heat management?). And there are several major providers…

Several points: - The price for on-prem conveniently omits costs for power, cooling, networking, insurance and building space, it's only the purchase price. - The price for the cloud server includes (your share of) the costs of replacing a broken power supply or hard drive, which is not included in the list price for on-prem. You will have to make sure enough of your devs know how to do that or else hire a few sysadm…

Thank you, that explains it.
Post reply on HN