"Monty says it is trivial" is the oldest running joke in the community. I heard it in my first talk I attended, about adding data types to MySQL, a talk given by Brian Aker. :)
But ok. I'll try to be nicer. I really think community is important, and nobody should be a pariah, or a punching bag. Sent from my iPhone > On Oct 12, 2016, at 12:25 PM, MARK CALLAGHAN <mdcal...@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-efficient-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-limitations). > > 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-Isolation > > 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.rei...@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.rei...@thelounge.net >>> <mailto:h.rei...@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 > mdcal...@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
_______________________________________________ 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
