云时代的分布式数据库：阿里分布式数据库服务DRDS.pdfVIP

云时代的分布式数据库：阿里分布式数据库服务DRDS

摘要：伴随着系统性能、成本及扩展性的新时代需要，以HBase、MongoDB为代表的NoSQL数据

库和以阿里DRDS、VoltDB、ScaleBase为代表的分布式NewSQL数据库如雨后春笋般不断涌现出来。

本文详细介绍了阿里分布式数据库服务DRDS。

随着互联网时代的到来，计算机要管理的数据量呈指数级别地飞速上涨，而我们却完全无法对用

户数做出准确预估。我们的系统所需要支持的用户数，很可能在短短的一个月内突然爆发式地增长几

千倍，数据也很可能快速地从原来的几百GB飞速上涨到了几百个TB。如果在这爆发的关键时刻，系

统不稳定或无法访问，那么对于业务将会是毁灭性的打击。

伴随着这种对于系统性能、成本以及扩展性的新需要，以HBase、MongoDB为代表的NoSQL数据

库和以阿里DRDS、VoltDB、ScaleBase为代表的分布式NewSQL数据库如雨后春笋般不断涌现出来。

本文将会介绍阿里DRDS的技术理念、发展历程、技术特性等内容。

DRDS设计理念

从20世纪70年代关系数据库创立开始，其实大家在数据库上的追求就从未发生过变化：更快的

存取数据，可以按需扩缩以承载更大的访问量和更大的数据量，开发容易，硬件成本低，我们可以把

这叫做数据库领域的圣杯。

为了支撑更大的访问量和数据量，我们必然需要分布式数据库系统，然而分布式系统又必然会面

对强一致性所带来的延迟提高的问题，因为网络通信本身比单机内通信代价高很多，这种通信的代价

就会直接增加系统单次提交的延迟。延迟提高会导致数据库锁持有时间变长，使得高冲突条件下分布

式事务的性能不升反降（这个具体可以了解一下Amdahl定律），甚至性能距离单机数据库都还有明

显的差距。

从上面的说明，我们可以发现，问题的关键并不是分布式事务做不出来，而是做出来了却因为性

能太差而没有什么卵用。数据库领域的高手们努力了40年，但至今仍然没有人能够很好地解决这个

问题，GoogleSpanner的开发负责人就经常在他的Blo上谈论延迟的问题，相信也是饱受这个问题

的困扰。

面对这个难题，传统的关系数据库选择了放弃分布式的方案，因为在20世纪70~80年代，我们

的数据库主要被用来处理企业内的各类数据，面对的用户不过几千人，而数据量最多也就是TB级别。

用单台机器来处理事务，用个磁盘阵列处理一下磁盘容量不够的问题，基本上就能解决一切问题了。

然而，信息化和互联网的浪潮改变了这一切，我们突然发现，我们服务的对象发生了根本性变化，

从原来的几千人，变成了现在的几亿人，数据量也从TB级别到了PB级别甚至更多。存在单点的单机

系统无论如何努力，都会面对系统处理能力的天花板。原来的这条路，看起来是走不下去了，我们必

须想办法换一条路来走。

可是，分布式数据库所面对的强一致性难题却像一座高山，人们努力了无数个日日夜夜，但能翻

越这座山的日子看来仍然遥遥无期。

于是，有一群人认为，强一致性这件事看来不怎么靠谱，那彻底绕开这个问题是不是个更好的选

择？他们发现确实有那么一些场景是不需要强一致事务的，甚至连SQL都可以不要，最典型的就是日

志流水的记录与分析这类场景。而去掉了事务和SQL，接口简单了，性能就更容易得到提升，扩展性

也更容易实现，这就是NoSQL系统的起源。

虽然NoSQL解决了性能和扩展性问题，但这种绕开问题的方法给用户带来了很多困扰，系统的开

发成本也大大提升。这时候就有另外一群人，他们觉得用户需要SQL，觉得用户也需要事务，问题的

关键在于我们要努力地往圣杯的方向不断前进。在保持系统的扩展性和性能的前提下，付出尽可能小

的代价来满足业务对数据库的需要。这就是NewSQL这个理念的由来。

DRDS也是一个NewSQL的系统，它与ScaleBase、VoltDB等系统类似，都希望能够找到一条既能

保持系统的高扩展性和高性能，又能尽可能保持传统数据库的ACID事务和SQL特性的分布式数据库

系统。

DRDS发展历程

在一开始，TDDL的主要功能就是做数据库切分，一个或一组SQL请求提交到TDDL，TDDL进行规

则运算后得知SQL应该被分发到哪个机器，直接将SQL转发到对应机器即可（如图1）。

图1TDDL数据库切分

开始的时候，这种简单的路由策略能够满足用户的需要，我们开始的那些应用，就是通过这样非

常简单的方式完成了他所有的应用请求