我们为什么采用TiDB代替MySQL

Posted 2022-12-09 hanruikai

背景

我们的系统最初采用mysql作为后台数据库，随着数据量的增加，采用业界主流的分库分表方案。但是，随之而来的问题是，增加了应用的复杂度，不利于多维度的数据查询，性能将来也面临挑战。

所以，我们考虑采用TiDB，因为Tidb是分布式数据库，支持二级索引，能够解决多维度查询问题，并且性能很强。

本文，我会介绍我们为什么选择tidb和我们的业务场景，以及tidb如何解决我们的 问题。

为什么是TiDB

最初，我们采用mysql作为后端数据库，随着数据量剧增，我们采用分库分表的方案，但是分库分表的方案有以下劣势：

• 增加应用复杂度，不利于维护
• 不利于多维度查询
• 如果shard之间负载不均衡，需要重新reshard

基于上面的背景，我们寻找新的数据库方案。

TiDB是一个开源的分布式数据库，支持mysql协议，支持水平扩展，强一致性和高可用，对于OLAP和OLTP提供了一站式解决方案，架构图如下：

其他细节，参考下面的文献：

https://docs.pingcap.com/tidb/stable/tidb-architecture

TiDB吸引我们的优点有以下几点：

• 兼容MySQL语法，协议功能，方便迁移
• 支持水平扩容收缩
• 高可用和强一致性保证

所以我们采用了Tidb作为数据库方案。

 

我们如何使用Tidb

Tidb在以下场景解决了我们很多问题，一个一个分析。

• 处理大量数据，高并发写入

比如我们的课堂trouble shooting 系统，主要负责解决上课系统可能出现的问题，包括切换线路、提高画面质量等各种情况。

该系统需要从家长端和教师端实时收集信息，比如进入、离开课堂，课程开始、打开麦克风等操作，数据量非常大，实时性要求高。系统技术点如下：

1. 系统当前峰值的TPS为10000
2. 每天增加1800W行记录，
3. 保存最近两个月的记录
4. 当前一个表保存12亿数据，如果用mysql，显然扛不住

迁移到Tidb的过程中，我们进行了两个改动：

• 废弃自增id
• 提前建立分区定义

 

• 多维度查询实现

最初使用mysql的时候，我们采用shard方案，一般在shard的时候，只能采用一个列进行sharding，作为sharding key。

当时，比如一个定时任务，涉及教师、学生、课堂、课程等多个维度，而且其他应用也会访问数据。

比如当老师访问数据的时候，数据是依据老师的角度组织的，如果按照学生的角度组织，老师的请求就无法处理了。

因此，我们把所有的shard数据迁移到tidb，整合成一个全局表。Tidb有工具可以整合，如下：

https://docs.pingcap.com/tidb-data-migration/stable/overview

 

 

• 数据生命周期管理

如果利用mysql，数据的后期管理成本很大。利用tidb，我们把数据进行分级，包括冷数据、热数据等。

如果后期数据迁移，增加修改列，tidb的性能远远 高于mysql，tidb增加或者减少一个列在秒内就可以完成。

 

• 实时数据分析

此场景主要是BI团队使用，我们使用 TiDB Data Migration (DM) 工具拷贝所有的数据到Tidb，利用tidb的水平扩展和计算能力，进行实时数据分析。

 

TiDb 4.0的变化

TiDb4.0带了了新的存储引起，TiFlash，TiFlash是一个新的扩展存储引擎，支持HTAP分析。

随着互联网的发展，企业的业务数据量不断增多，单机数据库的容量限制制约了其在海量数据场景下的使用。因此在实际应用中，为了面对各种需求，OLTP、OLAP 在技术上分道扬镳，在很多企业架构中，这两类任务处理由不同团队完成。当物联网大数据应用不断深入，具有海量的传感器数据要求实时更新和查询，对数据库的性能要求也越来越高，此时，新的问题随之出现：

1. OLAP 和 OLTP 系统间通常会有几分钟甚至几小时的时延，OLAP 数据库和 OLTP 数据库之间的一致性无法保证，难以满足对分析的实时性要求很高的业务场景。
2. 企业需要维护不同的数据库以便支持两类不同的任务，管理和维护成本高。

因此，能够统一支持事务处理和工作负载分析的数据库成为众多企业的需求。在此背景下，由 Gartner 提出的 HTAP（混合事务 / 分析处理，Hybrid Transactional/Analytical Processing）成为希望。基于创新的计算存储框架，HTAP 数据库能够在一份数据上同时支撑业务系统运行和 OLAP 场景，避免在传统架构中，在线与离线数据库之间大量的数据交互。此外，HTAP 基于分布式架构，支持弹性扩容，可按需扩展吞吐或存储，轻松应对高并发、海量数据场景。

目前，实现 HTAP 的数据库不多，主要有 PingCAP 的 TiDB、阿里云的 HybridDB for MySQL、百度的 BaikalDB 等。其中，TiDB 是国内首家开源的 HTAP 分布式数据库。

 

PingCAP 高级技术总监、CMC 成员、华南区总经理姚维表示：“我们经过两年多的内部开发，终于将 OLAP 和 OLTP 真正放在同一套 TiDB 集群上，让 TiDB 可以同时支持联机交易和海量的数据分析。并且这两种计算在内部转换的过程对用户是透明的。”通过底层数据同步及行列透明转换的技术，TiDB 将 TiKV 面向联机交易的行存式引擎与 TiFlash 面向实时分析场景的列存引擎，转为真正的行列混合数据架构。同时，该版本在 TiDB 分布式计算层实现了透明的可根据请求自动选择行列存储引擎的能力，使高并发、低延迟的联机交易与海量数据实时分析查询计算，在 TiDB 新一代架构上完美地融合在一起。

参考文献：

https://en.pingcap.com/case-studies/why-we-chose-a-distributed-sql-database-to-complement-mysql