摘要：分布式数据库系统是与计算机网络相结合的一个系统，分布计算主要体现在客户机/服务器模式和分布式数据库体系结构两个方面。同时这种组织数据库的方法克服了物理中心数据组织的弱点，降低了数据传送代价，提升了系统可靠性，便于系统的扩充。

关键词：分布式；关系型数据库；高可用；水平扩展；分布式事务

一、分布式数据库的产生背景

　　很多零售企业的核心资产是各种各样的商业数据，例如商品、交易、订单、会员等等，这些数据通常是结构化的，并且数据之间存在各种各样的关联，传统的关系数据库曾经是这些数据的最佳载体。然而，随着业务的快速发展，这些数据急剧膨胀，记录数从几千万条增加到数十亿条，数据量从百GB增加到数TB，未来还可能增加到数千亿条和数百TB，传统的关系型数据库已经无法承担如此海量的数据。分布式数据库就是用于解决不断增加的结构化数据存储与查询的问题。

　　从Eric Brewer教授的CAP（一致性C: Consistency，可用性A: Availability，分区容错性P: Tolerance of network Partition）理论角度分析，作为传统企业的IT架构，做大业务对一致性和可用性的要求高于分区容错性，数据特征是数据总量庞大且逐步增加，单位时间内的数据更新量并不大，但实时性要求很高。这就要求我们提供一套更加偏重于支持CA特性的系统，同时兼顾可分区性，并且在实时性、成本、性能等方面表现良好。

二、什么是分布式数据库

　　分布式数据库系统通常使用廉价的服务器，每台服务器上都有DBMS的一套完整拷贝副本，并具有局部的数据库。位于不同地点的许多廉价服务器通过网络互相连接，共同组成一个完整的、全局的大型数据库。这种组织数据库的方法克服了物理中心数据库组织的弱点。首先，降低了数据传送代价，因为大多数的对数据库的访问操作都是针对局部数据库的，而不是对其他位置的数据库访问；其次，系统的可靠性提高了很多，因为当网络出现故障时，仍然允许对局部数据库的操作，而且一个位置的故障不影响其他位置的处理工作，只有当访问出现故障位置的数据时，在某种程度上才受影响；第三，便于系统的扩充，增加一个新的局部数据库，或在某个位置扩充一台适当小型服务器，都很容易实现。

　　分布式关系型数据库的特点：

　　多数处理就地完成

　　服务器间由数据通信网络相联系

　　克服了中心数据库的弱点，降低了数据传输代价

　　提高了系统的可靠性，局部系统发生故障，其他部分还可继续工作

　　各个数据库的位置是透明的，方便系统的扩充

　　为了协调整个系统的事务活动，事务管理的性能花费高

三、数据分片

　　分布式数据库系统经常对数据库进行数据分片。从数据意义上讲，数据分布的合理与否不仅影响着访问的局部性，而且也制约着数据查询及事务处理的效率。
　　在分布式数据库中，数据存储包括数据分片和数据分配两个部分。数据分片和分配是分布式数据库中两个重要慨念，分布式数据库大部分问题均与数据分片和分配有关，它们对整个系统的可用性、可靠性、及效率都有极大的影响，同时也与分布式数据库系统的其他方面密切相关，尤其是分布式查询处理问题。以关系数据库为例，在关系型分布式数据库系统中，数据分片是从逻辑上将全局关系划分为逻辑片断即子关系，而数据分配就是再以一定的冗余度将子关系分配到多个结点上，数据存储即数据分片与数据分配的总和。

　　数据分片的类型：

　　水平分片：按一定的条件把全局关系的所有元组划分成若干不相交的子集，每个子集为关系的一个片段

　　垂直分片：把一个全局关系的属性集分成若干子集，并在这些子集上作投影运算，每个投影称为垂直分片

　　导出分片：又称为导出水平分片，即水平分片的条件不是本关系属性的条件，而是其他关系属性的条件

　　数据分配的类型：

　　集中式：所有数据片段都安排在同一个场地上

　　分割式：所有数据只有一份，它被分割成若干逻辑片段，每个逻辑片段被指派在一个特定的场地上

　　全复制式：数据在每个场地重复存储，也就是每个场地上都有一个完整的数据副本

四、分布式数据库设计原则

　　分布式数据库中，由于数据的分布和冗余，使得查询处理中需要考虑站点间传输数据的通信费用，所以除了考虑CPU代价和I\O代价之外，还应该包括数据在网络上的传输代价。即总代价=CPU代价+I\O代价+通信代价。因此，分布式数据库进行分布式设计时，一个重要原则是使数据和应用程序实现最大程度的本地性，这样就可以使应用数据尽可能地本地化，以减少通信开支。

五、分布式数据库设计思路

　　分布式数据库目标是支持数百TB的数据量以及数十万TPS、数百万QPS的访问量。无论是数据量还是访问量，即使采用非常昂贵的小型机甚至是大型机，单台关系数据库系统都无法承受。当前常见的处理方法主要有以下两种：

　　一种常见的做法是根据业务特点对数据库进行水平拆分。根据某个业务字段，通常取用户编号，哈希后取模，根据取模的结果将数据分布到不同的数据库服务器上，客户端请求通过数据库中间层路由到不同的分区。这种方式目前还存在一定的弊端：

　　第一，数据和负载增加后添加机器的操作比较复杂，需要人工介入。

　　第二，有些范围查询需要访问几乎所有的分区，例如，按照用户编号分区，查询收藏了某个商品的所有用户需要访问所有的分区。

　　第三，目前广泛使用的关系数据库存储引擎都是针对机械硬盘的特点设计的，不能够完全发挥新硬件（SSD）的能力。

　　另外一种做法是参考分布式表格系统的做法。例如Google Bigtable系统，将大表划分为几万、几十万甚至几百万个子表，子表之间按照主键有序，如果某台服务器发生故障，它上面服务的数据能够在很短的时间内自动迁移到集群中所有的其它服务器。这种方式解决了可扩展性的问题，少量突发的服务器故障或者增加服务器对使用者基本是透明的，能够轻松应对促销或者热点事件等突发流量增长。另外，由于子表是按照主键有序分布的，很好地解决了范围查询的问题。

　　万事有其利必有一弊，分布式表格系统虽然解决了可扩展性问题，但往往无法支持事务。例如Bigtable只支持单行事务，针对同一个user_id下的多条记录的操作都无法保证原子性。而零售企业所需要的分布式数据库架构希望能够支持跨行跨表事务，这样使用起来会比较方便。

　　最直接的做法是在Bigtable开源实现（如HBase或者Hypertable）的基础上引入两阶段提交（Two-phase Commit）协议支持分布式事务，这种思路在Google的Percolator系统中得到了体现。然而，Percolator系统中事务的平均响应时间达到2~5秒，只能应用在类似网页建库这样的半线上业务中。另外，Bigtable的开源实现也不够成熟，单台服务器能够支持的数据量有限，单个请求的最大响应时间很难得到保证，机器故障等异常处理机制也有很多比较严重的问题。总体上看，这种做法的工作量和难度超出了普通零售企业的承受能力，因此，往往需要根据企业的业务特点在以上的思路中做一些定制。

　　以企业经营商品的库存信息数据库为例，随着经营渠道及商品的扩展，有可能达到上千万级别，而且每年的数据都会增长，同时由于每天的交易数也非常活跃，所以对商品库存的访问量也是相当大的。更比如在一些高峰期，比如节假日或者大促，一天的访问量可能就是平常的好几倍。针对此类应用带来的高可用，高性能，低成本的扩展诉求，可以通过采用分布式数据库的sharding方案，对大表数据水平切割，主从备份，读写分离，同时与Cache系统结合来实现高并发的读写服务，从而为上商品库存计算带来更高的吞吐能力及安全性。

文/王新