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

Readyset: A MySQL and Postgres wire-compatible caching layer

github.com

Post reply on HN
Print view View original

11–20 of 71 posts

Re: Readyset: A MySQL and Postgres wire-compatible caching layer

#11

Post by marceloaltmann »

jitl wrote: post #9
zer00eyz wrote: post #4

I dont understand what the use case is for this. If I have a front end, I would hope that the formated response is what were caching. Be that HTML or JSON. If I cant read from that cache then I should be reading from fresh data all together? right?

How do you invalidate your cache? Is it complicated? What about search queries with many filters? What about responses that are unique per user? What about common queries that are shared between multiple views, do you constantly re-run those as your response cache is invalidated?

Caches are never invalidated. Readyset uses CDC to receive updates from PostgreSQL/MySQL and update the cache entries. No invalidation required. The price you pay is eventually consistent data, which is already true if you use any async replication like readyset does.

Re: Readyset: A MySQL and Postgres wire-compatible caching layer

#12

Post by iknownothow »

qaq wrote: post #7

But the read side is already fairly trivial to scale with read replicas

Not denying your point but in some applications (which aren't outliers) a good cache can increase number of requests served 100x. Achieving those with read-replicas is easy and possible but can be quite expensive.

A read-replica doesn't give you perfect transactional guarantees as well. Read operations to the replica after a write operation to the leader might still give you stale data (lagging by a few milliseconds).

Re: Readyset: A MySQL and Postgres wire-compatible caching layer

#14

Post by marceloaltmann »

jerrygenser wrote: post #6
zer00eyz wrote: post #4

I dont understand what the use case is for this. If I have a front end, I would hope that the formated response is what were caching. Be that HTML or JSON. If I cant read from that cache then I should be reading from fresh data all together? right?

What if it's a backend service that is not exposed to a frontend that receives html or Json. E.g a task that takes an id and a operation name and needs to fetch from the database a bunch of data to process.

You will add readyset between your backend and database in order to cache the data you fetch from db.

Re: Readyset: A MySQL and Postgres wire-compatible caching layer

#15

Post by giovannibonetti »

I imagine a good use case for this at its current stage would be for powering up a monitoring dashboard that runs ad-hoc queries against your operational DB. I've seen this situation in a previous Fintech company I worked at, where we had some people staring at dashboards all day long looking for issues in any of the subsystems.

Re: Readyset: A MySQL and Postgres wire-compatible caching layer

#16

Post by lukoktonos »

redwood wrote: post #2

Anyone successfully using? There are a few other services out there like PolyScale. It will be interesting to see if any of these introduce some form of write support over time

What do you mean by write support here? Readyset will apply writes via a replication stream from the upstream database.

Re: Readyset: A MySQL and Postgres wire-compatible caching layer

#17

Post by jitl »

marceloaltmann wrote: post #11
jitl wrote: post #9

Earlier quoted context omitted.

How do you invalidate your cache? Is it complicated? What about search queries with many filters? What about responses that are unique per user? What about common queries that are shared between multiple views, do you constantly re-run those as your response cache is invalidated?

Caches are never invalidated. Readyset uses CDC to receive updates from PostgreSQL/MySQL and update the cache entries. No invalidation required. The price you pay is eventually consistent data, which is already true if you use any async replication like readyset does.

That’s how ReadySet works, I’m asking the grandparent (rhetorically) how their own method of caching works for them

Re: Readyset: A MySQL and Postgres wire-compatible caching layer

#18

Post by jitl »

lukoktonos wrote: post #16
redwood wrote: post #2

Anyone successfully using? There are a few other services out there like PolyScale. It will be interesting to see if any of these introduce some form of write support over time

What do you mean by write support here? Readyset will apply writes via a replication stream from the upstream database.

I think they mean acting as a write-through cache. If you send writes to the cache and have the cache delegate those writes to the underlying DB you get consistent invalidation, and if the write-through cache is smart enough it can even be transactional with the underlying source of truth.

Re: Readyset: A MySQL and Postgres wire-compatible caching layer

#19

Post by marceloaltmann »

redwood wrote: post #2

Anyone successfully using? There are a few other services out there like PolyScale. It will be interesting to see if any of these introduce some form of write support over time

I found one case study on their blog - https://blog.readyset.io/medical-joyworks-improves-page-load...

> It will be interesting to see if any of these introduce some form of write support over time

Writes performed by your application in Readyset are automatically proxied(redirected) to your database.

Re: Readyset: A MySQL and Postgres wire-compatible caching layer

#20

Post by jitl »

qaq wrote: post #7

But the read side is already fairly trivial to scale with read replicas

Some queries might be too slow at p95 even on a read replica with no other clients. Those kinds of queries can benefit greatly from a materialized view, and incremental view maintenance as data changes.
Post reply on HN