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可以使用定时任务定时清理历史数据,控制表的大小
本文来自博客园,作者:流年灬似氺,转载请注明原文链接:https://www.cnblogs.com/lic0914/p/migration-bigdata-in-apollo.html