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

ReadySet Core: next-generation SQL caching, freely available

readyset.io

Post reply on HN
Print view View original

31–40 of 59 posts

Re: ReadySet Core: next-generation SQL caching, freely available

#31

Post by freitasm »

Interesting. I would love to see this available for MS SQL Server.

I've played with Safepeak (1) which runs on Windows Server. It was sold later to an Israeli company (2), which have since gone out of business and assets ended up with another company and now sold as ScaleArc (3)

The original SafePeak is available free but no maintenance or anything, so not really production ready. It works, as tested in a test environment but eight years without support or updates...

(1) http://www.safepeak.org/ (2) https://en.wikipedia.org/wiki/SafePeak (3) https://www.devgraph.com/scalearc/

Re: ReadySet Core: next-generation SQL caching, freely available

#32

Post by jinjin2 »

marzoeva wrote: post #10
_jezell_ wrote: post #3

Earlier quoted context omitted.

When you care about perf a lot more than consistency

Hi! CEO of ReadySet here. You can think of ReadySet as being a cross between a traditional read replica and a custom caching layer (e.g. one you might build on top of Redis). With read replicas, you still rerun queries from scratch every time they're issued, which means you still have to think about things like query optimization. ReadySet caches frequently run queries in memory so you get super-fast query latencies…

How do you deal with security? In modern databases like MongoDB permissions are granular down to the field level.

The same query could produce wildly different result based on the user issuing them, and the caching somehow has to take that into account. Is that something you address?

Re: ReadySet Core: next-generation SQL caching, freely available

#34

Post by gst »

simonw wrote: post #23
jjice wrote: post #12

Earlier quoted context omitted.

From their README: > ReadySet is licensed under the BSL 1.1 license, converting to the open-source Apache 2.0 license after 4 years. The ReadySet team is hard at work getting the codebase ready to be hosted on Github.

Has anyone else done this thing with BSL for 4 years that then converts to Apache 2? I've not seen it before.

In addition to the other software already listed here Materialize does this too: https://github.com/MaterializeInc/materialize/blob/main/LICE...

Re: ReadySet Core: next-generation SQL caching, freely available

#35

Post by zasdffaa »

There are too many questions here. What does it not do? What's the overhead of monitoring the main DB and how's it done - triggers? Does it need schema changes? What about race conditions - can you guarantee none? What's the memory overhead you need for the cache? Can you control what gets cached?

> It can serve millions of reads per second on a single node ...

I'm not a network guy but that seems just astonishing - what is a 'node' here?

> ReadySet incrementally maintains result sets of SQL queries based on writes to the primary database.

So basically you've solved the general materialised view incremental update problem? That's an unsolved problem in general, surely?

Edit: not dissing but trying to see where the limits are.

Re: ReadySet Core: next-generation SQL caching, freely available

#36

Post by zasdffaa »

steve-chavez wrote: post #33

How does ReadySet interact with Row level security[1]? For RLS to work you'd need validation at the origin server anyway right? [1]: https://www.postgresql.org/docs/current/ddl-rowsecurity.html

Damn, that's a good question! Or security in general. But I wouldn't blame them at all if they didn't do it. Good thought though.

Re: ReadySet Core: next-generation SQL caching, freely available

#37

Post by trollied »

> ReadySet is a lightweight SQL caching engine that precomputes frequently-accessed query results and automatically keeps these results up-to-date over time as the underlying data in your database changes

I don't see the point in using an extra app - you can do this natively in Postgres. Materialized views. https://www.postgresql.org/docs/current/rules-materializedvi...

Re: ReadySet Core: next-generation SQL caching, freely available

#38

Post by trollied »

zasdffaa wrote: post #35

There are too many questions here. What does it not do? What's the overhead of monitoring the main DB and how's it done - triggers? Does it need schema changes? What about race conditions - can you guarantee none? What's the memory overhead you need for the cache? Can you control what gets cached? > It can serve millions of reads per second on a single node ... I'm not a network guy but that seems just astonishing -…

Oracle has had MVs that can refresh on update for decades.

Re: ReadySet Core: next-generation SQL caching, freely available

#39

Post by adwf »

trollied wrote: post #37

> ReadySet is a lightweight SQL caching engine that precomputes frequently-accessed query results and automatically keeps these results up-to-date over time as the underlying data in your database changes I don't see the point in using an extra app - you can do this natively in Postgres. Materialized views. https://www.postgresql.org/docs/current/rules-materializedvi...

Except then you need to be paying someone to monitor your queries and develop your views rather than just dropping a container in the middle with this app.

Re: ReadySet Core: next-generation SQL caching, freely available

#40

Post by zasdffaa »

trollied wrote: post #38
zasdffaa wrote: post #35

There are too many questions here. What does it not do? What's the overhead of monitoring the main DB and how's it done - triggers? Does it need schema changes? What about race conditions - can you guarantee none? What's the memory overhead you need for the cache? Can you control what gets cached? > It can serve millions of reads per second on a single node ... I'm not a network guy but that seems just astonishing -…

Oracle has had MVs that can refresh on update for decades.

So does Pgres & mssql, but general views that are incrementally updated - that's another matter. I'd be very surprised (and pleased).
Post reply on HN