zlacker

[parent] [thread] 8 comments
1. tehbea+(OP)[view] [source] 2021-06-12 07:52:10
> Why would you choose to use a system that doesn't scale by default?

By all accounts Postgres seems to be a pain to scale off a single machine, much more so than redis.

replies(2): >>cbsmit+Z3 >>hardwa+I8
2. cbsmit+Z3[view] [source] 2021-06-12 08:34:48
>>tehbea+(OP)
Which PostreSQL scaling pain point would you be referring to? Citus?
3. hardwa+I8[view] [source] 2021-06-12 09:31:20
>>tehbea+(OP)
Postgres is not as automatic as other tools but is mostly an artifact of it being around so long, and focus being on other things. Few projects have been around and stayed as relevant as postgres.

Most of the time, you really don't need to scale postgres more than vertically (outside of the usual read replicas), and if you have tons of reads (that aren't hitting cache, I guess), then you can scale reads relatively easily. The problem is that the guarantees that postgres gives you around your data are research-level hard -- you either quorum or you 2pc.

Once you start looking into solutions that scale easily, if they don't ding you on performance, things get murky really quick and all of a sudden you hear a lot of "read-your-writes" or "eventual consistency" -- they're weakening the problem so it can be solved easily.

All that said -- Citus and PostgresXL do exist. They're not perfect by any means, but you also have solutions that scale at the table-level like TimescaleDB and others. You can literally use Postgres for something it was never designed for and still be in a manageable situation -- try that with other tools.

All that said, KeyDB[0] looks pretty awesome. Multithreaded, easy clustering, and flash-as-memory in a pinch, I'm way more excited to roll that out than I am Redis these days.

[0]: https://github.com/EQ-Alpha/KeyDB

replies(1): >>victor+vm
◧◩
4. victor+vm[view] [source] [discussion] 2021-06-12 12:14:09
>>hardwa+I8
KeyDB is really good. We use it in production to achieve millisecond response times on millions of requests per second.
replies(2): >>hardwa+Mo >>killin+CE
◧◩◪
5. hardwa+Mo[view] [source] [discussion] 2021-06-12 12:41:06
>>victor+vm
It really looks absolutely amazing, I feel guilty because I want to run a service on it, there's almost no downside to running it everywhere you'd normally run Redis.

Also in the cool-redis-stuff category:

https://github.com/twitter/pelikan

Doesn't have the feature set that KeyDB has but both of these pieces of software feel like they could the basis of a cloud redis product that would be really efficient and fast. I've got some plans to do just that.

◧◩◪
6. killin+CE[view] [source] [discussion] 2021-06-12 15:15:51
>>victor+vm
Are you Google search? How do you have millions of requests per second?
replies(2): >>maniga+iI >>qetern+DR
◧◩◪◨
7. maniga+iI[view] [source] [discussion] 2021-06-12 15:52:38
>>killin+CE
Lots of industries and applications can get to that scale. My last few companies were in adtech where that is common.
replies(1): >>killin+gB1
◧◩◪◨
8. qetern+DR[view] [source] [discussion] 2021-06-12 17:11:27
>>killin+CE
It's likely millions of internal requests, which as another comment mentions, is common in a number of industries.
◧◩◪◨⬒
9. killin+gB1[view] [source] [discussion] 2021-06-13 00:31:37
>>maniga+iI
Thanks, I had no idea!
[go to top]