aws 上采用 tidb 和原生使用 aws rds 价格的比较。兼数据分析性能的测试
作者: tidb 狂热爱好者原文来源:https://tidb.net/blog/ef242615
项目背景介绍
有一个 20t-30t 的历史库需要做数据分析,节能减排,减容增效。今年大环境不好,aws 的费用又是出奇的贵。
历史库的作用是公司近 1 年的订单合集,平时不需要查询,偶尔会有月统计的需求。之前用 aws 的 mysql 无法完成需求,现在寻找数据库替换。
分别测试了 oltp 性能和 olap 性能。
数据分析 pk
压测步骤
本地启动一个 tidb 单节点端口 4000,启动一个 mysql8.0 端口 4001
tiup playground
初始化测试数据
tiup bench tpch –sf=1 prepare -P4000
tiup bench tpch –sf=1 prepare -P4001
#进入tidb开启tiflash。 ALTER DATABASE tpcc SET TIFLASH REPLICA 1; #等待同步完成后收集统计信息。 analyze table customer; analyze table district; analyze table history; analyze table item; analyze table new_order; analyze table order_line; analyze table orders; analyze table stock; analyze table warehouse; analyze table nation; analyze table region; analyze table supplier;
分别开始测试
tiup bench tpch –sf=1 run -P4000
tiup bench tpch –sf=1 run -P4001
mysql8 数据分析测试
tiup is checking updates for component bench ...timeout(2s)! Starting component bench: /var/root/.tiup/components/bench/v1.12.0/tiup-bench tpch --sf=1 run -P4001 [Current] Q1: 78.89s [Current] Q2: 3.79s [Current] Q3: 26.81s [Current] Q4: 6.14s [Current] Q5: 6.48s [Current] Q6: 10.23s [Current] Q7: 26.21s [Current] Q8: 39.76s [Current] Q9: 98.75s [Current] Q10: 13.25s [Current] Q11: 10.37s [Current] Q12: 15.94s [Current] Q13: 12.72s [Current] Q14: 32.78s [Current] Q15: 31.24s [Current] Q16: 4.06s mysql无法进行数据分析依赖redshift 无法进行Q17测试。
tidb 数据分析
[Current] Q3: 0.30s [Current] Q4: 1.31s [Current] Q5: 0.57s [Current] Q6: 0.17s [Current] Q7: 0.30s [Current] Q8: 0.50s [Current] Q9: 0.97s [Current] Q1: 0.57s [Current] Q10: 0.44s [Current] Q11: 0.17s [Current] Q12: 0.44s [Current] Q13: 0.70s [Current] Q14: 0.17s [Current] Q15: 0.50s [Current] Q16: 0.23s [Current] Q17: 0.44s [Current] Q18: 0.84s [Current] Q2: 0.17s [Current] Q21: 0.84s [Current] Q22: 0.10s [Current] Q3: 0.30s [Current] Q4: 1.38s [Current] Q5: 0.44s [Current] Q6: 0.17s [Current] Q7: 0.37s [Current] Q8: 0.50s [Current] Q9: 0.91s [Current] Q1: 0.57s [Current] Q10: 0.44s [Current] Q11: 0.17s [Current] Q12: 0.30s [Current] Q13: 0.57s [Current] Q14: 0.17s [Current] Q15: 0.64s [Current] Q16: 0.23s [Current] Q17: 0.50s [Current] Q19: 0.64s [Current] Q2: 0.17s [Current] Q20: 0.23s [Current] Q21: 0.91s [Current] Q22: 0.10s [Current] Q3: 0.37s [Current] Q4: 1.17s [Current] Q5: 0.44s [Current] Q6: 0.17s [Current] Q7: 0.37s [Current] Q8: 0.50s [Current] Q9: 0.84s [Current] Q1: 0.64s [Current] Q10: 0.44s [Current] Q11: 0.17s [Current] Q12: 0.23s [Current] Q13: 0.57s [Current] Q14: 0.10s [Current] Q15: 0.37s [Current] Q16: 0.17s [Current] Q17: 0.30s [Current] Q18: 0.67s [Current] Q19: 0.64s [Current] Q2: 0.17s [Current] Q20: 0.30s [Current] Q21: 0.77s [Current] Q22: 0.10s [Current] Q3: 0.30s [Current] Q4: 1.17s [Current] Q5: 0.44s [Current] Q6: 0.10s [Current] Q7: 0.37s [Current] Q8: 0.30s [Current] Q9: 0.70s tidb数据分析性能是mysql的几百倍 均是几百毫秒完成。
测试结果比较
差距最大的 q1 q9 有 100 多倍,最小 q4 也有 5 倍
ycsb 测试
测试命令
读 10000 次计算执行时间
更新 500 次计算执行时间
tiup bench ycsb run tidb -p tidb.instances=127.0.0.1:4000 -p operationcount=10000
tiup bench ycsb run mysql -p tidb.instances=127.0.0.1:4001 -p operationcount=10000
tidb
Starting component `bench`: /var/root/.tiup/components/bench/v1.12.0/tiup-bench ycsb run mysql -p tidb.instances=127.0.0.1:4000 -p operationcount=10000 ***************** properties ***************** "command"="run" "tidb.instances"="127.0.0.1:4000" "operationcount"="10000" "dotransactions"="true" ********************************************** Run finished, takes 4.191237542s READ - Takes(s): 4.2, Count: 9495, OPS: 2267.3, Avg(us): 402, Min(us): 179, Max(us): 7951, 99th(us): 705, 99.9th(us): 3519, 99.99th(us): 7007 UPDATE - Takes(s): 4.2, Count: 505, OPS: 120.7, Avg(us): 675, Min(us): 419, Max(us): 2497, 99th(us): 1117, 99.9th(us): 1926, 99.99th(us): 2497
mysql
tiup is checking updates for component bench ... Starting component `bench`: /var/root/.tiup/components/bench/v1.12.0/tiup-bench ycsb run mysql -p tidb.instances=127.0.0.1:4001 -p operationcount=10000 ***************** properties ***************** "operationcount"="10000" "dotransactions"="true" "command"="run" "tidb.instances"="127.0.0.1:4001" ********************************************** READ - Takes(s): 10.0, Count: 4522, OPS: 452.5, Avg(us): 2086, Min(us): 778, Max(us): 151423, 99th(us): 8687, 99.9th(us): 26655, 99.99th(us): 151423 UPDATE - Takes(s): 9.9, Count: 234, OPS: 23.6, Avg(us): 2306, Min(us): 972, Max(us): 10543, 99th(us): 7859, 99.9th(us): 10543, 99.99th(us): 10543 Run finished, takes 19.66040875s READ - Takes(s): 19.7, Count: 9506, OPS: 483.7, Avg(us): 1955, Min(us): 778, Max(us): 151423, 99th(us): 7867, 99.9th(us): 17759, 99.99th(us): 41343 UPDATE - Takes(s): 19.6, Count: 494, OPS: 25.2, Avg(us): 2080, Min(us): 807, Max(us): 10543, 99th(us): 6959, 99.9th(us): 10543, 99.99th(us): 10543
结论
亚马逊上的费用对比
三实例 aws Aurora 费用
aurora预估费用页面 https://aws.amazon.com/cn/rds/aurora/pricing/?pg=pr&loc=1 存储费率 每月每 GB 0.12 USD 每月每 GB 0.27 USD I/O 费率 每 100 万个请求 0.24 USD 包含
aws rds 费用
rds预估费用页面 https://aws.amazon.com/cn/rds/mysql/pricing/?pg=pr&loc=2 多可用区存储费率 每月每 GB 0.45 USD 多可用区预调配 IOPS 费率 每月每 IOPS 0.36 USD
tidb 非高可用方案 冷磁盘 250m 峰值读取
优点:
费用便宜只需要 1943 元就能完成大数据的计算任务。如果好后期可以扩容支撑大数据计算业务
tiflash 采用计算分离架构节约 80% 费用
缺点:
本方案是单点 tidb。如果 ec2 宕机,需要代码遇到 tidb 无法写入时,不再删除 mysql 原始库的数据。等待处理
tidb 高可用三副本
优点:
费用便宜只需要 5431 元就能完成大数据的计算任务。如果好后期可以扩容支撑大数据计算业务
并且是三副本高可用的版本。不存在宕机问题
tiflash 采用计算分离架构节约 80% 费用
https://docs.pingcap.com/zh/tidb/stable/tiflash-disaggregated-and-s3
缺点:
相比单节点费用较高。保证了业务可用性。
结论
感觉 tidb 上了后会节约至少一半的费用。
整体算下来 aurora 的费用会比 rds 便宜因为 aurora 的存储基于 s3 的三副本。存储费用低。
而自建 tidb 的存储价格会比 aurora 低。合理利用 s3,hhd,gp3,不同存储的搭配会节省出不少费用。s3 作为 aws 的引流产品价格是出奇的低我恨不得任何时候任何产品后段都挂载 s3. 实现容量和性价比的
版权声明: 本文为 InfoQ 作者【TiDB 社区干货传送门】的原创文章。
原文链接:【http://xie.infoq.cn/article/25252d20f5c2872b4934d1666】。文章转载请联系作者。
评论