Large pages (64KB vs default 16KB) significantly improve the compression ratio with page compression, at the cost of inducing misalignment with the storage stack.

One of the best compromises is to configure InnoDB with 64KB pages, put it on ZFS with recordsize=64K, and enable zstd compression on ZFS. That leaves both compression and alignment to ZFS to take care of. Throughput and compression in that combination are both excellent, a much better compromise than myrocks IMVHO.



On Tue, 15 Aug 2023, 13:29 jocelyn fournier, <jocelyn.fournier@gmail.com> wrote:
Hi!

I confirm I was also my choice, the migration from TokuDB to InnoDB with row compression is a really good option.

BR,

> Le 15 août 2023 à 12:52, Gordan Bobic via discuss <discuss@lists.mariadb.org> a écrit :
>
> You may find that InnoDB with row compression and 64KB pages compares relatively favourably, if that is an option for you.
>
> On Tue, 15 Aug 2023, 11:44 pslawek83 via discuss, <discuss@lists.mariadb.org> wrote:
> Hi Guys, i'm looking for tokudb replacement and i'm again thinking about rocksdb. Is it mature enough to be used as an engine for statistical tables (several billions rows, around 2TB in size?).
> - Is it (will it be?) possible to have something like single-file-per-table (or single dir per table?)
> - Is it shared per all tables, so all tables are still using single set of files (can single crashed table/row lead to all tables being unusable?)
> - Will partitioning the table have performance benefits like with other engines? Can I do instant TRUNCATE PARTITION for easy data retention?
>
> Thanks
> _______________________________________________
> discuss mailing list -- discuss@lists.mariadb.org
> To unsubscribe send an email to discuss-leave@lists.mariadb.org
> _______________________________________________
> discuss mailing list -- discuss@lists.mariadb.org
> To unsubscribe send an email to discuss-leave@lists.mariadb.org