企业级分布式数据库 TDSQL 元数据管控与集群调度( 四 ) _分布式数据库

文章插图

我们设立表内数据的概念，每个数据在物理层面都可以知道每个 Key 落在哪个 TDStore，但无法感知到它们属于哪个二级索引。对此我们需要建立关系去创建表，使得在创建表和索引时，MC 可以感知到每个 Key 在物理意义上属于哪个 TDStore，逻辑意义上属于哪些表的分区、属于哪些表的二级索引。
我们还引入了复制组的概念。在原始版本中，每个数据分片是一个复制组，现在则是将多个 Region 归属于一个复制组，通过管控体系架构的改变，将表数据和二级索引放在同一复制组里。这种做法的好处有两方面：一方面，业务中常常按照分区键来划分事务，一次性修改的数据非常大，可能只落在同一复制组里，这时需要进行多次网络交互才能完成一个分布式事务，优化后只需要一次落盘即可完成；另一方面的好处是计算下推，由于计算层可以感知到要写的主键、二级索引都在同一 TDStore 的同一复制组内，就可以提前将逻辑下推到存储层中完成。

文章插图

接下来解决的问题是表与表之间的亲和性。在部分系统中，以一定规则如哈希去分区的表结构中，在更新表 1 分区时，也会去访问表 2 的 1 分区。这就要求管控层必须理解表与表之间的概念。如果能感知到它们是在同一组事务里被操作的单位，就可以更好地改善事务的两阶段提交。
对此我们提供了一个扩展语法。假如用户有需求，可以去指定他所倾向的数据分布策略，为该策略命名，允许在该分布策略里再指定分区策略。如下图所示，当下面第三行创建表时，如果有两个表在业务场景中经常被访问，就可以将它们关联到同一 DP 组里，MC 会在后台创建表。所有的分布策略都会通过 MC 进行，MC 可以在后台将这些关联的表做背后的调度优化。这就为更多跨表之间的操作提供较多的可能性。

文章插图

Risk & Opportunity未来我们仍有许多挑战需要克服。首先是全局事务时间戳，目前 MC 承担许多的管控操作，后续我们计划将其设计成多进程模式，全局事务时间戳独占一个进程。其次是 Lieutenant 分流，我们计划增加副队长角色，分流部分网络。最后是数据亲和调度的利用也是我们未来会去重点攻坚的领域。