可扩展数据库（下）

数据库层的扩展是典型云应用五层架构中的第四层，也是最复杂的一层（有人认为可扩展存储系统更为复杂，笔者以为，取决于业务应用模式。对于存在复杂交易处理类型的应用，其数据库层实现的挑战显然更高；而对于单纯的海量数据简单事件处理型应用，数据库层甚至不需要存在，而云存储层的实现则更为复杂）。

数据库扩展大体有如下四类解决方案：

·Scale-Up ·Master-Slaves（一主多仆）读代理模式

·Master-Master模式 ·Sharding模式

---

【书接上文】以下图中的分布式数据库为例，我们可以如下设计数据库CS中的表以确保在旧金山（SF）、纽约（NY）和达拉斯（DL）的Master节点可以同时完成写操作并且不会出现冲突（见下表）。

三个数据库节点（集群）间的同步

三个Master数据库节点如何避免写入区域重叠

参数	Master SF	Master NY	Master DL
起始Id （如主键）	1	2	3
Increment by	10	10	10
可能数值	1,11,21,31,41…	2,12,22,32…	3,13,23,33…

（4）分区（Partitioning）模式

数据库分区通常有如下两种模式：

· 水平分区（Horizontal Partitioning）

· 垂直分区（Vertical Partitioning）

水平分区又常被称作Sharding（分表），是谷歌公司的工程师最早在BigTable项目中使用的技术。简单而言，Sharding的主旨就是按照一定的规则把一张表中的行水平切分放置到多个表中，而这些新表被水平地放置到不同的物理节点上，以此实现高I/O。

垂直分区则是按照列来切分一张表，分区后的每张表通常列数较少。值得指出的是，垂直分区有些类似于数据库正则化操作（Normalization），但不同的是，即便是已经正则化的表，依然可以在其上进行垂直分区以实现水平扩展来提高系统综合性能。因此我们通常也把垂直分区叫作Row Splitting（行分操作）。

数据库分区一般遵循简单的逻辑规则，总结如下四条：

·范围分区（Range Partitioning）

·列表分区（List Partitioning）

· 哈希分区（Hash Partitioning）

·组合分区（Composite Partitioning）

范围分区比较容易理解。例如电商数据库中按照商品的销售价格范围来分区，0～10元，10～25元，25～50元，50～100元，100～250元，250～500元，500～1,000元，1,000元以上，可以把原表中的商品以价格为key分成8张表。

列表分区也非常简便。例如在微信数据库后台，如果按照注册用户所在省或直辖市信息（该数据既可以通过注册信息来提取，也可以通过对注册IP地址来自动分析获取）分表，可以分成北京、上海、广东等几十张表。

哈希分区通常是对某个表中的主键进行哈希（或取余）运算后来对表进行分区，参考图下图中的三张表，users、group messages与photo albums都采用了哈希运算后水平分为n张表（第四张表events则采用的是典型的范围分区方式）。

组合分区则是以上3种方法的组合而成的复合分表方法。

下图展示了垂直分区与水平分区如何协同工作。应用服务器访问的数据库Single先是被垂直分区，每个表形成了一个独立的数据库逻辑节点，每个节点之上又可以继续水平分区形成多个细分逻辑节点。这样二层（甚至更多层）分区可以对数据库层系统实现充分的水平扩展以获取更高的系统并发性能。

图：数据库sharding（水平分区）

分区之后，数据库系统的物理与逻辑构造会因高度分布性而变得复杂，但是在SQL及编程访问API角度看并没有（也不应该）产生任何变化。这样就保证了系统在内核经过分区操作后的向后兼容性。在实现方法上，应用层所看到的数据库依然可以是一个完整的数据库及表，但是这只是逻辑上的概念（例如：view），数据库系统内核要负责实现对分区节点的并发访问。

分区的实现方法较之前的Master-Slave或Master-Master模式具有一个明显的优势就是不同层之间交互的复杂度大大降低。在Master-Slave/Master模式中，应用层通常需要有明确的逻辑判断来确保写与读面向哪个节点，而在分区实现方法中则对应用层逻辑可以完全透明。

上面我们介绍了传统数据库的分布式设计方法，在新型的数据库，例如图数据库和一些NewSQL类数据库中，它们的分布式架构的设计和SQL类数据库会有很多差异性，大体有如下几种设计模式：

1. 热备份模式：例如Neo4j的企业级版本就是典型的采用3节点热备份模式。这种模式的优点就是“高可用”，但是缺点确比较明显，并没有增加系统整体负载能力。

2. 分布式共识模式：RAFT算是一种典型的分布式共识算法，但是原生的RAFT依然存在很多缺陷，因此有很大的模式增强和提升的空间。在同一个集群内，不同的节点有不同的角色分配，并且可以做到系统负载的随节点增加的线性负载能力提升。

3. 水平分布式系统：在模式上面最早的谷歌的GFS/BigTable/MapReduce，以及Spanner系统等算是开创了这种大规模水平分布式系统的设计思路，包括Hadoop/Spark等系统，都有类似的“分而治之”的设计模式。简单而言就是通过在集群中设置有不同的”角色“节点，例如计算节点、存储节点、NameServer节点、ID-Server节点等等。这其中比较复杂的是图数据库，因为图数据库中的数据是高度关联的，按照传统的暴力分表的模式，无论是partitioning还是sharding，根本不可能让分图后的图数据库具备跨节点的高性能和实时数据处理能力。这个时候就需要一整套完整的工具链条和逻辑来实现更智能化的切图的。在之后的文章中，我们会单辟章节来介绍水平分布式图数据库的架构设计。记住一点：现在市场上的所有的开源的图数据库，没有一个不是暴力切图的逻辑，无论它是点切还是边切，这种系统根本没有能力做深度的（穿透3层以上）数据关联查询，更不用说做到实时计算了。