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 SQL proxy on a local machine but thats it.
I wonder if the testimonials on your website are just pulled from thin air, I don't think any sane person would even experiment with this anywhere near production environments.
Hey, PM @ ReadySet - fair points, and thanks for checking us out.
We've been in pretty heavy development and have been heads down on getting ReadySet into your hands as quickly as we could. We'll be doing a major documentation pass soon which will have more info about clustering, etc.
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.
CREATE MATERIALIZED VIEW rental_by_category
AS
SELECT c.name AS category,
sum(p.amount) AS total_sales
FROM (((((payment p
JOIN rental r ON ((p.rental_id = r.rental_id)))
JOIN inventory i ON ((r.inventory_id = i.inventory_id)))
JOIN film f ON ((i.film_id <> f.film_id))) -- tweak
JOIN film_category fc ON ((f.film_id = fc.film_id)))
JOIN category c ON ((fc.category_id < c.category_id))) -- tweak
GROUP BY c.name
HAVING sum(p.amount) NOT IN (196, 203, 791) -- tweak
ORDER BY sum(p.amount) DESC
It can materialise and efficiently (read: incrementally) maintain the result set of that??
I believe the non-equijoin will cause problems for Materialize today (I don’t work on our optimizer team, so I’m not 100% sure and don’t take this as authoritative). We might turn that into a cross join followed by a filter.
I will answer that for sure later today when I’m back at my desk.
If you changed that back to an equals sign, yes, we could incrementally maintain your query.
I originally had added the HAVING clause to nastify it further, because this would cause values to appear and disappear, so to handle that you (probably?) have to materialise the entire result of the GROUP BY before applying a HAVING. Which is doable could cause some overhead.
I guess I could see it work for INSERT-only tables, with a lot of headache, but throw in UPDATE and DELETE and it could become awful.
Also we have to agree on what 'incrementally' means :)
Updates and deletes work fine, because Differential Dataflow stores everything as a (row, timestamp, cardinality) tuple. Materializes uses signed integers as its cardinality type. Thus deletes are modeled as (“the row”, t2, -1), which will cancel out with (“the row”, t1, +1), and thus nothing will be returned for that row when the view is queried at any time >= t2. Eventually compaction will cause these cancelled rows to be annihilated entirely and so there will be no lingering space impact.
I checked the plan. This will involve a cross join, and maintaining the entire result of the group by before the having (the former could possibly be avoided with some future work in Materialize to allow range queries; the latter is probably essential). Without your tweaks, the only required state is the join indexes.
I love the concept. Not needing to have extra code and logic for a caching layer seems very nice. In my experience, I haven't ever been in a situation where I needed super heavy caching, but this seems like it gives it to you "for free". Interested to see if we see more of ReadySet in the future.
Woah, I had the same idea not so long ago. Right now I'm using GraphCDN but would much rather cache at the database level. Looks like this could be a drop in for lots of people already on Postgres & MySQL (meaning no more dog-slow Rails apps).
As an alternative, you can use WunderGraph (oss) to compile GraphQL Queries to REST Endpoints so that you can use fastly or Cloudflare as a CDN (and the Browser Cache obviously): https://wundergraph.com/docs/overview/features/caching
It supports configurable Cache-Control Headers per Operation and comes with ETags out of the box, so content can be invalidated easily.
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...
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.
PolyScale [1] is a serverless plug-and-play database edge cache. Our goal is for devs to be able to scale reads globally in a few minutes. It’s wire compatible with Postgres, MySQL, MS SQL Server (more coming including no-sql).
It has a global edge network, so no infrastructure to deploy and AI managed cache and auto invalidation, so no cache configuration needed.
> 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
Postgres materialized views have to be manually refreshed on a schedule, and so are always out of date, whereas ReadySet keeps your results up to date automatically as the input changes. For PG materialized views, the compute required proportional to the size of the input data, and is paid every time, whereas with ReadySet the computation is incremental, so it's proportional to the size of the change in the data over time.
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.
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.
I was just looking this up and it's correct, they don't cache queries (if they do, it's a separate feature), they only manage query planning in ways that make them faster.
Even CochroachDB doesn't do query cache, only query planning is cached. [0] [1]
Interesting. What would you say the use case is for this, rather than setting up read replicas? Not having to maintain routing to the replicas on the application side?
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 on cache hits. Because of this, you can scale to much higher read throughputs without extra effort. This is especially useful for read-heavy applications (e.g. websites, certain types of dashboards, among others!)
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?
Funnily enough, I wrote a paper on this topic when I was in grad school. It's not on our short-term roadmap at ReadySet, but this idea is certainly compatible with the underlying dataflow model. I'd love to hear more about what you had in mind here, shoot me an email at alana@readyset.io
I signed up for the waitlist! I noticed it asked about AWS, Azure, and GCP but we use Heroku. Hopefully, that won't put me too low on the list.
Do you have a sense for when people can try it? Most of our app is reads and we're using Rails + Redis and it's fine and sometimes a pain. Would love to try it.
> 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.
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 SQL proxy on a local machine but thats it.
I wonder if the testimonials on your website are just pulled from thin air, I don't think any sane person would even experiment with this anywhere near production environments.