关于数据库sharding带来的聚合问题

 

当前我们的 oracle 数据库架构如下：

 

 

如上图所示整个数据库按照 mapping 方案进行了水平 shard （三个核心）以及一个汇总数据库（平台），然后在每一个大表上又进行了垂直 shard （按照数据热度）。无论是垂直切分的数据迁移还是核心到平台的归档数据迁移都是通过数据库的定时任务以及存储过程完成（核心到平台用到了 DBLink ）。

 

这种架构虽然带来了很大的灵活性，但同时也给系统带来了很多的复杂性、不可预知性、维护难等缺点。

 

出现的问题：

       对外的应用会定时将平台 DB 的汇总数据通过 FTP 发往其他应用（强约束：必须在早晨 6 点前发送结果），现在就发现这些 FTP 文件并没有生成。

 

分析原因有以下两点：

1．  从核心归档到平台的定时 job 经常无缘无故的停掉，导致核心数据无法按时迁移到平台，初步怀疑是 DBLink 的 bug 导致。

2．  平台的暖表到冷表的数据迁移因为存在很多处理逻辑，消耗时间过长。

 

其实对于数据库的高级复制、定时任务、存储过程等都是由我们专门的 dba 来完成的，我在这方面比较没有发言权，所以我只从应用的角度看如何来解决这个问题。

 

核心到平台的数据归档迁移完没完成我不 care ，我认为的本质问题是 ftp 文件没有生成，所以我就解决这个问题。所有的平台汇总数据在核心 DB 都是已经存在的，只不过核心的数据没有归档到平台而已，因此为了不改变对外的接口，我觉得可以通过如下手段来解决。

 

 

应用将核心表数据的变化提交到核心数据库后，需要发送一个数据变化事件到数据集成模块，然后由数据集成模块来处理事件数据的整合以及定时 ftp 文件发送。

 

这样做的好处就是独立一个模块来处理对外的数据接口，不需要对数据库的归档和迁移脚本作任何处理,以及良好的扩展性,在需要的时候可以增加平台数据更新管道更新平台数据库数据来替换核心到平台归档过程。

 

这种做法同样也有缺点，就是需要对原有应用代码进行侵入来发送数据变更事件。

 

其实我个人觉得数据库已经这样架构了，再想做什么改进已经很困难了，前段时间一直在研究 Command/Query Separation （ CQS ），其实我觉得我们当前的应用很适合用 CQS 来架构。水平 shard 保持不变，通过事件来更新平台数据库，不过可能并不是严格的数据库读写分离。