【预告】千亿数据的潘多拉魔盒：从分库分表到分布式数据库

近年来，随着国内互联网行业的加速发展，以及摩尔定律的实效，千亿数据的潘多拉魔盒早已打开，传统的开源/商业关系数据库早已遇到了容量的瓶颈。而容量告警则不仅意味着业务发展收到影响，同时对现有系统的稳定性和可用性、可维护性，也带来极大的挑战。



从十年前起，淘宝等公司就遇到这类制约业务发展的技术问题，进而有了 TDDL 框架，2016 年当当网也发起了 Sharding-JDBC 项目，通过包装 JDBC，来屏蔽 MySQL 分库分表的逻辑，让业务系统想使用单机数据库一样方便。



后来，JDBC 封装框架逐渐演变到中间件，在 TDDL 的基础上，淘宝逐渐发展出来了 DRDS，在 Sharding-JDBC 转移到 Apache 和京东数科以后又孵化出来了 Sharding-Proxy，都是以一个虚拟的 MySQL Server 提供更透明和无侵入的客户端接入服务。其他的中间件，像 MyCat 和 DBLE 也方兴未艾。



另一方面，随着 Google 的 Spanner，阿里的 OceanBase 和 PolarDB，AWS 的 Aurora，PingCAP 的 TiDB，Cockroachlabs 的 CockroachDB 等商业或开源的技术作为代表，分布式数据库开始大规模兴起。这些技术试图通过一个直接的数据库来解决上述问题，而不仅仅是类库或中间件，这种增强 MySQL/PGSQL 的间接方式。当然，分布式数据库本身的复杂度，是另外一个话题。



以上种种对于企业来说，都是试图通过采用类似 Apache ShardingSphere 这种分布式的数据库中间件、或者 CockroachDB 这种分布式数据库作为整体解决方案，增强数据库的吞吐能力，保证高可用和实时强一致性的同时，实现线性的水平扩展能力，在一定规模上提升企业信息系统的数据管理上限。本文将从这个整体的发展过程谈起，详细介绍每一个阶段技术的特点、解决的问题，适用的场景，带领大家了解千亿数据的秘密。



计划写作大纲：



• 从单机数据库讲起

• MySQL 的高可用与短板

• 分库分表的优势与陷阱

• 哪些场景下我们需要用分库分表

• 数据库中间件的技术选型

• 什么时候引入数据库中间件

• NoSQL 与 NewSQL

• 当我们谈分布式数据库的时候，我们在谈什么典型的

• 几个分布式数据库