数据迁移到MySQL的性能测试
2023-03-14 22:26:48 时间
今天对一套环境的数据从SQL Server迁移到MySQL,中间涉及诸多的架构改进,我们主要说一下数据迁移的一些基本思路,以下是一个开始,会在后面不断的迭代改进一些方案。
整体来说,迁移的数据量听起来不是很多,大概是300G左右。
整体的步骤是:
1)数据从SQL Server导出为csv文件
2)数据流转到MySQL中间服务器上
因为文件较大,比如有的文件有几十G,单次导入会直接抛错,所以需要做下切分,比如按照1000万的数据维度切分。
3)数据切分
数据会被切分成相对规整的分片,比如按照1000万的基准,一个4亿数据量的文件会被切分为近40个500M的文件
4)因为切分后的文件太多,所以在导入前需要把这些任务划分为几个组
5)导入的时候,是按照并发进程的方式,因为数据库后端已经做了分片,所以就不需要调用是开启太多的线程了。
6)数据通过中间件导入,数据落盘在多个分片节点上,物理分片是4个,每个物理分片上有4个逻辑分片,即一共有16个逻辑分片。
数据流程图如下:
从目前的测试来看,如果是4个物理分片,通过中间件使用load data的方式,速度基本在80万每秒。和单机的20万相比,效率和性能是很明显的。
从目前的数据迁移来看,还是存在一些使用风险,一来转储数据为csv文件的时间较长,中间还涉及数据流转和数据切分,等到数据真正导入的时候,流量和性能的损耗已经很高了。
目前的测试,有些分片节点的负载高达30以上,算是充分利用了服务器资源。
按照目前的基本数据情况,导入近70亿数据需要2个小时左右,而这个过程还不包括中间环节的衔接和数据流转,实际的时间会在近5个小时,从数据迁移窗口来算,这个时间明显是不符合需求的,如果把时间控制在1个小时,有没有更好的方法?
相关文章
- 新一代国产 NewSQL 昆仑数据库的云上探索和压测表现
- Amazon Aurora Serverless v2正式发布:瞬时扩展应对高要求的工作负载
- 将数据仓库迁移到 Amazon Redshift 时的考虑事项
- 使用多区域 Amazon EKS 和 Amazon Aurora Global Database 扩展应用程序:第 1 部分
- Amazon EMR 上 Apache Hudi 0.9.0 提供的新功能
- 将 Microsoft Azure SQL 数据库迁移到 Amazon Aurora MySQL 兼容版
- 从 Amazon EMR 和 AWS Glue 访问 Amazon S3 中数据的性能优化最佳实践
- java篇
- 使用 Amazon Glue、Amazon Neptune 和 Spline 为数据湖构建数据沿袭
- Amazon Redshift 继续保持在性价比方面的领先地位
- java dfs
- IoT 数据摄入和可视化的 7 种模式 – 如何确定最适合您使用场景的模式
- Data-centric AI之特征工程(第一讲)
- Kylin 4 集成 Amazon Glue Catalog!
- 实时数据处理中的AWS lambda (python) 性能优化
- Python enumerate() 函数
- 无需订阅费! 手把手教你如何在Amazon OpenSearch Service中使用跨集群复制功能(Cross-Cluster Replication)
- Amazon MSK Serverless 现已正式推出–无需再为托管式 Kafka 集群进行容量规划
- AWS IoT TwinMaker 现已正式发布
- 利用Amazon Redshift的流式摄取构建实时数仓