数据存储和处理是一个古老而重要的技术,从远古时期的结绳记事到古人的文本记的事,再到计算机诞生后的各种系统,直到E.F.Codd提出关系模型,人类终于有了一种相对高效而统一的数据处理系统,关系数据库。
在传统的关系数据处理系统中,习惯把系统按照业务特点分为在线事务处理系统(OLTP)和在线分析处理(OLAP),一般意义上OLTP关注实时在线业务,要求低延时,高吞吐量,总体数据量一般不会特别大;而OLAP系统用来处理大规模数据的报表分析,要求低响应时间。两者因为数据量,查询请求,业务要求的不用,加上之前技术条件的限制,就分解为两个独立的系统,即OLTP系统用来处理在线交易,OLAP系统用来进行报表处理,两者之间通过ETL工具连接。
一般这个两套数据库系统是相互独立的产品,常见的OLTP产品有IBM DB2, Informix, ORACLE SQL SERVER、mysql、PostgreSQL等,在OLAP常见的如TeraData, SybaseIQ, GreenPlum,惠普VERTICA SAP HANA, Hadoop大数据平台等等。在这个架构中,有两套独立的数据系统需要维护,增加系统采购的成本和系统运维的成本;同时ETL过程中OLTP到OLAP系统的数据一致性也是一个让人头疼的问题。
TBase向我们展示了一种革命性的数据处理架构,把OLTP和OLAP处理进行融合,在一套数据库系统中同时完成两种操作,同时降低业务复杂度和业务成本.TBase在某省部门上线运行超过快四年,在客户的架构升级中扮演了重要的角色,当前在该客户有快10套TBase系统在运行,集群规模快接近百台。本文希望借助客户的实际案例来对TBase的架构进行下解析,增加大家对TBase的了解。
TBase架构特点
协调节点(简称CN),对外提供接口,负责数据的分发和查询规划、多个节点位置对等,每个节点都提供相同的数据库视图;在功能上CN上只存储系统的全局元数据,并不存储实际的业务数据。
处理存储本节点相关的元数据,每个节点还存储业务数据的分片,简称DN。在功能上,DN节点负责完成执行协调节点分发的执行请求又是;
全局事务管理器(全局事务管理器),负责管理集群事务信息,同时管理集群的全局对象,比如序列等。
每个协调员提供相同的集群视图,可以从任何一个CN进行写入,业务无需感知集群拓扑;
数据被分片存储在了不同的DN,集群的读/写能力,随着集群规模的扩大做而得到提升;
业务在一个CN节点发生的写事务会一致性的呈现在其他的CN节点,就像这些事务是本CN节点发生的一样;
数据位于不同的数据库节点中,当查询数据时,不必关心数据位于具体的节点;TBase的份额没有集群架构方便了业务接入,降低了业务接入的门槛。
TBase的HTAP能力
事务酸强保证:
在分布式数据库中,分布式事务的酸保证是一个很有挑战性的工作,但是业务系统在使用数据库的过程中,往往会依赖数据库提供的酸能力来开发他们的业务,因此事务酸能力的保证也成了分布式数据库必不可少的能力。先把数据库理论中的酸的定义拿出来,熟悉下这些概念:
酸,指数据库事务正确执行的四个基本要素的缩写。包含:原子性(原子性)、一致性(一致性),隔离性(隔离),持久性(耐久性)。一个支持事务(事务)的数据库,必须要具有这四种特性,否则在事务过程(事务处理)当中无法保证数据的正确性,交易过程极可能达不到交易方的要求。
详细解释下:
整个事务中的所有操作,要么全部完成,要么全部不完成,不可能停滞在中间某个环节。事务在执行过程中发生错误,会被回滚(Rollback)到事务开始前的状态,就像这个事务从来没有执行过一样。
事务必须始终保持系统处于一致的状态,不管在任何给定的时间并发事务有多少。
也就是说:如果事务是并发多个,系统也必须如同串行事务一样操作。其主要特征是保护性和不变性(保持不变),以转账案例为例,假设有五个账户,每个账户余额是100元,那么五个账户总额是500元,如果在这个5个账户之间同时发生多个转账,无论并发多少个,比如在A与B账户之间转账5元,在C与D账户之间转账10元,在B与E之间转账15元,五个账户总额也应该还是500元,这就是保护性和不变性。
