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等工具进行迁移 ，相信非常快的就搞定了

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