于是乎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 添加一个用于清理已删除数据的生命周期：

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

1. 确保 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 部署为存算分离架构，请参考以下步骤手动进行配置：

1. 准备 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}

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

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

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

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

3. 重启 TiDB:

1. 修改 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费用

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 云是有返点的，交给公司公司用的更便宜。