Apollo数据项太大怎么迁移

前言

Apollo是携程开发的开源配置中心，支持分布式部署，是非常方便且受欢迎的。一般大多数使用都会作为应用服务的配置项，但也不排除🈶的公司存储一些业务数据，因为Apollo的设计导致数据库中Commit表，Release表变得非常大，注意这个大是指表中列非常大。在迁移时就较为困难

存储原理

聊聊Commit表
有了解他原理的朋友会知道Commit表是对项进行CUD操作时都会增加一条记录，每次都会增加一个ChangSets变化数据集，对于Properties的业务数据来讲，每次变更Apollo会认为你整个数据项都变化了，就会整体插入ChangeSets字段内

最头疼Release表
Apollo是以NameSpace为发布单元，这点不如Nacos了，所以每次发布都会增加Release的记录，以及ReleaseHistory和ReleaseMessage，Release的Configurations字段每次发布会包含整个Namespace的Properties，会转换为字典进行存储，这些Properties若是存放业务数据时可想而知Configurations字段会有多大。

迁移数据库

最难迁移的莫过于Commit与Release了，由于不合理的运用，字段数据量太大，严重影响查询性能，导致严重影响迁移效率，既然查询慢那我们是不是可以将每个namesce的最后一次的release进行迁移即可呢。

解决方案

当时我们在迁移时运维直接把全表进行迁移，发现每次都超时，再加上Apollo是我一手搭建的，对其原理还是较为熟悉的。
先看下图中实际生产中的数据

Commit表提交次数

Release表的发布次数

Oh, My God!!!，这么多次，再加上prop的value非常大，可层想有多少数据是大表，把历史记录进行迁移无非是浪费了时间以及磁盘的空间，这些数据完全不需要历史记录

对于Commit表只需要保留每个命名空间的最后一条快照即可，其他历史无需关心，
Release表同理。数据量最大的命名空间，提交次数也比较高，迁移时最麻烦的就是这个了。

下面附上迁移SQL
Commit表中有用的数据

SELECT
  *
FROM
  (
    SELECT
      id,
      ROW_NUMBER() OVER (
        PARTITION BY AppId,
        ClusterName,
        NamespaceName
        ORDER BY
          Id DESC
      ) AS row_num
    FROM
      `Commit`
  ) AS t
WHERE
  row_num = 1
LIMIT
  100

自行调整 limit ，根据Id主键查询指定数据在使用DataX等工具进行迁移 ，相信非常快的就搞定了

优化表

可以使用语句把表进行优化，直接删除row_num>1的即可，但由于数据量大，而且还有碎片问题，所以直接把有效数据复制临时表，再进行rename

CREATE TABLE `Commit_temp` LIKE `Commit`;
INSERT INTO `Commit_temp` SELECT * from `Commit` c 
WHERE id in (
	SELECT
	      id
	    FROM
	      (
	        SELECT
	          id,
	          ROW_NUMBER() OVER (
	            PARTITION BY AppId,
	            ClusterName,
	            NamespaceName
	            ORDER BY
	              Id DESC
	          ) AS row_num
	        FROM
	          `Commit`
	      ) AS t
	    WHERE
	      row_num = 1
);
RENAME TABLE `Commit` TO `Commit_backup`, `Commit_temp` TO `Commit`;
DROP TABLE `Commit_backup`;
ANALYZE TABLE `Commit`;

对于外键AppId可以使用定时任务定时清理历史数据，控制表的大小