一、背景

MyTopling 是基于  ToplingDB 的 MySQL，分叉自 MyRocks，ToplingDB 则分叉自 RocksDB，兼容 RocksDB 接口，从而  MyTopling 可以复用 MyRocks 的大部分成果。

ToplingDB 和  MyTopling 目前都已经开源。

ToplingDB 的一个重要功能是  分布式 Compact( 文档)，去年我们实现了  托管 Todis 的 分布式 Compact 支持。同样是基于 ToplingDB，分布式 Compact 自然也是 MyTopling 的重要功能。

系列文章： MyTopling 分布式 Compact（一）：从多线程到多进程

系列文章： MyTopling 分布式 Compact（二）：CompactionFilter

二、PropertiesCollector 介绍

在稍微复杂点的 RocksDB 应用中，都少不了使用  CompactionFilter，相对而言，PropertiesCollector 比 CompactionFilter 露脸的机会要少一些。

在 MyRocks 中，PropertiesCollector 的具体实现是 Rdb_tbl_prop_coll，用来在 Flush/Compact 过程中来收集 SST 的统计信息， MyTopling 通过 ToplingDB 的 Web 可视化系统对此信息可视化如下：

原版 MyRocks 未保存 name 字段，这里的 name 字段是 MyTopling 新增的，我们为此还向 MyRocks 提交了一个 Pull Request:  properties_collector: (un)materialize: add missing m_name。

这个文件所属的 table 是 TPCC 的  bmsql_stock ，其主键是联合键  (s_w_id, s_i_id)，上图中的 distinct per prefix 就是在该 SST 文件中，该  index_id=2170(对应 bmsql_stock) 的 cardinality，即  s_w_id 只有 2 个不同的值，而  (s_w_id, s_i_id) 联合键有 31003 个不同的值（与总行数 rows 相同）。

CREATE TABLE `bmsql_stock` (
  `s_w_id` int NOT NULL,
  `s_i_id` int NOT NULL,
  `s_quantity` int DEFAULT NULL,
  `s_ytd` int DEFAULT NULL,
  `s_order_cnt` int DEFAULT NULL,
  `s_remote_cnt` int DEFAULT NULL,
  `s_data` varchar(50) DEFAULT NULL,
  `s_dist_01` char(24) DEFAULT NULL,
  `s_dist_02` char(24) DEFAULT NULL,
  `s_dist_03` char(24) DEFAULT NULL,
  `s_dist_04` char(24) DEFAULT NULL,
  `s_dist_05` char(24) DEFAULT NULL,
  `s_dist_06` char(24) DEFAULT NULL,
  `s_dist_07` char(24) DEFAULT NULL,
  `s_dist_08` char(24) DEFAULT NULL,
  `s_dist_09` char(24) DEFAULT NULL,
  `s_dist_10` char(24) DEFAULT NULL,
  PRIMARY KEY (`s_w_id`,`s_i_id`));

所以，和 Rdb_compact_filter 一样，Rdb_tbl_prop_coll 在执行过程中也需要访问数据字典。

三、Rdb_tbl_prop_coll 怎么支持分布式 Compact

原版 RocksDB 也有跟 ToplingDB 分布式 Compact 类似的东西，叫做  RemoteCompaction(Experimental)，不支持插件化的 PropertiesCollector 。

ToplingDB 从一开始就通过  SidePlugin 来管理所有的 DB 配置信息，PropertiesCollector 就是其中之一，所以，在 MyTopling 中，我们只需要修改一点代码，将 Rdb_tbl_prop_coll_factory 和相应的序列化方法注册到 SidePlugin 体系即可，在  MyTopling 分布式 Compact（二）：CompactionFilter 中我们以 CompactionFilter 为例，在架构上对此进行了详细阐述。在 Rdb_tbl_prop_coll 这里，我们深入一点细节，对整个流程进行一个梳理：

在 DB 结点上，Rdb_tbl_prop_coll 通过指针直接访问 ddl_manager 全局变量，在 Compact Worker 结点，脱离了 DB，没有相应的 ddl_manager(该全局对象仍然存在，但是个无效对象)。

我们对代码的修改方式依然是“ 微创手术法”，在 MyRocks 内部接口上，关键修改非常微小：

原本 MyRocks 辗转将全局变量  ddl_manager 的地址传给 Rdb_tbl_prop_coll，然后在 compact 过程中调用 m_ddl_manager->safe_find，MyTopling 在此处改为调用  m_find_key_def：

当然，麻烦的地方肯定不在这里，而是在 Compact Worker 结点上， find_key_def 怎么工作，整个 Rdb_tbl_prop_coll 又怎么“虚拟化”成象是在 DB 上一样执行的。

首先，Rdb_tbl_prop_coll_factory_SerDe 的准备工作：

DeSerialize 和 Serialize 执行的操作相对应，在 Compact Worker 上：

在 DB 上，DeSerialize 是在 Compact 即将结束时调用：

这其中每个环节都非常简单，甚至简单到“ 明显没有 Bug”。

其中的 DEBG 和 TRAC 都是最开始一股脑从  Todis 中的 CompactionFilter  拷过来的，实际上从未开启过。

上面有两个函数  write_key_def_rng， read_key_def_all，这是是 MyTopling 为支持分布式 Compact 中传输数据字典而新增的，这里面的代码就不是那么“ 明显没有 Bug”了。好在使用了  topling-zip 中的序列化框架，使得代码简洁清晰了很多，Rdb_tbl_prop_coll_factory_SerDe 的 Serialize/DeSerialize 也用到了该序列化框架。