41–50 of 59 posts
> 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...
Earlier quoted context omitted.
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).
Earlier quoted context omitted.
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?
https://people.csail.mit.edu/malte/pub/papers/2019-hotos-mul...
> 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...
And finally, ReadySet's (Noria's) big innovation is that the result set can be only partial, storing only the elements of the result set (and underlying data flow graph) that are frequently accessed, instead of the whole result set like a materialized view would.
If you release something new, you should make sure that your documentation contains useful information. Even the most fundamental information like available configuration options, command-line arguments, deployment information and so on is missing. Looking at the code it appears that you need Consul, Zookeeper and Redis to make this fly and the docs don't mention this anywhere. They (barely) explain how to run the SQ…
> need Consul, Zookeeper and Redis to make this fly
A hard dependency on 3 key value stores?
Great that someone is productionalizing this!
Btw, is Jon involved in ReadySet?
[1] Partial State in Dataflow-Based Materialized Views - https://github.com/mit-pdos/noria
If you release something new, you should make sure that your documentation contains useful information. Even the most fundamental information like available configuration options, command-line arguments, deployment information and so on is missing. Looking at the code it appears that you need Consul, Zookeeper and Redis to make this fly and the docs don't mention this anywhere. They (barely) explain how to run the SQ…
From the blog post "Rather than forcing developers to switch to a key-value store"... > need Consul, Zookeeper and Redis to make this fly A hard dependency on 3 key value stores?
That part of the blog post refers to ReadySet having a SQL interface, rather than a key-value one.
If you release something new, you should make sure that your documentation contains useful information. Even the most fundamental information like available configuration options, command-line arguments, deployment information and so on is missing. Looking at the code it appears that you need Consul, Zookeeper and Redis to make this fly and the docs don't mention this anywhere. They (barely) explain how to run the SQ…
From the blog post "Rather than forcing developers to switch to a key-value store"... > need Consul, Zookeeper and Redis to make this fly A hard dependency on 3 key value stores?
This looks really nice. I was reading about this and realized it had similar ideas to this [1] Phd thesis from Jon Gjengset. I checked his twitter [2] and it was based on his work indeed. Great that someone is productionalizing this! Btw, is Jon involved in ReadySet? [1] Partial State in Dataflow-Based Materialized Views - https://github.com/mit-pdos/noria [2] https://twitter.com/jonhoo/status/1537474261689872384
https://twitter.com/jonhoo/status/1511401461669720068 https://readyset.io/blog/introducing-readyset
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 -…
It's not. Materialize (my employer) incrementally maintains views too, using tech (Differential Dataflow) that has existed for almost 10 years: https://cs.stanford.edu/~matei/courses/2015/6.S897/readings/... .
ReadySet is based on Noria (Jon Gjengset's Ph.D thesis, explained for non-experts here: https://jon.thesquareplanet.com/noria-in-simpler-terms.pdf).
Taking a research project and making it into a production-ready product is hard work -- congrats to the ReadySet team on the launch, and best of luck!