注意:以下文档只适用于TOP接口,请谨慎使用!

文档中心 > 基础技术

历史数据迁移方案

更新时间:2017/01/09 访问次数:13092

 1. 场景需求

在线上加密覆盖到全量用户后,接下去的一个重要步骤就是要把历史数据全量加密。

我们根据内部压测数据和案例经验总结出的RDS迁移方案和性能数据,以供参考。

 

2 方案介绍

2.1 数据迁移,准备:

1) 请确认代码逻辑已经做好明文和密文的兼容。

2) 确认加密开关已经打开。

3) 确认从RDS和TOP api新流入的数据已经是密文的。

 

2.2数据迁移建议方案

 在确认容错逻辑已完成后进行迁移。先进行少量客户迁移测试之后,可以进行全量迁移测试。

 1) 首先单个客户数据迁移测试:

借用迁移1个客户的机会测试迁移方案。建议迁移量<100万。可以先从较低的并发数开始。例如:并发5- 10个线程。(可以根据上面压测数据自选)

提前记录平时的性能;

记录迁移期间再记录迁移时间、迁移过程中的IOPS/连接/CPU/TPS/QPS等,和平时的性能做比较。

 2) 迁移方案

  根据前期计算好的迁移速度,计算迁移时间和方案。

 首先确定迁移的最小粒度:例如,独立部署的ISV,则可决定一个部署为一个最小粒度。兼顾功能的独立性,以及迁移的总时长(控制在3个小时以内)。

 第一天进行迁移时,继续记录数据量、时间……等。

如果迁移过程顺利无问题、且性能负载可以承受,可以在之后逐渐增加线程数。

之后,可在第一天的基础上逐步增加线程数和迁移并发数。注意持续监测数据库性能。直至迁移完成。

 3) 代码逻辑注意:

• 请注意:仅当用户Session有效的,或者过期不超过90天,并且用户状态没有过期才能拉取到密钥。

在迁移过程中,请排除已经过期超过90天和无效的用户(即:冻结、清退等)

否则造成大量失败的密钥请求,且加密失败。

• 从数据库中拉取用户数据并加密的时候,请注意控制分页大小。

 

 2.3 数据迁移,关键数据参考:

目标:根据数据库大小、数据库和应用架构以及选择的数据库性能,推荐ISV适当的数据迁移方案。

 资料和数据:

RDS推送数据库性能:http://cloud.tmall.com/rdsSelection.htm

 

上图为数据库配置列表。我们内部压测选择了红框中的4种RDS配置做了测试。测试结果见下一节。

 

压测结果:


1) 中型数据库(IOPS = 1200)压测:采用4台机器,做了三个测试,分别启用了10个、15个和25个线程,迁移数据200w,迁移耗时和迁移过程中的性能分别如下:

 

数据迁移时间:

 

机器数

线程数

数据量

时间

测试1

4

10

200w

31min

测试2

4

15

200w

19 min

测试3

4

25

200w

13 min

 

迁移性能:

 

机器数

线程数

IOPS

活跃连接数

CPU峰值

平均每秒事务数(TPS) (峰值)

每秒SQL数 (QPS) (峰值)

测试1

4

10

27

20

12%

3000

4500

测试2

4

15

40

45

20%

5500

7500

测试3

4

25

40

75

32%

7500

10000

 

 2) 大型数据库(IOPS = 3000)压测:采用4台机器,做了三个测试,分别启用了10个、15个和25个线程,迁移数据200w,迁移耗时和迁移过程中的性能分别如下:

 

数据迁移时间:

 

机器数

线程数

数据量

时间

测试1

4

10

200w

31 min

测试2

4

15

200w

19 min

测试3

4

25

200w

13 min

 

迁移性能:

 

机器数

线程数

IOPS

活跃连接数

CPU峰值

平均每秒事务数(TPS) (峰值)

每秒SQL数 (QPS) (峰值)

测试1

4

10

30

20

10%

3300

4500

测试2

4

15

40

45

18%

6000

7500

测试3

4

25

112

60

27%

8000

11000

 

注意:数据库IOPS性能消耗较低,因为数据库本身含有缓存缓写逻辑。

因此,不同IOPS性能的数据库最终迁移时长区别不大。

 

FAQ

关于此文档暂时还没有FAQ
返回
顶部