云数据库成本分析 AWS上TiDB与RDS性能成本大比拼

aws的费用是非常贵的云上rds的费用更高。我来给出一组数据。如果全部用aws来储存数据。一个月的费用是500w美元左右。某某某公司。

于是乎dba中的冯大嘴喊出了云数据库就是杀猪盘。让每个公司自建数据库。

那么有没有一种数据库又便宜又好用呢。有 哪就是tidb数据库。

之前一个dba工程师的工作内容可能包括以下几个方面：

监控带宽、流量、并发、业务接口等关键资源及访问信息的变化趋势。

根据相应趋势变化不断演进和优化dba架构。

设计各类解决方案，解决公司业务发展中遇到的dba技术瓶颈。

编写各种自动化脚本（shell，python），自动化部署优化服务。

实现dba平台化运维。

制定dba运维流程、规范、制度，并有序推进。

研究先进dba运维理念、模式，确保业务持续稳定、有序。

但是现在dba还得帮公司省钱。如果贵公司的业务多。公司里面有个几百个数据库很正常。

这些数据库的月费用就是百万级别的。

那么我们能不能省下这些费用呢？没问题的tidb就是专门干这个的。

我们从两方面来省数据库的钱

双剑合璧

oltp，和olap数据库合二为一，同一套数据库即跑oltp也跑olap业务盛夏redshift的钱。

在用aws的物理机中

TiDB 资源控制和隔离：此部分主要介绍 TiDB 与 NUMA 和 cgroup 技术结合实现单机多实例部署时资源控制和隔离，以及 TiDB 自带的资源控制参数； TiDB 数据隔离：此部分主要介绍 TiDB Label 与 Placement Rules in SQL 技术实现数据存储隔离； 基于上述资源控制和数据隔离技术实现单集群多业务融合架构； 方案收益分析； 监控和报警隔离说明：融合部署的业务应用可以根据重要性分别配置监控和报警。

把一台物理机当成2台使用通过绑定numa。节约了机器又提高了性能。解决了机器不够的问题。

多个业务A业务B业务用户中心公用一个数据库。做到了资源最大化利用。如果A用户量多就支援A业务。如果B用户量多就支援B业务。并由于大集群带来的业务容量的提升。无论各个业务量再怎么增长也能支撑的住。原本为了满足A的增长，B业务的增长得准备两套物理机器。现在由于共用，可以相互资源就节省了服务器的使用。并且把5套套业务机器并成一套。提升了5倍性能。TiDB 多业务融合方案是指将多个业务系统部署在同一套 TiDB 集群中，利用 Placement Rule 来实现资源隔离和负载均衡。

他就是线下的雪花模型

二

多业务融合管控功能。把公司所有的云业务放在一起，避免了搬迁这就用到了我们说的云资源管控。这是tidb7.1出的新功能。

以前有8个数据库分别做不同的业务。又因为费用贵但个数据库实例选择只能往小的选，容量刚刚够用。数据库经常报警。dba处于救国救民的忙碌状态。一顿操作猛如虎，还是经常250.数据库经常因为资源不够而告警。

现在换成tidb数据库后原先的8份资源替换成一份大的数据库。就有原先8倍的冗余资源来应对数据库告警。就形成了一个超大规模的数据库。但费用会比单个数据库省很多。

在这样的系统架构下我们采用了这样的

每类业务分配4核心8g内存的tidb，用于各类业务的oltp业务查询。在用资源管控来约束最大的cpu占比。把更多的资源，内存留给tikv tiflash

tiflash层采用s3作为冷存储 因为s3本身可无限扩容费用又是最低的

而且tiflash的cpu 是可以动态扩容的 这个时候就可以很好的利用aws的spot实例 价格是ec2的10分之1

准备条件

准备一个 S3 的 bucket，用于存储 TiFlash 数据。你也可以使用已有的 bucket，但需要为每个 TiDB 集群预留专门的 key 前缀。关于 S3 bucket 的更多信息，请参考AWS 文档。也可以使用兼容 S3 的其他对象存储，比如 MinIO。TiFlash 使用的 S3 API 接口列表包括：

PutObject

GetObject

CopyObject

DeleteObject

ListObjectsV2

GetObjectTagging

PutBucketLifecycle

给准备好的 S3 bucket 添加一个用于清理已删除数据的生命周期：

"ID": "tiflash-clean", "Expiration": { "Days": 1 }, "Filter": { "And": { "Tags": [ { "Value": "tiflash_deleted", "Key": "true" } ] } }

确保 TiDB 集群中没有任何 TiFlash 节点。如果有，则需要将所有表的 TiFlash 副本数设置为 0，然后缩容掉所有 TiFlash 节点。比如：

SELECT * FROM INFORMATION_SCHEMA.TIFLASH_REPLICA; # 查询所有带有 TiFlash 副本的表 ALTER TABLE table_name SET TIFLASH REPLICA 0; # 将所有表的 TiFlash 副本数设置为 0

使用方式

默认情况下，TiUP 会将 TiFlash 部署为存算一体架构。如需将 TiFlash 部署为存算分离架构，请参考以下步骤手动进行配置：

准备 TiFlash 的拓扑配置文件，比如 scale-out.topo.yaml，配置内容如下：

tiflash_servers: # TiFlash 的拓扑配置中存在 storage.s3 配置，说明部署时使用存算分离架构 # 配置了 flash.disaggregated_mode: tiflash_compute，则节点类型是 Compute Node； # 配置了 flash.disaggregated_mode: tiflash_write，则节点类型是 Write Node - host: 192.168.1.11 config: flash.disaggregated_mode: tiflash_write # 这是一个 Write Node storage.s3.endpoint: http://s3.{region}.amazonaws.com # S3 的 endpoint 地址 storage.s3.bucket: mybucket # TiFlash 的所有数据存储在这个 bucket 中 storage.s3.root: /cluster1_data # S3 bucket 中存储数据的根目录 storage.s3.access_key_id: {ACCESS_KEY_ID} # 访问 S3 的 ACCESS_KEY_ID storage.s3.secret_access_key: {SECRET_ACCESS_KEY} # 访问 S3 的 SECRET_ACCESS_KEY storage.main.dir: ["/data1/tiflash/data"] # Write Node 的本地数据目录，和存算一体的配置方式相同 - host: 192.168.1.12 config: flash.disaggregated_mode: tiflash_write # 这是一个 Write Node storage.s3.endpoint: http://s3.{region}.amazonaws.com # S3 的 endpoint 地址 storage.s3.bucket: mybucket # TiFlash 的所有数据存储在这个 bucket 中 storage.s3.root: /cluster1_data # S3 bucket 中存储数据的根目录 storage.s3.access_key_id: {ACCESS_KEY_ID} # 访问 S3 的 ACCESS_KEY_ID storage.s3.secret_access_key: {SECRET_ACCESS_KEY} # 访问 S3 的 SECRET_ACCESS_KEY storage.main.dir: ["/data1/tiflash/data"] # Write Node 的本地数据目录，和存算一体的配置方式相同 # 192.168.1.11 是 TiFlash Compute Node - host: 192.168.1.13 config: flash.disaggregated_mode: tiflash_compute # 这是一个 Compute Node storage.s3.endpoint: http://s3.{region}.amazonaws.com # S3 的 endpoint 地址 storage.s3.bucket: mybucket # TiFlash 的所有数据存储在这个 bucket 中 storage.s3.root: /cluster1_data # S3 bucket 中存储数据的根目录 storage.s3.access_key_id: {ACCESS_KEY_ID} # 访问 S3 的 ACCESS_KEY_ID storage.s3.secret_access_key: {SECRET_ACCESS_KEY} # 访问 S3 的 SECRET_ACCESS_KEY storage.main.dir: ["/data1/tiflash/data"] # Compute Node 的本地数据目录，和存算一体的配置方式相同 storage.remote.cache.dir: /data1/tiflash/cache # Compute Node 的本地数据缓存目录 storage.remote.cache.capacity: 1858993459200 # 1800 GiB - host: 192.168.1.14 config: flash.disaggregated_mode: tiflash_compute # 这是一个 Compute Node storage.s3.endpoint: http://s3.{region}.amazonaws.com # S3 的 endpoint 地址 storage.s3.bucket: mybucket # TiFlash 的所有数据存储在这个 bucket 中 storage.s3.root: /cluster1_data # S3 bucket 中存储数据的根目录 storage.s3.access_key_id: {ACCESS_KEY_ID} # 访问 S3 的 ACCESS_KEY_ID storage.s3.secret_access_key: {SECRET_ACCESS_KEY} # 访问 S3 的 SECRET_ACCESS_KEY storage.main.dir: ["/data1/tiflash/data"] # Compute Node 的本地数据目录，和存算一体的配置方式相同 storage.remote.cache.dir: /data1/tiflash/cache # Compute Node 的本地数据缓存目录 storage.remote.cache.capacity: 1858993459200 # 1800 GiB

注意以上 ACCESS_KEY_ID 和 SECRET_ACCESS_KEY 是直接写在配置文件中的。你也可以选择使用环境变量的方式单独配置。如果两种方式都配置了，环境变量的优先级高于配置文件。如需通过环境变量配置，请在所有部署了 TiFlash 进程的机器上，切换到启动 TiFlash 进程的用户环境（通常是 tidb），然后修改 ~/.bash_profile，增加这些配置：

storage.s3.endpoint 支持使用 http 模式和 https 模式连接 S3，可以直接通过修改 URL 来选择。比如 https://s3.{region}.http://amazonaws.com。

export S3_ACCESS_KEY_ID={ACCESS_KEY_ID} export S3_SECRET_ACCESS_KEY={SECRET_ACCESS_KEY}

执行扩容 TiFlash 节点，并重新设置 TiFlash 副本数：

tiup cluster scale-out mycluster ./scale-out.topo.yaml

以编辑模式打开 TiDB 配置文件：

在 TiDB 配置文件中添加以下配置项：

重启 TiDB:

修改 TiDB 配置，用存算分离的方式查询 TiFlash。

tiup cluster edit-config mycluster server_configs: tidb: disaggregated-tiflash: true # 使用存算分离的方式查询 TiFlash tiup cluster reload mycluster -R tidb

用最少的钱办最大的事，这就是tidb给我们节约费用最大的帮助。

这部分计划了很久我们有300多个数据库。我计算了一个数据库的费用可供大家参考一下。用tidb能省下来的费用。

aws rds费用

cpu实例小时费用存储费用小时io1万次数总费用主读r5.4xlarge162.2800 USD每月每 GB 0.375 USD每月每 IOPS 0.30主写r5.4xlarge162.2800 USD每月每 GB 0.375 USD每月每 IOPS 0.30redshift最低配dc2.8xlarge324,449.35月费用5088.961536600010819.2

tidb费用

cpu实例小时费用20t cold hhdgp3 1t(给tiflash)总费用pdc5.2xlarge80.1920tidbc5.4xlarge160.8560kvr5.4xlarge161.096200200月费用1543.682002001943

价格的比较

tidb费用对比费用比single19430.35tidb5431.041.0rds10819.22.0Aurora9232.321.7

性能结果比较

用tpcc-h做数据分析性能比较rds和自建tidb的数据计算速度。

差距最大的q1 q9 有100多倍，最小q4 也有5倍

q1

q2

q3

q4

q5

q6

q7

q8

q9

q10

mysql8

78.89s

3.79s

26.81s

6.14s

6.14s

10.23s

26.21s

39.76s

98.75s

13.25s

tidb

0.64s

0.17s

0.30s

1.17s

0.44s

0.10s

0.37s

0.30s

0.70s

0.44s

本文是按照美元计价的月费用如果rmb计价就很恐怖了。

tidb费用对比费用比single1632120.35tidb456207.361.0rds960749.42.0Aurora819830.0161.7

因为本数据库主要用来做数据分析。所以磁盘上用了hhd做kv存储。如果要用作正常存储数据。机器需要用ssd硬盘。

一个历史归档数据库一年的话费能从96万减少到16万 费用节省80w。不可想像。这样的数据库有几百个。他能省多少钱各位cfo去算算。上云是真省钱呀。

尾记

TCO: TCO（Total Cost of Ownership, 总体拥有成本）其实并不陌生。1996年，IBM为PC和网络用户提出这个概念，同时，Intel也提出了管理标准WfM，两家公司还开发出一些进行TCO管理的解决方案。此外，Intel、IBM与HP等公司携手制定了很多规范，例如：DMI（桌面管理接口）以及WfM（联网化管理）等，这些标准得到了业界的支持并逐渐成为了厂商所共同遵循的标准。当时，业界对TCO的讨论程度之热烈至今还记忆犹新。

就算是IDC托管也是不可能保证做到随时分钟级别的服务器资源弹性伸缩。在业务不确定性日趋增大的市场背景下，拥有及时的弹性部署能力将成为大部分中小企业的刚需。这一点就能为企业节约大量资源，避免采购过量浪费，或者资源不足拖累业务的两难情况。

而恰恰是这些特性，大大降低企业的成本，例如，企业可以按需使用计算和存储资源，不必支付高昂的固定费用。同时，弹性伸缩可以让企业在高峰期轻松扩展计算和存储资源，避免浪费资源。

这些特性是云计算的核心优势，作者没有将它们纳入成本分析中，因此分析结果是不完整的。

最后还有一点，就是作者没有考虑到公有云提供的其他强大能力。

特别是对中小企业来说，原文的分析可能会造成误导，甚至可以说，任何不考虑人力成本的IT服务成本分析都是耍流氓。

其次，作者没有考虑到公有云的特性。相比于传统的IDC，公有云提供了即插即用，弹性伸缩，按需按量计费等特性。

怎么用好云我们任重道远。

by the way 云是有返点的，交给公司公司用的更便宜。