Readit Newsmarceloaltmann commented on 450× Faster Joins with Index Condition Pushdown readyset.io/blog/optimizi... · Posted by u/marceloaltmann
Straddled joins were still a bottleneck in Readyset even after switching to hash joins. By integrating Index Condition Pushdown into the execution path, we eliminated the inefficiency and achieved up to 450× speedups.
marceloaltmann commented on A Brief History of MySQL Replication altmannmarcelo.medium.com... · Posted by u/marceloaltmann
Replication has been one of MySQL’s most powerful and relied-upon features since the early days — long before it had things like foreign keys or even subqueries. It’s one of the foundational pillars that made MySQL suitable for large-scale, production use. This blog post walks through how replication evolved over time, and why it remains one of the strongest features in the MySQL ecosystem.
The Beginning (MySQL 3.23 — early 2000s) MySQL introduced statement-based replication (SBR) in version 3.23.15 in May 2000. This was a major milestone: it allowed users to replicate changes from one server (the source, previously called master) to others (replicas, previously slaves) by logging SQL statements executed on the source and replaying them on replicas.
This might be good tech and a good company.
Once we used a distributed caching system in a startup which was open source. Then the open source version got cut features we needed, so we bought a license. Then the startup was bought up by a large software company and the license costs went 10x YoY with a one week notice. As our migration away from this tech was not done, because it was very complicated and tied into our application we had to pay. Luckily we also had been bought and the very large costs were not a problem. I would never again use something from a company that is crucial to our operations.
That is a good point on the application changes.
What is appealing from Readyset is that it does not require you to change your application code. You can just change your database connection string to point to it and it will start to proxy your queries to your database. From there you can choose what you want to cache, and everything else (writes, non supported queries, non cached read queries) will be automatically proxied to your database.
On top of that, quoting @martypitt reply:
> Most commonly the restrictions prevent you from launching a competing offering. In their case, you can't offer database-as-a-service using their code.
Meaning the self hosted version is free to use in any number of servers having in mind the competing offering restriction.
What are some advantages to ReadySet versus read replicas from YugabyteDB or CockroachDB? A downside is that it appears to require a separate cloud subscription.
You can deploy on your own via their .deb packages - https://readyset.io/download
The advantages is that reading from a cache will be faster than from a read replicas. The benefits increase even further if you have to perform computation on the fetched data.
Would be curious if any RocksDB knowledgeable people have a different analysis.