Having said this, the paper itself (in the original link) under Section 4 "Evaluation" describes the differences in more detail, and Figure 6 probably does the best job of showing Jungle benefits in a compact human-readable line of charts.
If I'm reading the paper correctly, and as summarized on slide 16, using the combination of CoW B+ and LSM means that instead of a 3-way tradeoff between Read/Write/Space, Jungle can minimize the cost trade-off such that the only remaining material trade-off is Write/Space.
Pretty cool stuff.
Maybe three colors for the bars.
I think this :) I also had to look more closely a few times.
Very recently timescaledb did some really really interesting stuff with compressing tables, and I’m wondering if that is useable with non-time-series data too etc?
I’m a heavy tokudb user because of the compression and I’m looking forward to seeing if a b+ lsm with compression is going to turn up in MySQL or even better Postgres.
Postgres has slowly grown some ... tolerance ... for alternative storage engines, via federation and forks like greenplum and timescaledb that put their own engines in, but they are always feeling like second class citizens and hitting integration limits.
I got the impression that TokuDB is pretty much dead. Hasn't Percona stopped updating TokuDB and is focusing on MyRocks instead?
Tokudb runs rings around myrocks. Particularly, it has better read/write perf and much better compression.
But it will disappear by MySQL 9. Tokudb died because it wasn’t widely adopted nor sponsored, not because it was worse tech.
I think the recent timescaledb stuff about compression is really promising. I hope Postgres moves towards built-in compression rather than telling people the fs should do it.