缓存内存优化

使用OracleTimesTenApplication-TierDatabaseCache提高Oracle数据库的速度ORACLE白皮书|2014年6月1|使用OracleTimesTenApplication-TierDatabaseCache提高Oracle数据库的速度目录1.
引言22.
应用程序层缓存33.
OracleTimesTenIn-MemoryDatabase43.
1OracleTimesTen的性能64.
使用OracleTimesTenApplication-TierDatabaseCache缓存数据64.
1定义缓存的内容84.
2加载数据和管理缓存94.
3在缓存网格范围内共享数据104.
4维护数据一致性104.
5高可用性145.
性能176.
示例186.
1只读缓存186.
2只读滚动窗口缓存196.
3可更新的缓存196.
4可更新的动态缓存206.
5发生率不均的数据捕获缓存206.
6稳定的高发生率的数据捕获缓存216.
7可更新的用户管理的缓存216.
8只读动态分布缓存227.
总结222|使用OracleTimesTenApplication-TierDatabaseCache提高Oracle数据库的速度1.
引言OracleTimesTenApplication-TierDatabaseCache可以加快业务流程速度、支持实时业务智能、促进面向客户的应用程序实现个性化.
OracleTimesTenApplication-TierDatabaseCache(TimesTenCache)是一个Oracle数据库产品选件,非常适于将Oracle数据库中对性能影响极大的部分缓存在应用程序层中.
使用TimesTenCache可提高应用程序的响应速度和吞吐量.
TimesTenCache由三个重要技术组件构成—OracleTimesTenIn-MemoryDatabase(TimesTen),用于应用程序层实时数据管理;缓存技术,用于将频繁访问的表从Oracle数据库服务器缓存到应用程序层并维护缓存数据的一致性;事务型数据复制组件,用于确保跨层的高可用性.
TimesTen是一个内存优化的关系数据库,它为性能要求极高的系统提供了极快的响应时间和极高的吞吐量.
其设计目标是运行于应用程序层(靠近应用程序),也可与应用程序一起在进程中运行.
TimesTen数据库可用作记录数据库和/或某个Oracle数据库的缓存.
应用程序可以在TimesTen中创建和管理数据库表,也可以将Oracle数据库中频繁访问的内容缓存在TimesTenCache中.
缓存表和非缓存表可共存于同一个内存中数据库中,并且这些表都是可持久存在和可恢复的.
应用程序可以使用ODBC、JDBC、ADO.
NET、OracleCallInterface(OCI)或TTClasses以及Pro*C通过SQL92或PL/SQL对缓存数据和非缓存数据执行查询和更新.
OracleTimesTenIn-MemoryDatabase是一个内存优化的关系数据库,它为性能要求极高的系统提供了极快的响应时间和极高的吞吐量.
其设计目标是运行于应用程序层(靠近应用程序),也可与应用程序一起在进程中运行.
它可用作记录数据库,也可以用作某Oracle数据库的缓存.
缓存网格由一组共同管理应用程序缓存数据的TimesTenCache构成,可用于改善性能和容量,实现横向可伸缩性.
缓存数据分布在网格成员之间,缓存网格为应用程序提供位置透明性,从而使应用程序可以有效地使用所有网格成员中缓存的数据聚合.
通过联机添加(和删除)网格成员,缓存网格可以实现增量可伸缩性.
缓存网格可以维护缓存网格成员与Oracle数据库之间缓存数据的一致性.
TimesTenCache跨应用程序层和数据库服务器层管理数据的可用性.
无论何处发生故障,它都能确保高可用性,并确保不丢失事务.
无论故障是发生在某个缓存节点、某个OracleRAC节点,还是发生在网络级,甚至是整个RAC集群都发生故障,均可保证高可用性,并保证不丢失事务.
TimesTen和TimesTenCache在实时企业和响应时间要求极短的行业中部署具有极佳表现,包括网络通信服务、运营支持系统、联系中心、机票预订系统、指挥和控制系统以及证券交易系统.

3|使用OracleTimesTenApplication-TierDatabaseCache提高Oracle数据库的速度全球数千家公司在生产应用中使用了TimesTen和TimesTenCache,这些公司包括Alcatel-Lucent、Aspect、Avaya、BankofAmericaMerrillLynch、BridgewaterSystems、BroadSoft、Cisco、DeutscheBrse、Ericsson、JPMorgan、KDDI、NEC、NYFIX、SmartCommunications、UnitedStatesPostalOffice和VerizonWireless.
2.
应用程序层缓存通常,应用程序层缓存用于缩短数据访问延迟并减少后端数据库的负载.

人们已经开发了各种缓存技术来提高数据库访问性能或减少后端数据库服务器上的争用.
快速响应时间对实时应用程序和面向客户的应用程序尤为重要.
另外,对于那些用户群体持续增长的应用程序(如托管软件服务、电子商务站点或电信服务),减少后端数据库的负载也很重要.
至于缓存哪些信息以及将信息缓存在何处,有多种选择,每种选择都有其优缺点.
已经开发的一些缓存技术包括:查询结果缓存.
这通常在应用程序层进行并由一个专用软件管理,该软件向应用程序隐瞒了缓存的存在.
这种情况下,缓存软件自动保存提交给数据库系统的查询结果.
如果某个查询与之前提交的一个查询完全匹配(包括相同的参数值),则确认一个缓存命中并由缓存提供服务.
这种缓存技术的优点是简单,适于可能反复提交相同查询的访问情况.
但它的用途有限,因为无法处理对缓存内容的查询处理.
对象关系映射工具缓存.
通过提供对象与关系数据之间的透明映射,对象关系映射工具(O/R映射工具)向面向对象的编程人员隐藏了关系数据库.
一旦关系数据映射为一个对象表示,O/R映射工具就可对其进行缓存,直到不再需要该数据或该数据过期.
通过O/R映射工具进行缓存是避免编程语言对象模型与数据库关系模型之间高开销映射的一种常用技术.
对象缓存.
这里的"缓存"一词某种程度上是个误称,因为放入这些缓存中的对象不一定是存储在其他地方的对象的子集.
这些"缓存"是独立于对象源的对象信息库.
它们通常对应用程序不透明.
应用程序从这些缓存中"put"、"get"、"insert"和"delete"对象.
市场上提供这类缓存的产品很少,并且它们所支持的功能水平也有所不同.
这些缓存可能是完全的内存驻留,也可能是回到磁盘或其他数据管理系统.
一些产品提供并发控制,一些产品提供网络中多个节点上的透明分布,还有一些产品提供高可用性.
OracleTimesTenApplication-TierDatabaseCache具备完整的关系功能和SQL功能,能够自动维护数据与Oracle数据库的一致性,并能维护实时性能.
OracleTimesTenApplication-TierDatabaseCache(TimesTenCache)采取了一种独特的方法,支持将表或表片段从Oracle数据库缓存到应用程序层.
表片段通过扩展的SQL语法进行描述,并缓存在OracleTimesTenIn-MemoryDatabase(TimesTen)中.
应用程序使用SQL、PL/SQL或Pro*C读取和更新缓存数据,TimesTenCache自动将Oracle数据库中的更新传播到缓存中,并将缓存中的更新传播到Oracle数据库中.
4|使用OracleTimesTenApplication-TierDatabaseCache提高Oracle数据库的速度可以将一组TimesTenCache配置成一个缓存网格.
缓存数据分布在网格成员之间,缓存网格为应用程序提供位置透明性和并发控制,从而使应用程序可以有效地使用网格成员中缓存的所有数据聚合.
随着应用程序性能或容量需求的增加,还可向缓存网格添加更多节点,而无需中断服务.
因此,TimesTenCache除了为应用程序提供关系数据库的完整功能,还提供了增量可伸缩性及位置透明性,并能自动维护缓存与Oracle数据库的一致性,还提供了实时的内存中数据库性能.
TimesTenCache方法有两个主要优点,有助于提高整体性能.
第一,TimesTen的内存中架构消除了应用程序层与数据库服务器之间的通信,因此使用TimesTenCache的应用程序可以大大缩短响应时间并显著增加吞吐量.
第二,该方法减少后端数据库的负载,从而提高所有应用程序的总吞吐量.

它所提供的关系数据库的全部优势、实时性能、增量可伸缩性及自动缓存管理,都是TimesTenCache的独特功能.
它适于缓存对性能影响极大的Oracle数据库子集,支持读取和更新缓存数据,并且,它还能自动管理数据一致性.
本文的后续部分将简单介绍OracleTimesTenIn-MemoryDatabase(可在1中找到更详细的信息),还将介绍OracleTimesTenApplication-TierDatabaseCache是如何缓存和管理数据的,并且列举了几个说明性的使用缓存的情况.
3.
OracleTimesTenIn-MemoryDatabaseTimesTenIn-MemoryDatabase通过标准API提供对数据和关系功能的事务访问.
OracleTimesTenIn-MemoryDatabase是一个内存优化的关系数据库,它通过ODBC、JDBC、ADO.
NET、OracleCallInterface(OCI)、TTClasses2API以及Pro*C/C++支持SQL92和PL/SQL.
通过支持标准接口和常用Oracle接口,TimesTen确保被现有应用程序方便地使用.
虽然TimesTen对主内存中的数据进行操作,但TimesTen数据库在软件、硬件或电源故障时仍然可持久存在且可恢复.
通过检查点和将其记录到磁盘可确保持久性.
应用程序可以为其事务选择ACID属性,但还提供了其他更优选项以实现更高性能.
TimesTen提供一个基于成本的查询优化器,应用程序可通过它查看和改变查询计划.
可以将TimesTen数据库作为应用程序链接库提供,也可以通过客户端/服务器选项提供.
通过客户端/服务器选项访问TimesTen时,对TimesTen的每个请求都会产生进程间通信开销,即使应用程序与TimesTen服务器运行在同一台计算机上也是如此.
相反,TimesTen与应用程序链接后,对TimesTen的请求就只是开销可忽略不计的本地调1使用OracleTimesTenIn-MemoryDatabase实现极限性能.
Oracle白皮书,2014年6月.
2TimesTenC++InterfaceClasses(TTClasses)是一个C++类库,提供了关于最常用ODBC功能的打包.
它比ODBC更易于使用,并且在保持快速性能的同时促进最佳实践.
5|使用OracleTimesTenApplication-TierDatabaseCache提高Oracle数据库的速度用,应用程序与TimesTen之间的数据传输就只是开销较小的内存复制操作.
通过复制提供了高可用性.
还提供了大量实用程序,包括一个交互式SQL实用程序,以及一个用于数据库开发和缓存配置、联机备份和还原以及批量加载的图形化工具.
此外,还通过可编程的API提供了数据库维护操作.
运行时,主内存中驻留了数据库的一个副本.
在一个共享内存段中管理这个副本,所有连接到该数据库的进程均可访问该副本.
图1显示了TimesTenIn-MemoryDatabase系统的架构.
图1.
TimesTen架构针对数据所驻留的内存对OracleTimesTenIn-MemoryDatabase数据结构和算法进行了优化.
TimesTen的数据结构和存取算法利用数据库所驻留的内存实现了性能突破.
与完全基于磁盘缓存的数据库相比,TimesTen的内存优化架构使用的CPU周期要少很多,这是因为它省去了用于管理内存缓冲区并处理多个数据位置(磁盘和内存)的开销.
OracleTimesTen内存优化的性能由支持事务属性、持久性机制以及系统故障恢复所完善.
有各种方法可用于锁定、多用户隔离和日志记录,从而满足各种应用情形(从临时查找缓存到核心事务性财务交易和电信计费系统).

TimesTen数据库可持久存在且可恢复.
TimesTen通过将已提交事务中的更改记录到磁盘并通过检查点定期更新数据库的磁盘映像实现了持久性.
应用程序6|使用OracleTimesTenApplication-TierDatabaseCache提高Oracle数据库的速度可以对日志写入磁盘的时间进行配置(要么与事务的结束时间同步,要么一直延迟到事务完成之后),从而实现更高的性能.
在许多情况下,高吞吐量要比同步记录重要,尤其是当事务的货币价值很低或事务数据的生存时间较短时(如,在每几秒种传输一次移动电话位置的网络中跟踪移动电话的位置时).

TimesTen允许应用程序跟踪特定表的变更.
这在应用程序对特定事件的发生非常敏感的环境中是很有用的.
例如,应用程序可能希望知道某支股票的价格何时超出给定的阈值.
这种变更通知特性不仅能跟踪基表的变更,而且还能跟踪物化视图的变更,因此特别有用.
3.
1OracleTimesTen的性能仅靠添加硬件无法实现极低的响应时间.
TimesTen凭借其独特的架构提供了极低的延迟.
TimesTen采用内存中架构,因此可实现微秒级的响应时间.
使用TimesTen,读取一条数据库记录的事务所用时间不到2.
5微秒,更新或插入一条记录的事务所用时间也小于8微秒.
图2.
TimesTen的响应时间图2显示了应用程序在运行OracleLinux的IntelE5-2680(2.
7GHz,2插槽,8核/插槽)上执行读取和更新事务的响应时间.
4.
使用OracleTimesTenApplication-TierDatabaseCache缓存数据TimesTenCache包含Oracle数据库表的子集.
使用TimesTenCache可将Oracle数据库中表的子集缓存到应用程序层.
可对缓存表进行更新,并且TimesTenCache在Oracle数据库与缓存之间同步数据.
管理缓存数据的数据库引擎为OracleTimesTenIn-MemoryDatabase.
其功能有所增强,能够加载和同步缓存数据.
与TimesTenCache关联的后台进程之一是缓存代理,它管理部分数据同步.
图3显示了TimesTenCache的架构.
7|使用OracleTimesTenApplication-TierDatabaseCache提高Oracle数据库的速度图3.
TimesTenCache的架构缓存网格是共同管理应用程序数据的TimesTenCache的集合.
缓存网格由一个或多个网格成员组成,而TimesTenCache支持所有网格成员.
网格成员缓存中央Oracle数据库或RealApplicationCluster(RAC)中的表.
缓存数据跨无共享存储的多个节点(即TimesTenCache)分布.
缓存网格确保节点间数据的一致性.
网格成员可以复制.
图4.
包含3个复制网格成员的缓存网格8|使用OracleTimesTenApplication-TierDatabaseCache提高Oracle数据库的速度图4显示了由3个复制网格成员组成的缓存网格.
可以逐渐增加网格成员,而不中断操作.
必须与TimesTenCache一起使用的复制配置为主动/备用对配置.
4.
1定义缓存的内容使用扩展SQL语法定义TimesTenCache的内容.
缓存组是一组TimesTenCache表,它对应于一组频繁使用的Oracle数据库表,这些表通过外键约束相关联.
使用SQL语法定义缓存组,并从Oracle数据库表中选择要缓存的列和行.
用户可以通过编程方式或者通过交互式ttIsql实用程序定义缓存组.
示例:假设Oracle数据库中存在以下表:-Customer(CustId、Name、Age、Gender、StreetAddress、State、ZipCode、PhoneNo)-Order(CustId、OrderId、PurchaseDate、Amount)-CustInterest(CustId、Interest)应用程序可能希望对2014年1月1日以来下单客户的配置文件进行缓存.
为达到此目的,它可能定义以下两个缓存组:第一个缓存组包含上述三个表的部分内容,也就是只包含2014年1月1日以来的下单客户,并且这些客户居住在美国西海岸.
而且,应用程序可以选择只缓存这些表的部分列.
例如,它可能缓存以下列:-Customer(CustId、Name、Age、Gender、State)-Order(CustId、PurchaseDate、Amount)-CustInterest(CustId、Interest)第二个缓存组与第一个缓存组包含同样的信息,但是其中的客户居住在美国的山区.

这两个缓存组可以缓存在运行TimesTenCache的不同节点中.
TimesTenCache使用的另外一个概念是缓存实例.
缓存实例是唯一可标识的相关记录的集合,用于建立一个复杂对象的模型.
正如下面将要介绍的,缓存实例构成了缓存加载和缓存老化的基本单位.
在上面的示例中,Customer、Order和CustInterest三个表中属于给定客户ID(CustId)的所有记录都属于同一个缓存实例,这些记录通过外键约束互相关联.
CustId唯一标识缓存实例,因此我们将CustId称为缓存实例键.
TimesTen与Oracle数据库支持相同的数据类型.
除了支持自己的数据类型外,TimesTen还支持与Oracle数据库相同的基本数据类型,因此无需将Oracle数据库数据类型映射为TimesTen数据类型.
但是,可能需要将Oracle数据库数据类型映射为更高效的TimesTen实现.
例如,应用程序可将Oracle数据库的NUMBER数据类型映射为TimesTen的INTEGER数据类型.
9|使用OracleTimesTenApplication-TierDatabaseCache提高Oracle数据库的速度注意,应用程序开发人员可以在内存中缓存表上创建索引.
内存中缓存索引可能与Oracle数据库的索引相匹配,也可能不同.
应用程序设计人员可以利用TimesTen的灵活性在同一个表上创建多个索引,也可以对多列定义索引.
索引顾问程序这款工具可以评估给定的SQL负载并给出最佳索引建议,以提高TimesTen数据库内相关查询的性能.
4.
2加载数据和管理缓存应用程序必须确定如何将缓存组数据加载到TimesTenCache以进行处理.
可使用以下方法加载数据:显式加载.
这可通过下列几种方式完成:一次加载整个缓存组.
如果一个缓存可以容纳整个缓存组的内容,则适合使用该方法.
还能够卸载整个缓存组.
"按WHERE子句"加载缓存实例.
这种情况下,WHERE子句用于描述应该进入缓存的部分缓存实例.
应用程序也可"按WHERE子句"卸载缓存实例.
"按ID"加载缓存实例.
这种情况下,使用缓存实例Id列表指定应放入缓存的缓存实例.
应用程序也可"按ID"卸载缓存实例.
动态加载.
该方法用于加载缓存实例.
当缓存组太大以至于缓存中无法容纳时,动态加载非常有用,这时缓存中只保留应用程序的工作集.
这种情况下,根据缓存缺失自动加载构成缓存实例的记录,也就是说,SQL语句3在缓存中找不到请求的数据时就加载含有该数据的记录.
如果缓存实例已经在缓存中,则由该缓存直接处理SQL语句.
动态加载通常与自动缓存老化一起使用.
当超过缓存容量时,自动将老化的缓存实例从缓存中换出.
TimesTenCache支持基于使用情况的老化和基于时间的老化.
当超过缓存容量时,基于使用情况的老化使用LRU(最近最少使用的)方案将老化的缓存实例换出.
基于时间的老化在缓存中授予缓存实例一定时间的生存期,这种老化需要缓存组的某个表含有时间戳列.
时间戳列的值由应用程序管理.
只要缓存实例的时间戳值加上生存期不超出当前时间,缓存实例就能保留在缓存中.
注意,缓存老化可独立于动态加载单独使用,实际上,可以和不是从Oracle数据库缓存的常规TimesTen表一起使用.
应用程序可以选择对一些缓存组实施老化,而其他缓存组则保留.
例如,应用程序可能希望在缓存中始终保留目录信息,但又希望在用户连接到应用程序时才按需加载用户的配置文件,在用户断开连接后再自动换出这些配置文件.
应用程序也可以显式地卸载缓存实例.
已经加载到内存中缓存表的数据可通过JDBC、ODBC、ADO.
NET、TTClasses、OCI和Pro*C进行SQL、PL/SQL处理.
3动态加载缓存实例可用于在缓存实例的任何记录的主键或外键上带有等式的SQL语句.
10|使用OracleTimesTenApplication-TierDatabaseCache提高Oracle数据库的速度4.
3在缓存网格范围内共享数据缓存组可以是本地的,也可以是全局的.
对于本地缓存组,缓存数据不能在同一个缓存网格的成员之间共享.
网格成员可能具有分散的数据或者重叠的数据,由应用程序决定数据在网格成员中的分布方式.
例如,为了获得最佳性能,可将只读目录数据缓存在所有网格成员中,而将可更新的客户信息按地理区域分区缓存于不同网格成员中.
提交的对缓存表的更新被传播到与其他网格成员没有协调关系的Oracle表中.
可将本地缓存组定义为显式加载的缓存组或动态加载的缓存组.
默认情况下,缓存组都是本地的,除非将它们定义为全局的.

在全局缓存组中,同一个缓存网格的成员可共享缓存数据.
跨整个网格执行并发控制,网格中任意位置运行的事务始终会看到最新提交的缓存实例版本.
不同网格成员提交的对同一个缓存实例的更新,按照它们在网格中的提交顺序传播给Oracle数据库,以确保数据一致性.
4.
4维护数据一致性OracleTimesTenCache支持对缓存数据的更新,并能自动维护缓存与Oracle数据库之间的一致性.
缓存数据可在TimesTenCache中更新,也可在Oracle数据库中更新.
TimesTenCache能够自动将更新从缓存传播到Oracle数据库,也可将Oracle数据库的更新传播到缓存.
但基本前提是,缓存组主要或仅在缓存或Oracle数据库中更新.
对既要在缓存中大量更新又要在后端数据库中大量更新的一组表进行缓存是一个重大设计缺陷.
但是,实际应用中存在着缓存和后端数据库中都允许更新的情况.
例如,Oracle数据库中的更新只发生在夜间,其目的是为了维护,而缓存中的更新发生在白天;或者中央数据的更新发生在Oracle数据库中,而区域数据更新发生在缓存中.
缓存组可以是系统管理的,也可以是用户管理的.
有三种系统管理的缓存组:只读缓存组.
这些缓存组不能在缓存中更新.
它们只能在Oracle数据库中更新,并且由TimesTenCache管理从Oracle数据库向缓存传播更新.
异步直写(AWT)缓存组.
这些缓存组可以在缓存中更新,但不能在Oracle数据库中更新.
事务提交后,TimesTenCache异步地将更新从缓存传播到Oracle数据库.
同步直写(SWT)缓存组.
这些缓存组可以在缓存中更新,但不能在Oracle数据库中更新.
提交事务的同时将内存中缓存表中的更新同步传播到Oracle数据库.
系统管理的缓存组有定义清晰的语义和执行这些语义的约束条件.
相反,用户管理的缓存组的语义都由应用程序负责.
例如,用户管理的缓存组既可在缓存中更新,也可在Oracle数据库中更新.
只读、AWT、SWT和用户管理的缓存组都可以是本地缓存组.
但是,只有AWT缓存组可以指定为全局缓存组.
11|使用OracleTimesTenApplication-TierDatabaseCache提高Oracle数据库的速度维护数据一致性下表汇总了可用的各种缓存组加载、缓存网格共享和一致性维护选项.

向缓存组中加载数据显式加载动态加载只读缓存组xxAWT缓存组xxxxSWT缓存组xx用户管理的缓存组xx全局缓存组本地缓存组全局缓存组在缓存网格范围内共享数据通过一个到TimesTenCache数据库的连接,TimesTenCache应用程序可以向缓存组或Oracle数据库发送SQL语句.
此单一连接功能由直传(PassThrough)特性启用,该特性检查内存中缓存表能否在本地处理SQL语句,或者是否必须将其重定向到Oracle数据库.
该直传特性提供了一些设置,使用这些设置可以指定在哪些情况下将哪些类型的语句进行传递.
一个尤为有用的设置是,指定将所有更新数据库的语句都传递给Oracle数据库.
通过该设置,应用程序可以通过单个连接在Oracle数据库中执行更新,在TimesTenCache中执行读取.
下面几节将介绍用于维护缓存数据一致性的TimesTenCache操作.
其中部分操作由TimesTenCache自动启动;其他操作则由应用程序显式启动.
4.
4.
1从TimesTenCache向Oracle数据库传播更新以及在全局缓存组的所有缓存网格成员之间传播更新正如我们已经看到的,全局缓存组也是动态AWT缓存组.
使用全局缓存组的应用程序将连接到一个网格成员.
大部分时间,应用程序将访问该网格成员中已经缓存的缓存实例.
但是,当应用程序试图访问该网格成员中没有的缓存实例时,TimesTenCache将从另一个网格成员或从Oracle数据库动态加载要访问的缓存实例,具体从何处加载取决于该缓存实例的最新更新版本所在位置.
这一过程是完全自动的,无需应用程序干预.
TimesTenCache确定最新副本所在位置,并使用点对点通信与该网格中的其他TimesTenCache数据库交换信息.
如果某个事务更新了任一网格成员中的缓存实例,可通过以下机制保持Oracle数据库与缓存的同步:传播.
事务提交后,TimesTenCache将更新传播到Oracle数据库.
如果不久之后另一事务更新了另一网格成员中的同一个缓存实例并且进行了提交,则TimesTenCache会确保将该提交按正确的顺序传播到Oracle数据库中.
本地缓存组12|使用OracleTimesTenApplication-TierDatabaseCache提高Oracle数据库的速度图5显示了由三个网格成员组成的缓存网格.
所有网格成员缓存的是同一个全局缓存组,每个网格成员的缓存中只缓存了该全局缓存组的部分缓存实例.
因为这些实例最近被访问过,因此被缓存在它们各自的网格成员中.
随着时间的流逝,每个实例要么继续在其网格成员中被访问从而保留在那里;要么在另一个网格成员中被访问,从而将它移动到被访问的成员中;要么永不再被访问,这时就将它从该缓存网格中彻底换出.

图5.
全局缓存组的更新传播与缓存一致性4.
4.
2本地缓存组从TimesTenCache向Oracle数据库的更新传播对于可在缓存中更新的本地缓存组,使用以下机制保持Oracle数据库与缓存的同步:传播.
打开传播选项后,对缓存组的所有修改(即所有插入、更新和删除操作)都自动传播给Oracle数据库.
SWT缓存组和AWT缓存组传播发生的时间不同.
对于SWT缓存组,应用程序完成了一个修改一个或多个缓存组的事务后,首先在Oracle数据库中提交该事务,然后在TimesTenCache中提交该事务.
这种方法使得Oracle数据库在将任何所需的相关逻辑在TimesTenCache中提交之前就先应用于数据.
对于AWT缓存组,应用程序完成一个事务后,就在TimesTenCache中提交该事务并且控制权返回给应用程序.
然后,再将该事务所进行的变更异步传播到Oracle数据库.
数据库刷新.
该操作由来自应用程序的显式请求驱动,可应用于缓存组或缓存实例.
只有对关闭了传播选项的缓存组或缓存实例才允许使用该机制.
该操作会根据缓存中记录的值更新Oracle数据库中的记录.
当某段时间内需要对同一个记录集进行频繁更新时,该操作很有用.
不是每个更新都实时传播,而是将每个记录的最终映像发送并应用到Oracle数据库.
一个应用程序可以配置一个包含若干位于不同网格成员中的可更新本地缓存组的缓存网格.
从网格成员向Oracle数据库的更新传播将由TimesTenCache管理,但是,我们建议不同网格成员中的本地缓存组不要重叠,这样可以避免在不同节点中同时发生对同一个数据的不同更新,如果发生这种情况,将在后端数据库上产生不可预测的数据值.
13|使用OracleTimesTenApplication-TierDatabaseCache提高Oracle数据库的速度图6.
更新传播和可更新的本地缓存组4.
4.
3本地缓存组从Oracle数据库向TimesTenCache的更新传播对于在Oracle数据库中更新的本地缓存组4,可以使用以下机制保持缓存内容与Oracle数据库的同步:刷新.
这是一个来自应用程序的显式请求,可以刷新整个缓存组,也可刷新特定的缓存实例.
它相当于在卸载操作后紧跟着执行加载操作.
完全自动刷新.
使用完全自动刷新时,应用程序指定刷新应该发生的频率,而TimesTenCache按照应用程序指定的时间间隔自动刷新缓存组.
增量自动刷新.
与完全自动刷新不同,增量自动刷新只更新上次刷新后Oracle数据库中有所修改的记录.
与完全自动刷新一样,应用程序也必须指定刷新频率,TimesTenCache按照这个频率自动执行增量刷新.
增量自动刷新可以与基于时间的老化一起使用,以便在缓存中保留一个滚动窗口.
例如,客户支持应用程序可能希望在缓存中保留过去5天内报告的所有事件.
这种情况下,应用程序可以指定缓存组应使用增量自动刷新,并且指定基于时间的老化的生存期为5天.
随着新的事件不断插入Oracle数据库中,增量自动刷新自动将它们传播到内存中缓存表.
如果这些事件在Oracle数据库中进行了更新,这些更新也将自动传播到内存中缓存表.
这些事件必须包含由应用程序维护的时间戳.
一旦时间戳的值比当前时间早5天以上,则其关联的事件将会自动从缓存中换出.
上面介绍的三种方法适用于不同的情况.
假设只需在每天凌晨2点刷新一次缓存组,此时内容提供商网站的活动最少,这种情况下,使用完全自动刷新也许是最佳选择.
另一种情况,如果需要每五分钟刷新一次缓存组,则应使用4注意,全局缓存组不能在Oracle数据库上进行更新.
14|使用OracleTimesTenApplication-TierDatabaseCache提高Oracle数据库的速度增量自动刷新.
最后,对于只需很少刷新但又无法预测刷新次数(次数只有应用程序知道)的缓存组,应选择使用上边介绍的第一种方法—刷新.
一个应用程序可以配置一个包含若干位于不同网格成员中的只读本地缓存组的缓存网格.
不同网格成员中的缓存组也许是完全分散的、部分重叠的或完全相同的.
将由TimesTenCache管理从Oracle数据库向所有网格成员的更新传播.
图7.
增量自动刷新只读本地缓存组4.
5高可用性TimesTenCache支持跨应用程序层和数据库服务器层的高可用性.
将OracleTimesTen专门用作记录数据库时,与用作Oracle数据库的数据库缓存相比,它通过复制、各种联机操作功能以及大量支持故障切换、恢复和联机升级的实用程序,更能确保数据的高可用性.
通过与OracleClusterware的集成,提供了数据库和应用程序的自动故障检测和自动故障切换功能.
类似地,Oracle数据库通过包括OracleRealApplicationClusters(RAC)、Oracle自动存储管理(ASM)和OracleDataGuard在内的一组特性,支持其数据的高可用性.
另外,TimesTenCache的Replication组件提供了大量特性,不但可确保缓存数据的高可用性,还可确保分布于应用程序层和数据库层中的Oracle数据库中的故障的自动恢复.
下面分别介绍这些特性.
4.
5.
1内存中缓存节点故障的处理为防止缓存节点故障并确保缓存数据的持续可用性,TimesTen复制特性提供了缓存节点的故障切换与恢复处理.
具有多个只读使用者的主动/备用对复制配置旨在将Oracle数据库作为配置的一部分,以便提供缓存节点的故障切换与恢复.
15|使用OracleTimesTenApplication-TierDatabaseCache提高Oracle数据库的速度使用主动/备用对时,始终将所有更新先应用于主动节点.
然后将更新复制到备用节点,接着再将更新从备用节点复制到所有只读使用者节点.
这样,备用节点始终在只读使用者节点前头,如果主动节点发生故障,毫无疑问可以确定哪个使用者节点应该成为新的主动节点.
只读缓存组主动/备用对复制配置旨在让只读缓存组与直写缓存组协同工作.
使用只读缓存组时,Oracle数据库中应用的更新只传播到主动节点.
然后,TimesTen复制将更新先通过备用节点再传播到所有其他节点.
图8.
使用主动/备用对配置的只读缓存组如果主动节点发生故障,备用节点就成为新的主动节点.
从这时开始,来自Oracle数据库的更新将传播到新的主动节点(以前的备用节点),然后再从该节点复制到只读使用者节点.
一旦原来的主动节点恢复联机,它将成为新的备用节点.
TimesTen复制特性自动处理从主动到备用的更新传播的切换以及故障节点的恢复.

类似地,如果备用节点发生故障,来自主动节点的复制操作将自动重定向到只读使用者节点.
一旦备用节点恢复联机,复制特性将确保它补上恢复为备用节点角色前错过的所有更新.
16|使用OracleTimesTenApplication-TierDatabaseCache提高Oracle数据库的速度直写缓存组使用直写缓存组时,更新先应用于主动节点.
然后再将它们复制到备用节点.
一旦到达备用节点,就可将它们传播到Oracle数据库并复制到所有只读使用者节点.
图9.
使用主动/备用配置的直写缓存组如果主动节点发生故障,备用节点就成为新的主动节点.
从这时开始,必须将所有更新发送到新的主动节点,即以前的备用节点.
对新主动节点的更新将传播到Oracle数据库并复制到只读使用者节点.
一旦原来的主动节点恢复联机,它将成为新的备用节点.
TimesTen复制特性自动处理新备用节点的恢复,并负责将向后端传播更新的职责转移给新备用节点.
类似地,如果备用节点发生故障,来自主动节点的复制操作将自动重定向到只读使用者节点,而主动节点将直接开始向Oracle数据库传播更新.
一旦备用节点恢复联机,复制特性将确保它补上恢复为备用节点角色前错过的所有更新,并让备用节点重新开始向Oracle数据库和只读使用者传播更新.
4.
5.
2Oracle数据库中的故障处理如果由于网络故障、硬件故障或Oracle数据库故障等原因导致TimesTenCache无法访问Oracle数据库,TimesTenCache的设计已经将这些故障对它的影响降至最低.
应用程序仍然可以继续访问内存中缓存.
而且,在使用AWT缓存组的情况下,对缓存的更新将继续记录到OracleTimesTen中,以便在Oracle数据库恢复为可访问后,将更新传播给它.
类似地,对Oracle数据库中的只读缓存组进行的但尚未传播到内存中缓存的变更仍将记录在Oracle数据库上,一旦Oracle数据库恢复为可访问,就会将这些变更传播给缓存.
17|使用OracleTimesTenApplication-TierDatabaseCache提高Oracle数据库的速度另外,TimesTenCache充分利用了RAC的高可用性特性.
RAC配置包含一个可供几个节点访问的物理数据库.
一个节点上的运行时配置称为一个实例.
RAC提供了跨所有实例的负载平衡、高可用性和数据一致性.
无需用户干预,TimesTenCache即可从RAC节点故障中快速恢复.
为此,在可以使用Oracle透明应用程序故障切换(TAF)特性和快速应用程序通知(FAN)特性的场合,TimesTenCache会使用这两个特性.
也就是说,这两个特性是否可用取决于Oracle客户端、服务器和TAF配置的版本.
如果与TimesTenCache连接的Oracle实例发生故障,则自动将该连接切换到另一个实例.
发生故障时,如果正在进行刷新、完全自动刷新或增量自动刷新操作,则该操作将自动回滚内存中数据库中发生的变更,并重启该操作.
发生故障时,如果正在进行AWT缓存组的传播操作,那么,如果需要对发生在Oracle数据库中的变更进行回滚,则该事务将自动回滚这些变更,并将重启传播操作.
如果使用同步DataGuard将Oracle数据库复制到备用数据库,那么主动Oracle数据库出现故障时,TimesTenCache将自动切换到备用Oracle数据库,并且不会丢失数据.
5.
性能为了测量TimesTenCache的性能,我们开发了一个基准测试,它可以模拟蜂窝网络中使用的归属位置寄存器(HLR)应用程序.
该基准测试由7个事务组成,每个事务模仿HLR执行的一个典型操作,如建立或删除呼叫转移,或更新移动电话用户的有关信息.
我们用两种不同的配置运行了这个基准测试.
在第一种配置中,HLR应用程序基于Oracle数据库运行,基准测试应用程序运行在一台服务器上,而OracleDatabase11g运行在另一台服务器上.
在第二种配置中,我们在Oracle数据库的前面添加了TimesTenCache,HLR应用程序直接与TimesTenCache数据库链接,运行在一台服务器上,而OracleDatabase11g运行在另一台服务器上.
缓存数据存储在AWT缓存组中,这使得对缓存数据的所有更新可自动传播到Oracle数据库.
基准测试应用程序是用Java实现的,使用JDBC进行数据访问.
这四台服务器具有相同的配置:具有超线程的多个IntelXeonCPUE5-2680@2.
7GHz处理器,运行OracleLinux.
我们分别测量了基于Oracle数据库运行和基于TimesTenCache运行时的每种事务的平均响应时间.
下图显示了使用TimesTenCache时,应用程序的响应时间大大缩短.
18|使用OracleTimesTenApplication-TierDatabaseCache提高Oracle数据库的速度图10.
HLR基准测试应用程序的响应时间比较该基准测试显示了使用TimesTenCache的好处.
如上图所示,应用程序的响应时间减少至原来的1/10到1/69.
通常,TimesTenCache改善率随不同的硬件和平台会有所差异.
6.
示例在本节中,我们将介绍几种缓存的使用情况以及针对这些情况建议的TimesTenCache配置和缓存组类型.
注意,尽管每个示例使用的是特定类型的缓存组,但同一个TimesTenCache中可以同时存在不同类型的缓存组以更好地满足应用程序的需要.
6.
1只读缓存使用增量自动刷新的只读缓存组最适用于缓存频繁引用的数据.
许多应用程序可通过使用只读缓存受益.
这些应用程序的主要特征是需要反复查询某些记录.
无论这些记录是否频繁更新,读/写比率都非常高.
这类记录的示例包括:在线购物应用程序的价格表、航班预定应用程序的航班时刻表,以及酒店预订应用程序的可用房间表.
适用于此类数据的最佳缓存配置是使用增量自动刷新的(系统管理的)只读本地缓存组.
在后端数据库上对数据进行更新.
更新将自动传播到缓存.
传播的频率由应用程序决定,应根据后端数据库的更新频率及应用程序需要的数据流量决定传播频率.
如果缓存部署于缓存网格的多个网格成员中,则应在这些网格成员上定义本地缓存组,每个成员将直接从后端数据库获得更新.
注意,在线购物应用程序通常无需频繁更新缓存的价格表,因为价格表并不经常变化.
但是,航班跟踪应用程序在频繁读取数据的同时还要保证缓存的航班状态及时更新.
这种更新最适合在应用至Oracle数据库时使用为只读缓存组定义的较小的合理增量自动刷新间隔(如5分钟)来进行刷新.
TimesTenCache将所有更新自动传播到包括19|使用OracleTimesTenApplication-TierDatabaseCache提高Oracle数据库的速度更新数据的网格成员.
连接到某个网格成员的应用程序可以建立一个到TimesTenCache的连接,并且在缓存中执行所有读取操作的同时,使用直传选项将所有更新路由到Oracle数据库.
6.
2只读滚动窗口缓存使用增量自动刷新和基于时间老化的只读缓存组最适用于缓存落在某个滚动窗口中的频繁引用的数据.

许多情况下,应用程序需要的只读数据是与时间因素有关的数据,这种情况下,新数据的访问比旧数据频繁.
对这类应用程序,新数据不断生成,旧数据逐渐失去价值.
因此,我们可以考虑一个固定长度的时间段,该时间段不断向前推进,使数据从一端进入该时间段,从另一端离开该时间段.
应用程序只对该时间段内的数据感兴趣,通常将这种机制称作滚动窗口.
这类需要落在滚动窗口内的数据的应用程序示例包括:股票交易应用程序,它可能需要最近3天的交易数据;新闻传播应用程序,它可能需要最近24小时的新闻简报.
为了缓存落在滚动窗口中的数据,我们希望自动将新数据放入缓存中,并且还能自动将旧数据换出缓存.
我们还希望对后端数据库进行的修改能自动更新到缓存的数据中.
适用于此类数据的最佳缓存配置是使用增量自动刷新和基于时间老化的(系统管理的)只读缓存组.
与前一个示例一样,如果缓存部署于缓存网格的多个网格成员中,则应将在这些网格成员上定义本地缓存组,每个成员将直接从Oracle数据库获得更新.
6.
3可更新的缓存异步直写缓存组最适用于可更新的缓存.
有些应用程序需要对缓存数据立即进行实时更新,并最终向Oracle数据库传播更新.
例如,管理和供应电话预订服务及验证对该服务访问的应用程序通常将预订者信息缓存在TimesTenCache中.
对用户服务的变更必须立即反映在缓存中,并且应该传播到后端数据库.
适用于这类数据的最佳配置是异步直写缓存组.
如果预订者人数过多,需要将应用程序部署在缓存网格的多个网格成员中,则应在这些网格成员上定义本地缓存组,每个成员的缓存组拥有自己的预订者子集,并且不同网格成员拥有的子集之间不重叠.
例如,预订者有可能是按区号分区的.
20|使用OracleTimesTenApplication-TierDatabaseCache提高Oracle数据库的速度6.
4可更新的动态缓存使用动态加载和基于使用情况老化的异步直写全局缓存组最适用于可更新的动态缓存.

对某些应用程序来说,对活动数据的访问必须非常快,但活动数据集随时间变化并且是一个更大量数据集的子集,而这个大量的数据集因为数据量太大,无法完整地容纳在一个缓存中.
这就需要按需将活动数据引入缓存,并且缓存的内容需要是动态的,以便活动数据可以替换陈旧数据.
这类应用程序的一个示例就是呼叫中心应用程序,它管理着大量并发客户会话.
通常,这种应用程序部署在几个应用服务器节点上.
与呼叫中心联系的客户被自动路由到一个可用的应用服务器节点,理想情况下,该服务器节点也应提供该客户的配置文件.
适用于该情况的最佳配置是使用动态加载和基于使用情况老化的AWT全局缓存组,每个应用服务器节点上配置一个网格成员.
使用这种配置,当客户被路由到可用的服务器节点时,会将该客户的配置文件从Oracle数据库动态加载到该服务器节点上的网格成员中.
客户结束一次呼叫后,对客户配置文件的更改将从TimesTenCache传播到Oracle数据库.
LRU老化将自动从TimesTenCache中删除非活动客户的配置文件.
如果同一个客户在首次呼叫后不久又联系了呼叫中心,但这次被路由到另一个服务器节点,则该客户的配置文件会动态加载到这个新节点,这次既可以从Oracle数据库加载,也可以从之前加载过的网格成员加载,具体取决于配置文件最新副本所处的位置.
由TimesTenCache决定最新副本所处的位置.
它还负责管理对网格内数据的并发更新.
所有客户数据都存储在Oracle数据库中.
Oracle数据库远远大于组合的TimesTenCache数据库,最适合那些不要求TimesTenCache实时性能但需要访问大量数据的应用程序访问.
这类应用程序可能包括计费应用程序和数据挖掘应用程序.
随着客户群的增加以及为更多客户提供服务的要求的同步增加,呼叫中心可能会决定部署更多的应用服务器节点.

可以向TimesTenCache网格添加新TimesTenCache成员,但不会中断该网格中正在运行的请求.
类似地,某些节点出现故障或被删除也不会中断该网格其他节点的操作.
6.
5发生率不均的数据捕获缓存基于使用情况老化的异步直写缓存组最适用于捕获发生率不均的数据.

有一类应用程序,某些时间段的新数据生成率特别高,而其他时间段则一般.
在高活动时间段,后端数据库常常无法满足应用程序要求的高吞吐量.
这类应用程序可以通过使用缓存受益,实际上,通过使用缓存最终可以使新生成数据的发生率达到"平滑".
21|使用OracleTimesTenApplication-TierDatabaseCache提高Oracle数据库的速度例如,股票行情应用程序的新价格的发生率随时间变化非常大.
开盘与收盘时数据发生率特别高,其他时间则较低.
基于磁盘的数据库通常无法处理峰值发生率,但TimesTenCache可以承担这一任务.
适用于此类数据的最佳缓存配置是使用基于使用情况老化的(系统管理的)异步直写缓存组.
插入到直写缓存组的数据自动传播到后端Oracle数据库.
基于使用情况的老化从内存中缓存中自动删除老化的数据以释放空间.

6.
6稳定的高发生率的数据捕获缓存基于使用情况老化的异步直写缓存组与基于使用情况老化的常规TimesTen表一起使用,这种配置最适用于捕获具有稳定的高发生率的数据.
另一类应用程序,其新数据的生成率也很高,并且高发生率不一定会减退.
如果因为没有为后端数据库留出追赶的时间而使发生率无法平滑,那么只是对那些发生率太高而无法被后端数据库容纳的数据进行临时缓存是不能解决问题的.
但是,对这类应用程序,在将新生成的数据永久存储在后端数据库中之前,通常将它们集中到一个更精简的表单中.
通常这些应用程序会实时分析收集的数据,以检测感兴趣的模式或异常模式.

此类应用程序的一个示例就是从传感器或RFID阅读器收集数据的应用程序.
数据经常重复且非常容易收集,但常常需要进行实时分析.
适用于此类应用程序的最佳配置就是,当数据到达仅由OracleTimesTen管理的一个或多个表时插入数据,也就是说,后端数据库中没有该数据的映像.
非缓存的仅TimesTen表配置了基于使用情况的老化.
数据一旦被应用程序收集,就会插入到基于使用情况老化的(系统管理的)异步直写缓存组的缓存中.
TimesTenCache自动将收集到的所有数据传播到后端数据库.
因为仅TimesTen的表和缓存表都配置了基于使用情况的老化,因此最近最少使用的记录将自动换出,以便使缓存中的空间用于存储新记录.
6.
7可更新的用户管理的缓存显式刷新的用户管理的缓存组最适用于数据频繁更新但业务事务不多的应用程序.

某些应用程序为了达到最佳性能需要在缓存中执行多次更新,但只需在Oracle数据库中永久记录最终的事务.
此类应用程序的一个示例就是电子商务应用程序,这种应用程序可能需要为活动用户维护大量的购物车.
并且缓存中的购物车会反复更新.
因为这些更新意义不大,因此无需传播到Oracle数据库.
然而,一旦用户下了定单,就需要将这笔交易永久记录在Oracle数据库中.
适用于此类数据的最佳配置是用户管理的可更新缓存组,在这种配置中,每当应用程序需要向Oracle数据库中记录一个事务时,它就会发出显式刷新请求.
可以与基于使用情况的老化一起使用这种配置,以便自动将丢弃的购物车从缓存中删除.
22|使用OracleTimesTenApplication-TierDatabaseCache提高Oracle数据库的速度6.
8只读动态分布缓存动态加载和基于使用情况老化的只读表最适用于只读动态分布缓存.
某些情况下,一个应用程序可能分布在许多节点上,以便处理单个节点无法处理的吞吐率,并且应用程序需要的活动数据集是动态的,在任何指定的时间,活动数据集都是一个比完整数据集小得多的子集.
此类应用程序的一个示例就是贸易应用程序,在这种程序中活动数据就是活动贸易商的配置文件.