maria-discuss team mailing list archive

[MARK CALLAGHAN <mdcallag@xxxxxxxxx>]

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