MyRocks now supports group commit and XA -
On Wed, Oct 12, 2016 at 9:25 AM, 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
> 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.
> 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/
> 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/
> 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>
>> 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
>>> 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 : email@example.com
>> Unsubscribe : https://launchpad.net/~maria-discuss
>> More help : https://help.launchpad.net/ListHelp
> Mark Callaghan
Mailing list: https://launchpad.net/~maria-discuss
Post to : firstname.lastname@example.org
Unsubscribe : https://launchpad.net/~maria-discuss
More help : https://help.launchpad.net/ListHelp