云数据库是杀猪盘么，去掉中间商赚差价，aws 数据库性能提升 10 倍！价格便宜十倍。

原文来源：https://tidb.net/blog/021059f1

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

准备条件

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

• PutObject

• GetObject

• CopyObject

• DeleteObject

• ListObjectsV2

• GetObjectTagging

• PutBucketLifecycle

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

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

使用方式

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

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

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

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

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

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

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

4. 重启 TiDB:

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

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

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

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 费用

价格的比较

性能结果比较

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

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

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

因为本数据库主要用来做数据分析。所以磁盘上用了 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 云是有返点的，交给公司公司用的更便宜。