昆仑分布式数据库之ScaleOut介绍

一、分布式数据库的基础核心能力-水平扩容（ScaleOut）

数据库系统架构的演变，如实的反映了信息社会不断发展所带来的数据处理规模不断变大这一基本事实。

如今，分布式数据库产品已成为各行各业信息系统的存储服务中，应用越来越广泛的技术选型。究其原因，是因为其在海量数据存储管理的扩展能力和性价比方面，较单机数据库有着压倒性的优势。

在我们对昆仑分布式数据库的扩容功能正式开始介绍之前，我们首先回顾一下数据库管理系统扩容的常见模式。

数据库的扩容大体上分为如下两种模式：垂直扩容（Vertically Scale Up），水平扩容（Horizontally Scale Up）。

- Vertically Scale Up

垂直扩容是指对物理资源，如存储容量、计算能力、网络带宽等资源的扩展。

这种扩容方式由单机物力资源的瓶颈触发，以扩充单机物理资源为解决方案，满足数据库系统对物力资源的需求。然而这种扩容方式的缺点也是显而易见的：单机物理资源总有上限，且一般价格非常昂贵。

- Horizontally Scale Up

水平扩容的基本思路是将数据按照一定的规则分布在不同的物理设备上，整个系统对外仍然呈现逻辑上的单一数据库服务。

系统的扩展方式以通过增加物理设备的个数，来提升数据库的整体对外服务能力。这种扩展模式，可以说在理论上实现了无限扩展。

其中，如果扩展的物理节点，包含了存储能力，则称为share-nothing架构，否则称为share-storage架构。

我们熟知的oracle-RAC就是典型的share-storage架构，所有计算节点共用一套存储服务，而昆仑分布式数据库是典型的share-nothing架构。

如果从物理设备扩展引发的读写冲突的角度来审视这两种架构的优劣的话，share-nothing架构下，数据分片存储在多个存储集群中，分片之间没有交集，因而不会产生多点写入冲突的问题，因此线性扩展能力相对于share-storage有优势，但分布式事务处理和分布式查询处理功能以及自动的、应用无感知的水平弹性扩容等核心功能是在这种架构下必须要实现的功能，只有具备了所有这些功能，才是真正的分布式数据库系统。

这也是为什么分库分表中间件和应用层分库分表已经不再适合当前的技术水平要求—这些技术方案没有上述功能，会给应用开发者和DBA带来沉重的负担和工作量，相当于要在应用代码中case by case实现分布式数据库系统的分布式事务处理和分布式查询处理功能，以及DBA手动停服完成扩容，这些沉重的负担给应用系统的稳定性可靠性带来巨大的风险，并且验证影响客户业务开展和终端用户体验。

昆仑分布式数据库在架构选型时，就充分考虑到了上述的种种问题。基于我们自身对分布式事务处理和分布式查询处理功能以及自动水平扩容的等分布式数据库核心功能的丰富的设计和实现经验以及对相关用户需求的深刻理解，以及对线性扩展性的极致追求，我们在昆仑分布式数据库中实现了基于share-nothing架构的业务无感知的水平弹性扩容机制，更好地满足业务快速增长对数据库系统的服务要求。

二、昆仑分布式数据库ScaleOut功能介绍

2.1 存储层水平扩容

昆仑分布式数据库的存储服务逻辑上由多个独立的MySQL集群组成，每个集群称为一个shard。

每个shard是昆仑分布式数据库存储层的独立的容