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住更多的场景，给业务赋能。