A-A+

TenDB单表并行恢复方案评测

2014年01月23日 TenDB 暂无评论

【概述】

本周分别在Z3和A5两台机器,对xxx_china_gd1.postal这张112G大表进行拆分恢复试验。期望通过并发恢复大表,提升大表恢复性能。观察并发导入引起的附加变化是否满足业务需求,进而对TenDB的tmysqldump增加单表并行恢复功能的可行性进行评估。

【背景】

目前xxx广东一区最大的两个表:postal表112G & charac_action_point表71G。TenDB1.4已经支持多线程并发导入多个表,但单表导入依然是在一个线程中进行。当单表数据量巨大时,恢复时间依然较长,不能很好地满足业务需求。

由此,TenDB开发团队希望在现有粗粒度(表级)并发导入的基础上,增加对大数据量单表拆分并发导入的更细粒度控制功能。

【评测维度】

  1. 分片规则如何制定才能最大化收益? -- 收益即恢复速度提升的百分比
  2. 分片导入后单表是否会发生数据不一致? -- 单线程恢复单表和多并发恢复,全表内容的checksum值应该一致
  3. 分片导入会带来物理存储的碎片化问题是否能容忍? -- 用checksum命令评估全表读性能
  4. 分片导入是否会导致ibd存储空间的浪费? -- 对比idb文件大小

【实验结果】

  • 并发粒度越大,恢复时间越短,收益越高。本次实验在Z3机12并发恢复时收益达到峰值,对比单线程恢复速度提升了81.83%。但当并发粒度大于CPU物理CORE数后,收益并未和并发数同比例上升。
  • 单表拆分后并发恢复,与单线程恢复校验值完全一致。
  • 产生的碎片在Z3机器上不会对读取造成影响;但在A5机器上会有一定性能损耗,全表read性能下降22.21%。
  • 单表拆分后并发恢复,引起的ibd文件增大程度均小于0.3%。

结论:按表拆分能极大地提高恢复性能。同时,在Z3上性能损耗几乎可以忽略;在A5上会带来一定的read性能损耗。

【预实现方案】

在目前tmysqldump基础上,增加2个参数实现单表拆分的并行恢复功能。

例如,调用以下命令可以将10G(含)以上的大表拆分成12份:

tmysqldump -uroot --gztab=/path/to/output --largetable_size=10G --split_count=12

  • -- gztab表示开启并行导出与恢复的功能,后两个选项只有在--gztab启用时才有效
  • -- largetable_size表示需要被拆分表大小的下限
  • -- split_count分片数,根据实验结果分析,分片数取CPU物理CORE数时,收益相对较好

【实验环境】

Z3机器:

  • IP: xxx.xxx.xxx.47
  • OS:Linux 2.6.16.60-0.21-TENCENT64-121128-VSL322 x86_64
  • CPU:2个物理封装,6个Core,24个逻辑Processor
  • Mem:64G

A5机器:

  • IP: xxx.xxx.xxx.40
  • OS:Linux 2.6.16.60-0.21-TENCENT64-120327 x86_64
  • CPU:1个物理封装,4个Core,4个逻辑Processor
  • Mem:32G

【实验内容】

分别在两台机器进行独立测试:

  • 根据CPU物理信息,在Z3机器上进行4组实验,分别是:1并发恢复/5并发恢复/12并发恢复/23并发恢复
  • 根据CPU物理信息,在A5机器上进行2组实验,分别是:1并发恢复/3并发恢复

wps_clip_image-3315
Z3机器
图片1

A5机器
图片2

原创文章,转载请注明: 转载自腾讯游戏DBA团队

本文链接地址: TenDB单表并行恢复方案评测

文章的脚注信息由WordPress的wp-posturl插件自动生成

Copyright © 腾讯游戏DBA团队 保留所有权利.  

用户登录

分享到: