使用 IBM solidDB Universal Cache 提高关键数据的访问速度

使用内存 RDBMS 缓存现有的基于磁盘的数据库

IBM® solidDB® Universal Cache 是一种内存(in-memory)缓存软件,用于传统的基于磁盘的关系数据库。它向用户承诺提供高速率、适应性和健壮性。本文将研究这些特性并研究第一个承诺的示例使用场景 — 高速率。同时,了解如何使用一种由 Jython 编写的定制测试工具。

Sami Salkosuo, 软件架构师, IBM

Sami SalkosuoSami Salkosuo 是芬兰 IBM Software Group 的一名软件 IT 架构师。



2009 年 5 月 11 日

IBM solidDB 产品系列是 IBM 软件组合中最近新添的成员。Version 6.1 于 2008 年 6 月发布,而第二个发行版 6.3 则在 2008 年 12 月发布。IBM solidDB 产品系列包含的两个产品分别是 IBM solidDB(一个持久性内存数据库)和 IBM solidDB Universal Cache(针对基于磁盘的关系数据库的内存缓存软件)。

在本文中,将介绍 IBM solidDB Universal Cache 及其特性。将跟随一个简单的用例和测试场景,展示 IBM solidDB 实现的速度。了解如何使用 Jython 编程语言编写自己的测试工具(但是应用程序开发并非本文的重点)和测试 JDBC 连接性,从而快速地原型化一个测试应用程序。测试场景使用了 IBM DB2®、Apache Derby 以及 solidDB Universal Cache 来探究数据库性能。

IBM solidDB 和 IBM solidDB Universal Cache

IBM solidDB 是一个关系内存数据库。它提供微秒级的数据库事务处理速度。应用程序可以使用熟悉的 SQL 通过标准 JDBC(使用 JDBC 2.0 Type 4 驱动程序)和 ODBC 接口进行访问。IBM solidDB 支持多处理器和多核架构,并且具有使用用户和角色特权的可配置的安全性。

IBM solidDB 具有高可用性和负载平衡特性,以及高级复制特性。它还可以被直接嵌入到 Java™ 或 C/C++ 应用程序中。

IBM solidDB Universal Cache 可以作为缓存来加快 DB2、IBM Informix® Dynamic Server 和 Oracle 这类传统的基于磁盘的数据库中对性能关键数据的访问。图 1 展示了 IBM solidDB 产品系列:

图 1. IBM solidDB 产品系列
IBM solidDB 产品系列

IBM solidDB 和 IBM solidDB Universal Cache 两者都将所有数据持久性存储到磁盘中,因此不管使用哪一种产品,应用程序都可以确保数据持久性。

高速率

由于 IBM solidDB 是一种内存数据库,所以高速率是必然的。此外,solidDB 被设计为利用位于内存中的数据。比如,数据结构和访问方法专门针对位于主内存中的数据进行了优化。

由于 IBM solidDB 始终把所有数据持久化到磁盘中,因此确保了在发生服务器故障时的数据完整性。持久性是通过内置的检查点和事务日志机制实现的。通过使用检查点,已提交的事务将被写入到磁盘。在检查点之间的事务被写入到一个事务日志中,并且,如果系统发生崩溃,事务将从事务日志中恢复。事务日志可以通过严格或宽松的记录方式进行配置,其中,严格的日志记录将把已提交事务同步写入到磁盘,而宽松的日志记录将异步写入事务。事务日志功能还可以被关闭。

内存数据库提供的高速率功能可以与传统 DBMS 结合使用,其中 IBM solidDB 可充当一个数据库的缓存。图 2 展示了 Universal Cache 的工作原理:

图 2. IBM solidDB Universal Cache 的工作原理
IBM solidDB Universal Cache 的工作原理

让我们大致了解一下 Universal Cache 是如何工作的:

  1. 找出可以从高速访问中获益的表(高速访问可能和全部表有关,也可能只和少数表有关)。
  2. 将选择的表从后端数据库加载到 IBM solidDB Universal Cache 中。
  3. 将应用程序连接到 IBM solidDB Universal Cache 并使用标准接口访问数据。
  4. 以对应用程序透明的方式,IBM solidDB Universal Cache 自动与后端数据库同步数据。

由于相同的数据位于后端 DBMS 中,不需要进行高速访问的应用程序(比如报告工具)可以访问后端数据库中的数据。图 3 展示了 IBM solidDB Universal Cache 的架构概览:

图 3. IBM solidDB Universal Cache 架构概览
IBM solidDB Universal Cache 架构概览

此架构包括以下组件:

  • solidDB - 前端内存缓存。与前端数据库的同步可以是单向的,也可以是双向的。
  • 数据库服务器- 后端数据库。
  • CDC 实例(Change Data Capture 实例)- 面向每个数据库的代理软件,可以使用另一个 CDC 代理读取数据库日志文件并复制对目标数据库的更改。
  • 配置工具 - 用于配置 CDC 实例的工具。
  • 管理控制台 - 用于配置和监视复制的 GUI 应用程序。
  • 访问服务器 - 支持管理控制台访问和配置 CDC 实例。

适应性

IBM solidDB Universal Cache 可以根据具体需要进行更改。Universal Cache 可以作为只读缓存进行部署,这种情况下数据由后端数据库(DB2 或 IDS)所有,也可以部署为读写缓存,其中数据由 IBM solidDB 前端数据库所有,或者数据所有权可由前端和后端数据库共享。

在每一种场景中,数据修改都将被自动同步,可以逐一执行同步,也可以按需同步。在共享所有权的场景中,通过使用预定义的冲突解决方法来解决同步冲突。

IBM solidDB Universal Cache 的适应性使您可以灵活地配置缓存。您可以在前端数据库中使用与后端数据库相同的数据库模式,也可以仅将特定的表、列或行加载到前端,并且可以使用额外的表扩展前端内存缓存。IBM solidDB Universal Cache 还支持存储过程、触发器和事件,支持 IBM solidDB Universal Cache 在内存缓存中执行业务逻辑。

IBM solidDB Universal Cache 的可伸缩性利用了 64 位机器的大内存量,并使用了多处理器和多核架构提供并维持微秒级别的响应时间和高事务吞吐量。可伸缩性能够使 IBM solidDB Universal Cache 横向扩展到多个服务器,其中每个服务器提供对相同数据的访问,或者每个服务器保存有后端数据库中海量数据的不同部分。例如,如果一个后端数据库包含 1,000,000 个数据行,它可以被划分为分别位于 4 个服务器的 4 个 IBM solidDB Universal Cache 实例中,每个实例包含 250,000 个数据行。

健壮性

IBM solidDB Universal Cache 的健壮性由几部分组成:数据持久性、高可用性、即时故障转移和缓存管理/监视功能。

IBM solidDB 实现了与 ACID(原子性、一致性、隔离性和持久性)兼容的内存缓存来提高数据持久性。通过使用检查点和事务日志技术,ACID 属性确保 solidDB 事务被可靠地处理并且数据被持久化到磁盘中。如果前端数据库和后端数据库之间的网络连接被中断,前端将把事务记录到磁盘中,并且在稍后恢复了网络连接之后,它们将被同步到后端数据库中。

高可用性和即时故障转移特性是通过 solidDB HotStandby (HSB) 配置提供的,其中将在两个缓存实例之间对两个数据副本进行同步。如果系统发生故障,在不到一秒的时间内即可完成故障转移,并且不会影响到操作。

在 HotStandby 配置中,事务被从主节点复制到从节点,这样两个节点都进行了同步。复制可以配置为同步或异步复制。

HotStandby 的一个主要特性是应用程序只能与 IBM solidDB 建立一个逻辑连接。在出现故障的情况下,应用程序不会执行操作,而 ODBC/JDBC 驱动程序将自动维护与 IBM solidDB 的连接。

HotStandby 还附带一个好处,即负载平衡读操作。由于驱动程序维护与两个节点的连接,同时写事务被定向到主节点,因此读事务可以定向到任何一个节点。这甚至可以让性能得到 100% 的提升。

图 4 展示了 IBM solidDB HotStandby 配置的架构概览,可以提供 IBM solidDB(独立)和 IBM solidDB Universal Cache 场景中的健壮性:

图 4. IBM solidDB HotStandby 架构概览
IBM solidDB HotStandby 架构概览

主服务器和从服务器都拥有使用 HotStandby API (HSB API) 管理命令通信的 solidDB 服务器。watchdog 应用程序被称为高可用性控制器(High Availability Controller,HAC)。

IBM solidDB Universal Cache 为用户提供了图形管理控制台来定义数据库模式、字段映射和数据转换。运行时计数器也可用于监视缓存操作。


IBM solidDB Universal Cache 用例

本文的用例来自于金融行业。提供了一个虚拟的股票交易所和一个股票经纪公司以及多名股票交易员,每个人都会执行一些交易。在这个场景中,交易是随机生成的。图 5图 6 提供了此用例场景的架构概览。

速度和可靠性对于金融市场非常重要,而 IBM solidDB Universal Cache 可以同时实现两者。此外,网络延迟问题也可通过 IBM WebSphere® MQ Low Latency Messaging 解决,但是这属于另一篇文章的内容。


测试场景

为了测试 IBM solidDB Universal Cache 的速度,本文使用了一个简单的场景,其中有一名或多名 “交易员” 在执行交易,而您将使用普通的 SQL INSERT 语句更新数据库。

测试场景包括 IBM DB2 and Apache Derby 数据库,并且测试将针对每个数据库执行。测试结果只是用来研究 IBM solidDB Universal Cache 的速度,而不能对实现的数据库性能作出任何定论(参见测试结果 免责声明)。

架构

测试用例使用如 图 5图 6 所示的架构。图 5 表示使用直接数据库连接的场景(在本例中为 Derby 和 DB2):

图 5. 测试架构,直接连接数据库
测试架构,直接连接数据库

图 6 展示了将 IBM solidDB Universal Cache 用作 DB2 后端数据库的前端缓存的场景:

图 6. 测试架构,solidDB 缓存
测试架构,solidDB 缓存

Broker 1 机器表示 “一个股票经纪公司”,它具有一个或多个 Trader 流程,即 “股票交易员”。每个 Trader 流程运行在 Java Virtual Machine (JVM) 之上。测试数据库位于另一个名为 DB Server 的机器中,而数据库连接是 JDBC,使用了特定于数据库的驱动器。

统计数据库是位于 “股票经纪公司” 机器上的一个独立 IBM solidDB 数据库,而统计程序在执行完测试用例后,使用一个独立的进程从统计数据库中检索 INSERT 语句的运行时间。统计数据库还用于生成惟一的交易 ID。

数据库服务器、IBM solidDB Universal Cache 缓存服务器和 DB2/Derby 服务器,都是运行在一个桌面 PC 上的 VMWare 虚拟机。图 7 展示了这些服务器上的组件结构:

图 7. 数据服务器组件结构
数据服务器组件结构

下面的 表 1 展示了组件细节:

表 1. DB 服务器组件细节
组件说明
硬件CPU:AMD Athlon 64 Dual Core 3GHz
RAM:3.5GB
硬盘(后端 VM):80GB External USB 2.0
硬盘(前端 VM):320GB Internal SATA
网络:100 Mbps
主机 OSWindows XP SP2 (x86)
虚拟硬件后端服务器:
VMWare Workstation 6.5.0
RAM:2GB
单核 CPU
桥接网络
前端服务器:
VMWare Workstation 6.5.0
RAM:512MB
单核 CPU
桥接网络
客户机 OS前端和后端:
Windows 2003 Standard SP 2 (x86)
DatabaseDB2、Derby 和 solidDB(参见 “Databases” 小节获得更多信息)。

对于测试场景,“股票经纪公司” 是一台 IBM T42 笔记本,RAM 为 2GB,使用 Windows XP SP 2 操作系统。该笔记本使用 100Mbps LAN 连接到虚拟机。

工具

Jython

Jython 是使用 Java 代码编写的 Python 编程语言的实现。Jython 集成了 Java 技术,因此可以轻松地使用一个脚本语言开发 Java 应用程序。Jython 可以很方便地嵌入到应用程序中以为应用程序用户提供脚本功能。
Jython 还在 IBM 产品中得到了采用。例如,WebSphere Application Server, Version 6.1 和更新版本都倾向于使用 Jython 作为脚本语言,用于 WebSphere Application Server 管理。

测试场景使用的测试工具是定制的。本文使用 Jython 来测试如何在特定开发和原型化中应用它。以下是本文作者针对数据库测试开发的工具:

  • trader.py
  • dbstats.py
  • cleartables.py
  • createstatisticstables.py
  • clearid.py

您可以从本文 下载 这些测试工具的代码。

trader.py 是执行股票交易的程序。这个 Jython 连接到数据库并使用随机交易更新股票交易数据库。清单 1 展示了向数据库中插入交易的循环:

清单 1. 向数据库中插入交易
for dbname in databaseNames:
  preparedStatement[dbname]=dbConnections[dbname].prepareStatement(
          "INSERT INTO TRADE_DATA (ID, TICKER, PRICE) VALUES (?,?,?)")    
currentPrice=0.0
for i in range(totalTrades):
  print "\rTrade %04d/%04d" % (i+1,totalTrades),
  currentPrice=getNextPrice()
  tradeId=getNextIDFromSolidDB()
  insertElapsedTimeRow(tradeId)
  for dbname in databaseNames:
    preparedStatement[dbname].setLong(1,tradeId)
    preparedStatement[dbname].setString(2,ticker)
    preparedStatement[dbname].setFloat(3,currentPrice)
        
    startTime=System.nanoTime()
    preparedStatement[dbname].executeUpdate()
    endTime=System.nanoTime()
        
    updateElapsedTimeRow(tradeId,dbname,endTime-startTime)

用于获得 SQL INSERT 运行时间的数据库响应时间是通过 preparedStatement 及其 executeUpdate() 方法确定的。运行时间(以微秒为单位)随后被插入到统计数据库中。

dbstats.py 程序使用开源库 JFreeChart 为统计结果绘制图表。清单 2 展示了如何使用 JFreeChart 插件数据库表的图表。该程序生成一个平均时间图并在 HTML 页面中显示结果。dbstats.py 程序的结果单独显示在 “测试结果” 小节中。

清单 2. 创建统计数据图表
for dbname in databaseNames:
  cols=cols+(", AVG(ELAPSED_TIME_%s) AS %s " % (dbname,dbname))

jdbcCategorySet=JDBCCategoryDataset(statDbConnection)
jdbcCategorySet.executeQuery("SELECT 'Averages' %s FROM ELAPSED_TIMES" % cols)
chart=ChartFactory.createBarChart3D(
          "Total trades: %d\nElapsed time averages." % totalTrades,"","Microseconds",
          jdbcCategorySet,PlotOrientation.VERTICAL,True,True,True)
averageFileName="%s_average_times.png" % timestamp
writeImage(chart, averageFileName)

cleartables.py、createstatisticstables.py 和 clearid.py 用于设置和重置测试场景。cleartables.py 将清除每个数据库的数据库表,createstatisticstables.py 为 IBM solidDB Universal Cache 统计数据库创建统计表,而 clearid.py 清除每次测试运行之间的的交易 ID。有关测试过程的更多信息,请阅读 “测试用例” 小节。

用于测试工具的 Java 运行时是 JDK 1.6.0_11。可从本文 下载 测试工具的代码。注意,需要为数据库单独下载 Jython、Java 运行时、JFreeChart 和 JDBC 驱动程序。

数据库

表 2 列出了测试所使用的数据库。数据库同时运行在单个虚拟机上,但是它们并没有被同时访问。

表 2. 测试场景中的数据库
数据库版本说明
IBM solidDB Universal Cache6.3用于后端 DB2 数据库的前端缓存。
IBM DB29.5免费的 DB2 Express-C 版本。
Apache Derby10.4.2.0撰写本测试时的最新版本。
JVM 为 Sun JDK 1.6.0_10。

注意,所有数据库都未进行任何形式的优化;它们使用的是在安装时设置的默认配置。


测试用例

测试场景使用三个测试用例来评测 IBM solidDB Universal Cache 的速度。图 8 展示了测试过程。测试场景中的三个测试用例使用 1、2 或 4 个交易客户机,向数据库插入 50,000、100,000 和 200,000 个交易。

图 8. 测试过程
测试过程

如图 8 所示,首先需要对每个数据库进行设置并将 solidDB Universal Cache 配置为 DB2 的前端;复制被配置为仅从 solidDB 复制到后端 DB2。还需要创建将在测试中使用的表。

设置 IBM solidDB Universal Cache

图 9 展示了设置 solidDB Universal Cache 所需的步骤。

图 9. 设置 solidDB Universal Cache
设置 solidDB Universal Cache

在这个测试场景中,第一步 — 识别可从高速访问获益的表 — 非常简单。对于本测试场景,只需要在 DB2 数据库中场景一个表,称为 TRADE_DATA。清单 3 展示了用于在 DB2 数据库中创建表的 SQL:

清单 3. DB2 SQL 片段
CREATE TABLE TRADE_DATA (ID BIGINT NOT NULL, TICKER VARCHAR(5), PRICE REAL, 
                         CONSTRAINT pk PRIMARY KEY (ID) )

设置 solidDB Universal Cache 的第二步是从后端数据库中将所选的表加载到前端缓存中。完成本步骤需要用到 Management Console。由于 IBM solidDB Universal Cache 提供了良好的适应性,因此可以设置复制,从而使用读/写缓存,其中数据由前端所有。

第三个步骤是实际开发(或使用)连接到数据库的应用程序。由于连接是通过标准接口(本例为 JDBC)实现的,因此应用程序不需要担心数据库实现问题。

第四步是自动执行的 — IBM solidDB Universal Cache 将把数据同步到后端数据库。

测试

图 8 所示,对每个测试用例(1、2 或 4 个客户机)执行以下步骤(图 8 中的步骤 1 到 9):

  1. 清除表。在运行测试之前,从表中删除数据。
  2. 在运行测试前创建统计表。
  3. 使用 1、2 或 4 个客户机对 Derby 数据库执行交易。
  4. 在对另一个数据库运行测试前清除 id。
  5. 使用 1、2 或 4 个客户机对 DB2 数据库执行交易。
  6. 在对另一个数据库运行测试前清除 id。
  7. 在 DB2 中创建表,这样 solidDB 缓存就不会尝试更新现有数据。
  8. 使用 1、2 或 4 个客户机对 DB2 数据库执行交易。

在 “执行交易” 的步骤中,交易流程是在 1、2 或 4 个客户机并行执行的。


测试结果

测试用例也显示了测试结果。提供了每个测试用例的平均时间图,以及最短时间和最长时间表。结果值以微秒为单位。

免责声明

这些测试用例中的结果在任何情况下都不能作为官方甚至是非官方结果。它们仅仅用于表明数据库的执行情况,除此之外没有得出任何结论。测试用例全部由作者执行,并且测试结果也完全由本文作者进行检验。

测试环境和架构远未达到理想条件,并且任何测试数据库都未进行任何优化;每个数据库按照安装时的状态使用。

测试工具通过 “快速而粗糙(quick-and-dirty)” 方式开发,并没有进行优化。工具完全由 Jython 实现,因为作者希望了解在应用程序原型化中如何使用 Jython。

此外,所有测试都是 SQL INSERT 命令。对每个数据库的读访问速度自然大幅提升。

测试用例 1:一台客户机

本测试用例仅仅使用一台客户机访问数据库。Broker 1 机器用作客户机。对单个客户机执行的交易总数,即对数据库执行的 SQL INSERT 语句为 50,000。

图 10. 测试用例 1 的结果
测试用例 1 的结果
表 3. 测试用例 1 的结果
数据库最短时间最长时间平均时间
solidDB270.98400986586.984375831.555115
Derby1223.060059155578.7187501938.367920
DB21159.64502085668.4296881823.605347

注意,总交易数(如 图 10 所示)显示为只有 49994 项交易。这是因为统计程序在绘制图表前去掉了运行时间的最大值(最大值可能是初始化数据库连接后对数据库的第一次调用的结果)和最小值。

测试用例 2:两台客户机

本测试用例使用两台客户机访问数据库。这两台客户机执行的总交易数为 100,000。

图 11. 测试用例 2 的结果
测试用例 2 的结果
表 4. 测试用例 2 的结果
数据库最短时间最长时间平均时间
solidDB274.058014102114.375000946.763733
Derby1262.171997278358.2812502938.149902
DB21250.718018194886.2187502905.133301

测试用例 3:4 台客户机

本测试用例使用 4 台客户机访问数据库。这 4 台客户机的总交易数为 200,000。

图 12. 测试用例 3 的结果
测试用例 3 的结果
表 5. 测试用例 3 的结果
数据库最短时间最长时间平均时间
solidDB270.704010174741.4843751137.652710
Derby1259.656982332118.7500003137.169678
DB21189.816040334269.8437502780.724121

结束语

本文介绍了 IBM solidDB Universal Cache 及其主要特性:高速率、适应性和健壮性。本文使用 SQL INSERT 命令进一步研究了高速率特性,并且清楚地表明这种高访问速度可以为各种应用程序带来巨大的价值,比如在金融市场中使用的应用程序。


下载

描述名字大小
数据库测试工具TestingTools.zip5KB

参考资料

学习

  • IBM solidDB:了解有关 solidDB 的更多信息,这是针对高速率进行优化的内存数据库。
  • IBM solidDB 数据表(IBM,2008 年):详细了解 solidDB 及其特性。
  • DB2 skill kit:提高数据库管理员和应用程序开发人员的知识和技能。了解如何安装、配置和管理 IBM DB2 Universal Database。主题包括:概述、安装、配置、数据库创建和管理。
  • developerWorks Information Management 专区:了解有关 Information Management 的更多信息。查找技术文档、how-to 文章、培训、下载、产品信息等。
  • 随时关注 developerWorks 技术活动网络广播
  • 技术书店:浏览有关这些主题和其他技术主题的图书。

获得产品和技术

  • Jython 项目:了解有关 Jython 的更多信息。
  • JFreeChart:下载 JFreeChart,这是一个完全免费的 Java 图表库,可以使你轻松地在自己的应用程序中显示专业的图表。
  • Apache Derby:下载 Apache Derby。
  • IBM 软件下载:IBM DB2 Express-C 9.5:现在可以免费使用 DB2。下载 DB2 Express-C,这是为社区提供的 DB2 Express Edition 的免费版本,它提供了与 DB2 Express Edition 相同的核心数据特性,为构建和部署应用程序奠定了坚实的基础。
  • 使用可直接从 developerWorks 下载的 IBM 产品评估试用软件 构建您的下一个开发项目。

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Information Management
ArticleID=388374
ArticleTitle=使用 IBM solidDB Universal Cache 提高关键数据的访问速度
publish-date=05112009