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

Redis is fast – I'll cache in Postgres

dizzy.zone

Post reply on HN
Print view View original

211–220 of 311 posts

Re: Redis is fast – I'll cache in Postgres

#211

Post by otikik »

ezekiel68 wrote: post #51

> Both postgres and redis are used with the out of the box settings Ugh. I know this gives the illusion of fairness, but it's not how any self-respecting software engineer should approach benchmarks. You have hardware. Perhaps you have virtualized hardware. You tune to the hardware. There simply isn't another way, if you want to be taken seriously. Some will say that in a container-orchestrated environment, tuning go…

> Ugh.

> if you want to be taken seriously

For someone so enthusiastic about giving feedback you don't seem to have invested a lot of effort into figuring out how to give it effectively. Your done and demeanor diminish the value of your comment.

Re: Redis is fast – I'll cache in Postgres

#212

Post by pigbearpig »

lemagedurage wrote: post #145
dizzyVik wrote: post #47

Earlier quoted context omitted.

There's a reason this is on my blog and not a paper in a journal. This isn't supposed to show the absolute speed of either tool, the benchmark is not set up for that. I do state that redis has more performance on the table in the blog post.

The main issue is that a reader might mistake Redis as a 2X faster postgres. Memory is 1000X faster than disk (SSD) and with network overhead Redis can still be 100X as fast as postgres for caching workloads. Otherwise, the article does well to show that we can get a lot of baseline performance either way. Sometimes a cache is premature optimisation.

That's the reader's fault then. I see the blog post as the counter to the insane resume-building over-engineered architecture you see at a lot of non-tech companies. Oh, you need a cache for our 25-user internal web application? Let's put an front a redis cluster with elastisearch using an LLM to publish cache invalidation with Kafka.

Re: Redis is fast – I'll cache in Postgres

#214

Post by foobarian »

not_kurt_godel wrote: post #32
maxbond wrote: post #26

Earlier quoted context omitted.

I like to call cases like this "premature distribution." Or maybe you could call it "premature capacity." If you have an application running in the cloud with several thousand requests per day, you could probably really benefit from adding a service like Redis. But when you have 0-10 users and 0-1000 requests per day, it can make more sense to write something more monolithic and with limited scalability. Eg, doing ev…

You probably don't need Redis until you have thousands of requests per minute, nevermind per day.

I'd go further and even say per second! Actually PG can still handle it, the main problem is that it has a more complex runtime that can spike. Backups? Background jobs doing heavy writes? Replication? Vacuum? Can tend to cause multisecond slowdowns which may be undesirable depending on your SLA. But otherwise it would be fine.

Re: Redis is fast – I'll cache in Postgres

#216

Post by hvb2 »

odie5533 wrote: post #157
motorest wrote: post #143

Earlier quoted context omitted.

> High read/write and low-ish size. Also it's faster You posted a vague and meaningless assertion. If you do not have latency numbers and cost differences, you have absolutely nothing to show for, and you failed to provide any rationale that justified even whether any cache is required at all.

At 10k RPS you'll see a significant cost savings with Redis over DynamoDB. ElastiCache Serverless (Redis/Memcached): Typical latency is 300–500 microseconds (sub-millisecond response) DynamoDB On-Demand: Typical latency is single-digit milliseconds (usually between 1–10 milliseconds for standard requests)

> At 10k RPS

You would've used local memory first. At which point I cannot see getting to those request levels anymore

> ElastiCache Serverless (Redis/Memcached): Typical latency is 300–500 microseconds (sub-millisecond response)

Sure

> DynamoDB On-Demand: Typical latency is single-digit milliseconds (usually between 1–10 milliseconds for standard requests)

I know very little use cases where that difference is meaningful. Unless you have to do this many times sequentially in which case optimizing that would be much more interesting than a single read being .5 ms versus the typical 3 to 4 for dynamo (that last number is based on experience)

Re: Redis is fast – I'll cache in Postgres

#217

Post by [deleted] »

otikik wrote: post #211
ezekiel68 wrote: post #51

> Both postgres and redis are used with the out of the box settings Ugh. I know this gives the illusion of fairness, but it's not how any self-respecting software engineer should approach benchmarks. You have hardware. Perhaps you have virtualized hardware. You tune to the hardware. There simply isn't another way, if you want to be taken seriously. Some will say that in a container-orchestrated environment, tuning go…

> Ugh. > if you want to be taken seriously For someone so enthusiastic about giving feedback you don't seem to have invested a lot of effort into figuring out how to give it effectively. Your done and demeanor diminish the value of your comment.

[deleted]

Re: Redis is fast – I'll cache in Postgres

#218

Post by wredcoll »

dgfitz wrote: post #210
yomismoaqui wrote: post #169

Earlier quoted context omitted.

If you are going to ask ChatGPT some specific tidbit it's better to force it to search on the web. Remember, an LLM is a JPG of all the text of the internet.

Wait, what? Isn't that the whole point, to ask it specific tidbits of information? Are we to ask it large, generic pontifications and claim success when we get large, generic pontifications back? The narrative around these things changes weekly.

I mean, like most tools they work when they work and don't when they fail. Sometimes I can use an llm to find a specific datum and sometimes I use google and sometimes I use bing.

You might think of it as a cache, worth checking first for speed reasons.

The big downside is not that they sometimes fail, its that they give zero indication when they do.

Re: Redis is fast – I'll cache in Postgres

#219

Post by fatata123 »

noisy_boy wrote: post #190

I have dealt with an abomination of a bespoke setup on Redis that was neither simple key/value nor an RDBMS but a grotesque attempt to simulate tables using key prefix with value being a hash containing "references" to entries in other "tables" (with some "special condition" edge cases thrown in to make it spicy). All with next to no documentation. It took adding many unit tests with generous logging to expose the lo…

[dead]
Post reply on HN