maria-discuss team mailing list archive
Mailing list archive
Re: MariaDB Server 10.3 notes
The main reason to drop TokuDB would be it being redundant. If MyRocks
and TokuDB would cover, basically, the same use case and MyRocks
would've done it better - then nobody would need TokuDB, right?
But you're saying that they have different use cases and even on the
common use case, MyRocks is not necessarily better - do I understand you
correctly? In that case we should be interesed in keeping TokuDB in
MariaDB Server, not removing it.
It's true that in general it shouldn't matter for the end-user what the
storage engine is called as far it has more or less the same (needed)
features and delivers comparable performance (in the end it would be great
if we could have only one for all purposes and workloads :)).
But my concern is that at least currently publicly available Facebook
version has several limitations (
https://github.com/facebook/mysql-5.6/wiki/MyRocks-limitations ) which (for
me) would be problematic (for example no partitions, no online ddl and only
row based replication (the locking is also interesting)) and seems strange
since I would guess people (would) use theese engines mainly for compressing
large tables (at least in some cases I can't even go back to compressed
Innodb by how much the database size would inflate).
Myself have tested Rocks only as mongo-rocks in MongoDB environment but for
me as a user the features the engine has for Mysql seem subpar.
Obviously there are bunch of issues with Toku and in the future RocksDB
might get all the options people need - wanted to just share my opinion.