本文是分布式数据库的总纲文章的第一部分，主要探讨分析性分布式数据库的发展和技术差异；第二部分则是交易性数据库的一些关键特性分析。Ivan开始计划的分布式数据库是不含分析场景的，所以严格来说本篇算是番外篇，后续待条件具备将以独立主题的方式展开。
特别说明：本文是原创文章，首发在DBAplus社群，转载须得作者同意。
正文随着大规模互联网应用的广泛出现，分布式数据库成为近两年的一个热门话题。同样，在银行业主推X86限制主机与小型机的背景下，传统的单机数据库逐渐出现了一些瓶颈，马上会面临是否引入分布式数据库的问题。
近期，Ivan在个人公众号就“银行引入分布式数据库的必要性”做过一些展望，并收到了一些朋友的反馈，除了对分布式数据库具体技术探讨外，还有一类很有趣的建议，“能不能也讲讲Teradata、Greenplum这类MPP，这些也是分布式数据库，但老板总是认为OLTP场景下的才算数”。
的确，为了解决OLAP场景需求，其实很早就出现了分布式架构的产品和解决方案，其与目前的OLTP方案有很多共通的地方。而且Ivan相信，今后OLAP和OLTP两个分支技术的发展也必然是交错前行，可以相互借鉴的。
鉴于此，本文会将OLAP类场景的分布式数据也纳入进来，从两个维度对“分布式数据库”进行拆解，第一部分会横向谈谈不同的“分布式数据库”，把它们分为五类并对其中OLAP场景的三类做概要分析；第二部分结合NoSQL与NewSQL的差异，纵向来谈谈OLTP场景“分布式数据库”实现方案的关键技术要点，是前文的延伸，也是分布式数据库专题文章的一个总纲，其中的要点也都会单独撰文阐述。
首先，Ivan们从横向谈谈不同的“分布式数据库”：
一、万法同宗RDBMS1990年代开始，关系型数据库（RDBMS）成为主流，典型的产品包括Sybase、Oracle、DB2等，同期大约也是国内IT产业的起步阶段。RDBMS的基本特征已有学术上的定义，这里不再赘述。
但从实际应用的角度看，Ivan认为有两点最受关注：
内部以关系模型存储数据，对外支持ANSI SQL接口；
支持事务管理ACID特性，尤其是强一致性（指事务内的修改要么全部失败要么全部成功，不会出现中间状态）。
而后出现的各种“分布式数据库”，大多都是在这两点上做权衡以交换其他方面的能力。
“数据库”虽然有经典定义，但很多大数据产品或许是为了标榜对传统数据库部分功能的替代作用，也借用了“数据库”的名号，导致在实践中这个概念被不断放大，边界越来越模糊。本文一个目标是要厘清这些产品与经典数据库的差异与传承，所以不妨先弱化“数据库”，将其放大为“数据存储”。
那么怎样才算是“分布式数据存储”系统？
“分布式”是一种架构风格，用其实现“数据存储”，最现实的目的是为了打开数据库产品的性能天花板，并保证系统的高可靠，进一步展开，“分布式数据库”的必要条件有两点：
支持水平扩展，保证高性能
通过增加机器节点的方式提升系统整体处理能力，摆脱对专用设备的依赖，并且突破专用设备方案的性能上限。这里的机器节点，通常是要支持X86服务器。
廉价设备+软件，保证高可靠
在单机可靠性较低的前提下，依靠软件保证系统整体的高可靠，又可以细分为“数据存储的高可靠”和“服务的高可靠”。总之，任何单点的故障，可能会带来短时间、局部的服务水平下降，但不会影响系统整体的正常运转。
将这两点作为“分布式数据库”的必要条件，Ivan大致归纳了一下，至少有五种不同的“分布式数据库”：
NoSQL
NewSQL
MPP
Hadoop技术生态
Like-Mesa
注：也许有些同学会提到Kafka、Zookeeper等，这些虽然也是分布式数据存储，但因为具有鲜明的特点和适用场景，无需再纳入“数据库”概念进行探讨。
这五类中，前两类以支持OLTP场景为主，后三类则以OLAP场景为主。Ivan将按照时间线，主要对OLAP场景下的三类进行概要分析。
二、OLAP场景下的分布式数据库1990-2000年代，随着应用系统广泛建设与深入使用，数据规模越来越大，国内银行业的“全国大集中”基本都是在这个阶段完成。这期间，RDBMS得到了广泛运用，Oracle也击败Sybase成为数据库领域的王者。
在满足了基本的交易场景后，数据得到了累积，进一步的分析性需求自然就涌现了出来。单一数据库内同时支持联机交易和分析需求存在很多问题，往往会造成对联机交易的干扰，因此需要新的解决方案。这就为MPP崛起提供了机会。
1. MPPMPP（Massively Parallel Processing）是指多个处理器（或独立的计算机）并行处理一组协同计算[1]。