IBM solidDB and IBM solidDB Universal Cache认证指南，第 4 部分
简介： 本系列共分为 7 个部分，旨在帮助您准备 IBM solidDB and IBM solidDB Universal Cache 认证 （考试 550），从中您可以学习构建 IBM solidDB and IBM solidDB Universal Cache 解决方案的技能。本文是系列教程的第 4 部分，主要介绍了 IBM solidDB and IBM solidDB Universal Cache 的高速缓存应用等相关内容。
开始之前
关于本系列
如果您正准备参加 IBM solidDB and IBM solidDB Universal Cache 认证考试 550，那您就来对地方了 —— 这是一份内容翔实的自学教程。这一共分 7 部分的准备 IBM solidDB and IBM solidDB Universal Cache 认证考试系列教程囊括了为考试而必须掌握的主要概念。您可通过本系列教程做好准备工作，轻松应对考试。
关于本教程
本教程介绍了为恰当地架构 IBM solidDB and IBM solidDB Universal Cache 解决方案而必须具备的技能。共分 7 部分的系列教程帮助您备考 IBM solidDB and IBM solidDB Universal Cache 认证（考试 550），这是其中的第 4 篇。本教程中的内容主要涵盖了考试第 4 部分“Universal Cache”中的目标，共占有 15% 的分数。要查看这些目标，请参阅 IBM solidDB and IBM solidDB Universal Cache 认证考试信息。
目标
学习完本教程后，您应能够：
- 掌握作为磁盘数据库高速缓存应用的只读和读写部署方式
- 掌握作为磁盘数据库高速缓存应用的不同拓扑架构和分区技术
- 掌握作为磁盘数据库高速缓存应用的数据映射和转换功能
先决条件
为了理解本教程中的内容，您应该熟悉以下概念：
- 掌握 SolidDB 表的类型，内存表与磁盘表的区别和特性
- 掌握内存表的持久性选项
- 熟悉数据类型
- 掌握应用接口 JDBC、ODBC、SA
- 掌握服务器进程，驱动，连接属性，文件系统使用
- 掌握启动和停止 solidDB 数据库
- 掌握运用 solsql 和 solcon 来管理 SolidDB 数据库
- 掌握 solidDB 数据库的备份和恢复
- 掌握使用 solexp、solload 和 soldd 进行 solidDB 的数据迁移
- 掌握 solidDB 数据库的版本迁移
- 掌握安装和配置不同部署环境下的 solidDB 数据库
系统需求
您不需一份 IBM solidDB and IBM solidDB Universal Cache 拷贝即可顺利完成本教程的学习。但是建议获得一份拷贝，亲自动手实践和实验，并与教程配合使用。同时可以阅读 IBM solidDB and IBM solidDB Universal Cache 的相关文档来更深入掌握知识点，同时在本教程末尾处的参考资料部分中，您还可找到其他一些关于 IBM solidDB and IBM solidDB Universal Cache 的资源。
概述
通过引入 IBM solidDB Universal Cache，可以加快访问 IBM DB2、IBM Informix Dynamic Server (IDS)、Oracle、Microsoft SQL Server 和 Sybase 数据库的速度，并且能将这些数据库的性能提高至 10 倍。当将受支持的基于磁盘的数据库中的性能关键型数据存储到 solidDB 的内存缓存时，应用程序能够以超快的速度访问数据，因为这些数据保存在计算机的内存而不是磁盘中。通过使用 IBM solidDB Universal Cache，现有的或新的应用程序每秒钟能够生成包含超过 120,000 个事务的数据负载，并且能够安全地依赖可预测的微秒级响应时间，以支持不断增加的用户和数据，让企业能够快速实现数据的业务价值，这就是所谓的随需应变的信息（Information on Demand）。
工作原理
由于 IBM solidDB 是一种内存数据库，所以高速率是必然的。此外，solidDB 被设计为利用位于内存中的数据。比如，数据结构和访问方法专门针对位于主内存中的数据进行了优化。内存数据库提供的高速率功能可以与传统 DBMS 结合使用，其中 IBM solidDB 可充当一个数据库的缓存。
从图 1 可以看出 IBM solidDB Universal Cache 包含以下组件：
- IBM solidDB：前端数据库缓存。
- 后端数据库 RDBMS：用于复制的后端数据库。
- InfoSphere CDC：允许在 solidDB 和 RDBMS 之间复制数据的复制工具。
- InfoSphere CDC Access Server：为 solidDB 和 RDBMS 管理复制流程的服务器。
- nfoSphere CDC Management Console：用于配置、管理和监控复制流程的 GUI。
图 1. IBM solidDB Universal Cache 的组件
图 2 展示了 Universal Cache 的工作原理：
- 找出可以从高速访问中获益的表（高速访问可能和全部表有关，也可能只和少数表有关）。
- 将选择的表从后端数据库加载到 IBM solidDB Universal Cache 中。
- 将应用程序连接到 IBM solidDB Universal Cache 并使用标准接口访问数据。
- 以对应用程序透明的方式，IBM solidDB Universal Cache 自动与后端数据库同步数据。
图 2. IBM solidDB Universal Cache 的工作原理
由于相同的数据位于后端 DBMS 中，不需要进行高速访问的应用程序（比如报表工具）可以访问后端数据库中的数据。
SQL 传递
在 solidDB Universal Cache 最新 6.5 版本中提供了 SQL Passthrough 的功能。通过 solidDB SQL 传递，应用程序可通过单个连接来访问前端和后端数据服务器中的数据。例如，可以启用 SQL 传递以使无法在 solidDB 前端服务器上执行的 SQL 语句传递到后端。可根据会话或事务来设置 SQL 传递方式。solidDB 服务器中名为 SQL 传递介体的层负责根据所选的传递方式将 SQL 语句传递到后端。SQL 传递方式可在运行时动态更改。使用与 solidDB 服务器链接的后端 ODBC 驱动程序可加速对后端服务器的访问。后端的登录数据（用户名和密码）将通过 CDC 组件进行传送。
图 3. solidDB 6.5 新增 SQL Passthrough 的功能
使用该功能需要在 solidDB 节点上安装后端 ODBC 驱动程序（客户机）。传递方式定义如何将读语句和写语句传递到后端。将分别为读语句（SELECT）和写语句（包括 INSERT、UPDATE 和 DELETE 在内的非读语句）设置传递方式。共有三种传递方式可用：
- FORCE：所有的读语句或写语句都会传递到后端。
- NONE（缺省值）：从来不会将读语句或写语句传递到后端。
- CONDITIONAL：如果语句导致发生表丢失错误或语法错误等问题，那么此语句会传递到后端。
在 solid.ini 配置文件的 [Passthrough] 部分中设置与 SQL 传递相关的参数。
- 将 PassthroughEnabled 设置为 yes。缺省值是 no。
- 使用 SqlPassthroughRead 来设置如何将读语句从 solidDB 服务器传递到后端，可以设为 None（缺省值）、Conditional 或 Force。
- 使用 SqlPassthroughWrite 来设置如何将写语句从 solidDB 服务器传递到后端，可以设为 None（缺省值）、Conditional 或 Force。
- 定义 solidDB 服务器和驱动程序或驱动程序管理器之间的连接设置。使用 RemoteServerDriverPath 来设置驱动程序路径或者驱动程序管理器路径。使用 RemoteServerDSN 来设置驱动程序连接字符串或数据源名称。
部署方式
IBM solidDB Universal Cache 可以根据具体需要进行更改。Universal Cache 可以作为只读缓存进行部署，这种情况下数据由后端数据库（DB2 或 IDS）所有，也可以部署为读写缓存，其中数据由 IBM solidDB 前端数据库所有，或者数据所有权可由前端和后端数据库共享。
在每一种场景中，数据修改都将被自动同步，可以逐一执行同步，也可以按需同步。在共享所有权的场景中，通过使用预定义的冲突解决方法来解决同步冲突。
只读缓存
在只读缓存的部署方式中，应用可以通过访问 solidDB 内存数据库中的数据获得极大的性能提升。但是数据只能由后台数据库进行修改，并通过日志复制的方式同步到只读缓存。这种部署方式适合于要求快速访问不太变化的数据。在图 4 中可以看到，数据复制的方向是从后台数据库到 solidDB。
图 4. 只读缓存的部署方式
在复制定义的时候，需要指定 solidDB 为目标，如图 5 所示。为了保证数据正确，需要合理定义 solidDB 中数据表的权限，只有 CDC 复制数据才可以更改表的数据。因此运行 CDC 的用户才有数据写的权限，而应用访问的用户只有读数据的权限。例如可以把 solidDB 的 DBA 作为 CDC 运行的用户，而再创建应用访问用户并赋予只读权限。
清单 1. 应用访问 solidDB 具有只读权限
CREATE USER APPUSER IDENTIFIED BY APPPWD; GRANT SELECT ON T1 TO APPUSER; |
图 5. 只读缓存复制定义
读写缓存
在读写缓存的部署方式中，应用可以增、删、改、读 solidDB 内存数据库中的数据。所有 solidDB 中发生的数据改变会通过日志复制的方式同步到后台数据库。后台数据库仅仅作为数据归档或报表。这种部署方式适合于要求性能极高的读写应用，通过内存数据库比磁盘数据库更快的速度来满足需求。在图 6 中可以看到，数据复制的方向是从 solidDB 到后台数据库。
图 6. 读写缓存的部署方式
在复制定义的时候，需要指定 solidDB 为源，如图 7 所示。为了保证数据正确，需要合理定义后台数据库中数据表的权限，只有 CDC 复制数据才可以更改表的数据。因此运行 CDC 的用户才有数据写的权限，而应用访问的用户只有读数据的权限。
图 7. 读写缓存复制定义
使用读写缓存这种部署方式，往往在初始化的时候需要把后台已有的数据迁移到 solidDB 数据库中。这可以通过数据文件的方式来进行同步，也可以通过 CDC 组件来实现：
- 创建加载的订阅
- 映射已有的表做刷新复制
- 运行初始化刷新
- 检查后台数据和 solidDB 数据是否一致
- 删除加载订阅
共享缓存
在共享缓存的部署方式中，应用可以同时增、删、改、读后台数据库或者 solidDB 内存数据库中的数据。后台数据库或者 solidDB 数据库中发生的数据改变会通过日志复制的方式双向同步。复制同步的冲突可以检测到，并通过预先定义的方式来解决。这种部署方式适合于内存数据库和后台磁盘数据库都需要读写访问的场合。在图 8 中可以看到，数据复制的方向是双向的。
图 8. 共享缓存的部署方式
在复制定义的时候，需要分别把 solidDB 作为源和目标创建两个复制订阅，如图 9 所示。
图 9. 共享缓存的复制定义
最为重要的是，需要点击 Advanced Settings，然后选中 Do not replicate data received from any Subscriptions 来控制复制传播，如图 10 所示。
图 10. 控制复制传播
在共享缓存的部署方式中，由于后台数据库或者 solidDB 内存数据库可以同时增、删、改、读同一条记录，而数据的同步复制是异步的。这就可能会产生不一致的数据同步，需要解决同步冲突的问题。这包括检测、记录和解决不一致的数据，可以自动根据业务规则解决数据复制的冲突问题。这个特性需要开发人员选择同步表里面的若干字段作为冲突检测字段，同时定义当冲突发生的解决办法。InfoSphere CDC 在解决源表与目标表之间的冲突时，会在 TS_CONFAUD 表中记录有关解决方案的信息。InfoSphere CDC 安装程序会在配置 InfoSphere CDC 期间指定的目标元数据位置创建此表。
同步冲突的主要内容包括：
- 插入数据时，这条记录已经存在
- 更新数据时，这条记录不存在
- 更新数据时，这条记录的内容不一致
- 删除数据时，这条记录不存在
- 删除数据时，这条记录的内容不一致
下面是在 InfoSphere CDC 中处理冲突的办法：
- None：把冲突作为错误记录在 event log 中
- Source wins：覆盖原来数据
- Target wins：不做任何更新
- Largest value wins：取相对大的数据结果
- Smallest value wins：取相对小的数据结果
- User exit：由用户自定义的程序来处理冲突
冲突处理是在每个表的复制定义时候根据业务规则设置的。如图 11 所示，选择表的字段作为冲突检测并设定了冲突处理办法。
图 11. 复制冲突处理
拓扑架构和分区技术
负载均衡水平扩展
IBM solidDB Universal Cache 提供了多种水平扩展方案。如图 12 所示，可以采用负载均衡的方式，把应用分散到多个 solidDB 高速缓存中。每个 solidDB 拥有相同的数据。当数据在任意的 solidDB 中发生改变，更新会透明地同步到后台数据库中，然后再通过后台数据库传递到其他 solidDB 数据库中。
图 12. 负载均衡水平扩展
数据分区水平扩展
可伸缩性能够使 IBM solidDB Universal Cache 横向扩展到多个服务器，其中每个服务器提供对相同数据的访问，或者每个服务器保存有后端数据库中海量数据的不同部分。例如图 13 所示，如果一个后端数据库包含 400,000 个数据行，它可以被划分为分别位于 4 个服务器的 4 个 IBM solidDB Universal Cache 实例中，每个实例包含 100,000 个数据行。
如果客户的表数据量巨大以致不能放到内存中，用户可以选择这种扩展方案同时也获得了性能提升。同样的，solidDB Universal Cache 负责前台 solidDB 和后台数据库之间的数据一致和同步。
图 13. 数据分区水平扩展
通过 InfoSphere CDC 提供的 Row filtering 的功能可以定义不同的数据分区复制到相应的 solidDB 数据库中。如图 14 所示，在 Row filtering 的表达式定义中可以选择或者忽略相应的记录集。以下运算符可以用在 Row filtering 的表达式中：
- AND
- OR
- NOT
- = 等于
- != 不等于
- < 小于
- > 大于
- >= 大于或等于
- <= 小于或等于
图 14. 数据分区复制定义
高可用性架构
图 15 示意了两节点高可用性的配置架构。当出现系统异常的时候，备数据库自动接替高速缓存的主数据库。由于主数据库和备数据库之间保持高效的数据复制，因此即能保持高可靠性和高性能。例如可以把主数据库的关闭事物日志耐久性为“宽松”，那么用户可能会在数据被写入磁盘上的事务日志之前被告知数据已落实完毕，但是另一个服务器（即备数据库）上存在事务的副本，即使在记录事务之前主数据库失败，也不会丢失事务。这样就能既保证性能又能兼顾可靠性。
如果具有只读查询（例如，用于生成摘要报告的查询）就在备数据库上运行这些查询，以便由两台机器共同分担工作负载，从而实现“分散负载”并提高系统的总体性能。这对于读取许多记录，但是又不希望更改它们的应用特别有用。
图 15. 高可用性架构
数据映射与转换
表的映射
在配置高速缓存的表映射类型时候，通常选择一对一的映射类型，这是最常用和最简单的映射方式。但实际上 InfoSphere CDC 提供了多种表映射方式，如图 16 所示。
图 16. 表映射类型
- One-to-one
源表和目标表有类似的结构。这种映射方式最常使用，也被称为标准的映射关系。
- LiveAudit
生成审计的字段。采用 LiveAudit 方式，通常是用于审计或者需要进行状态跟踪。目标表会有相应的标记来说明是插入、删除、更新的操作。常用的审计字段有 &TIMSTAMP 表明源数据改变的时间；&ENTTYP 表明源数据改变的类型；&USER 表明源数据改变的操作用户。
- Adaptive Apply
根据源和目标的自动同步数据。如果已经知道源表和目标表的数据可能存在不一致，那为了保证数据复制正确而不报错，则可以采用 Adaptive Apply 映射方式。当需要插入目标表的时候发现数据已经存在，InfoSphere CDC 会改 Insert 操作为 Update；同样的，需要更新目标表的时候发现数据不存在，InfoSphere CDC 会改 Update 操作为 Insert。
- Summarization
在目标端生成汇总数据。如果需要在目标表计算数值型数据，可以采用 Summarization 的映射方式。有两种计算方式：Accumulation 和 Deduction。Accumulation 是累加方式把目标表的数值增加，Deduction 是减少目标表的数值。
- Consolidation: One-to-One
把很多表的数据合并成一条记录。如果在业务环境中需要把分散在各个源表的信息合并，比如把人、客户、产品的信息合并到一起，则可以采用这种映射方式。
- Consolidation: One-to-Many
通过用 lookup 表来更新目标表记录的方式。在设计的时候，利用 InfoSphere CDC 的 %GETCOL 函数来获取 Lookup 表的内容。例如，需要根据 STATE 的信息获取 TAXCODES 表中 TAX 的内容，则表达式为 %GETCOL(TAX, TAXCODES, , STATE, STATE)。
数据转换
在 InfoSphere CDC 中提供了丰富的数据映射功能。这其中包括数据格式的转换（如日期格式）、数据类型的转换、字段拆分、字段合并、代码标准化、数据清洗（如去除空格）等。
在图 17 的示例中，可以看到可以用表达式的方式实现数据转换，比如用 %CONCAT 的表达式来实现字符串的拼接。可以创建 derived columns，比如创建 SALARYMAX 的新字段来实现源表数值两列的计算。也可以通过 Data Translations 实现值的变化，比如定义 'A' 变为 'Active'，而 I' 变为 'Inactive'，在 Management Console 中可以定义源表的列复制到目标表的列时候的数据转换，可以在每列定义任意多的转换值。
图 17. 数据转换示例
样例试题
问题 1：What are two possible conflict resolution methods between solidDB and a back-end database? (Choose two.)
A. Source wins
B. Reference
C. Trigger
D. UserExit
E. Alert user
答案 : A, D
问题 2：You want to map multiple source tables to multiple target tables in the same subscription. These tables share the same table structure and similar table names. Which mapping method should you use?
A. Standard
B. Mirror
C. LiveAudit
D. One-to-One
答案 : D
问题 3：A conflict detection and resolution method within CDC is only available when you map your tables using ______.
A. Standard
B. One-to-One
C. Consolidation
D. Bidirectional replication
答案 : A
原文链接：http://www.ibm.com/developerworks/cn/data/tutorials/dm-1009wumd2/resources.html
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/15082138/viewspace-674559/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/15082138/viewspace-674559/