作者： 18515065291 原文来源：https://tidb.net/blog/9391f6b6

TiDB 使用场景漫谈

               --2021-08-19 春雷

1、前言

为了方便大家对于多种数据库产品有个大致的认知，对于更好的使用 TiDB，今天随便谈谈 TiDB 使用场景。

首先个人观点：没有一种数据库是银弹。

此篇文章也不是黑 TiDB，只是从客观的角度，来说下当前 TiDB 更适合的场景。

借此希望大家能更好的用起来 TiDB，而不是用在了错误的场景，再来吐槽 TiDB 不好，这样就不好啦~

个人观点：伴随着业务的发展，业务场景复杂多样，一种数据库解决所有业务类型是很难办到的，或者可以说：即使能办到，是要消耗很多很多的资源，现实上可能就不可行了。也就是：有时并不是技术问题~

对于复杂的场景需求，多种数据库，大家相互辅助，各自发挥自己答特点，才是比较好的方式。

2、TiDB 架构特点及应对场景

要想知道一款数据库的使用场景，首先要了解一款数据库的架构及主要特点。

2.1、TiDB 重要特点

• 兼容 MySQL 5.7 协议和 MySQL 生态等重要特性

• 分布式数据库， 一键水平扩容或者缩容

• 实时 HTAP

• 金融级高可用

2.2、常规分析

既然兼容 MySQL5.7 协议及 MySQL 生态等特性，那么可以推断：他就可以支持一部分的 MySQL 数据库的场景

但是 MySQL 这么稳定，使用场景这么多，互联网必用的数据库，哪种场景放 TiDB 更好呢？

那么就从 MySQL 的痛点问题说起吧

针对以上痛点问题，我们再比对 TiDB 的特性：

• 分布式数据库：性能、磁盘可扩容，免去分库分表

• 读写在 leader 上：无读延迟

• TiFlash 列存：支持分析

• Multi-Raft 协议：保证节点宕机切换高可用

那么很清晰的就可以推断 TiDB 可以替换 MySQL 数据库的一部分业务场景：

• 分库、分表的场景 ：可以迁移到 TiDB 上，合并成一张表的使用

• 磁盘占用大的业务： 可以迁移到 TiDB 上，可以扩容

• 有一定分析 SQL 的业务 ：可以迁移到 TiDB+TiFlash 上，可以快速分析

• 读写性能要求高的业务 ：可以迁移到 TiDB 上，读写可以扩容，读无延迟

• 宕机要求影响小的业务 ：可以迁移到 TiDB 上，Multi-Raft 协议，宕机影响小

2.2、交易业务分析

虽然 TiDB 从上面的特点看，简直无敌。但是毕竟是一款年轻的数据库，还存在一定的问题，或者是很多分布式数据自身的问题。

这对于交易业务来说，就不那么让人放心了， 交易业务的特点如下：

• 稳定性要求超级高，要保证实时可用

• 宕机影响大，历史故障看，分钟级别损失百万，都是正常的例子

• 业务变化不频繁，SQL 成熟稳定

• 业务层保证多，有一定保证、降级方案

• 大业务量的话，多分片 或 分库分表比较常见

• 要支持指定点的恢复，且越快越好

• ETL 拉取数据、或者分析 SQL 不能影响线上服务

再来看看 TiDB 的问题，此处简单罗列部分问题如下：

• 大集群备份不好做，如果做，需要资源多

• 指定点级别恢复，需要依赖 TiCDC 工具、备份等

• TiCDC 目前稳定性还有待提升

• 大集群的指定点恢复消耗时间长也是必然的

• 慢 SQL 影响范围广，会导致整个集群的性能下降

• 大表添加索引，性能影响有一些大

所以也可以很简单的推断：TiDB 数据库个人当前不太推荐直接替换 MySQL 涉及金钱交易的业务。

如果是交易的业务，放 MySQL 上，如果业务量大，可以多分片，这样备份、恢复方便、宕机影响小，慢 SQL 相对可控，对于当前来说还是比较放心的。毕竟交易业务还是要谨慎的。

如果要放，也是可以的，但推荐业务侧多做保证，例如队列、访问重试，更详细的日志记录、补数据机制、降级方案等等

不过，随着 TiDB 的高速发展，业务上积累的经验，运维上积累的经验，上面的问题都会迎刃而解。

2.3、分析业务相关分析

TiDB 的一个重要特点是：有 TiFlash 列存，这个可是分析型业务的必备。

我们先来看下 TiFlash 的特点：

• 异步复制：TiFlash 中的副本以特殊角色 (Raft Learner) 进行异步的数据复制

• 智能选择：TiDB 可以自动选择使用 TiFlash 列存或者 TiKV 行存

• 5.0 支持 MPP

• 使用上：一个 SQL 即可把表加入到 TiFlash

从以上特点，我们也可以看出：TiDB 更推荐的场景是 HTAP，也就是部分 TP，部分 AP 业务。

• 异步复制 ：也就是写入先写入到 TiKV，再同步到 TiFlash 上，此架构就带来了如下问题

• 对于几乎全是 AP 场景的，存在 TiKV+TiFlash, 无疑是浪费了 TiKV 机器资源

• 写入速度受限于 TiKV, 想要提高写入速度，只能扩容 TiKV 实例，这无疑又带来了资源浪费

• 且对于 TiDB，只支持 SQL，也就是很多大批量的导入任务，必须走 TiDB SQL，这又被 TikV 的写入速度限制了

• 但有一点很好：支持更新，这个是其他 AP 数据库很少有的

• 智能选择 ：是指查询中可以使用到 2 个存储引擎，TikV+TiFlash，相比更智能一些

• 但是也会同样带来问题，如果优化器选择错误了，导致应该走 TiFlash 更快的，却走了 TiKV，导致 SQL 执行不佳，这些在日常中也是发生过的。

• 5.0 支持 MPP ：也就是可以加速计算，但是需要大家注意：

• 使用低版本的 TiDB 需要升级 5.0, 这样才能查询加速

• 如果需要提高 AP 查询效率，需要多个 TiFlash 节点才行，实测：不同版本：比 4.x 版本提高很多；相同版本多节点比单节点提高很多

• 使用上 ：需要 DBA 做更多的工作：

• 如果表多，需要定期分析慢 SQL，看哪些集群需要添加 TiFlash，哪些表需要加入到 TiFlash，这样对于 DBA 来说就有一定的工作量

综上，也就是说对于纯 AP 分析、体量很大的分析的业务，可能更纯粹的分析数据库更合适，例如 ClickHouse，DorisDB 等。

或者 TiFlash 什么时候可以独立接受写入的时候，那么就可以解决上面的一些问题了。

对于 HTAP 业务 或 分析量不是很重的场景：TikV+TiFlash 就很合适了。

3、我们的场景

分析了那么多，我们到底是怎么用 TiDB 的呢？

• MySQL 大表 ：

• 对于不涉及交易业务的大单表：超过 100G 的，条数大于 1 亿的，全部迁移到 TiDB, 我们使用 TiDB 的初期，迁移了几十 T 的数据到 TiDB，减轻了 MySQL 的压力。

• 监控数据 ：

• 监控业务特点是数据正常都比较大，有一定保存时间需求，且流量比较大，连接数可能比较多

• 例如 DBA 的数据库存活监控、性能监控、其他业务的相关监控，我们接入到了 TiDB，使用多个 TiDB Server 支撑流量，多个 TiKV 保证数据写入速度及数据保留，很好的支撑了业务

• 数仓 ：

• 数仓业务特点是表很多，业务逻辑比较复杂，存在详细数据与分析后的结果数据的需求，一定写入速度的需求，并发查询 + 分析查询的情况

• 例如金融业务数仓，商业某业务的数仓等，使用 TiKV+TiFlash, 大部分表都加入到 TiFlash，升级到最新版本，多 TiFlash 节点，多个 TiKV 保证数据写入速度及数据保留，很好的支撑了业务

• 报表：

• 报表业务的特点跟数仓有点像，表多，存在详细数据与分析后的结果数据的需求，一定写入速度的需求，并发查询 + 分析查询的情况

• 例如安居客业务报表、DBA 使用的报表、商业报表等等，也是 TiKV+TiFlash，5.0 版本，按需扩展多个 TiFlash

• 日志、流水：

• 日志、流水业务的特点：其实就是大单表，有一定的保留日期，写入平稳，分析查询相比不多

• 例如安居客相关日志、商业操作日志，操作流水等等，可以建立分区表，方便历史数据清理，只使用 TiKV 即可

• 数据归档：

• 归档业务的特点：定期归档，查询少，但数据重要，不能丢失，接受一定的写入速度慢

• 原来归档我们使用 TokuDB，但是 TokuDB 要被官方废弃了，TiDB 是个很好的接任者，目前我们部分业务的归档开始使用 TiDB 了

• 例如商业的归档数据等，可以使用普通的大容量的 SSD 盘，例如多块 8T SSD ，提升容量，且配置更高压缩率的压缩参数等

• ​​​​​​​通用 ：

• ​​​​​​​其实很多的业务我们都放在了 TiDB，总结起来，通用的接入规范大致就是：

• 表条数过亿，表大小 100G+

• 不涉及交易业务，不影响收入

• 不涉及对外的客户、用户体验等

• 必须有查询

• 有一定详细数据查询需求的分析查询，即 HTAP

• 能接受一定的数据库的不稳定性

• 清晰说明数据库不稳定时主要影响的业务情况

4、总结

4.1、不止 TiDB

没有一种数据库是银弹，多种数据库协作支持是比较好的解决方案

当前 58 的 DBA 支持的数据库如下，希望能够提供丰富的数据库解决方案，总有一款适合你~

MySQL ：关系型数据库

特性：稳定、轻量级、高可用、成熟，指定点恢复

业务：日常的轻量级 OLTP 业务，重要性高的业务

Redis ：NoSQL 缓存型数据库

特性：内存型，Key-Value，轻量、不支持恢复、查询效率高

业务：读流量高、数据变化不频繁的业务

MongoDB ：NoSQL 非关系型数据库

特性：高可用，面向集合存储，模式自由

业务：适用于文档型、地理位置等业务

Elasticsearch ：搜索与数据分析引擎

特性：分布式，可扩展，周边组件配合使用 (例如：filebeat,logstash,kibana 等)，

写入速度快，数据源灵活

业务：日志、搜索型、标签画像业务

TiDB ：NewSQL 分布式关系型数据库

特性：分布式，可扩展，行存 TiKV+ 列存 TiFlash，HTAP（OLTP+OLAP）

业务：日志，报表、监控、大量数据存储需求的、业务重要性要求不高的

SQL：并发写入 (单 value/ 多 value)；并发读；更新 SQL

接入：本地文件 csvload

模型：无模型

DorisDB ：NewSQL 分布式列存数据库

特性：分布式，可扩展、写入速度快，列存，分析 SQL 效率好，支持 SQL

业务：数仓、纯分析业务、大体量报表。

SQL：分批次写入；单 value、并发写入性能不好且会存在一定报错；并发读；不支持更新 SQL

接入：多入口接入：本地文件,HDFS,Kafka 和 S3, 外表 (MySQL,TiDB,ES,Hive),spark 导入等

模型：明细模型，聚合模型，更新模型

Nebula Graph ： 分布式图数据库

语言：声明型的文本查询语言， 类似于 sql 语言

场景：组织架构关系、链路分析、安全风控、图谱挖掘等

目前还在接入业务中

4.2、期许

随着 TiDB 越发的稳定、高性能、多功能，我们使用的场景也越来越多，接入的规范也适当放松了很多，也更大胆的接一些很重要的业务，包括订单业务。

我们当前的集群已经近百套，节点数 1300 左右，多种复杂的场景在应用，可能玩笑的说：只要你量大，那么 TiDB 就是你业务的曙光。

也有越来越多的小伙伴尝试更多的场景，分享使用经验，相信不久的将来，TiDB 能 hold 住更多的场景，给业务赋能。