分布式OLTP数据库选型---汇报

汇报思路

  开场：各位好，分布式数据库经近个月的集中调研，目前有了阶段性的进展，现就调研的结果对各位领导做一个详细的汇报。

  本次汇报共16页PPT。汇报思路为：漏斗形，有宽到窄的一个思路体系。

  汇报时间我会控制在30分钟内，先总体做串讲，完了针对有疑问的地方我们进行详细的分析讨论。

  下面就开始我们本次的汇报。

P1 背景

  谈到分布式，会不可避免的想到一个问题，分布式数据库是来干什么的？解决什么核心问题的？这个问题我曾在同行DBA中做过一个简单的调研，得到的答案是：80%的人回答的是：存储、成本。的确，分布式解决的最核心问题应该是存储，只有能包住我们的数据，在我们数据迅速增长的情况下，能方便的弹性水平扩容是我们关心分布式DB的原因之一。其二是成本。

  我这里有一个资料，是关于银联当时做分布式数据库的成本调研，从详细的对比看，同样是承载30T的业务数据，分布式的成本远远低于Oracle垂直架构方案，且不说性能平均要提高3倍。

  第三个是发展趋势。无论OLAP，OLTP发展的趋势均是朝着分布式的方向发展。这个在我们第二章讲分布式数据库的演变时会清晰的看到。

  第四个是自主可控。我想这个抛出成本外，也是去IOE的一个重要原因之一。

  总之，基于以上因素我们队分布式数据库进行了调研。

P2 分布式数据库发展历程

  既然分布式数据库是未来发展的趋势，那么分布式数据库到底是什么？

  要想深入的了解一个事物，最行之有效的办法是：知道它是怎么来的，知道他是怎么发展的，他的特点，发展的规律，以及它是怎么没滴。当然这里我们不关注他是怎么没底，我们重点关注他是怎么来滴。

  那么分布式数据库是怎么来的呢？

  原来的时候是没有数据库的，随着大型超市，仓库，甚至一些大型公司对自己公司数据库管理和使用的需求越来越强烈。在1960年前后出现了一批管理数据库的软件雏形，人们发现这个东西太好了，太实用了，能把数据很好的管理和使用起来，这类数据库雏形的软件迅速发展，1980年逐步发展成一批成熟的商业产品，优秀的代表产品有：Oracle, sqlserver,到1990年人们在使用数据库的时候发现，我白天正常的处理业务没问题，但是我想要统计分析一下发现会影响白天的业务，也就是说在线交易和离线分析是不能同时执行的，会严重相互影响。于是数据库专业的人士就根据业务场景不同把数据库分为OLTP(联机交易),OLAP（离线分析）两个突出场景。这也就是数据库发展阶段中第一个有名的分析型系统和事务型系统分离阶段。 分离后OLTP一直朝着自己的方向发现，之后又出现mysql, postgresql 这些关系型数据库在各大公司企业总广泛的应用，长期占领这关系数据库市场的主导地位。应用架构也多是多样，发展为有原来的单机，双机，多机，以及现在的cloudDB 。但是CloudDB完全是黑盒，目前只有国外的少数公司例如亚马逊，国内的阿里云等，完全自主研发，据说是在一批定制机环境下定制开发的。

那么另一支，在OLAP分离后，也一直发展很快，有成熟的MPP架构产品例如：IBM的DB2,DPF，TeraDate,Vertica, 2000年GreenPlum 2000-2010年的HD(Hadoop) 2010年的Spark 以及逐步发展的 Flink等。

    这两分支一直因场景明确，各种朝着自己的方向发展，并且不可合并。并且均随着硬件性能的提高而提高。是数据库史上的第二个阶段：硬件提升带动数据库能力阶段 。

其实在这两个分支之间，在2000年左右随着互联网的迅速发展，特别是谷歌分布式论文发布后，迅速催生了一批新的数据库：Nosql数据库。代表产品有：MongoDB ,Hbase,Redis,Memchace,Neo4j,RoachDB.这就是数据库史上的第三个阶段：非关系型数据库发展阶段 。这类数据库解决的场景是：海量存储，非关系型业务场景，同时还满足在线高并发查询的业务场景。业界成为：operational（可操作类型）数据库，Nosql就是专门应对这类场景而生的。例如我们常见的日志管理平台，内容管理平台，文档管理平台，手机银行历史账单查询。这类数据库有第一代Nosql,发展到第二代Nosql。第二代与第一代最大的区别是第二代Nosql含义是NotNolysql。也就是支持了部分的SQL语言。这类数据库本身底层有天然的分布式存储优势，并且逐步的支持了sql语言，如果再支持事物，那么就可以解决一些关系型是应用场景，于是有部分数据库厂家就在Nosql的基础上研发出来一个新的分支，这时也就出现了数据库史上的第四个阶段： 分布式事务数据库发展阶段 典型的代表产品有Tidb,CRDB,SequioaDB。同时在OLTP一部分朝着云分布式数据库的方向发展了，另外一部分在实际的应该中，人们发现我本身底层是关系型数据库，天然支持事务，那我通过分库分表其实也实现了数据的分布存储，也变相的实现了分布式数据库的功能，所以也产生一个分支。典型的产品代表：Ocenbase HotDB Goldendb.。

    以上就是分布式数据库演变的历史，及发展规律。从中不难看出，不管是那条线过来的均是朝着分布式的方向发展的，所以我们第一章提到的不管是AP，TP均是朝着分布式的方向发展的。    那分布式既然是未来发展的方向，为什么在金融行业中没有大规模的使用？据近期调研发展，有实力的各大行也是在逐步深入试用的过程，或者有的是定制开发的过程，为什么？这其实是跟分布式数据库不可回避的CAP数据原理有关系。

P3 银行交易型业务需要兼顾CAP原则

    那什么是CAP？为什么分布式会存在CAP？关系型数据库Oracle是否存在CAP？

    1. 首先谈到分布式，必有P,(partition terlarance)分区容错。也就是说有分布式才有P，没有分布式就不存在P。所以P也可以理解为分布式。

    2. C (consistency) 一致性。在分布式数据库里面可以理解为锁。为什么是锁呢？举个例子：我给贠磊转账，那么在分布式中，数据可能不存在一个数据节点上，需要通过锁来锁住我转账的记录，进行下账，同时锁着贠磊的那条记录进行上账。所以锁是保证事物一致性的。所以在这里C可以理解为分布式事务锁。

3. A （avilablity）可用性。在这里可以理解为高TPS。而不是传统意义的故障造成的可用性。这里是有区别的。举个例子，还如上面的，我给贠磊转账， 同时胡总给贠磊发红包，或者胡总给我发红包，那么这时，是要等到我给贠磊转账动作完成后，胡总才可以操作，如果此时有查看，那么查看动作为了保证事务的一致性，也要等转账动作结束。所以在这里的A就是等到C锁完成后，而获得的资源可用。而且这里的锁，耗时要比单集群事务所耗时长。因存在网络不同数据库的交互。

   所以在分布式数据库里面，PC，A在同一时间片段不可共存，只能同时满足其二，尽可能靠近第三。这就是有名的分布式数据库遵从的数学命题。因为是三角形所以称之为数学原理。

   从这里看出，想Oracle,mysql关系型数据库不存在CAP问题，因为他们本身就不存在P。

   根据CAP原理，我们在总结分布式数据库在OLTP，OLAP，Nosql场景下关注的侧重点：

   OLAP场景  PA   C(最终一致即可允许有很大时间的数据延迟)

   OLTP场景  PC   A(在提高硬件的性能基础上， 无限的缩小锁的时间，尽可能大的提高可用性，及提高TPS)

   Nosql场景 PA   无锁，完全放弃了锁。

   所以分布式数据库总结起来以上三种场景关注点如上。

 既然，分布式数据库不可避免CAP原理，那么金融行业数据库该如何选择，如何取舍？

   我们在P一定存在的情况下，通过ACID，已经2PC(2阶段提交协议)，MVCC(多版本控制)来保证C要100满足，同时在达到C满足的基础上，通过2复制，1协议以及一个跨DB共享来尽快能的提高A的可用性。但是每一个协议其实都是存在不完全可靠性，也即是说这几个协议的可靠性最好可以达到4个9，5个9，以及7个9这以及是最好的啦。所以A永远不可能100，只有趋向无穷大，A趋向穷大的分布式产品是我们金融级一直在追求与探索的目标。也是我们取舍的原则。

   那么很明显，我们银行交易业务如果用分布式数据库必须兼顾CAP。

   

P4 行业OLTP数据库主流三种架构

   以上我们了解了分布式数据库不可回避的CAP原理，也清晰了我们金融级选择取舍的原理。其实我相信大家很好奇，同行业目前数据库架构是什么样的？大家是怎么用的，用在哪些地方。下面就是总结的目前行业主流的三种架构。

1. 垂直分库型的。 2.分库分表型的。3.原生分布式架构。也就是原生分布式型的。其中每个都有自己的特点和相关的代表产品。

  第一种，大家都比较熟悉，Oracle+小机的架构。将不同模块的数据表分库存储，库间不相互关联查询，如果有，必须通过数据冗余或在应用层二次加工来解决，无法支持分布式事务。也是目前保守金融行业在用的很传统的架构体系。

     优点：起点比较早，应用控制能力强，可进行深度定制化。对于底层数据库没有任何特殊要求，完全在应用程序内部进行分库。

     缺点：应用程序逻辑侵入性极强，应用程序需要进行复杂逻辑才能进行合理数据分布

拓扑结构调整或扩容时非常痛苦，几乎不可能完成在线扩容

很难支持跨库事务

  第二种：通过分布式数据库中间件进行用户ID的路由分发，保证用户的一类操作涉及的表多数情况下在一个数据节点上完成，减少分布式事务操作提升吞吐量和降低资源占用。如果有跨界点的事务，则通过分布式数据库中间件中的排队机制保证事务的实时强一致性。支持分布式事务。

     优点：构建中间SQL解析层，尽可能将标准SQL拆分成多个子查询下压到下层数据库，在SQL层进行结果拼装。对于底层数据库无特殊要求，在中间件进行SQL切分（支持XA即可）。部分兼容传统SQL，应用程序开发难度小于垂直分库

     缺点：应用程序逻辑侵入性较强，应用程序需感知底层数据分布结构，才能设计出优化后的查询逻辑。

中间件实现分布式事务，跨库事务使用XA机制，性能较单机数据库大幅度下降

作为单点向新型分布式数据库转型的过渡阶段，技术延续性堪忧。

   第三种：原生态分布式架构

   数据被数据库分片，而不是被应用分片。通过全局事务锁实现分布式事务。同时将表分布到不同机器的库上，减轻数据库的压力物理机的CPU、内存、网络IO负载分摊。支持分布式事务。

   优点：数据库内部处理分布式事务与数据切分逻辑，对于应用程序完全透明，不需感知底层数据分布

数据库内部原生支持分布式事务，MCVV多版本控制，提高读性能。

高可用与容灾能力由数据库内核原生支持，不需额外辅助工具

   缺点：遵守CAP原理

由于全局事务锁的限制目前只有通过提升硬件性能，尽可能提高A。

技术较新，业界成熟案例相对较少

辅助工具相对较少，生态环境有待完善

P8 5种产品的来源及案例介绍

我们了解了行业主流的三种架构及优缺点后，抛除第一种架构，我们分别在第二种，第三中架构的体系中选择数据库行业排名比较靠前的产品进行测试。选出的产品分别为：HotDB，GoldenDB。CockrachDB,TIDB，SequioaDB。5个产品。围绕这几款产品就行后面的测试。

P10 测试结果：测试角度说明及测试结果。

围绕我们所选的四款产品，我们进行了相关的测试。下面一块是我们测试的具体汇报。

首先是我们测试原理，即测试关注的点：

根据CPA原理。

我们测P测什么？  掉电，丢数据库，网络不可用情况下，集群的数据是否丢，是否可用。因我们集群是最小配置，且有的是网络申请的远程账号，所以不具备测试P的条件。

测C测什么？ C一致性，无非是测事务，测回滚。那我这边的业务场景均为非交易性业务场景，拿不到结合行内真实的交易业务场景，再模拟类交易场景也有偏差，所以也不具备真结合业务测试的条件。

那么我们的测试在在默认PC均满足的情况下，测试A。

结合我这边的应用场景，选出来，访问量大的Top10个报表进行测试其A。

当然通用的测试，想sql语法兼容性，管理易用性，安全可靠性等。这里不做重点关注。

下面是我的测试结果。

  

P15 结论：基于应用场景的数据库选择建议

虽然我们的测试比较薄弱。但是通过深入分析这几类分布式数据库产品，分支有来及基因。我们可以总结出来不同场景可选不同分布式数据库类型。

结尾：

    同时在调研的过程中我们发现同行业 在分布式数据库应用中，有规律可循的，我们可以借鉴：“管理后交易，先外围，后核心”的方向进行。以上是本次分布式数据库汇报的全部内容。汇报完毕。下面对于有疑问的点，请提问，我们详细的分析讨论。