Hello All,Back in the day, I was one of the Tokudb developers @ Tokutek. Two of the features that I worked on were read free replication (RFR) and online schema change for Tokudb.RFR has some nice slave performance benefits by the replacing read modify write algorithm with a write algorithm. This works because the replication stream includes the before and after rows. IMO, this would be nice to have with Myrocks. There is a Mariadb push request for RFR that works with Tokudb that may be used as the API for this feature for other storage engines.Online schema change in Tokudb only injects 'schema change messages' into the top of the fractal tree. This is very fast. The actual change in the encoded row format occurs much later when these messages are executed on the leaf nodes. This seems nice to me, but it can be replaced with other online schema change packages. It would be nice to compare these various method WRT to performance.Tokudb also supports large transactions defined as transactions that effect a large number of rows such that the memory footprint of the undo log for these operations spills to external storage. Personally, I don't like large transactions, and believe that they should be avoided. However, some people do use them, and the mysql server should be able to support them without crashing, perhaps with degraded performance.On Wed, Oct 12, 2016 at 12:25 PM, MARK CALLAGHAN <mdcallag@gmail.com> wrote:0) Sergei and Justin - I prefer to avoid the "Monty says" game either for or against. We are trying to establish a community here. He is one of many. His reputation (good or bad) shouldn't be a stick that is deployed to win arguments.
1) RocksDB has persistent snapshots. That would make flashback trivial to implement for MyRocks assuming you took snapshots ahead of time. So maybe that isn't flashing back.
http://rocksdb.org/blog/2015/11/10/use-checkpoints-for-effic ient-snapshots.html
2) I expect almost everyone to choose MyRocks given a choice between MyRocks and TokuDB. I have evaluated TokuDB over several years. I have many performance and efficiency results from this year that I have yet to publish. Results are almost always much better with MyRocks, we have more resources dedicated to MyRocks so it will improve quickly.
MariaDB is a community project, so if someone maintains TokuDB I assume it will be included in MariaDB. But I think time is better spent on MyRocks. Our docs need to be updated and our communication needs to be better. But we move fast and Yoshi has been updating the limitations wiki page as I write this (https://github.com/facebook/mysql-5.6/wiki/MyRocks-limitati ).ons
I am not surprised that there are so few performance results published for TokuDB. And when they are published they are almost always for trivial workloads -- like insert-only insert benchmark. Try adding queries concurrent with the inserts.
3) Partitioning via the partition storage engine is supported for MyRocks. My employer doesn't need it for the initial deployment. It might be needed elsewhere and I am sure the community needs it. I assume we also need native partitioning in MyRocks when we move up to MySQL 8. The limitations page is getting updated to explain this.
4) By default the FB MySQL branch doesn't allow mysqld to start if MyRocks and InnoDB are enabled. This was misinterpreted to mean it wasn't possible to use MyRocks and InnoDB at the same time. It is possible now. And MariaDB/Percona are free to always allow both to be enabled. It was previously prevented in the FB MySQL repo because of fear that internal users might try to do a transaction that spans engines. I think that is a bad idea and XA scares me. I assume evaluations for MariaDB Server and Percona Server require that both InnoDB and MyRocks are enabled concurrently. See https://github.com/facebook/mysql-5.6/issues/106
5) We have work in progress to support XA for MyRocks. Code has been merged. Perf tests are in progress.
6) We have work in progress to support online DDL.
7) MyRocks supports read-committed (RC) and repeatable-read (RR). RR in MyRocks is Postgres-style and I assume that it won't get much use, just like i assume it doesn't in Postgres. If we add gap-locking to MyRocks RR then it will match InnoDB. For details see https://github.com/mdcallag/mytools/wiki/Cursor-Isolatio n
8) I am a long time user of SBR and think that RBR is the future. MyRocks needs RBR because we expect most deployments to use it with read-committed and just like InnoDB, that needs RBR. If gap locking is added to MyRocks RR then SBR is feasible, but you give up all of the great new replication features that will be RBR only. http://dba.stackexchange.com/questions/101122/mysql- why-statement-based-binlog- format-cannot-work-with- innodb-read-uncommitte
9) MyRocks could do transportable column family for all indexes/tables in a column family. Transportable is a nice feature but I don't think the lack of it is a big deal. It is part of being storage efficient, but the overall storage efficiency story is much stronger for MyRocks than InnoDB.
10) I hope there is a plan for foreign key and spatial in MyRocks. There isn't one yet. I don't think full text in any MySQL engine is a good use of time given how infrequently it is used.--On Wed, Oct 12, 2016 at 8:39 AM, Reindl Harald <h.reindl@thelounge.net> wrote:
Am 12.10.2016 um 17:34 schrieb Justin Swanhart:
When upgrading from 5.0 -> 5.1 the sort order of some german characters
was modified, which meant indexes had to be rebuilt (they are in sorted
order after all). The mysql_upgrade would suggest a table rebuild
(ALTER TABLE xyz ENGINE=INNODB) or dump/restore for every affected
table. I was a consultant during this time, and I can't tell you how
many tables I had to rebuild. Thousands to say the least. Yuck.
well, a five-liner in PHP using a root account while UTF8_GENERAL_CI was the wrong charset/collation anyways for german umlauts :-)
On Wed, Oct 12, 2016 at 10:01 AM, Reindl Harald <h.reindl@thelounge.net
<mailto:h.reindl@thelounge.net>> wrote:
Am 12.10.2016 um 15:53 schrieb Justin Swanhart:
Also having to dump/restore to go from 10.2 to 10.3 tables is a PITA
it's a simple no-go and the answer to "should i use postgre or
mysql/mariadb" is always "stay away from postgre, while it got
better you need to dump your data and import them again still way
too often while our mysql tables where created 2002 and now running
on MariaDB 10 without doing such a bullshit a single time"
Remember how awful it was to migrate all those BDB tables to
InnoDB? Or
even just how frustrating it was when UTF8_GENERAL_CI changed
the umlaut?
when did something change umlauts?
as charsets where introdcued with MySQL 5.0 it was a simple script
just to add the correct charset information that it is *not* UTF8 to
5000 tables with not a single char damaged and since we are located
in austria üöäß are very common
_______________________________________________
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help : https://help.launchpad.net/ListHelp
Mark Callaghan
mdcallag@gmail.com
_______________________________________________
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help : https://help.launchpad.net/ListHelp