TiDB

最新推荐文章于 2025-07-10 14:48:00 发布

转载最新推荐文章于 2025-07-10 14:48:00 发布 · 2.1k 阅读

文章标签：

#数据库

[1]Hive 专栏收录该内容

21 篇文章

订阅专栏

转载自：TiDB：世界级开源 NewSQL 分布式关系型数据库

数据库技术发展演进

在 08 年以前基本上是以单机型数据库为主，比如大家耳熟能详的 Oracle，MySQL，遇到的比如大数据存储、高并发等问题。于是，以 Google 为代表的一些互联网公司开始转向 NoSQL 这种分布式的数据库，这是一个牺牲掉关系的模型去追求可扩展性的方向，那我们有没有办法把单机型的 SQL 的关系模型跟 NoSQL 所带来的分布式的能力结合在一起呢，newSQL，代表产品是 Google 的Spanner/F1

大数据时代传统数据库之困 - 痛点

单机型数据库，一般来说你没有办法很优雅的解决，只能在业务层来做分库分表或者使用中间件等折衷方案
(1)强一致性事务，比如说转账只能在业务层自己来做保证，写很多代码
(2)高可用主从复制,很麻烦
跨数据中心多活、跨数据中心容灾的方案来说，在已有开源实现上基本没有一个方案可以很好的去支持跨数据中心多活的架构，都是通过业务层，或者很重的 DBA 的介入来做这样的事情

Google Spanner/F1:第一个真正意义上 NewSQL

分布式的架构，它可以根据业务压力无限地去做一个水平扩展，或者收缩

上层保证了是一个完整的 SQL 支持，没有做任何妥协，也就是它支持跨行的事务

完整的强一致的 Auto-Failover

真正的 NewSQL？一是我们有水平扩展，而且在水平扩展的过程中是不会将事务和强一致性做任何妥协的，是保证业务层透明的强一致的支持跨行事务的水平扩展。第二是我们能做到跨数据中心的多活，任何一个数据中心宕机，上层的业务是没有感知而且整个集群可以自动的做数据恢复和高可用，不需要任何的人工介入。第三，我们的数据库一定是面向云的架构去做设计的，不会出现一个个数据孤岛的这种状态，我们相当于是一个整体的数据库的解决方案。

TiDB 典型应用场景

首先，如果你在用关系型数据库，比如 MySQL 比如 Oracle 这样的单机关系型 SQL 的数据，当你有水平扩展的需求，当你的数据量比较大已经超出了单机的限制，比如说并发量单机已经扛不住了，但是同时你又不想在业务层做很复杂的分库分表，这时候你可以使用 TiDB。

第二，就是你的数据极端重要，不能容忍任何的数据丢失，不能容忍任何的宕机的时间，这时候你还需要跨数据中心的多活和高可用的话，TiDB 是你唯一的选择。

第三，你需要对你整个业务做云上的改造，但却还在使用单机数据库的话，它一定会成为你整个架构的瓶颈，这时候你需要 TiDB 去帮你解决在云上的数据存储方案。

DB Sharding vs NewSQL

（1）业务的开发工作量的对比，比如说你在用传统的 DB Sharding 的时候，在项目的设计之初，你需要做分库分表、需要做中间件的选型、需要做主备的设计，可能是数以月计的，而且你还要有很强的架构能力去帮实现这事情。

（2）开发阶段，如果你是用传统的单机型数据库或者直接去做业务层的分库分表的话，很多业务的跨库、跨表的事务的查询是没有办法直接在数据库做的，需要业务层对连表查询去做保证，但这个程序的复杂度是非常高的，工作量至少要以月计算的。

（3）扩容，在传统的 DB Sharding 方案上，基本是没有办法去搞定的，复杂度会随着节点数的增加形成指数级的提升。

数据中心高可用、容灾、多活的完美解决方案

（1）DB2 的小型机，或者传统的硬件或者高端存储这种硬件复制的方案，缺点一是价格昂贵，另外，备份是一个冷备，就是当你的主生产中心故障时，还是需要人工手动去切换业务；

（2）Oracle ADG，但是 ADG 的方案和用传统的 DB2 的问题也是一样的，一是需要去额外购买 license，第二是并没有办法做到真正意义上的多活，他的备机也是一个 stand by，仍然在故障的时候没有办法做到秒级的 RTO，还是需要人工的介入，人工去确认数据没有问题，人工去把备机切换上来，这都是故障的隐患。

（3） MySQL这种互联网的开源关系型数据库，没有原生的安全的同步解决方案