maria-discuss team mailing list archive

[Justin Swanhart <greenlion@xxxxxxxxx>]

"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 <mdcallag@xxxxxxxxx> 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.reindl@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx
>>> <mailto:h.reindl@xxxxxxxxxxxxx>> 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@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~maria-discuss
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> -- 
> Mark Callaghan
> mdcallag@xxxxxxxxx
> _______________________________________________
> Mailing list: https://launchpad.net/~maria-discuss
> Post to     : maria-discuss@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~maria-discuss
> More help   : https://help.launchpad.net/ListHelp