作者： tidb 狂热爱好者原文来源：https://tidb.net/blog/a9c79421

怎么样用好 tidb，为了帮助到更多人学好 tidb，理解 tidb，也为了自己更好的学会 tidb，传道授业解惑，我准备花 1 万小时。写 1 万篇文章讲 tidb。

啦啦啦 tidb 专家课堂开课啦。

在云上怎么样用好 tidb。我们都知道云上的资源特别贵。

从前，当我们在上线一个系统的时候，第一件事就是 Capacity Planning，去评估一下我们大概需要多少台服务器，比如提前准备了 50 台，但是实际上线之后跑了一个月，发现 5 台机器就够了。这就导致了大量的资源浪费。如果整个系统能够在云上全自动弹性伸缩，就能避免这种资源浪费。

更重要的是，TiDB 的弹性伸缩，意味着你永远不需要按照业务的峰值配备系统资源。比如大家的业务会有早、晚两个明显的高峰，但实际上每个高峰持续时间通常只有 2 个小时左右，也就是说，为了这 4 个小时的高峰，而我们配置了 24 小时的最高资源配置，并为此付费，但非高峰时间的资源和成本完全是可以节省的，可能算下来，我们能够节省的成本大概在 70% 左右，甚至更高。

这就需要祭出我们 dba 的编程技能。

用一台 ecs 做管理机器。

把业务拆分成 ap 和 tp 业务。

ap 业务的最省钱设计

ap 业务的能力如下设计

ap 业务省钱法宝

如图，在存算分离架构中，TiFlash 原有进程的不同部分的功能，被拆分到两种不同的节点中，分别是 Write Node 和 Compute Node。这两种节点可以分别部署，各自扩展，即你可以选择部署任意数量的 Write Node 或者 Compute Node。

• TiFlash Write Node

负责接收 TiKV 的 Raft logs 数据，将数据转换成列存格式，并每隔一小段时间将这段时间的所有数据更新打包上传到 S3 中。此外，Write Node 也负责管理 S3 上的数据，比如不断整理数据使之具有更好的查询性能，以及删除无用的数据等。

Write Node 利用本地磁盘（通常是 NVMe SSD）来缓存最新写入的数据，从而避免过多使用内存。

• TiFlash Compute Node

负责执行从 TiDB 节点发过来的查询请求。它首先访问 Write Node 以获取数据的快照 (data snapshots)，然后分别从 Write Node 读取最新的数据（即尚未上传到 S3 的数据），从 S3 读取剩下的大部分数据。

Compute Node 利用本地磁盘（通常是 NVMe SSD）来作为数据文件的缓存，从而避免相同的数据反复从远端（Write Node 或者 S3）读取，以提高查询性能。

Compute Node 是无状态节点，它拥有秒级的扩容和缩容速度。你可以利用这个特性降低成本：

• 在查询负载较低时，减少 Compute Node 的数量，从而节省成本。在没有查询时，甚至可以停掉所有 Compute Node。

• 在查询负载变高时，快速增加 Compute Node 的数量，保证查询性能。

使用场景

TiFlash 存算分离架构适用于高性价比的数据分析服务的场景。在这个架构下，存储和计算资源可以单独按需扩展。在这些场景将会有较大收益：

• 数据量虽然很大，但是只有少量数据被频繁查询；其他大部分数据属于冷数据，很少被查询。此时经常被查询的数据通常已被缓存在 Compute Node 的本地 SSD 上，可以提供较快查询性能；而其他大部分冷数据则存储在成本较低的 S3 或者其他对象存储上，从而节省存储成本。

• 计算资源需求有明显的波峰和波谷。比如重型的对账查询通常放在晚上执行，此时对计算资源要求较高，可以考虑临时扩展 Compute Node；其他时间可以用较少的 Compute Node 完成查询任务。

准备条件

1. 准备一个 S3 的 bucket，用于存储 TiFlash 数据。

你也可以使用已有的 bucket，但需要为每个 TiDB 集群预留专门的 key 前缀。关于 S3 bucket 的更多信息，请参考 AWS 文档。

也可以使用兼容 S3 的其他对象存储，比如 MinIO。

TiFlash 将使用以下 S3 API 接口进行数据读写，需要确保部署 TiFlash 的节点有这些接口的权限：

• PutObject

• GetObject

• CopyObject

• DeleteObject

• ListObjectsV2

• GetObjectTagging

• PutBucketLifecycle

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，增加这些配置：

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

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

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

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

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

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

3. 重启 TiDB:

使用限制

• TiFlash 不支持在存算一体架构和存算分离架构之间原地切换。在切换到存算分离架构前，需要将原有存算一体架构的 TiFlash 节点全部删除。

• 从一种架构迁移到另外一种架构后，需要重新同步所有 TiFlash 的数据。

• 同一个 TiDB 集群只允许存在相同架构的 TiFlash 节点，不允许两种架构同时存在。

• 存算分离架构只支持使用 S3 API 的对象存储，存算一体架构只支持本地存储。

• 使用 S3 存储的情况下，TiFlash 节点无法获取非本节点文件的密钥，因此无法启用静态加密功能。

为什么要这么做

1.s3 的费用是几乎不要钱的 。

2.read 节点购买本地磁盘。也没有磁盘费用只有机器费用。和普通没有磁盘的机器几乎相等。

3. 这些节点你可以购买 spot 机器，这种费用几乎相当于按量付费的 10%。赢麻了，简直赢麻了 跟着蒋老师学 tidb，走上人生巅峰。而且 spot 机器销毁也对业务没有影响。只是计算变慢。还有正常的 ec2 机器支持 ap 查询。

4. 比如大家的业务会有早、晚两个明显的高峰，但实际上每个高峰持续时间通常只有 2 个小时左右，也就是说，为了这 4 个小时的高峰，而我们配置了 24 小时的最高资源配置，并为此付费，但非高峰时间的资源和成本完全是可以节省的，可能算下来，我们能够节省的成本大概在 70% 左右，甚至更高。

5. 比如双十一我们加 100 台，等结束立即关闭，还全是 spot 机器。

6. 应对流量高峰，突发事件，你一个脚本上 100 台

说花 1 小时其实我只花了 10 分钟。但这套技能你掌握好，你给公司省到钱，公司拿你当宝贝。我用这套技能原先公司一个月花 10 万美元，现在只需要 1 万美元。