Hacker News Reader

> The big question is: Do you need that kind of functionality? I agree that very large and complex infrastructures have their place - the problem is just that they import a ton of complexity and usually cost a lot.

I think that's the key. Most of us aren't Google/Facebook/whatever. Yet lots of people want to mimic those. A simple stack with a relation database on a single machine still goes a long way. In fact, it goes a lot longer way today than it did 20 years ago. It's ok to scale when you need to, but I think premature scaling is the wrong way to go, especially since most things never get to FB/Google/etc size.

I understand trying to keep complexity low. But I don’t understand how a relational database would be less complex than a simple key value store.

Every time this argument pops up, I end up wondering if it’s really about architectural complexity, or if it’s about sticking with the old and known.

A lot of relational databases offer a better (or more useful) consistency model than k-v stores, assuming your data isn’t just a bunch of keys and values. Having to worry about consistency can significantly your worsen complexity of your application code.

MongoDB is complex, that’s true. But DynamoDB or GCP Bigtable are pretty simple.

Simple indeed, they don't even offer anything that matches SQL flexibility.

Exactly my point. If the argument is to avoid unnecessary complexity, then how come a SQL database is the better choice?

Because not having proper query language turns simple wishes into complex solutions.

But it does have way to query, if you of course only know SQL and didn't bother to learn the MongoDB way to query then for you, the uninformed outsider, it might seem complex. But so does ArangoDB or Neo4j or GraphQL.

Like, if you were never exposed to rxjs and are now trying to build things with it doing

  $stream.pipe(
    switchmap(),
    filter(),
    etc(),
  )

It does seem more complex than

  stream.map().filter().etc()

but it's only so because you haven't put in the effort to learn that way.

Sure, whatever.

Now write DBA scale ISO SQL 2016 / Transact SQL / PL/SQL in that interesting Mongo flavoured language, including database engine debugger integration, and JIT compilation.

1. MongoDB is not complex, the driver structure sucks.

Example Go's mgo driver by Gustavo Niemeyer was simple and effective, but abandoned. The official drivers is unnecessarily complicated. And Go's need to have "context" everywhere adds to this, but MongoDB is not complex. Idk I'm not some super genius and picking up MongoDB was really easy. Querying (aka aggregation pipelines), you have to think of that as "pipes in bash". It's in the words aggregation pipelines. find | groupby | sort | filter | select. Something like that. It's not SQL it's different, but not complex, sorry.

In what context? A hosted database might be "simpler" to operatoe, but BigTable is quite complicated and does a lot of complex, low-level, work to be very fast.

First, I'd say the key value store is actually older than the relational database, by at least a couple of decades. Of course, not the current ones, but we're also not using the relational database from the 80s so ...

Now to try and answer your question, I think a relational database is a lot more complex than a simple key value store, but if it's a good implementation, it will hide this complexity from the user, and using the database will be rather simple. It can be as simple as a key value store since you can just use a relational database like one. Note that this hiding of complexity is by design, it is one of the main goals of the relational model, it's not accidental.

Throw ACID requirements on top of a simple kv store and it is not a simple kv store any more

you stick with an old and known since its getting the job done, customer is happy and you can get a good night sleep too

> tens of thousands of requests,

a raspberry pi can pretty much serve 100k req. / second. An average dev laptop should be able to handle 1M req. / second without much issues

> a raspberry pi can pretty much serve 100k req. / second

I appreciate the sentiment, but my intuition says that number is too high. What would that look like? I can't picture nginx or haproxy serving up a static 'hello world' response at that volume on a Pi3.

And if you do anything with a slow-ish 3rd party API you're probably going to hit the TCP socket limit before you can respond to 100k/s.

Legitimately curious about whether my intuition is wrong. I don't have an unused Pi handy to test it myself.

Edit: It's possible you're citing https://levelup.gitconnected.com/serving-100k-requests-secon... ? Pretty interesting article in any case, especially this claim:

> This test pitted a native C++ server against a scripted Node.js one, so of course the outcome was given. Well, not really. If I run the same test using µWebSockets.js for Node.js, the numbers are a stable 75k req/sec (for cleartext). That’s still 8.5x that of Node.js with Fastify and just shy of 75% of µWebSockets itself.

Edit 2: Doing a bit more research and finding some other benchmarks online, it seems like 100k with µWebSockets is plausible. I recant my skepticism.

> a raspberry pi can pretty much serve 100k req. / second. An average dev laptop should be able to handle 1M req. / second without much issues

Depends on what you do. It's quite easy to hit these numbers with a low number of static pages, but apps that can easily work with static pages usually don't have DevOps people. That's why I went with thousands, to have a reasonable number for an app that actually does some complex processing.

That doesnt seem right. https://www.diva-portal.org/smash/get/diva2:1439759/FULLTEXT... According to this paper, looks like 1000s of requests is more realistic, both for pi and laptop.

Still enough for 99% of websites.

> Still enough for 99% of websites.

I'm not sure you have much experience working on websites. Multiple deployments are required for performance reasons, which is the main driving force for paying hefty bills for CDNs, and their recent investment in edge computing.

You deploy to multiple deployments in multiple regions in a good part to drive down those 300ms requests to sub 50ms. Otherwise your user gets fed up and drops you in favor of a competitor.

But if you work on a service who has only a dozen users in the same region and can wait in turns to see who can make a request, go right ahead with your production raspberry pi setup.

https://en.m.wikipedia.org/wiki/Name_calling

I ultimately agree with you, but in between a raspberry pi and “hefty bills CDNs” is something like a half rack at a Colo, a f5, and a couple PowerEdges.

Those 99% of websites don’t have the performance problem you’re talking about. You’re talking about the 1%.

I bought artisanal knitted socks for Christmas. If their website is faster than their knitting that’s good enough. That website is part of the 99%.

> You deploy to multiple deployments in multiple regions in a good part to drive down those 300ms requests to sub 50ms

one raspberry pi per continent :p

e.g. I'm in a small rural village in southern france right now and I get 2GB down / 1GB up more or less with a 9ms speedtest ping (which is slow, it's often 2ms) - anyone from europe would get < 50ms ping notwithstanding the latency between them and their isp

by the time my website has, say, > 500k req/second I can definitely invest in, idk, some used 2015 i7 laptop to give myself a x10. For reference, 1M requests per second is Instagram in 2015, one of the most used websites in the world - by the time you're at that scale you've been bought by Facebook anyways.

Heyo, I worked at a CDN for a few years on edge cache stuff. Almost every web site would be well served with a single Pi and a CDN. For almost every web site, the CDN is free.

My user gets fed up because the page takes a second to load?

Not every page loads 50 different resources. Not every page serves people globally. Not every page has competitors.

And then you serve megabytes of js libs that will cause multi-second load times and log every single mouse movement, autostart a video with sound and pop up 10 different bullshit, so.. you would be at the exact same spot from a shitty dev laptop.

(Half kidding)

> I'm not sure you have much experience working on websites.

I might say the same about you. Be respectful.

> a raspberry pi can pretty much serve 100k req. / second. An average dev laptop should be able to handle 1M req. / second without much issues

How big are these requests? If you're returning more than 1kB including all the headers, you're not beating 100kreq/s on a standard consumer-level 1Gbit link.

The argument is about the power of a single machine. If your enterprise is somehow limited by 1Gb links, no amount of scaling is going to address that.

I think the parent's argument is that a Raspberry Pi is limited to 1Gb link, so how can do 100k reqs/sec

That, plus if I open dev tools and look at requests for even this site, the only things that small are three of the images (the orange Y in the corner, the vote arrow, and a 1x1 somewhere).

It wouldn't be possible to get that request rate outside of a microbenchmark, just because of the network speed the pi supports.

you can buy faster network cards for a RPi but this is missing the point: 100k req/sec is not a huge volume and a decent server should be able to handle it without issues.

it's not, people have been able to put >1G network cards on a Pi:

- 2.5G: https://www.jeffgeerling.com/blog/2020/testing-25-gbps-ether...

- 10G (in practice 3.6G max which is more than what most can expect from their ISP): https://www.hackster.io/news/10-gbps-ethernet-on-a-raspberry...

The thing is that sometimes you do.

At my current company we're at cusp when we need to address scalability to able to grow as a business, and the business is growing. It took several years to get to this point, but here we are.

I prefer simplicity as much as the next guy, but at some moment it becomes simpler overall to use cloud services controlled by k8s than to maintain large amounts Ansible scripts and Jenkins jobs.

With that, by the way, comes an inevitable untangling of various parts in the software, and simplification of it. To be fast you need the processing path to be simple.

> The big question is: Do you need that kind of functionality?

What functionality? Automated unit tests to ensure you're not shipping code that is so broken that it even breaks basic invariants? Automated integration tests that ensure you're not shipping code that fails to call other components/services? UI tests to ensure that your latest commit didn't made your prod service unusable for the end user? Performance tests that help you determine if your latest change doesn't suddenly exhaust your computational resources in peak demand?

Kind of depends on what you’re building, right? Avoiding building new features in order to limit complexity is probably a good idea in select cases but not in others. Using more complex, purpose-built technology over standard boilerplate is often very cost-efficient, but only if you run at a scale where the additional complexity is worth the savings…

The people paying my salary sure seem to think that we do need it.