MySQL已死，TiDB横行

马士兵 2021-09-24

1080

在不知不觉中，外面的世界，已经变成了数据的世界！

根据IDC的统计，全球数据量在2020年达到了44ZB，很多人看不懂"ZB"，哈哈，解释一下：1ZB = 1024 * 1024 * 1024 * 1024 * 1024 个MB，总之就是很多很多数据啦。

这其中，中国占了五分之一，具体数字自己算。在中国，每个人每天会产生1.5G的数据，每辆车每天会产生4T的数据，没错，我们每个人都是行走的数据源。

大量数据带给企业的，是容量上的挑战，并发上的挑战，扩容上的挑战，数据孤岛不断诞生的挑战，还有，为了追求效率所面临的实时计算的挑战。

当然，大量的数据同时带来的还有机遇，企业可以更加精确的获得用户画像，商家可以很方便的做出实时决策，工厂也可以依据数据进行精准的成本控制。

不管你接不接受，数据化时代的大浪，正裹挟着海量的数字呼啸而来！

面对扑面而来、遮天蔽日的数据量，传统存储架构已经变得越来越吃力

挡不住的数据量就像洪水，一浪接一浪，以MySQL为首的传统数据库已经越来越感觉到吃不消。

MySQL面对海量数据的处理方案往往是分库分表，但是这种方案的弊端非常的明显：

1、对DBA的技能要求很高
2、无法应对Schema经常变化的情况（这种在系统开发初期非常常见）
3、无法进行查询优化甚至不能充分利用二级索引
4、对于流行的两地三中心的容灾方案支撑力度不足
5、最重要的，还是对于BI、可视化、决策支撑、AI数据分析等应用的解决方案很不给力

MySQL对于大量数据OLAP的解决方案

MySQL、Oracle等传统库出生那一天就是为了OLTP而设计，面向OLAP的应用一定会力不从心，所以，MySQL的解决方案是借助外力，就像这样：

这种传统的方案被称之为TP + ETL + AP的解决方案，这种方案的弊端明显：

1、ETL操作非常昂贵，需要大量人力物力财力，以及具备专业技能的技术人员
2、一套TP的实现，有的时候需要对应多套AP的实现，操作难度比较大
3、很难实现实时分析，很难做到及时决策

MongoDB的解决方案和弊端

面对MySQL的短板，各种NewSQL数据库横空出世，这其中的佼佼者，当属Mongo！作为面向纯AP的数据库，Mongo的长处显而易见，例如：天生分布式、底层就支持无缝扩容，比MySQL手工的分库分表要简洁的多，对于AP操作，直接支持的毫秒级别，在大多数的时间，可以省略缓存层，想象一下你的架构里可以省略REDIS集群，哈哈，世界是不是美好了一些。

正因为这些优点，很多的中型电商就直接使用Mongo来进行存储和分析，调查下来要比MySQL的开发效率提高3倍。

但是，凡事有一利必有一弊：

Mongo的短板也非常明显，那就是天然不支持TP！如果需要数据一致性的话，不好意思，程序员自己在程序逻辑里完成，这就意味着数据可以随意的入库，逻辑只能靠程序员自己写。

结果就造成了程序员们的五花八门、千奇百怪的各种解决方案，开发成本大幅度的上升。

HTAP数据库带来曙光

如果我们把MySQL当成处理TP操作的一极，那么Mongo就是处理AP操作的另一极，有没有一种处在中间位置的，即能进行事务处理，又有AP的极致性能，同时还能做到运维友好，不用分库分表的数据库吗？（这就是传说中的大数据湖仓一体）

HTAP数据库挺身而出：我最能打！

HTAP的全称叫做：混合事务和分析处理数据库，这个领域产品的典型代表，就是鼎鼎大名的TiDB。

有请TiDB闪亮登场！TiDB带来TP + AP完美方案，作为特别能打的一款数据库产品，TiDB的优势非常明显：

1、底层支持天然分布式，无缝扩展
2、天然数据强一致高可用
3、对ACID事务完美支持
4、标准SQL不用换语言
5、兼容MySQL协议，MySQL分分钟升级TiDB
6、天然支持数据库云原生DBaaS
7、故障自动恢复，无需人工介入
8、多源高吞吐性能强劲
9、天然支持实时计算，支撑及时决策
10、天然支持两地三中心容灾多活
11、跟ETL再见，再也不需要成本昂贵的ETL
12、（敲黑板）再也不需要分库分表，业务不再受制于基础架构