189 8069 5689
数据存储和处理是一个古老而重要的技术，从远古时期的结绳记事到古人的文本记事，再到计算机诞生后的各种系统，直到E.F.Codd提出关系模型，人类终于有了一种相对高效而统一的数据处理系统——关系数据库。
在传统的关系数据处理系统中，习惯把系统按照业务特点分为在线事务处理系统(OLTP)和在线分析处理(OLAP)，一般意义上OLTP关注实时在线业务，要求低延时，高吞吐量，总体数据量一般不会特别大；而OLAP系统用来处理大规模数据的报表分析，要求低响应时间。两者因为数据量，查询请求，业务要求的不用，加上之前技术条件的限制，就分解为两个独立的系统，即OLTP系统用来处理在线交易，OLAP系统用来进行报表处理，两者之间通过ETL工具连接。
一般这个两套数据库系统是相互独立的产品，常见的OLTP产品有IBM DB2，Informix， ORACLE，SQL SERVER，mysql，PostgreSQL等，在OLAP常见的如TeraData，SybaseIQ，GreenPlum，HP VERTICA, SAP HANA，Hadoop大数据平台等等。在这个架构中，有两套独立的数据系统需要维护，增加系统采购的成本和系统运维的成本；同时ETL过程中OLTP到OLAP系统的数据一致性也是一个让人头疼的问题。
TBase向我们展示了一种革命性的数据处理架构，把OLTP和OLAP处理进行融合，在一套数据库系统中同时完成两种操作，同时降低业务复杂度和业务成本。TBase在某省部门上线运行超过快四年，在客户的架构升级中扮演了重要的角色，当前在该客户有快10套TBase系统在运行，集群规模快接近百台。本文希望借助客户的实际案例来对TBase的架构进行下解析，增加大家对TBase的了解。
TBase分布式无共享(share nothing)分布式数据库，集群结构如下：
Coordinator：协调节点（简称CN），对外提供接口，负责数据的分发和查询规划，多个节点位置对等，每个节点都提供相同的数据库视图；在功能上CN上只存储系统的全局元数据，并不存储实际的业务数据。
Datanode：处理存储本节点相关的元数据，每个节点还存储业务数据的分片，简称DN。在功能上，DN节点负责完成执行协调节点分发的执行请求。
GTM：全局事务管理器(Global transaction manager.)，负责管理集群事务信息，同时管理集群的全局对象，比如序列等。
在这个架构下，TBase集群具有下面几个能力：多活/多主：每个coordinator提供相同的集群视图，可以从任何一个CN进行写入，业务无需感知集群拓扑；
读/写扩展：数据被分片存储在了不同的DN，集群的读/写能力，随着集群规模的扩大做而得到提升；
集群写一致：业务在一个CN节点发生的写事务会一致性的呈现在其他的CN节点，就像这些事务是本CN节点发生的一样；
集群结构透明：数据位于不同的数据库节点中，当查询数据时，不必关心数据位于具体的节点；TBase的share nothing集群架构方便了业务接入，降低了业务接入的门槛。
HTAP是混合事务和分析处理
Hybrid Transactional/Analytical Processing的简写，TBase通过下面这些技术构建了原生的HTAP能力。
在分布式数据库中，分布式事务的ACID保证是一个很有挑战性的工作，但是业务系统在使用数据库的过程中，往往会依赖数据库提供的ACID能力来开发他们的业务，因此事务ACID能力的保证也成了分布式数据库必不可少的能力。先把数据库理论中的ACID的定义拿出来，熟悉下这些概念：
ACID，指数据库事务正确执行的四个基本要素的缩写。包含：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。一个支持事务（Transaction）的数据库，必须要具有这四种特性，否则在事务过程（Transaction processing）当中无法保证数据的正确性，交易过程极可能达不到交易方的要求。
详细解释下：
原子性（Atomicity）：整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
一致性（Consistency）：事务必须始终保持系统处于一致的状态，不管在任何给定的时间并发事务有多少。
也就是说：如果事务是并发多个，系统也必须如同串行事务一样操作。其主要特征是保护性和不变性(Preserving an Invariant)，以转账案例为例，假设有五个账户，每个账户余额是100元，那么五个账户总额是500元，如果在这个5个账户之间同时发生多个转账，无论并发多少个，比如在A与B账户之间转账5元，在C与D账户之间转账10元，在B与E之间转账15元，五个账户总额也应该还是500元，这就是保护性和不变性。
一致性是分布式事务中的重大挑战，网络时延和操作系统调度等不确定因素给分布式 事务一致性的保证带来诸多困难，但是分布式数据必须有一套完整的分布式事务一致性逻辑，否则会带来灾难性的后果。
隔离性（Isolation）：隔离状态执行事务，使它们好像是系统在给定时间内执行的唯一操作。如果有两个事务，运行在相同的时间内，执行相同的功能，事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。这种属性有时称为串行化，为了防止事务操作间的混淆，必须串行化或序列化请求，使得在同一时间仅有一个请求用于同一数据。
持久性（Durability）：在事务完成以后，该事务对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。
TBase中的事务严格遵守事务的ACID，当前支持read committed和repeatable read两个隔离级别，并提供可扩展的事务吞吐能力。
在事务测试模型TPC-C中有9张表，用来模拟从仓库中下订单发货，库存状态查询，并有一定的回滚比例，每个事务中有5-6条SQL，读写混合，测试过程中要求严格遵守ACID。在这个模型下TBase的处理能力随着集群规模的提升近似线性提升，在30台（24core，64G，1000Mb）规模时可以达到300W tpm。
Share nothing架构决定了随着集群规模的增加系统的TPC-C处理能力会进一步的提升，TBase在事务处理中处理能力可以到千万级QPS。
SQL是访问数据库的必备工具，在SQL诞生了几十年后的今天，大量的软件产品使用SQL进行开发，每个程序员都或多或少的使用到SQL，数据库对SQL的处理能力直接关系软件产品的稳定和程序开发的效率。
TBase认为：完整SQL兼容性 = 完美的SQL语法兼容+代价优化器+分布式执行器。因此TBase在设计之初就定下一条设计规则：SQL语法完全兼容SQL2003标准，让用户像使用普通数据库一样来使用TBase。
因此在TBase中，数据库开发工程师可以像在之前熟悉的数据库产品中一样编写SQL，不用担心数据库产品的变化带来额外的学习工作量。为业务节省大量的开发工作，降低业务升级的成本。
除了SQL语法兼容性，为了达到高效的分布式执行，TBase有专门为分布式环境设计的基于代价的查询优化器，与之配合的是专门为分布式环境设计的分布式执行器。
分布式执行器提供了目前已知的所有数据库算子(operator)支持，包括聚合，窗口函数，cube，存储过程，自定义函数，触发器，物化视图，并行执行等等。
通过这些设计，TBase为业务提供良好了的数据库使用体验，大幅降低业务的迁移成本和开发人员的学习成本，提高业务迁移的效率。
SQL兼容性和性能我们通过TPC-H来测试。TPC-H标准满足了数据仓库领域的测试需求。TPC-H中 用 3NF 实现了一个数据仓库，共包含 8 个基本表， 22 个查询(Q1~Q22)，其主要评价指标是各个查询的响应时间，即从提交查询到结果返回所需时间（越短越好）。其中的查询主要涉及：多表关联（超过4张），多表聚合，子查询等。
下图是TBase在行存储模式下TPC-H测试结果和国际知名数据库仓库的测试结果对比，从测试结果来看，TBase在所有22个测试用例中都大幅度的领先。
在数据库语法中，除了SQL标准外，每个数据库都产品有自己的本地化语义，在本地化语义方面， TBase完整的的兼容PostgreSQL语法，部分兼容Oracle语法。
数据库的物理文件存储格式常见的有两种：按行存储和按列存储。下面对每种存储结构给出一个例子，下表是我们的表结构和定义。
按行存储格式
按行存储格式，数据按照逻辑顺序相同的方式来来进行文件存储，一行中的所有列数据按照顺序存储在物理磁盘上，这种格式的好处很明显，如果同时访问一行中的多列数据时，一般只需要一次磁盘IO，比较适合OLTP类型的负载。
按列存储格式
表中的每列数据存储为一个独立的磁盘文件，比如例子中，“姓名”，“部门”，“薪酬”，“家庭信息”每列中的数据都为一个独立的数据文件，这中格式在一次需要访问表中少数列时相比行存能够节省大量的磁盘IO，在聚合类场景下尤其高效，因此多用在OLAP类系统中。
行存储是TBase的基本存储格式，为了支持高效的OLAP TBase也提供了完整的列存储能力，业务可以根据自己的需要对写入数据库中的数据选择需要的存储格式。TBase的列存储还支持强大的压缩能力，支持透明压缩和轻量级压缩，透明压缩支持gzip，zstd等压缩算法，轻量级压缩算法可以根据数据的特征进行高效压缩，压缩比高达400+。
TPC-DS是一套决策支持系统测试基准，主要针对零售行业。提供了99个SQL查询（SQL 2003），分析数据量大，测试数据与实际商业数据高度相似，同时具有各种业务模型（分析报告型，数据挖掘型等等），主要用来对决策支持系统进行性能性能评测。TBase列存储的 TPC-DS上运行了1T的工作集合，测试结果如下：
从测试结果来看，TBase在列存储模式下的TPC-DS能力要远远优于业界标杆。
PS：TBase中行表和列表之间可以进行任意关联查询，可以进行相互的格式转换（通过insert into select）。
在HTAP系统中，OLTP和OLAP业务要同时运行，两者都会消耗巨量的资源都，如果不对资源使用进行隔离必然会造成相互之间的干扰，影像系统的整体稳定性和服务质量。
TBase中的资源隔离方案--节点组的资源隔离方案，如果业务的OLTP和OLAP访问的是不同的数据，可以使用TBase中的节点组把OLTP业务和OLAP业务在集群中分离为两个节点组，对与OLTP节点组中的CN设置OLTP优化器，对于与OLAP节点组中的CN设置OLAP优化，从硬件上进行严格的分离。
在TBase中每个用户session都有一个资源配额限制，使用这个配额可以限制用户session的CPU，内存，网络等资源，在OLTP和OLAP不存在绝对竞争的场景也可以让两者运行在同一个group，使用用户资源配置来资源进行管控和配置。
TBase资源隔离方式—多副本方式（专利技术），多平面技术，此时用户数据还是同一份数据，通过副本复制的方式把数据从OLTP系统复制到OLAP系统，同时实现行存储到列存储的转换，通过这种方式从硬件上分离了OLTP和OLAP业务，同时数据库内部的数据复制可靠性由数据库内部机制保证，可靠性远远高于ETL工具。这种资源隔离技术TBase中的叫多平面技术。
通过上面这些资源隔离技术，TBase实现了HTAP中关键的资源隔离技术，可以很好的保证系统的服务质量和改善客户体验。
得益于TBase常年服务公司内部客户，
TBase建设了一套很有特色的数据安全系统，可以说TBase是目前市面上安全能力最出色的数据库产品，这一特性得到内外部客户的一致认可，并作为安全技术标准写入到PICC的数据库安全规范中。
TBase的数据安全系统我们称之为MLS（multiple level security），这个体系的整体视图如下：
以三权分立为基础，消除系统的超级用户权限。在安全管理规则中增加强制安全规则，支持对表进行矩阵式的权限划分，在数据访问层和存储层进行加密和脱敏控制，防止数据拖库时发生的数据泄密：
在事后追溯和实时审计中，TBase提供了完整的审计规则和丰富的自定义审计规则来进行支持。通过FGA（细粒度审计），TBase还可以做到数据越权访问的实时告警，实时防止数据越权访问。
案例1：TBase协助解决某省汇集库瓶颈，助力客户架构升级：
原有系统使用某知名数据库集群。在支撑数据量到300亿数据时，计算和查询的时候能力已经到达极限，超时宕机的场景频发，入库的速率最后只能达到数千/秒的极限值，远远无法满足业务需要。
TBase汇集库在系统中的位置：
汇集库在系统中承担着数据汇集处理的作用，既要对接其他关系数据库，消息中间件等，还要运行部分核心系统的OLTP业务，并在这两者数据的基础上运行模型构建，离线行为分析等OLAP类计算。是一个典型的HTAP系统。
之前的系统之所以遇到瓶颈，很大程度上也是因为业务模型本身计算量大，模型复杂超出了RAC的处理效率。
TBase团队在分析了业务的特点后，结合TBase的本身能力为业务制订详细的解决方案。方案的核心要点是OLTP和OLAP的多平面资源隔离技术，我们为系统的请求详细的划分了业务的运行平面，业务的写入全都集中在主平面，把查询类的请求根据计算复杂度和实时要求划分到备用平面和主平面。很好的隔离了实时请求和离线请求。汇集库TBase CN和DN的部署结构如下图。
汇集集群当前有节点数近百，存储数据数百T。120亿数据的OLTP类业务1秒内完成处理。
处理性能远远超越了之前系统，成本相比却大幅降低，得到用户的高度认可！
案例二：物联网地理信息系统
业务背景：随着物联网的到来，很多的传感器数据需要进行接入，这些数据中都包含共同点，都包含一些点位信息（经度和纬度）。结合这些位置信息和我们已有的地理信息进行关联分析，可以分析出很有价值的数据，为国民生产生活所用。
这个系统的核心功能是要对地理位置信息进行关联计算和查询，这个需要TBase提供的地理信息能力进行支持。
PS：TBase支持最先进的开源地理信息引擎PostGIS，可以提供丰富高效的地理信息处理能力。
该业务系统的部署架构如下：
TBase上游对接接业务传感器后端的ETL，数据进入集群后先对清洗变换，并把人和位置信息进行关联形成宽表；在宽表的基础上进行GIS OLAP分析，输出我们需要的高价值信息。
目前GIS系统规模：目前5台机器协调节点+6台机器Datanode节点主备混合部署。
案例三，某核心OLTP在线核查系统：某省核心服务微信公众号后台系统，核心系统结构如下：
业务的核心TBase服务器部署内网，敏感数据部署在这个核心TBase实例中，互联网部署的一台应用服务器，运行公众号相关的业务数据，并通过网络边界同步工具把数据同步到业务内网。
TBase构建HTAP能力的过程中团队小伙伴们突破了一个又一个技术难点，创造了一个又一个“不可能”，回顾这个过程，就想起一句古语“筚路蓝缕，以启山林”！对TBase来说，应该是“筚路蓝缕，开拓创新”！
当前TBase服务的外部客户包括金融，公安，消防，政务，医疗，社保，能源，税务等行业，外部集群超过30个。在案例中的省份上线运行已经快4年，集群规模从最开始的十几台逐渐增长到现在的近百台，业务系统也有最初的一个增长到现在的快十个，在帮助业务解决痛点的同时，TBase自己也获得了很多成长的机会，感谢大家对TBase的关注。
支撑微信支付的数据库如何提供超300万TPCC事务处理能力？