数据库Trafodion 调研报告

it2024-12-15  16

文章来源:设计架构

 

来自知乎:

Trafodion继承自Nonstop SQL

从Trafodion目前开源社区的开发进度看,这两年开发缓慢,代码库的代码风格也是略显杂乱和老旧。这样一方面难以维护,另外一方面缺少新的硬件特性的加持,比如SIMD, SSD 这些新硬件的加持。OLAP赶不上ClickHouse这些SIMD加持的新兴数据库。同时目前还只能在比较旧的GCC上面编译。

另外一个方面,使用HBase作为底层存储,在OLTP的负载下,写路径有些长,性能赶不上那些专门为OLTP优化的数据库。

写这么多,对于Trafodion这个开源项目,直接拿来用,还是不太合适,代码比较陈旧,难以维护,部署依赖Hbase, 安装运维成本都高。但是对于做数据库的同学们,其中某些优化的想法,可能可以参考一下。

作者:知乎用户 链接:https://www.zhihu.com/question/380833422/answer/1211263176 来源:知乎 著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

 

Trafodion的概述

1.Trafodion是啥?

Trafodion是一个建立在Hadoop/HBase平台上的关系型数据库,它完全开源免费。擅长处理交易型负载的Hadoop大数据解决方案。和传统关系数据库不同的地方在于,Trafodion利用底层Hadoop的横向扩展能力,可以提供极高的扩展性。Trafodion可以借助HBase的扩展性,仅通过增加普通Linux服务器就可以增加计算和存储能力,进而支持大数据应用。

2.Trafodion的主要特性有哪些?

完整的ANSI SQL语言支持完整的ACID事务支持。对于读、写查询,Trafodion支持跨行,跨表和跨语句的事务保护支持多种异构存储引擎的直接访问为应用程序提供极佳的高可用性保证采用了查询间(intra-query)并发执行模式。轻松支持大数据应用同时应用编译时和运行时优化技术,优化了OLTP工作负载的性能

3.事务管理特性包括哪些?

事务串行化基于开源项目HBase-Trx的实现原理,采用多版本并发控制(MVCC)增强的故障恢复机制保证了数据库中用户数据的一致性事务管理器支持多线程的SQL客户端应用支持非事务型数据访问,即直接访问底层HBase表

Trafodion的性能

(内容来自https://blog.csdn.net/zhangzeyuaaa/article/details/65684749)

测试环境为6节点Trafodion加上3节点Vertica X86架构的集群。

测试背景数据为:车辆轨迹表格为133亿条记录,告警日统计表格3亿6千万条,违规日统计为2750万条记录,违规月统计为671万条。

Trafodion加载以及查询时间

由于Trafodion是基于Hadoop/Hbase的大数据平台,所以它也具备性能的可扩展性。因此也做了一系列的性能可扩展性测试(4,6,8个节点集群,以及不同的并发用户数括包括200,300,400,500以及600并发),结果如下表。

 从以上结果可以看出在四节点集群配置下,可满足客户业务需求。考虑到未来车辆数量增多,可通过增加节点来提高加载速度以及缩短查询响应时间。

 

 

Trafodion的总体架构

(这个图有点迷惑人,好像连接可以连DCS)

1.Trafodion的进程构架,主要进程包括哪些?

客户端应用通过JDBC或者ODBC访问Trafodion。Trafodion的ODBC驱动采用了优化的wire protocol,高效地同Master Executor进程进行网络交互。上图演示了一个Type 4的JDBC配置。Master Executor是负责执行用户SQL语句的主进程。它内部包含了一份SQL compiler代码的拷贝,因此多数SQL语句可以在Master Executor进程内部进行编译而无需和单独的编译进程进行通信。此外,所有执行计划中的root节点都在Master Executor进程中执行。少部分SQL语句(比如,DDL和一些应用工具)需要启动第二个独立的编译器进程对SQL语句进行处理;即上图中的CMP进程Trafodion 支持多种不同形式的并发执行方式。当系统生成了并发查询计划时,系统会动态地启动多个ESP进程,即Executor Server Processes。每一个ESP负责执行查询计划中的一个分段(fragment)DTM进程负责分布式事务。DTM的职责包括日志管理和事务协调。Trafodion支持访问原生HBase表,为此,SQL引擎将读取HBase的元数据。为了提供更好的OLTP访问性能,Trafodion还提供了定制的Trafodion表结构,用HBase Table进行存储。Trafodion表拥有自己的元数据,同样存储在HBase中。

2.Trafodion负责连接的子系统

图中的DCS是一个分布式服务。它利用底层的HBase服务 ZooKeeper 来管理DCS集群。

数据库连接服务(DCS)允许标准的ODBC/JDBC应用程序访问Trafodion。

ZooKeeper(一个Apache开源项目)服务能提供配置管理,命名空间管理等功能。利用ZooKeeper,还可以实现分布式环境下的同步,以及集群成员管理。所有的集群节点以及客户端应用都可以访问ZooKeeper。

DCS由多个子系统组成:

ODBC/JDBC驱动程序:ODBC提供了标准的API来访问数据库管理系统。DCS主进程:DCS主进程负责监控所有的Server实例。它为ODBC/JDBC客户端连接请求分配MXOSRVR进程(在上图中显示为"Master Executor")。DCS主进程拥有一个standby备份,当DCS主进程发生故障时,standby备份可以立即接管,成为新的DCS主进程。DCS Server进程:Server进程负责启动和管理MXOSRVR进程的运行。集群的每个节点上都运行一个DCS Server进程。MXOSRVR Server 进程(在上图中显示为"Master Executor"): 这个进程负责处理ODBC/JDBC客户的数据库访问请求。一个客户端程序对应一个单独的MXOSRVR server进程。MXOSRVR server进程代表客户端执行SQL查询,并将结果返回给客户端应用程序。

3.Trafodion负责事务的子系统

Trafodion采用多版本并发控制(MVCC)的方法支持分布式ACID事务。

Trafodion在每个集群节点上启动一个事务管理进程(在上图中显示为"DTM")。该进程记录了该节点上启动的所有事务,并负责管理它们。

当Trafodion客户端开始执行一条SQL语句时,会和事务管理进程(DTM)进行通信,由DTM启动该事务。DTM返回一个集群唯一的事务ID。这个事务ID会传给执行该查询的所有执行器进程。这个传播过程建立在Trafodion消息层上,Trafodion消息层负责跟踪参与消息通信的节点健康情况,如果某个节点在这个过程中崩溃,Trafodion的DTM进程会得到相应的通知,并进行错误处理。

当Trafodion执行器调用HBase访问层,修改过的HBase-trx库相应地会被调用。通过解析事务ID,HBase-trx层能够获知启动该事务的DTM,并向该DTM进程进行注册。这样,DTM就可以在任意时刻获知参与某事务的所有进程信息。

Trafodion利用了HBase的协处理器,减少了代码间的耦合。这使得Trafodion的HBase-trx实现拥有更好的扩展性。Java语言不支持多重继承,因此采用扩展类的方法,一次只能实现一个特性。采用协处理,则可以实现多种扩展。Trafodion利用Endpoint和Observer协处理器协同工作,作为两阶段事务处理中的资源管理器(Resource Manager)。

 

Trafodion的编译器架构

1.Trafodion的编译器负责干什么?

Trafodion的编译器将SQL语句翻译为执行计划,并交给执行器(executor)负责具体执行。Trafodion采用了多阶段编译器。每个阶段对输入的SQL表达式进行特定变换,并输出作为下一个阶段的输入。

Master进程空间中有一份编译器代码的拷贝。因此Master进程无需和单独的编译器进程进行通信,而是可以直接进行函数调用。

编译器是由C++语言编写实现的。

2.Trafodion的编译器——Parser 语法编译器

Paser执行词法和语法分析,将SQL文本转化为语法树。Parser的输出为语法树,树节点为RelExpr类型。标量表达式用ItemExpr表示,并嵌入在RelExpr中。在接下来的所有编译阶段中,语法树都采用这个同样的形式表示。

3.Trafodion的编译器——Binder绑定器

Binder阶段在语法树中加入元数据信息。SQL对象(表,视图,列等)都会被绑定到相应的元数据。Binder也负责数据类型综合(即将SQL类型解析为C++类型和相应的存储空间)。在这个阶段,检查数据类型是否合法,比如是否符合函数调用的规约,或者是否符合列类型的定义。

Binder还负责处理查询计划缓存的管理。Binder会分辨出类似的,已经被缓存的SQL语句,并直接从计划缓存中取出相应的计划返回,从而略过后续的编译器阶段,极大地节约了编译时间。

4.Trafodion的编译器——Normalizer规范器

Normalizer将不同的表达方法规范为统一的表示方式,以便后续阶段的处理更加容易。

5.Trafodion的编译器——Optimizer优化器

Trafodion优化器是一个基于变换规则的成本驱动的优化器。这里的规则指的是对SQL进行等价变换的规则,而非基于经验的优化规则。(还需要和嵌入SQL语句中的hint区别开了,这里的规则并不是指hint优化规则)。‘成本驱动’的含义是指Trafodion优化器比较不同执行计划的成本来驱动优化过程。

7.rafodion的编译器——Pre-Code生成器

Pre-code生成器执行一些无条件的优化规则。利用VEG,优化器对于每个表达式都可以找到最优的表达方式。

8.rafodion的编译器——Generator 计划生成器

计划生成器将优化器生成的最佳执行计划转换为执行器可以执行的执行方案。在这个阶段,还需要对标量表达式执行底层优化。

9.rafodion的编译器——内存Heap管理

为了高效地管理堆内存,编译器使用了NAHeap类对内存进行直接管理。执行器也使用同一个NAHeap类进行内存管理。

10.rafodion的编译器——错误管理

编译器将执行错误保存在ComDiagsArea对象中。编译器代码采用C语言风格的错误处理,调用者必须检查调用函数的返回值来进行相应的错误处理。

 

Trafodion的执行器架构

1.关系操作符

一个执行计划由多个段组成,每一个段由一个单独的执行器进程负责。每一个段自身也是一个关系操作符组成的树。每一个关系操作符还可能会包含标量表达式。 关系操作符由两个类处理:ex_tdb和ex_tcb。ex_tdb(tdb代表task description block)仅包含了编译器生成的操作符。ex_tcb(tcb代表task control block)则包含了运行时的状态。比如,操作符之间通信所需要的queue就是保存在ex_tcb中。

2.标量表达式

标量表达式由表达式evaluator负责处理。如果表达式能够被编译为可执行的机器指令,则evaluator仅仅需要简单地跳转到该代码块的开始位置即可。否则,evaluator需要作为解释器执行表达式逻辑。由于历史的原因,Trafodion内部有两个解释器。第一个解释器(老的解释器)是一个clause-based表达式解释器,每一个clause对应于表达式中的一个操作符。第二个解释器(新的解释器)叫做PCODE-based evaluator。PCODE是一种中间代码。如果不能被直接编译为可执行的机器指令,那么表达式可以被编译为PCODE;对于无法编译为PCODE的部分依旧使用clause表达。有时,为了调试的需要,可以强制编译器生成PCODE,或者clause-based表达式。

3.进程间通信

各个组件之间的通信通过IPC层进行,IPC抽象了跨越进程边界的对象间通信。通信数据包括执行计划,执行结果数据,或者错误对象(ComDiagsArea)。

4.CLI接口层

执行器的最顶层软件被称为Call Level Interface(CLI)。CLI采用了类似ODBC的函数接口设计。Connectivity代码通过CLI层和执行器进行交互。在CLI层中,执行器维护SQL语句的抽象和游标。CLI也提供了获取SQL诊断信息的接口。

5.内存heap管理

执行器使用NAHeap类进行内存堆管理。将内存分为两个部分。第一部分由单个SQL语句使用,存放SQL语句本地所需的内存对象;第二部分存放全局内存对象。

6.错误管理

执行器也适用ComDiagsArea类进行错误处理。同编译器一样,执行器不使用C++风格的异常处理,而使用传统的检查函数返回值的方法进行错误处理。

7.统计报告

执行器负责收集特定查询的运行时统计信息。上层软件可以通过CLI接口获取这些统计信息。  

 

最新回复(0)