maria-discuss team mailing list archive

[MARK CALLAGHAN <mdcallag@xxxxxxxxx>]

MyRocks now supports group commit and XA -
https://github.com/facebook/mysql-5.6/issues/25

On Wed, Oct 12, 2016 at 9:25 AM, 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
>



-- 
Mark Callaghan
mdcallag@xxxxxxxxx