从架构特点到功能缺陷，重新认识分析型分布式数据库

随着大规模互联网应用的广泛出现，分布式数据库成为近两年的一个热门话题。同样，在银行业主推X86限制主机与小型机的背景下，传统的单机数据库逐渐出现了一些瓶颈，马上会面临是否引入分布式数据库的问题。

近期，我在个人公众号就“银行引入分布式数据库的必要性”做过一些展望，并收到了一些朋友的反馈，除了对分布式数据库具体技术探讨外，还有一类很有趣的建议，“能不能也讲讲Teradata、Greenplum这类MPP，这些也是分布式数据库，但老板总是认为OLTP场景下的才算数”。

的确，为了解决OLAP场景需求，其实很早就出现了分布式架构的产品和解决方案，其与目前的OLTP方案有很多共通的地方。而且我相信，今后OLAP和OLTP两个分支技术的发展也必然是交错前行，可以相互借鉴的。

鉴于此，本文会将OLAP类场景的分布式数据也纳入进来，从两个维度对“分布式数据库”进行拆解，第一部分会横向谈谈不同的“分布式数据库”，把它们分为五类并对其中OLAP场景的三类做概要分析；第二部分结合NoSQL与NewSQL的差异，纵向来谈谈OLTP场景“分布式数据库”实现方案的关键技术要点，是前文的延伸，也是分布式数据库专题文章的一个总纲，其中的要点也都会单独撰文阐述。

首先，我们从横向谈谈不同的“分布式数据库”：

一、万法同宗RDBMS

1990年代开始，关系型数据库（RDBMS）成为主流，典型的产品包括Sybase、Oracle、DB2等，同期大约也是国内IT产业的起步阶段。RDBMS的基本特征已有学术上的定义，这里不再赘述。

但从实际应用的角度看，我认为有两点最受关注：

内部以关系模型存储数据，对外支持ANSI SQL接口；

支持事务管理ACID特性，尤其是强一致性（指事务内的修改要么全部失败要么全部成功，不会出现中间状态）。

而后出现的各种“分布式数据库”，大多都是在这两点上做权衡以交换其他方面的能力。

“数据库”虽然有经典定义，但很多大数据产品或许是为了标榜对传统数据库部分功能的替代作用，也借用了“数据库”的名号，导致在实践中这个概念被不断放大，边界越来越模糊。本文一个目标是要厘清这些产品与经典数据库的差异与传承，所以不妨先弱化“数据库”，将其放大为“数据存储”。

那么怎样才算是“分布式数据存储”系统？

“分布式”是一种架构风格，用其实现“数据存储”，最现实的目的是为了打开数据库产品的性能天花板，并保证系统的高可靠，进一步展开，“分布式数据库”的必要条件有两点：

支持水平扩展，保证高性能

通过增加机器节点的方式提升系统整体处理能力，摆脱对专用设备的依赖，并且突破专用设备方案的性能上限。这里的机器节点，通常是要支持X86服务器。

廉价设备+软件，保证高可靠

在单机可靠性较低的前提下，依靠软件保证系统整体的高可靠，又可以细分为“数据存储的高可靠”和“服务的高可靠”。总之，任何单点的故障，可能会带来短时间、局部的服务水平下降，但不会影响系统整体的正常运转。

将这两点作为“分布式数据库”的必要条件，我大致归纳了一下，至少有五种不同的“分布式数据库”：

NoSQL

NewSQL

MPP

Hadoop技术生态

Like-Mesa

注：也许有些同学会提到Kafka、Zookeeper等，这些虽然也是分布式数据存储，但因为具有鲜明的特点和适用场景，无需再纳入“数据库”概念进行探讨。

这五类中，前两类以支持OLTP场景为主，后三类则以OLAP场景为主。我将按照时间线，主要对 OLAP场景 下的三类进行概要分析。

二、OLAP场景下的分布式数据库

1990-2000年代，随着应用系统广泛建设与深入使用，数据规模越来越大，国内银行业的“全国大集中”基本都是在这个阶段完成。这期间，RDBMS得到了广泛运用，Oracle也击败Sybase成为数据库领域的王者。

在满足了基本的交易场景后，数据得到了累积，进一步的分析性需求自然就涌现了出来。单一数据库内同时支持联机交易和分析需求存在很多问题，往往会造成对联机交易的干扰，因此需要新的解决方案。这就为MPP崛起提供了机会。

1

MPP

MPP（Massively Parallel Processing）是指多个处理器（或独立的计算机）并行处理一组协同计算[1]。

为了保证各节点的独立计算能力，MPP数据库通常采用ShareNothing架构，最为典型的产品是Teradata（简称TD），后来也出现Greenplum（简称GPDB）、Vertica、Netezza等竞争者。

架构特点：

MPP是多机可水平扩展的架构，符合“分布式”的基本要求，其中TD采用外置集中存储而GPDB直接使用本地磁盘，从这点来说GPDB是更彻底的Share Nothing架构。

考虑到TD商业策略上采用一体机方案，不具有开放性，而GPDB具有较高的开源程度，下文中通过分析后者架构特点来分析MPP工作机制。

GPDB属于主从架构[2]，Slave称为Segment是主要的数据加工节点，是在PostgreSQL基础上的封装和修改，天然具备事务处理的能力，可进行水平扩展；集群内有唯一Active状态的Master节点，除了元数据存储和调度功能外，同时承担一定的工作负载，即所有外部对集群的数据联机访问都要经过Master节点。

在高可靠设计方面，首先设置了Standby Master节点，在Master节点宕机时接管其任务，其次将Segment节点则细分为两类不同角色Primary和Mirror，后者是前者的备节点，数据提交时在两者间进行强同步，以此保证Primary宕机时，Mirror可以被调度起来接替前者的任务。

数据分析性需求对IT能力的要求包括：

复杂查询能力；

批量数据处理；

一定的并发访问能力。

MPP较好的实现了对上述能力的支撑，在前大数据时代得到了广泛的应用，但这个时期的数据总量相对仍然有限，普遍在TB级别，对应的集群规模也通常在单集群百节点以下。

随着数据价值关注度的不断提升，越来越多的数据被纳入企业分析范围；同时实际应用中考虑到数据存储和传输成本，往往倾向于将数据集中在一个或少数几个集群中，这样推动了集群规模的快速增长。

在大规模集群（几百至上千）的使用上，MPP从批处理和联机访问两个方面都显现了一些不足。以下内容主要借鉴了Pivotal（GPDB原厂）的一篇官方博客[3]。