6.1.3    TimesTen技术架构

接下来,我们就从应用形式、内部架构、连接方式、高可用形式四个方面来进行一个TimesTen技术架构的概述。

1.  应用形式

前面说到,TimesTen可以单独使用,也可以作为Oracle的缓存来使用,这里我们就先来介绍一下TimesTen内存数据库的使用形式,具体如下:

q  TimesTen内存数据库(TimesTen In-Memory Database):其为一个针对内存进行了优化的关系数据库,它为应用程序提供了即时响应性和非常高的吞吐量。TimesTen作为缓存或嵌入式数据库部署在应用程序层中,利用标准的SQL接口对完全位于物理内存中的数据存储进行操作。

q  Oracle数据库缓存(Oracle In-Memory Database Cache):其为一个数据库选件,它与Oracle数据库配合使用,作为Oracle数据库的一个高速缓存,为前端应用提供了实时、可更新的缓存。其将来自数据库的对性能极其关键的一系列表缓存到应用程序层,从而缩短应用程序事务响应时间。

2.  内部架构

知其然需知其所以然,TimesTen的高并发处理优势源自何处呢?我们需要来深入研究一下它的技术架构。

若要求快速的响应,就需要简单高效的架构来作为保障,如图6-3所示,和Oracle数据库一样,TimesTen的架构中也可以分为三个部分:

q  内存结构:负责与前端应用的数据交互和直接的数据库操作;

q  后台进程:负责应用、内存结构、文件结构之间的交互,作用就像通讯员一样;

q  文件结构:与内存的交互,存储数据库到磁盘,并记录相关日志,需要注意的是,和Oracle不同,文件和内存的交互是在后台异步完成的,不会直接影响到应用与内存交互的性能。

 book_tt_03

图6-3  TimesTen技术架构

    (1)内存结构

先来看一下内存结构吧。在内存结构中,包含如下三个主体结构:

q  Data Store:保存所有数据库数据的区域,我们将其视为一个独立的数据库,可以对应Oracle的数据文件和高速缓存的合集,只不过存储位置完全在内存区域;

q  日志缓存:用于暂时存储记录Data Store变更的日志,可以对应到Oracle的SGA共享内存区域的日志缓存(Log Buffer);

q  临时数据区域:临时存储执行计划等数据的共享区域,排序等等操作临时使用。相比与Oracle,TimesTen在此处作出了结构上的简化,可以视为Oracle的多个内存区域的合集,也正因为这样的简化,TimesTen在使用上相当于就必需保证简单化,否则争用热点出现,其性能甚至可能不如Oracle数据库。

在应用程序和主体内存结构之间,还架设了一层TimesTen的引擎,其需要在配置文件中进行具体的指定,功能为执行SQL语句并返回执行结果。

(2)后台进程

在后台进程中,我们可以分为常驻进程和可选进程两种,常驻进程是TimesTen数据库所必需的,包括:

q  主进程(Daemon):负责监听功能(Listener),读取配置文件信息,及分配和监视子进程。

q  子进程(Sub Daemon):负责加载和卸载Data Store,将日志缓存写入日志文件,监视和解除死锁,及执行检查点。

如果需要实现TimesTen数据库与Oracle数据库交互的高可用架构,可选进程也是不可少的。可选进程主要包括:

q  复制代理(Replication Agent):用以实施TimesTen主备数据库直接的复制工作,以及AWT缓存集合的数据刷新,以保证数据库高可用,有些类似与Oracle的Data Guard,但是相对来说,结构较为简单;

q  缓存代理(Cache Agent):实施缓存连接,开启缓存代理后,可以在TimesTen和Oracle之间开启心跳连接,并且数据定时刷新,使得TimesTen成为Oracle的前置缓存数据库;

q  Server进程:当TimesTen采用C/S连接模式时,响应客户端连接的服务器进程。

q  Process进程:当TimesTen采用Direct连接模式时,响应连接请求的进程。

(3)文件结构

最后来看一下TimesTen数据库的文件结构,是否可以看到一些Oracle的影子呢?麻雀虽小,五脏俱全,TimesTen的文件结构包括:

q  配置文件:

TimesTen服务器端的配置信息都被记录在sys.odbc.ini文件中,包括:服务器端基本配置和各个Data Store的初始化参数;

客户端连接的配置信息则被记录在sys.ttconnect.ini文件中,如果需要使用C/S连接模式,就需要配置该文件;

ttendaemon.options则用来记录TimesTen主进程所需要的配置信息,包括后台日志目录、日志大小、C/S连接端口号、TNS_ADMIN目录等。

q  警告日志文件:

ttmesg.log记录的是TimesTen运行情况的日志记录,有些类似于Oracle的alert.log文件;

tterrors.log则记录的是报错信息,有些类似于Oracle的系统进程跟踪文件;

instance_info用来记录该主机上安装过的TimesTen软件信息,包括:版本、软件目录、主进程端口号等。

q  在线日志文件:

可以视为Oracle的在线重做日志文件和归档重做志文件的合集,在TimesTen中是没有两者概念之分的,都称为在线日志文件,与Oracle不一样的是,其没有循环重复使用的机制,日志的数量会一直增加,需要定期清理,当满足如下条件时,会自动清理过期日志文件:

  • 关联事务已经全部提交完成的;
  • 检查点文件不再需要的;
  • 复制代理不再需要的;
  • Oracle缓存连接的缓存代理不再需要的;
  • 如果数据库进行过备份,则同时备份集中已经包含的。

q  预留日志文件:

也可以称为恢复日志文件,是在TimesTen宕机时恢复使用,如磁盘空间满了,TimesTen会使用该预留的日志文件记录日志,保证不丢数据(每个Data Store只能配置3个预留日志文件)。

q  检查点文件:

这类文件也是TimesTen比较特别之处,我们可以视其为数据文件,主要用来记录和同步Data Store的内存数据,是内存在磁盘上的一个镜像。当TimesTen重启或恢复的时候,子进程会将检查点文件的数据重新加载到Data Store内存区域。

每个TimesTen实例有两个检查点文件,在做检查点操作的时候会交替写入这两个文件,两个检查点文件之间的存在一定的时间间隔。在TimesTen数据库中,有三种类型的检查点:

  • 阻塞(Blocking)检查点,做该检查点操作时会加上数据库级别的锁,它是一个完全检查点,必须保证事务的一致性;
  • 非阻塞(Fuzzy)检查点,做检查点时不会加数据库级别的锁,不影响应用使用,通常数据库工作时周期性进行的就是该类检查点,它是一个不完全检查点,不必保证事务的一致性;
  • 静态(Static)检查点,TimesTen实例在创建和卸载的时候会做这种类型的检查点,此时不论是否存在脏数据块,都会全库写一遍数据文件。

需要注意的是,TimesTen与Oracle不一样,没有那么复杂的后台进程配置和触发关系,内存与检查点文件的记录和同步都是通过子进程来完成的。

为什么TimesTen需要配置两个检查点文件呢?主要还是为了保证数据冗余和快速恢复,当一个检查点失败,数据库宕机了,也可以通过另一个检查点文件快速的进行日志恢复。然而,因为有两个检查点,使得TimesTen内存与文件系统的I/O交互压力也相应增大了,内存数据库对前端应用是没有I/O的,但后台交互的I/O问题是不能小视的。

3.  连接方式

当应用端向TimesTen数据库发起连接的时候,主要可以有两种连接的模式:

(1)直接(Direct)连接模式

Oracle推荐的连接方式,具有最佳的性能,TimesTen数据库与中间件部署在同一台主机上,同处于中间件层,应用程序通过ODBC/JDBC直接对数据库进行访问,与传统的C/S模式相比,减少了TCP/IP、IPC方面的开销。

然而,TimesTen和中间件部署在同一台主机上,一定程度上增加了运维的风险。

(2)客户端/服务器(C/S)连接模式

传统的连接方式,性能比直接驱动器连接差,TimesTen数据库与中间件处于不同的主机上,客户端与服务器一般以TCP/IP方式连接,存在网络开销。

从性能上来看,直接连接的模式是有优势的,但也不是说应用程序就一定要选择该连接模式,还是需要考虑在运维方面是否能够接受因此而带来的风险。另一角度来看,TimesTen通常是作为数据库来进行运维的,被定义在数据库层,而直接连接的模式要求将其置于中间件层进行部署与运维,需要考虑在跨部门合作上的风险是否可以接受。

4.  高可用形式

我们说过TimesTen可以通过复制代理的方式实现类似于Oracle数据库Data Guard的容灾复制功能,但在功能上却没有那么强大,属于轻量级的应用。然而,因为架构的简单,所以形式更趋于多样化。

先来看一下复制代理的基本特征:

q  复制代理是一种基于事务日志的复制,即通过在线日志的应用来实现复制功能,而非简单的基于SQL语句的复制;

q  复制代理是通过TCP/IP流套接(Stream Socket)收发更新信息;

q  复制代理也可以像Data Guard一样,选择同步复制或异步复制的模式;

q  复制的粒度精细到日志的时间戳,有效解决了更新版本冲突的问题。

再来看一下常见的复制形式,如图6-4所示,TimesTen基于复制技术的高可用架构可分为:主从复制、双主复制、环形复制、衍生复制四种。

book_tt_04

图6-4  高可用复制模式

然而,在TimesTen数据库的架构设计上,我们还是要秉承简单快捷的原则,一定程度上可以参考MySQL复制的设计,虽然可以选择的方式很多,但只选择和使用最简单、最不容易出错、最容易排错的方式。TimesTen本身就是轻量级的,简单至上,我们不能期望其能像Oracle一样强大。因此,这里推荐主从复制方式,通常应用的要求基本上都能满足。

Trackback

3 comments untill now

  1. 侯总,您好。
    我也是从事 TimesTen 产品的工程师,在拜读了您相关TimesTen的大作之后,有几点小小的建议:
    1. TimesTen 目前有三种应用场景
    独立数据库
    Application-Tier Database Cache for Oracle Database(2012年产品从IMDB Cache 更名)
    以及 数据分析场景,用在 Oracle BI 一体机 Exalytics。因此, TimesTen还是可以进行复杂 SQL的运算。
    2. 对于PL/SQL的支持本身也是需要创建单独的共享内存段,因此整个TimesTen数据库加载到内存中并非只有一个独立共享内存段。
    3. TimesTen产品的命名的确有些奇怪,这个并没有继承 Oracle数据库的命名规则。也就是说,根据官方文档中 TimesTen 的 Instance 翻译为实例,实例包含的是 TimesTen Daemon 主进程,相关子进程以及一系列配置文件。而TimesTen数据库 DataStore 是真正存放数据的地方,由 SubDaemon 来管理。相信您对 Oracle数据库中实例的概念理解的非常透彻了,因此,整个书中交织了Daemon的实例,以及 DataStore实例。
    4. 图6-2中的常用实例参数应该是数据库参数,可以从安装后的 sys.odbc.ini文件开头部分找到绝大多数的参数默认值,其中有一个参数默认值很遗憾不是默认 B-Tree:
    RangeIndexType 当前默认值仍是 1: T-tree索引。
    相应的,您书中对于索引的相关描述也是 B-Tree。
    看得出来您是有远见的,能看出TT下一步应该会调整默认值为 B-Tree。
    5. ttIsql 创建数据库(240页)部分,通过Oracle数据库的 sysdba进行比较,非常直观的理解了。建议强调一下是实例管理员或者外部用户才有的能力。
    第一次登陆创建数据库需要强调是实例管理员的用户才具备的能力。
    6. TimesTen 的 Quick Start Guide 是一个亮点,但是您应该是篇幅有限,没有提及。这个是在./setup.sh中就可以选择安装的。安装之后,有大量的demo 以及常见工具说明和最佳实践指导(您书中对于数据库监控和常用工具的部分在QSG中都有更详细的介绍)。非常有利于初学者快速掌握这个产品。很遗憾是只有英文版本。建议您如果再版的时候,可以考虑一下。

    最后,希望侯总能继续关注TimesTen领域,再出更多的专著!

  2. 麻袋爸爸 @ 2015-07-14 11:10

    非常感谢能非常仔细地阅读,看得出您也是TT方面的专家,您的建议我先记下了,如您所说,如果再版,肯定采纳您的建议。

    我当初写书的定位点不是主打介绍TT,而是将TT作为一种解决问题的手段,所以细节方面有所忽略。

    再次谢谢您的建议。

  3. 麻袋爸爸 @ 2015-07-21 14:43

    非常感谢能非常仔细地阅读,看得出您也是TT方面的专家,您的建议我先记下了,如您所说,如果再版,肯定采纳您的建议。

    我当初写书的定位点不是主打介绍TT,而是将TT作为一种解决问题的手段,所以细节方面有所忽略。

    再次谢谢您的建议。

Add your comment now

切换到手机版