TopDB产品分析
1.1产品的背景
1.2用户需求和产品定位
1.3相关数据库的分析
1.4TopDB架构
1.5
TopDB的未来规划
1.1产品的背景
自从斯诺克事件引发国家对信息安全的忧虑，要求金融、通讯等核心领域逐渐使用自主可控的软件、硬件来替代传统的IOE厂商。其中重中之重就是数据库，而在银行业，DB2和Oracle两家就占了70%以上的份额。从政治层面上来说，国家已要求各大银行开始逐渐尝试使用自主可控的数据库来替代传统的Oracle、DB2。同时也可以看出，近年来随着互联网金融领域的崛起，银行也存在对成本控制的问题，之前动辄数十万一个license的数据库对于银行来说，也同样需要考虑成本和收益。除此之外，不满足传统单机数据库，要求数据库替代产品具有可扩展性等要求。这些要求是银行领域要求使用新型数据库的背景。
1.2产品定位
考虑银行的核心需求：
1.要求数据库自主可控，这要求数据库要么使用开源产品，要么自研，或者两者结合。
2.保证数据库具有传统Oracle、DB2的基本特性，可以理解为具有数据库的ACID特性。
3.要求具有可扩展性，暗含使用MPP分布式并行处理架构。
4.对现有系统系统影响最小
5.其他数据库需求，如高可用、异地容灾等。
基于以上背景，我们的产品定位是能够替代Oracle、DB2的具有可扩展性的分布式关系型数据库。要求满足：
1.是传统的关系型数据库
2.满足数据库的ACID属性，尤其是银行的事务属性。
3.同时支持OLTP和OLAP
4.采用分布式架构，具有高可扩展性
从以上的定位可以看出，我们的数据库首先仍然是传统的关系型数据库，具有分布式架构，同时需要在分布式架构下解决事务实时一致性问题。从客户的角度来说，本身银行业虽然是IT行业最重要的领域，但是也是对新技术最保守的行业。因此，要想逐步替代传统的Oracle、DB2数据库来说，最好的办法还是使用通用的关系型数据库来替代。同时，在此基础上，使用并行处理框架，采用分布式架构。采用分布式架构带来的好处是很容易进行线性扩展，包括存储、性能上的扩展。但是分布式架构带来的问题是CAP理论决定的，在分布式情况下，一致性和可服务性难以同时支持。因此需要在可服务性和一致性之间寻找一个平衡点。
1.3相关数据库产品的分析
数据库按照其架构特点，可以分为传统的关系型数据库OldSQL、NoSQL、NewSQL。
从技术路线上来说，NoSQL主要是非结构化的形式来存储数据，大多数是基于KV的形式来存储数据，要求查询场景基本固定，特别适用于互联网行业。其代表为DynamoDB、BigTable、HBase等,使用的厂家包括：Google、Facebook、阿里等。NoSQL处理非结构化数据占据优势，但是对于银行系统来说，最大问题还是不满足ACID属性。
NewSQL从技术上来讲，一般是以列式形式存储数据，这也决定了其批量读取速度快、存储空间小的特点，适用于OLAP分析型应用。但是对于现阶段的银行应用来说，其最大问题是实时的更新删除速度响应比较慢，无法满足金融行业实时性要求。其代表的厂商有Vertica、Greenplum、GBase等。
而OldSQL也即基于行式存储的关系型数据库，大的厂商有如Oracle、DB2，但是其本身成本大，同时对于一些海量数据，其本身也无法很好支撑，存在性能上的天花板。另外还有一些优秀的开源数据库如MySQL、PostgreSQL、MariaDB等，这些数据库本身在中小企业、互联网领域应用也都比较多。其本身最大的问题是本身数据库可以支撑的数据有限，并不支持海量的数据。
总结如下：
|
数据库类型
|
最大特性
|
优势 |
劣势
|
代表厂商
|
|
OldSQL
|
1.基于行的关系型数据库
2.支持ACID
|
产业链成熟
同时支持OLAP和OLTP
|
扩展性差
价格高昂
性能有限
|
DB2 Oracle
MySQL PostgreSQL
|
|
NewSQL
|
1.基于列的关系型数据库
2.支持ACID
|
批量读取速度快
存储压缩
|
对于OLTP实时型差
|
Vertica
Greenplum
GBase
|
|
NoSQL
|
基于KV存储 内存数据库 |
读取速度快
海量存储
可扩展性强
适用于OLAP
|
产业链不成熟
对事务支持有限
|
HBase DynamoDB BigTable Memecached
|
1.4TopDB产品分析
TopDB架构如上图所示，类似于Greenplum、阿里的TDDL架构。下面简单分析下TopDB的架构
数据存储层是采用MPP架构，数据根据规则分配在所有数据库上，每个数据库采用主备同步保证系统高可用性。对于前置中间件来说，一方面他需要将客户端下发来的SQL语句处理后下发到对应的数据节点上，另外一方面他需要将底层数据库返回的结果汇聚处理后返回给客户端。而对于数据库事务，通过全局事务处理中心来进行分布式事务控制。
其架构优点：
1.采用传统的关系型数据库，能够保持ACID属性。
2.采用分布式架构，数据分布在不同节点上，可扩展性强
3.数据节点、前置中间件节点都采用集群的方式对外提供服务，本身不会出现单节点的故障和性能瓶颈。
4.分布式架构，请求可以均分到多个数据节点上，其性能强劲，支持高并发
架构缺点：
1.对于大规模的跨库关联查询，其速度回比较慢(需要将数据捞出来后，放在前置中间计算结果)
2. 对于单个SQL语句来说，其需要经过前置中间件分析，执行的时延会增长。SQL语句的时延依赖于前置中间件的性能。
架构难点：
1.前置中间件需要做语法解析和SQL计划，这块就需要对SQL语言的分析过程了解透彻。
2.由于数据分布在多个节点，必须通过特殊机制才能保证分布式事务的实时一致性。
架构分析：
从TopDB的架构可以看出，底层的数据库集群仍然是MySQL这样的关系型数据库，多个关系型数据库上构建成数据库集群，再加上前置中间件对外包装成一个数据库整体对外服务。本身是关系型数据库，对当前银行使用的数据库是一个继承关系，满足通用性数据库要求。同时通过MPP分布式并行处理架构，使得系统具有良好的可扩展性。除此之外通过分布式事务处理机制，保证可以实现分布式事务控制。在此之外，通过前置中间件集群、数据库双击和集群可以看出系统不存在单点故障和性能瓶颈，具有良好的高可用性和可扩展性。
从以上的分析可以看出TopDB能够作为银行领域替换Oracle、DB2的替代产品。但是需要注意的是前置中间件需要做语法解析和计划，因此需要考虑设计成满足通用的SQL语法，这对前置中间件的要求非常高。
1.5TopDB的未来规划
TopDB的未来规划的内容主要包含几个方面，一方面是前置中间中自身语法解析、SQL计划的性能优化和提升、系统时延的降低、并发的提升。另外一方面本身TopDB作为同时具有OLTP和OLAP特性的通用型数据库，在做大规模跨库的关联查询时，性能会下降厉害，因此需要考虑如何加强OLAP这块的性能。
上述前者主要是对自身内部的优化，而后者就需要在系统层面上考虑TopDB的架构设计了。其中一个思路是将TopDB和大数据系统进行对接，利用大数据系统来进行OLAP分析类应用，将TopDB和BigData作为整体对外提供服务。TopDB和BigData通过接口将两边的数据进行对接，TopDB将数据吐给BigData进行分析，BigData将分析后的数据再返回给TopDB。
另外一个思路是利用新型的列式存储来完成OLAP，但是列式存储和行式存储本身只能两者取其一，两者结合使用除了使用数据导入导出方法以外，如何将两者进行结合到现在为止仍然没有很好的思路。
1.6总结
顺应时代的要求，在银行领域替换Oracle、DB2数据库，因此设计成通用型的关系型数据库，同时考虑系统扩展性，采用MPP分布式并行处理架构。从产品本身来说，十分贴切银行的真实需求，但是同时也需要看到，架构中前置中间件需要做的事情很多，难度较大。从产品的应用前景来看，在金融领域、通讯领域，证券领域，这些本身相对保守需要使用关系型数据库来保存数据，同时又由于数据量和性能要求的增加需要提升系统容量和性能的领域。
金融和通讯为了提升系统性能和降低成本，使用开源或者国产通用型数据库替代Oracle、DB2将是一个延续不断地过程。有如互联网领域去IOE的态势一样，这些领域将在未来若干年，逐渐使用其他替代产品来替换Oracle和DB2。不同的技术路线如NoSQL和NewSQL都会存在一些生存空间，NoSQL适用于银行领域对应于靠近互联网的应用。而NewSQL适用于这些领域的数据仓库。这些领域需要能够找到同时满足OLTP和OLAP的通用型数据库，同时又具有高性能和大存储，因此我们的TopDB应孕而生。