The MyRocks storage engine lacks the following features compared to InnoDB:
You should also consider the following:
latin1_bin) or binary collation should be used
VARCHAR indexed columns.
By default, MyRocks prevents creating indexes with non-binary collations
You can optionally use it by setting
(table names with regex format),
but non-binary covering indexes other than
german1) still require a primary key lookup
to return the
ORDER BY DESC or
ORDER BY ASC is slow.
This is because of “Prefix Key Encoding” feature in RocksDB.
See http://www.slideshare.net/matsunobu/myrocks-deep-dive/58 for details.
By default, ascending scan is faster and descending scan is slower.
If the “reverse column family” is configured,
then descending scan will be faster and ascending scan will be slower.
Note that InnoDB also imposes a cost
when the index is scanned in the opposite order.
MyRocks does not support operating as either a master or a slave in any replication topology that is not exclusively row-based. Statement-based and mixed-format binary logging is not supported. For more information, see Replication Formats.
When converting from large MyISAM/InnoDB tables, either by using the
INSERT INTO SELECT statements it’s recommended that you
check the Data loading documentation and
create MyRocks tables as below (in case the table is sufficiently big it will
cause the server to consume all the memory and then be terminated by the OOM
SET session sql_log_bin=0; SET session rocksdb_bulk_load=1; ALTER TABLE large_myisam_table ENGINE=RocksDB; SET session rocksdb_bulk_load=0; .. warning:: If you are loading large data without enabling :variable:`rocksdb_bulk_load` or :variable:`rocksdb_commit_in_the_middle`, please make sure transaction size is small enough. All modifications of the ongoing transactions are kept in memory.
For general inquiries, please send us your question and someone will contact you.