分布式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个产品。围绕这几款产品就行后面的测试。

在测试前，我们先简单概要的了解一下这四款产品的来源。及相关的行业案例。

1. HotDB是从阿里中间件产品出来的创业公司。目前在银行推广的比较多，有比较丰富的银行案例，且有交易级的案例。
2. GoldenDB是中兴通讯与中信银行合作的分库分表解决方案，预计2019年底中信银行的一些核心业务将会使用该技术。中兴通讯基于MySQL语法解析脚本，使用C语言开发了MySQL解析器，并将底层存储使用标准MySQL。有交易级的案例。

3. SequoiDB是从DB2出来的底层依托关系型数据库mongo深度开发形成的一块产品。在银行渗透非常大，但是多为内容管理，历史平台，影像平台相关的业务场景，有部分交易级案例。

4. TiDB内核是基于RoackDB开发的一块产品，跟CockroachDB内核一样。有较少的银行案例，大部分为互联网案例。

   且有交易级银行案例，是与北京银行深度合作下，来实现的交易业务场景。也是也很年轻的创业公司。

5. CockRoachDB是CockRoach lab的一块实验室产品，目前国内百度是其联合开发者，在百度有应用。无银行案例。

下面是案例的详细使用场景。这个稍后我们可以具体看一下。

 

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

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

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

根据CPA原理。

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

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

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

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

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

下面是我的测试结果。

从测试结果看，排除网络原因影响，CRDB的性能要高于巨衫的。HotDB在join关联查询场景不占优势，这个我也找金老师沟通过原因，根据反馈原因，是因为关联时如果不按照分布列去作为关联字段，会造成全表扫描，性能严重下降，建议不要用在关联查询场景。

在这里其实我们的测试是有偏差的，为什么？因为我们拿到的数据库均宣称为TP数据库，而我们测试是拿AP的场景进行的测试。也就是说我们那TP的数据库只测试啦AP的场景。

所以我这里增加一个Sysbanch的数据库压测场景，我只测试了CRDB。其他几家均为反馈的数据。真实性不知道有多少水分。这里仅供横向产品对比参考。

 从结果看，结果只能1. 我们只能严重数据库对我们业务场景sql的适应程度。

只能算是一个功能验证性测试。并不能作为性能指标的参考。

  

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

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

在小数据情况下，Oracle可以搞定所有场景。

在大数据量情况下：交易场景高TPS下，我们发现HotDB,GoldenDB比较实用。

                 交易场景低TPS，以及管理类O库下：TiDB,CockRoachDB,SequioaDB。

参考到同行业务场景：细化一下：基于应用场景的数据库选择建议如下：

高交易高读写QPS下：例如：账务系统，支付系统，比较推荐：底层是关系数据存储的比较适宜的有：Oracle, HotDB GoldenDB

低交易低QPS场景，信贷管理系统，CRM系统，征信查询，管信类O库， 这5款数据库均能支撑。

主机负载下移的：hot ,Tidb ,crdb,巨衫均可以。

批处理作业及AP场景先用现有的 OLAP数据相关的数据库即可。

 

结尾：

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