maria-discuss team mailing list archive

[Rich Prohaska <prohaska7@xxxxxxxxx>]

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@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
>
>