数据库水平拆分复盘小结

最新推荐文章于 2024-10-05 12:07:50 发布

weiweiracings

最新推荐文章于 2024-10-05 12:07:50 发布

阅读量465

点赞数

文章标签： java mysql 数据库

本文链接：https://blog.csdn.net/weiweiracings/article/details/121532625

版权

最近完成了一张近亿数据的拆分，其中遇到了一些问题，值得记录并改进。

交互调整

被拆分的是一张结算交易表。根据其基本特性，决定对其按创建年份拆分。由于数据在创建后会有大量更新，所以无法使用ES技术进行跨年搜索。和业务协商后，可以对现有业务做一定调整——将分页查询需求控制在单个年份内。在这里插入图片描述
在交互上做出一定微调后，用户仍可以正常查询历史年份数据数据。只是查询体验有一定变动。

数据层改写

由于被拆分的表上有两个同时被业务使用的主键。评估使用shardingsphere中间件处理有一定难度，决定还是通过代码改造原有的数据层。这种方案的优点是灵活，也相对简单。缺点是无法推广到其他系统中。
表上的两个主键一个交易编号中直接含有年份数据，故可以很方便的检索到分表。另一个主键则是单调自增的ID，为了优化他的相关查询，还需要维护一张ID和年份对应关系的表，方便快速定位分表。
一些统计类的SQL，原先是全表遍历实现的。那么改写后将有程序数据层完成遍历。
总的来说数据层改写相对直接和简单。

数据迁移

出于降低业务稳定性考虑，水平拆分任务不能长时间停服。所以就必须面对水平拆分后的数据如何初始化，初始化后如何与和主表保持一致的问题。
数据初始化如果使用SQL批量插入，由于数据量大，瞬时造成的数据库压力会过高，故被否决。实际是选择了相对灵活的python脚本来完成数据初始。

cursor.execute("insert ignore Trade_" + year + " select * from Trade where id >=" + str(j) + " and id <" + str(i) +
               " and timeCreated >= '" + yearStart + "'" + "and timeCreated < '" + nextYearStart + "'")

数据初始化离最终上线还有一段时间，这个时间内数据仍在不停的插入和更新。依靠批量脚本无法满足数据同步的要求。需要一个相对实时的同步方式。
最初我们选择的是基于debezium来同步的mysql binlog。使用kafka接收binlog来处理数据的变更，但线上实用后，同步任务总是不明原因崩溃，由于项目时间紧，只能被迫放弃此方案。
备用方案是在原有的老数据层上发出MQ消息，携带变更的ID来通知数据变更，接收到消息后驱动分表数据更新。这个方案会侵入原有的业务代码，但老数据dao层后续将废弃，也不会造成太大影响。实际使用中，通过MQ监听数据变更最大的问题是，MQ往往太快了，数据层的事务在未真正提交时就已经开始处理。这造成监听程序获得数据并非最新的数据。

if (TransactionSynchronizationManager.isSynchronizationActive()) {
          TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() {
              @Override
              public void afterCommit() {
                  try {
                      historyTradeDaoDispatcher.sendMsg(String.valueOf(id));
                  } catch (IOException e) {
                      LOGGER.error("HISTORY_MQ_EX ", e);
                  }
              }
          });
      }