mysql 存储引擎 压缩_MySQL不同的引擎在成本、压缩、性能比较如何？

说点别的。

正在尝试将集成了 terark 压缩技术的 RocksDB 用于 MySQL 存储引擎，碰到一个MyRocks(mysql 的rocksdb适配层) 实现的问题：

MyRocks 自定义了 Key 的 Comparator ： rdb_comparator.h，本质上讲，它这两个 comparator 完全是画蛇添足，Rdb_pk_comparator 就是 bytewise comparator，完全等价于默认的 comparator，而 Rdb_rev_comparator 只是 Rdb_pk_comparator 的翻转。

因为 rocksdb 的 iterator 是双向的，Rdb_rev_comparator 的作用只是相当于把 iterator 反过来，所以，这两个 comparator 对功能的实现没有任何帮助，只是平白无故地增加了概念上的复杂性。这严重违反了软件工程中“接口最小化”原则(比较一下std::sort，只需要 “ < ” 操作)。这对 rocksdb 内置的各种 memtable, sstable 可能并没有什么影响，但是对于一个第三方的 memtable 或 sstable，比如我们的 TerarkZipTable，就是一个大的问题：

本来，我们只支持默认的 comparator： bytewise comparator，因为 bytewise comparator 可以非常自然地兼容各种优化的索引，比如 terark 的压缩索引。现在，我们必须象吃苍蝇一样，去支持这个毫无用处的 reverse bytewise comparator。

还好，这不是最坏的结果。之前预料的最坏的结果是：如果这个 comparator 是按照 key schema 的定义，对数据进行比较。如果真这样，我们得自己参照 key schema，对 key 进行编码，以使得对编码后的 key，其 bytewise compare 等价于编码前的 compare，形式化一点就是：

对任意的 key1，key2，encode 应该使得：MySqlRocksCompare(key1, key2) == BytewiseCompare(encode(key1), encode(key2))

所以，我们还是应该感谢 Mysql rocks，这个 encode/decode 不用我们做了。

目前，我们的 mysql-on-terarkdb 已经可以基本稳定，大家可以试用。我们也在青云上提供了相应的云服务。