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