级别: 中级 Neeraj Singh, 顾问软件工程师, IBM Yongli An, MDM 性能经理, IBM
2009 年 10 月 22 日 Rapid Deployment Package (RDP) for IBM InfoSphere™ Master Data Management Server 解决方案解决了客户端在实现初始装载解决方案的第一阶段的需求。使用 MDM 时客户端需要执行初始和增量装载,并且通常以批处理的方式装载。本文主要关注执行初始装载的维护事务方法,包括简介、安装和设置。此外,还讨论性能调优技巧和最佳实践。在您自己的使用 RDP 的 MDM Server 初始装载解决方案中,可以将本文提供的建议作为指导。
简介
Rapid Deployment Package (RDP) for IBM InfoSphere™ Master Data Management (MDM) Server 解决方案的诞生是为了解决客户端在实现初始装载解决方案的第一阶段的需求。在这个阶段,客户端针对主数据管理部署 InfoSphere MDM Server,此时数据被装载到 MDM Server 储存库,但大部分数据更改仍然来自现有的遗留系统。使用 MDM Server 时客户端需要执行初始和增量装载,并且通常以批处理的方式装载。初始装载是指首次将数据从源系统移动到空的 MDM Server 储存库。增量装载是指从源系统到 InfoSphere MDM Server 的常规性(比如每天)数据更新。
有两种方法可以以批处理的方式将数据装载到 InfoSphere MDM Server。维护服务批处理方法使用 Batch Processor 调用的维护服务将数据装载到 InfoSphere MDM Server。大容量装载方法使用 DataStage 和 QualityStage 作业装载数据。
本文分享了 IBM 团队执行用例研究的经验,主要关注使用 InfoSphere MDM Server 版本 8.0.1 的 Maintenance Transaction 方法。
本文开始时首先介绍 RDP MDM Server Maintenance Transactions。接着讨论 MDM Server 环境的基本安装过程和设置步骤,包括 DB2® 数据库服务器、WebSphere® Application Server、InfoSphere MDM Server、RDP MDM Server Maintenance Transactions 和批处理器。本文根据内部用例研究高度概括了关键性能结果。本文的末尾包含一系列性能调优技巧和最佳实践,帮助您在进行初始数据装载时获得最佳性能。通过学习本文,您可以利用 IBM 团队的经验,并且在您使用 RDP 的 InfoSphere MDM Server 初始装载过程中将本文的建议作为指导。
开始
IBM InfoSphere Master Data Management Server (MDM Server) 是一个企业级应用程序,它让公司能够管理和维护主数据的完整、精确的视图,从而帮助它们控制业务信息。MDM Server 提供企业客户、帐户和产品的统一操作视图,并提供一个通过多种渠道处理更新的环境。它实时地将前台办公系统与多个后台办公系统协调起来,从而为获取主数据提供单一的来源。
在实现 MDM Server 解决方案的第一阶段,客户端需要执行初始和增量装载,并且通常以批处理的形式进行。本文讨论 InfoSphere MDM Server Database 的两种初始数据装载选项之一,它是来自 IBM for InfoSphere MDM Server 的 Rapid Deployment Package (RDP) 资产的一部分。
对于 InfoSphere MDM Server,以下是两种高性能数据装载方法,它们可以快速将大量数据装载到目标 MDM Server 数据库。
- RDP MDM Server Maintenance Service Batch —— 这种方法使用 Batch Processor 调用的维护服务将数据装载到 MDM Server 中。
- RDP MDM Server DataStage 作业 —— 这种方法利用新的选项装载数据,包括来自 InfoSphere Information Server 的直接装载能力。
本文主要关注第一种数据装载选项:RDP MDM Server Maintenance Service Batch。本文首先简单介绍 RDP MDM Server Maintenance Service Batch 方法,然后讨论为初始数据装载设置高性能的 MDM Server 环境的基本步骤。
为了展示性能和可伸缩性,本文描述了一个性能研究样例并显示一些性能结果。更重要的是,本文还包括一些性能调优技巧和最佳实践。您可以利用 IBM 团队的经验,并且在您使用 RDP 的 MDM Server 初始装载项目中将他们的建议作为指导。
RDP MDM Server 服务批处理方法简介
RDP MDM Server 服务批处理方法使用批处理器调用的维护事务,或其他任何批处理框架将数据装载到 MDM Server。因为 MDM Server 在装载期间处理数据,所以这种方法提供最佳的业务数据验证。您可以对初始和增量装载使用相同的维护事务集。
要创建使用该选项的设置,您需要安装能够运行维护事务的 InfoSphere MDM Server。此外,还需要以 Batch Processor 能够处理的格式准备输入数据。
什么是维护事务?
InfoSphere MDM Server 为每个记录或业务实体创建一个内部标识符,这些标识符用作它们的内部键。常规的 InfoSphere MDM Server 服务希望内部键作为更新服务请求的一部分提供,以确保服务能够识别数据库中的正确业务实体。不过,当数据直接从外部应用程序(比如遗留系统)进入 InfoSphere MDM Server 时,内部键是未知的,并且数据更改通常也是未知的。
维护事务解决了这个问题。这些事务不要求将内部键作为输入的一部分,并且不要求外部系统指定在 InfoSphere MDM Server 中是否要添加或更新某个实体。维护事务希望业务键作为输入的一部分而不是内部键,业务键是外部应用程序中的业务实体的唯一标识符。维护事务使用在装载操作中提供的业务键在数据库中查找正确的业务实体实例。如果找到现有的实体,那么就使用相应的事务(比如 updateParty)更新它。如果没有找到现有的实体,那么将使用相应的事务(比如 addParty)在 InfoSphere MDM Server 中创建一个新实体。
维护事务的种类非常多,包括 maintainParty、maintainPersonName 和 maintainContractPlus。要了解所有维护事务及其细节,请查看 MDMRapidDeploymentPackage_CompositeMaintenanceServices.pdf 文档,该文档是 EntryLevelMDM 包的一部分。
维护事务并不是默认的 InfoSphere MDM Server 8.0.1 发布版的一部分。要使用维护事务,您必须获取并安装 EntryLevelMDM 补丁。
注意:维护事务是默认的 InfoSphere MDM Server 8.5 发布版的一部分。它们作为 MDM Server Samples 发布版的一部分提供,并且包含源代码。您需要在现有的 InfoSphere MDM Server 8.5 实例之上安装它们。从 参考资料 部分可以获得一个提供说明的链接。我们建议您从本文的 获取安装程序 小节提到的 FTP 站点下载最新的 MDM Server。
批事务处理
您可以通过 MDM Server Batch 使用维护事务来装载数据,或使用 RMI 或 JMS 消息机制将它们作为 MDM Server 公开的服务进行调用。本文主要关注调用批处理方法。InfoSphere MDM Server 提供两种执行批事务处理的方法。您可以使用 J2SE 批处理器框架或 WebSphere Application Server eXtended Deployment 批处理框架。本文关注第一种方法:J2SE 批处理器框架。
J2SE 批处理器框架是一个 J2SE 客户端应用程序,并且是默认的 InfoSphere MDM Server 安装的一部分。这个批处理器是一个能够处理大量批数据的多线程应用程序。它可以同时从同一批输入中处理多个记录,从而增加吞吐量。另外,您可以同时运行批处理器的多个实例,每个实例都处理独立的批输入并指向相同或不同的服务器。
批输入中的每个批记录都按照以下次序经过批处理器:
- 读取器从批输入中读取记录。提交器将记录发送到请求/响应框架等待解析和处理。
- 解析器将输入请求转换成一个或多个业务对象。
- 在经过业务代理之后,将对业务对象应用业务处理和持久化逻辑。
- 应用程序响应被发送到构造器,以构造所需的批输出响应。
- 构造器构造的响应被返回给批处理器。
- 写程序在其日志中记录事务输入,如果必要的话。例如,FailedWriter 中记录了所有失败的消息。
批处理器是预构建的读取器和写程序附带的。默认的读取器希望批输入是 XML 格式的,其中每行包含一个 XML 请求。默认的写程序以 XML 格式记录响应。您还可以使用 InfoSphere MDM Server 批处理器处理包含 SIF 格式消息的批文件。
如果输入数据不是上面指定的格式,就必须将其转换成所需的格式,或者使用定制的读取器或写程序。批处理器的许多组件都是可以定制的,但定制不是本文的主题。
理解软件和硬件需求
以下是一个典型的 InfoSphere MDM Server 部署系统拓扑,其中从 Information Server for Standardization and Matching 使用了 QualityStage:
- Application Server 和 InfoSphere MDM Server 安装在具有足够 CPU 能力的物理机器或 LPAR(Server1)上。CPU 的数量取决于总体吞吐量需求。
- 数据库服务器安装在另一个具有足够 I/O 能力的物理机器或 LPAR(Server2)上。
- IIS Server 可以安装在数据库服务器或第三个具有足够 I/O 能力的物理机器或 LPAR(Server3)上。
- IIS Client 用于配置 QS 作业,它安装在 Windows® 计算机上。
要最大限度地提升特定配置的性能,请遵循以下的总体指导原则:
- 在 InfoSphere MDM Server 和 DB 服务器上的 CPU 比例范围是 2:1 到 3:1。例如,如果数据库服务器有 4 个 CPU,那么建议在 MDM Server 机器上至少使用 8 个 CPU,以充分利用数据库服务器上的 CPU 的计算能力。
- 数据库服务器的每个 CPU 应该具有 5 至 10 个物理磁盘。
- InfoSphere MDM Server 和 ISS 服务器的 CPU 比例范围是 2:1 到 1:1。例如,如果 MDM Server 有 8 个 CPU,那么建议 IIS 服务器上的 CPU 数为 4 至 8 个。
注意:只有计划使用 QualityStage 执行标准化和匹配时才需要 IIS 服务器。InfoSphere MDM Server 的默认配置不使用 QualityStage。
探索示例环境
这个小节简单描述示例环境,包括各个级别的硬件和软件信息。此外,还描述在测试中使用的系统拓扑。
硬件和软件组
- Server 1 (AppServer and InfoSphere MDM Server)
-
硬件
- 机器类型:IBM 9116-561, PowerPC®
POWER5™
- CPU:具有 16 个线程的 8 核 Power5,1.5GHz,64 位
- 内存/IO:32 GB RAM,6 个内部磁盘
-
软件
- OS:AIX® Version 5300-06(64 位)
- WebSphere® Application Server ND 6.1.0.11(32
位)
- InfoSphere MDM Server 8.0.1 + EntryLevelMDM 补丁
- Server 2 (DB2® database Server)
-
硬件
- 机器类型:IBM 9116-561, PowerPC POWER5
- CPU:具有 16 个线程的 8 核 Power5,1.5GHz,64 位
- 内存/IO:32 GB RAM,6 个内部磁盘 + 40 外部磁盘
-
软件
- OS:AIX Version 5300-06(64
位)
- DB2® database server v9.5(32
位)
- Server 3 (Information Server)
-
硬件
- 机器类型:IBM 9116-561, PowerPC POWER5
- CPU:具有 16 个线程的 8 核 Power5,1.5GHz,64 位
- 内存/IO:32 GB RAM,6 内部磁盘
-
软件
- OS:AIX Version 5300-06(64 位)
- IIS v8.0.1
- Server 4(IIS Client —— 用于配置 QualityStage 作业,运行测试时不需要它)
-
硬件
-
软件
- OS:Windows 2003 Server
- IIS client version 8.0.1 for Windows
系统拓扑
为了让 InfoSphere MDM Server 使用 QualityStage 作业执行标准化和匹配,您需要使用 Server3 和 Server4,如图 1 所示。对于来自 InfoSphere MDM Server 的默认标准化和匹配算法,Server1 和 Server2 已经足够。
图 1. 系统拓扑
安装组件
这个小节的目的是展示在测试环境中安装必要软件所需的高级步骤。这些步骤主要关注与 RDP 维护服务相关的步骤,只是简单提到必要的软件安装,包括 WebSphere® Application Server、DB2 数据库服务器、InfoSphere MDM Server 和 InfoSphere Information Server。
必须安装的软件
必须安装的软件包括 WebSphere Application Server、DB2 数据库服务器和 InfoSphere Information Server。要了解详细的安装说明,请在 参考资料 部分查看每个产品的 Information Center。
- 在 Server1 上安装 IBM WebSphere Application Server Network Deployment, Version 6.1,并使用 Fixpack 11 升级它。
- 在 Server2 上安装 DB2 Database Server, Version 9.5。
- 在 Server3 上安装 IIS Server, Version 8.0.1。
- 在 Server4(Windows 机器)上安装 IIS 客户端。
InfoSphere MDM Server 安装
要了解 InfoSphere MDM Server 的安装过程,请查看 参考资料 部分提供的到信息中心的链接。您可以将它安装到独立的 WebSphere Application Server 或安装到 WebSphere Application Server 集群。
为维护服务安装 Entry Level MDM Server 补丁
遵循本小节的步骤,以应用 Entry Level MDM (ELMDM) Server 补丁,该补丁让您能够使用维护服务。
这些步骤假设您已经安装 InfoSphere MDM Server 并且应用了所有必要的补丁。这些步骤基于在测试环境小节提到的软件组。
步骤 1. 获取安装程序。
维护事务不是默认的 MDM Server 的一部分,因此必须另外安装它们。如果您与 IBM 之间存在服务协议,您可以登录 Secure File Transfer 站点并找到 https://testcase.boulder.ibm.com/www/prot/MDM_RDP/?T,从这里可以获得维护事务的安装程序。在撰写本文时,最新的安装包是 https://testcase.boulder.ibm.com/www/prot/MDM_RDP/MDMServer801_RDP801/ELMDM-20090407.tar.gz。如果您需要这个包,请联系 IBM 服务代表。
要获得更多安装说明,请查看 MDMRapidDeploymentPackage_InstallGuide.pdf 文档的章节 Installing Rapid Deployment Package for MDM Server Maintenance transactions and MDM Customizations。您可以在解压缩安装程序之后的 Docs 目录下找到该文档。
步骤 2. 在安装之前进行必要的备份。
安装程序将更改 InfoSphere MDM Server Database。为了安全起见,您需要在运行安装程序之前备份数据库。安装程序为它将更改的文件创建备份。这些文件的名称为 *.beforeELMDM。不过,安装程序在随后的运行过程中会覆盖它们。因此,在再次调用安装程序之前,请确保将备份的文件转移到安全的地方。
安装程序修改的文件为:
- MDM Server 主目录下的可安装 .ear 文件。例如,/usr/IBM/MDM_801/ installableApps/MDM.ear
- WebSphere Application Server 的 <MDM_Instance>.ear 目录下的一组文件。例如 /opt/IBM/WebSphere/AppServer/profiles/AppSrv1/installedApps/myHostCell01/MDM_801.ear/
步骤 3. 准备安装程序。
通过以下步骤准备安装程序。
- 创建一个名为 setup 的新的基目录。
- 在该目录中解压缩安装程序 (.tar.gz file)。这个过程将创建几个目录,包括一个名为 install 的目录。
- 转到目录 setup/install/DB2 database server。
- 通过 chmod 755 *.sh 命令给所有脚本分配执行权限。
- 连接到 InfoSphere MDM Server 数据库并执行以下的 SQL 语句。假设模式的名称为 mySchema。
清单 1. 执行的 SQL 语句
db2 "insert into mySchema.DataAssociation values
(25083715210700005,'a_name',current_timestamp,'a_description',null)"
|
步骤 4. 定制一个集群环境。
如果您的 MDM Server 是一个独立的服务器,那么就不 需要该步骤。如果您在 Clustered MDM Server(MDM Server 运行在一个 WebSphere Application Servers 集群中)上安装 ELMDM,那么一定要对脚本进行以下修改。
- 在 setVariables.sh 脚本的开始处添加清单 2 中的代码行。NAME_OF_SERVER 引用作为集群成员的 WebSphere Application Server 实例的名称。
清单 2. 添加的代码行
#add the line below
export SRV_NAME=NAME_OF_SERVER
|
- 在脚本 install_DisableHVL.sh、install_EnableHVL.sh 和 install_ELPCustom.sh 中,必须按照清单 3 进行更改。
清单 3. 更改脚本文件
#comment out the line below and replace with the new line as shown below
#$CURRENT/restartServer.sh $WAS_HOME $NODE_NAME $APP_NAME $ADMIN_USER $ADMIN_PASSWORD
#add the line below
$CURRENT/restartServer.sh $WAS_HOME $NODE_NAME $SRV_NAME $ADMIN_USER $ADMIN_PASSWORD
|
- 在脚本 install_ELPTx.sh 中,必须按照清单 4 进行更改。
清单 4. install_EPLTx.sh 脚本
#comment out the line below and replace with the new line as shown below
#$LOC/restartServer.sh $WAS_HOME $NODE_NAME $APP_NAME $ADMIN_USER $ADMIN_PASSWORD
#add the line below
$LOC/restartServer.sh $WAS_HOME $NODE_NAME $SRV_NAME $ADMIN_USER $ADMIN_PASSWORD
|
步骤 5. 对安装程序进行其他可选的修改有助于调试。
遵循以下步骤,为调试目的修改安装程序。
- 在每个脚本的开始处添加 set -x
- 在以下脚本中,通过将 db2 -tf 替换为 db2 -tvf 添加详细说明选项:
- runsql.sh
- install_ELPCustom.sh
- install_EnableHVL.sh
- install_DisableHVL.sh
步骤 6. 设置环境变量
根据您的环境修改 setVariables.sh 脚本。清单 5 给出了一些示例值。阅读这个例子中嵌套的注释和说明。
清单 5. 选自 setVariables.sh 脚本
export WAS_HOME=/opt/IBM/WebSphere/AppServer
export CELL_NAME=myhostCell01
#set the profile name used by WAS running MDM Server. such as AppSrv01 and Custom01
export NODE_NAME=Custom01
export APP_NAME=MDM_801
#The Name of the WebSphere Application Server running MDM Server,
#You will have this only if you followed Step 4 above
export SRV_NAME=Cluster_member1
export INSTALL_HOME=/usr/IBM/MDM_801
# IIS Server Version: Could be 801 or 81
export IIS_SRV_VERSION=801
export DB_NAME=MDMDB
export DB_USER=myDBuser
export DB_PASSWORD=myDBpassword
export TABLE_SPACE=TABLESPACE1
export INDEX_SPACE=INDEXSPACE1
export LONG_SPACE=LONGSPACE1
export TRIG=COMPOUND
export DEL_TRIG=TRUE
export APPLICATION_NAME='WebSphere Customer Center'
export APPLICATION_VERSION=8.0.1.0
export DEPLOY_NAME=MDM_801
#You need to set this only if you are integrating QualityStage with MDM Server.
#Please note the back slashes. The number 2809 here refers to the
#bootstrap port of WebSphere Application Server instance running IIS server.
export ISP_URL='iiop:\/\/myIISserver.mylab.ibm.com:2809'
|
步骤 7. 执行脚本。
- 执行 install_ELPTx.sh。
- 如果您要将 InfoSphere MDM Server 与 QualityStage 集成起来,那么还要运行 install_ELPCustom.sh 脚本。
步骤 8. 检查错误。
仔细查看所有日志文件,确保不存在任何错误。
步骤 9. 对集群环境重复相同的步骤。
如果您在集群环境中进行安装,请对每个集群成员执行以下步骤。
- 将 setVariables.sh 重新配置为指向另一个集群成员。
- 运行 additionalClusterInstall.sh 脚本。
- 如果您要将 InfoSphere MDM Server 和 QualityStage 集成起来,那么运行 install_ELPCustom.sh 脚本。
注意:作为 install_ELPCustom.sh 脚本的一部分,需要对 InfoSphere MDM Server 数据库进行许多更改。某些更改只能执行一次(比如 DB 插入)。在重复执行该脚本时忽略这些错误,或通过修改该脚本让它不重复数据库操作。
步骤 10. 配置 SIF 解析器。
如果您需要使用 SIF 解析器,那么完成这个步骤。否则,跳到步骤 11。这个例子使用默认的 XML 解析器。要将批处理器配置为使用 SIF 解析器,请进行以下修改:
- 在 DWLCommon_extention.property 文件(位于服务器运行时环境的 properties.jar)中设置 sif_compatibility_mode = on。
- 在批处理扩展属性文件中,设置 ParserAndExecConfiguration.Parser = SIF。
要了解更多细节,请查看 MDMRapidDeploymentPackage_CompositeMaintenanceServices.pdf 的 SIF Parser 部分。
步骤 11. 重启 InfoSphere MDM Server。
重启 InfoSphere MDM Server,包括集群中的所有服务器。
集成 InfoSphere MDM Server 和 QualityStage
如果您需要从 InfoSphere MDM Server 使用默认的标准化和匹配算法,则可以忽略这些步骤,并跳到 使用关键配置参数优化性能。不过,如果您希望 InfoSphere MDM Server 使用 QualityStage 执行标准化和匹配算法,那么请阅读本小节的配置说明。
这些配置说明假设:
- 已经安装 InfoSphere MDM Server 并且应用了所有必要的补丁。
- 已经安装 EntryLevelMDM。
- 已经安装 IIS 服务器和 IIS 客户端。IIS 客户端的版本必须与 IIS 服务器的版本相同。
- 使用的软件组必须类似于示例环境的 软件和硬件组 小节描述的软件。
查看 参考资料 访问关于集成 InfoSphere MDM Server 和 QS 的文档(MDM Server Developers Guide 的 Integrating IBM Information Server QualityStage with IBM InfoSphere Master Data Management Server)。本文的说明与这份开发人员指南是互补的。不过,本文提到的一些配置更改在安装期间是非常有帮助的。
步骤 1. 更改安全设置。
如果运行 IIS 的 WebSphere Application Server 启用了全局安全,那么必须禁用该服务器上的事务协议安全。要禁用服务器上的协议安全,请在管理控制台中遵循以下步骤:
- 在管理控制台中,单击 Servers > Application
Servers > server_name。应用程序服务器的属性将显示在内容面板中。
- 在 Container Settings 下展开 Container Services,然后单击 Transaction Service 以显示事务服务的属性页面。
- 在 Additional Properties 下单击 Custom Properties。
- 在 Custom Properties 页面单击 New。
- 在 Name 字段输入 DISABLE_PROTOCOL_SECURITY,然后在 Value 字段输入 TRUE。
- 单击 Apply 或 OK。
- 单击 Save 保存对主配置的更改。
- 重启服务器。
或者,如果为 InfoSphere MDM Server 启用了 WebSphere Application Server 应用程序安全,那么需要在 MDM WebSphere Application Server cell 和 IIS WebSphere Application Server cell 之间共享 LTPA 密匙。要了解详细说明,请参考 WebSphere Application Server Information Center(见 参考资料)。
步骤 2. 获取安装程序。
这些可安装的组件是您前面安装维护服务时使用的捆绑包的一部分。您可以在 QualityStage
文件夹中找到它们。
步骤 3. 创建 IIS 项目。
使用 IIS Administrator Client 连接到 IIS 服务器。创建一个名为 ELMDMQS 的新项目。
步骤 4. 导入 IIS 项目。
- 通过 DataStage and QualityStage Designer 登录 ELMDMQS 项目。
- 单击 Import > Datastage Components。
- 在以上解压缩出来的 EntryLevelMDM\QualityStage 文件夹下面,浏览到 ELMDMQS.dsx 文件。
- 导入该文件。
步骤 5. 提供导入规则集。
您必须首先为 Designer 客户端提供导入规则集,这样作业才能使用它们。遵循以下步骤提供导入规则集。
- 在 Designer 客户端中,在存储库树图 ELMDMQS > ELMDMRT > Standardization Rules
> MDMQS 内部找到规则集。
- 通过单击右键选择规则集,然后从菜单选择 Provision
All,如图 2 所示。
图 2. 提供规则集
- 对以下列出的所有规则集重复以上步骤。
- MDMQS\Standardization Rules\MDMCanada\CAADDR\MDMCAADDR
- MDMQS\Standardization Rules\MDMCanada\CAAREA\MDMCAAREA
- MDMQS\Standardization Rules\MDMUSA\USADDR\MDMUSADDR
- MDMQS\Standardization Rules\MDMUSA\USAREA\MDMUSAREA
- MDMQS\Standardization Rules\MNADKEYS\MNADKEYS
- MDMQS\Standardization Rules\MNNAME\MNNAME
- MDMQS\Standardization Rules\MNNMKEYS
- MDMQS\Standardization Rules\MNPHONE\MNPHONE
- MDMQS\Standardization Rules\MNSPOST\MNSPOST
步骤 6. 准备测试数据并配置参数
- 将本文提供的测试数据(*.csv 和 *.txt 文件)复制到您的 issues 服务器(不是客户端)的 /data01/ELMDMQS 目录下。
- 在 ELMDMQS\ELMDMRT\Parameter Sets(在设计器的 Repository 视图)下打开参数集 ELMDMQS_Data_Directory。
- 双击该参数集。
- 转到 Values 选项卡并将参数 DATADIR 的值设置为刚才复制测试数据的目录路径(本例中为 /data01/ELMDMQS/),如图 3 所示。注意,斜杠 (/) 位于参数值的末尾。
图 3. 参数集
- 在 ELMDMQS\ELMDMRT\Shared Containers 目录下双击打开共享容器 MDMQSPartySuspectReferenceMatchOrganization。
- 将数据集 Data_Frequency 和 Reference_Frequency 的文件路径设置为与 ELMDMQS_Data_Directory.DATADIR 的路径(在前面步骤设置)相同,如图 4 所示。
图 4. 编辑输入文件路径
- 单击 OK 保存更改。
- 关闭这个 stage,当提示您保存更改时单击 Yes。
- 对 MDMQSPartySuspectReferenceMatchPerson 重复以上步骤。
步骤 7. 编辑作业。
- 使用设计器客户端菜单的 Tool > Multiple Job compile 编译 ELMDMQS\ELMDMRT\Jobs 文件夹及其子文件夹中的所有作业。
- 根据向导的说明开始编译。
注意:可以在 ELMDMQS\ELMDMRT\Jobs 文件夹中找到批处理的版本。可以在 ELMDMQS\ELMDMRT\Jobs\ISD 文件夹中找到这些作业的 Information Service Director (ISD) 版本。
步骤 8. 生成匹配频率数据
- 使用导向客户端运行作业 ELMDMQS\ELMDMRT\Jobs\MDMQS_Person_Match_Frequency_Generation 来生成匹配频率数据。运行完成之后,它将生成文件 PersonRefMatchTransFreq.txt 和 PersonRefMatchCandFreq.txt,如图 5 所示。
图 5. 生成匹配频率数据
- 类似地,运行 ELMDMQS\ELMDMRT\Jobs\MDMQS_Org_Match_Frequency_Generation 将生成文件 OrgRefMatchTransFreq.txt 和 OrgRefMatchCandFreq.txt。
步骤 9. 运行测试作业。
- 使用导向客户端运行以下批作业,以在使用 ISD 作业之前确保它们在您的系统上成功执行:
- ELMDMQS\ELMDMRT\Standardization Testing 中的所有作业
- ELMDMQS\ELMDMRT\Match Testing 中的所有作业
- 运行这些作业之后,在 Sequential 文件中查看输出,并检查结果
步骤 10. 使用 ISD 部署服务
- 登录 IBM Information Server (IIS) 控制台。
- 对 EntryLevelMDM\QualityStage 目录下的文件 ELMDMQS_ISDProject.xml 单击 File > Import Information Services Project >
Browse。
- 使用所有默认设置,单击 Import。
- 打开包含在导入项目中的 Information Service Application (ELMDMQS)。
- 单击 Develop,如图 6 所示。
图 6. 使用 ISD 配置作业
- 单击 Information Services Application。
- 在接下来的界面中,双击 ELMDMQS 应用程序打开它。
- 转到 Ededi 模式。
- 在 Select a View 窗口单击 Services >
ELMDMQSService,如图 7 所示。
图 7. 使用 ISD 配置作业
- 在展开的树图中,选择 Operations,然后每次双击一个操作对其进行编辑。
图 8. 核查项目名
- 按照以下方式编辑每个操作:
- 确保项目名正确,如图 8 的方框 1 所示。当您使用管理客户端创建新的项目时,如果选择 ELMDMQS 作为项目名,那么就可以使用默认设置。如果您指定了另一个名称,那么要确保项目名和作业名是正确的。要检查项目名和作业名是否正确,单击 Edit 按钮,然后浏览 ISD 文件夹中的项目和作业。
- 确保对输入启用 Group Arguments into Structure 选项,如图 8 的方框 2 所示。
- 根据以下的表 1 更改输入数据类型,如图 8 的方框 3 所示。
- 根据表 1 勾选或取消勾选 Accept Array 复选框,如图 8 的方框 4 所示(如果表条目表示 Yes 时,复选框应该显示一个勾号)。
- 根据表 1 勾选或取消勾选 output data type and Accept array 复选框。
表 1. ISD 作业配置
| 操作名 | 操作作业名 | 接收数组的输入 | 输入数据类型 | 返回数组的输出 | 输出数据类型 |
|---|
| standardizeAddress | ISD_MDMQS_Address_Standardization | No | AddressInput | No | AddressOutput | | elPersonMatch | ISD_MDMQS_Party_Suspect_Reference_Match_Person | Yes | ELPersonMatchInput | Yes | ELPersonMatchOutput | | elOrgMatch | ISD_MDMQS_Party_Suspect_Reference_Match_Org | Yes | ELOrgMatchInput | Yes | ELOrgMatchOutput | | standardizePhoneNumber | ISD_MDMQS_Phone_Standardization | No | PhoneNumberInput | No | PhoneNumberOutput | | standardizeOrgName | ISD_MDMQS_Organization_Standardization | No | OrgNameInput | No | OrgNameOutput | | standardizePersonName | ISD_MDMQS_Person_Standardization | No | PersonNameInput | No | PersonNameOutput |
- 在 Provider Properties 选项卡上,根据您的设置修改凭证,如图 9 所示。
图 9. 修改凭证
- 保存并关闭应用程序。
- 通过单击 Develop 菜单部署应用程序。图 10 显示了一个例子。注意,突出显示的方框显示 Select the Application ELMDMQS。
图 10. 部署应用程序
- 单击 Deploy,如图 10 所示。
- 使用默认设置,然后单击 Deploy 开始部署。
步骤 11. 为 QualityStage 设置配置值。
注意:这个示例集成针对安装了维护服务的 InfoSphere MDM Server。在安装维护服务期间,如果您运行了 install_ELPCustom.sh,那么可以跳到 使用关键配置参数优化性能。
根据表 2 设置配置值,以正确地与 IIS-QS 服务器通信。
表 2. 配置修改
| 配置名 | 默认值 |
|---|
| /IBM/ThirdPartyAdapters/IIS/defaultCountry | 185 | | /IBM/ThirdPartyAdapters/IIS/initialContextFactory | 这个配置元素与提供者 URL 一起使用,以使用 JNDI 注册表初始上下文。这个元素的典型值是 com.ibm.websphere.naming.WsnInitialContextFactory。 | | /IBM/ThirdPartyAdapters/IIS/providerURL | iiop://<yourQSServer>:<QSServerBootstrapPort>.
例如:iiop://myIIS.torolab.ibm.com:2809。 | | /IBM/Party/Standardizer/Name/className | com.ibm.mdm.thirdparty.integration.iis8.adapter.InfoServerStandardizerAdapter | | /IBM/Party/Standardizer/Address/className | com.ibm.mdm.thirdparty.integration.iis8.adapter.InfoServerStandardizerAdapter |
步骤 12:使用 QualityStage (QS) 名和地址标准化。
使用 QS 标准化输入到 InfoSphere MDM Server 中的名称和地址。查看 MDM 开发人员指南中的 Standardizing name, address and phone number information 了解更多信息(见 参考资料)。
步骤 13:在 Suspect Duplicate Processing 中使用 QualityStage。
QualityStage 可以和 InfoSphere MDM Server Suspect Duplicate Processing (SDP) 特性一起使用。查看 MDM 开发人员指南中的 Configuring IBM Information Server QualityStage integration for SDP 了解更多结合使用 QualityStage 和 SDP 的信息(见 参考资料)。
使用关键配置参数优化性能
安装 InfoSphere MDM Server 之后,通过调优关键配置参数以获得最佳性能。
InfoSphere MDM Server 和批处理器配置
- 通过增加提交器的数量来增强并行性。为此,编辑文件 <MDM_installation_Folder>/BatchProcessor/properties/Batch.properties。在 8 路的 MDM Server 机器上,24 个提交器是最佳的。
- 增加批处理器的 JVM 堆设置。为此,编辑文件 <MDM_installation_Folder>/BatchProcessor/bin/runbatch.sh。例如,对于 24 个提交器,512MB 的堆已经足够。
- 通过将阈值设置为 ERROR 减少 BatchProcessor 日志。为此,编辑 <MDM_installation_Folder>/BatchProcessor/Log4J.properties 并将日志阈值设置为 ERROR,如果还没有这样设置的话。例如:log4j.appender.file.Threshold=ERROR。
- 通过将阈值设置为 ERROR 减少 MDM Server。为此,在 <WebSphere_Location>/profiles/<ServerName>/installedApps/<CellName>/<InstanceName>/properties.jar 上的 properties.jar 文件内部编辑 Log4J.properties。
WebSphere Application Server 配置
- 增加 JDBC 连接池的大小以支持并行性。
- 从 WebSphere Administration Console 转到 Resources
>JDBC > Data sources > DWLCustomer
> Connection pool properties。
- 增加最大连接数的值。样例设置中使用的值为 50。注意,整个 DataSource 仅使用一个缓存,但每个 Connection 需要具有每个预定义语句的副本。因此,缓存的大小取决于 DataSource 连接池中的连接数。因此,如果您更改了连接池的大小,那么也应该更改预定义语句缓存大小。
- 增加预定义语句缓存的大小。
- 为了确定预定义语句缓存的适合大小,可以用您的应用程序中使用的唯一 SQL 语句的数量乘以连接的最大数量。注意,整个 DataSource 只有一个缓存,但是每个 Connection 都需要每个预定义语句的副本。
- 从 WebSphere Administration Console 转到 Resources
> JDBC > Data sources > DWLCustomer
> Connection pools > WebSphere Application
Server data source properties。
- 先将它的值设置为 1000,然后监控应用程序确定是否需要增加缓存的大小。
- 增加 EJB 缓存的大小。为此,使用 WebSphere
Administration Console 并转到 Servers > Application
servers > [ServerName] > EJB Container Settings
> EJB cache settings。示例使用的值为 4000。
- 更改 JVM 堆大小和 GC 策略。
- 从 WebSphere Administration Console 转到 Servers
> Application servers > [ServerName] >
Java and Process Management > Process Definition
> Java Virtual Machine。
- 表明初始堆大小为 512 MB,最大堆大小为 1024 MB。
- 使用 gencon GC 策略获得更佳的性能。要使用这个 GC 策略,在 Generic JVM 参数下指定 -Xgcpolicy:gencon。当使用 gencon GC 策略测试样例时,有时 WebSphere Application Server 会生成不必要的堆转储。为了禁用这个行为,在服务器启动之后执行:
- 从 WebSphere Administration Console 转到 Servers
> Application servers > [ServerName]
> Performance > Performance and Diagnostic
Advisor Configuration > Runtime (tab)。
- 取消选择该复选框(确保复选框是空的)以启用自动堆转储收集。
数据库调优 (DB2)
在设置数据库服务器时,建议您遵循最佳实践和指导。此外,还建议您严密监控数据库性能,并根据需要调优数据库,以获得最佳性能和最大限度地利用资源。这个小节简单地描述配置和调优 DB2 数据库的几个建议。这些建议也适用于其他类型的数据库。
- 通常建议对 DB2 事务日志使用一组专用的磁盘,而对 DB2 表空间使用另一组专用的磁盘。如果条件允许的话,分别对 DB2 事务日志和 DB2 表空间使用不同的磁盘控制器会更好,因为这样做允许您灵活地将磁盘控制器配置为不同的 I/O 模式,着重于实现最佳的写性能,而不是将读和写混合在一起。
- 确保在储存系统上启用读写缓存。监控缓存的效率,并配置
合适的缓存大小。
- 适当地规划表空间,确保在所有可用磁盘上平衡分布 I/O 操作。这避免数据库热点和避免最繁忙的磁盘影响数据库性能。适当的表空间能够最大限度地利用所有物理磁盘的可用 I/O 带宽。
- 除了在 I/O 系统使用良好规划的表空间布局之外,显著影响性能的配置参数之一是数据库缓冲池的大小。仔细观察总体缓冲池的访问率,它反映访问物理磁盘以获取储存在数据库缓冲池中数据的频率。
- 争取实现缓冲池的数据和索引访问率分布超过 80% 和 90%。在 MDM Server 实现中,通常首先开始对数据和索引使用比较大的缓冲池。如果必要的话,将数据缓冲池和索引缓冲池分开,这样做有助于确保较高的索引缓冲池访问率。
- 因为 MDM Server 支持许多定制和扩展,所以可以分析来自数据库截屏或其他工具的开销最大的 SQL。确保这些 SQL 使用最佳的索引并拥有最优的访问计划。
必须全面考虑这些建议以获得所需的性能,因为某个区域的性能症状可能是由另一个区域设置不当引起的。
理解示例中使用的性能测试方法
输入数据准备
maintainContractPlus 事务用于测试本文的例子。因为使用了来自 BatchProcessor 的默认解析器,所以输入数据的格式必须为换行的 XML 事务。
获取输入数据的第一步是创建原始数据。原始数据是使用自制的基于 Java 的工具根据美国户口普查资料(2000年)生成的。还添加了一些真实的数据,从而所有方面都紧密围绕一个典型的 MDM 业务场景。原始数据包含的细节包括姓名、性别、出生日期和住址。
第二步是为 maintainContractPlus 事务创建一个模板。这个模板拥有针对关键部分细节的变量,需要使用生成的原始数据填充它们。另一个自制的基于 Java 的工具用于生成 XML 事务。每个这样的事务都生成一个具有名称、地址、联系人和联系方式的人。表 3 显示了由一个事务填充的数据库表的详细情况。这个例子使用 100 万条这样的记录作为一个输入数据集,表示一方及其属性。
可疑重复数据准备
到目前为止,这个例子生成的数据基本上都是干净的。我们使用另外一种类似的方法生成脏 数据,其中有 40% 是重复的。当启用 Suspect Duplicate Processing 时,将使用这个数据集。
在初始装载期间,输入数据可能包含重复条目,其中一个记录的细节非常接近于来自另一个记录的细节。这些记录被称为可疑重复数据。根据两个记录的匹配程度,可疑重复数据被分配到一个匹配类别中。为了确定匹配类别,将在比较两个记录时使用一些关键的数据字段。关键数据字段包括名、姓、出生日期和社会保险号。根据比较结果,可疑重复数据将被分配一个匹配——得分 和一个不匹配——得分,然后生成匹配类别。InfoSphere MDM Server 将根据匹配类别对可疑重复数据采取适当的操作。
在测试这个例子时使用了两组数据:
- 100% 干净的数据,输入数据集中不包含任何可疑重复数据
- 输入数据集中包含 60% 的干净数据和 40% 的可疑重复数据
这个示例测试在包含 60% 干净数据的数据集中包含 4 种类型的可疑重复数据。每种类型的可疑数据的数量保持一样,它们被自制的基于 Java 的工具随机分布到数据集中。
表 3 显示了该数据集的细节。
表 3. 包含可疑数据的输入数据的细节
| sr# | 匹配关键数据细节 | 不匹配关键数据细节 | 数量 | 权重(匹配/不匹配得分) | 匹配类别 |
|---|
| 1 | Gender, FirstName, LastName, Address, DOB, SSN | None | 10% | 63/0 | A1 | | 2 | Gender, FirstName, LastName, DOB,SSN | Address | 10% | 60/3 | A2 | | 3 | Gender, Address, DOB, SSN | FirstName, LastName | 10% | 55/4 | A2 | | 4 | Gender, Address, Last Name DOB | First Name(SSN 字段为空) | 10% | 46/1 | B |
表 3 中的得分和类别是使用 InfoSphere MDM Server 的确定性匹配方法计算的,它是匹配比较使用的默认实现。相比之下,QualityStage 匹配使用概率的匹配方法进行计算,它仅计算一个复合权重。
数据描述
表 4 显示了装载这两组数据集时 InfoSphere MDM Server 数据库表的成分。
表 4. 数据库成分
| 表名 | 100% 干净数据 | 60% 干净数据 |
|---|
| ADDRESS | 1,000,000 | 700,000 | | ADDRESSGROUP | 1,000,000 | 900,000 | | CONTACT | 1,000,000 | 900,000 | | CONTACTMETHOD | 1,000,000 | 900,000 | | CONTACTMETHODGROUP | 1,000,000 | 900,000 | | CONTEQUIV | 1,000,000 | 1,000,000 | | CONTRACT | 1,000,000 | 1,000,000 | | CONTRACTCOMPONENT | 1,000,000 | 1,000,000 | | CONTRACTROLE | 1,000,000 | 1,000,000 | | IDENTIFIER | 1,000,000 | 900,000 | | LOBREL | 1,000,000 | 900,000 | | LOCATIONGROUP | 2,000,000 | 1,800,000 | | MISCVALUE | 1,000,000 | 1,000,000 | | PERSON | 1,000,000 | 900,000 | | PERSONNAME | 1,000,000 | 900,000 | | PERSONSEARCH | 1,000,000 | 900,000 | | SUSPECT | 0 | 300,000 |
测试方法
将通过不同的测试检查稳定性和可伸缩性,以及度量与几个常用特性相关的开销。使用两种解决方案配置进行所有测试:
- 仅 MDM Server 解决方案,其中 InfoSphere MDM Server 使用自己的算法执行标准化和匹配。在这个例子中,不需要使用 IBM Information Server。
- MDM Server + QS 解决方案,其中 InfoSphere MDM Server 使用 QualityStage 执行标准化和匹配。
所有测试使用的方法是类似的:
- 设置系统。根据先前小节提到的方法进行配置和调用各种组件。
- 使用这里提到的方法准备一组包含 10000 个记录的输入数据。
- 在批处理器中使用 1 个提交器装载包含 10000 个记录的输入数据。这样做是为了避免处理空数据库时出现死锁。
- 对所有表执行 DB2 reorgchk 以更新统计数据。
- 在这个阶段创建一个 MDM Server 数据库备份,并将其作为所有测试的起点。
以下是运行示例测试所需的步骤:
- 使用备份副本恢复数据库。
- 如果测试需要,则更改数据库配置。例如,您可能想关闭 Suspect Duplicate Processing。
- 重启运行 InfoSphere MDM Server 的 WebSphere Application Server。
- 在后台运行数据收集脚本,它将收集 CPU 统计数据、I/O 统计数据和数据库快照。
- 开始运行测试,装载选择的输入数据集。
- 从 InfoSphere MDM Server、WebSphere Application Server 和 DB2 数据库服务器收集日志。
- 从 InfoSphere MDM Server 生成的 transactiondata.log 得出响应时间和吞吐量。
度量性能结果
这个小节描述的性能度量指标包括:
- 显示每个表的性能吞吐量和响应时间的结果
- 某些常用的特性在初始数据装载上下文中的性能开销
- 吞吐量的可伸缩性
测试 1:吞吐量和响应时间的稳定性
该测试的目的是显示随着装载进行和数据库变大时,吞吐量和响应时间是否保持稳定。此外,该测试还在整个测试过程中度量系统资源的使用模式。用于测试吞吐量和响应时间的数据来自于 InfoSphere MDM Server 生成的 transactiondata.log。
将针对仅 MDM Server 和 MDM Server + QS 场景进行各种测试,并且所有测试都显示出良好的稳定性。表 5 显示了第一个测试的配置设置。
表 5. 测试 1 的配置
| 参数 | 值 |
|---|
| Hardware/Software stack | 如示例测试环境所述 | | InfoSphere MDM Server heap size | Initial : 512MB; Max 1024MB | | InfoSphere MDM Server JVM GC policy | gencon | | Number of submitters in batch processor | 24 | | Batch processor JVM memory | 512MB | | ISD job configurations (applicable to MDM Server + QS scenario
only) | Default | | Type of transaction used | MaintainContractPlus | | Total volume | 1 million parties and their associated records | | Input data quality | 60% clean 40% suspected duplicates of various types | | | Name standardization | ON (default) | | Address standardization | ON (StandardFormatingIndicator to N in the requestXML) | | Suspect duplicate processing | ON | | History triggers | Enabled |
测试 1 的结果:稳定性结果
图 11 显示了针对仅 MDM Server 场景捕捉到的吞吐量和响应时间。这个图表表明在整个运行期间吞吐量和响应时间是稳定的。MDM Server + QS 场景也得到类似结果。
图 11. 吞吐量和响应时间
图 12 显示了通过将提交器配置为所需的足够数量,运行 InfoSphere MDM Server 的 WebSphere Application Server 上的所有 CPU 资源几乎都可以利用,并且系统没有任何其他瓶颈。图 12 也显示了其他系统上的资源使用。
图 12. 资源使用
测试 2:特性开销
这个测试的目的是度量 4 个常用的 InfoSphere MDM Server 特性的开销。在这组测试中,将度量以下特性的开销:
- Name standardization
- Address standardization
- Suspect duplicate processing
- History triggers
开销通过在启用特性特性时每个时间单位吞吐量减少的百分比表示。例如,与某个特性相关联的 5% 开销意味着如果吞吐量为 100 事务/每秒(TPS),那么启用该特性时吞吐量就变为 95 TPS。吞吐量是通过总装载数据量/总消耗时间 来计算的。
针对仅 MDM Server 和 MDM Server + QS 场景进行各种测试,并且一次启用一个或多个特性。在 MDM Server + QS 场景,标准化和可疑重复处理的开销应该更高,因为它们涉及由 QualityStage 进行的额外处理。
表 6 显示第二个测试的配置设置。
表 6. 测试 2 的配置
| 参数 | 值 |
|---|
| Hardware/Software stack | 如前面的测试环境所述 | | InfoSphere MDM Server heap size | Initial: 512MB ; Max 1024MB | | InfoSphere MDM Server JVM GC policy | Default | | Number of submitters in batch processor | 24 | | Batch processor JVM memory | 512MB | | ISD job configurations (applicable to MDM Server + QS scenario
only) | Default | | Type of transaction used | MaintainContractPlus | | Total volume | 1 million parties and their associated records | | Input data quality | a) 100% clean; b) 60% clean |
以下是一些关于该配置的注意事项:
- 可以将 /IBM/Party/ExcludePartyNameStandardization/enabled 分别设置为 FALSE 或 TRUE 启用或禁用 Name standardization。
- 可以在事务请求 XML 中将 StandardFormatingIndicator 设置为 N 或 Y 启用或禁用 Address standardization。
- 通过在配置表中将以下设置分别设置为 TRUE 或 FALSE 启用或禁用 Suspect duplicate processing:
- /IBM/Party/SuspectProcessing/enabled
- /IBM/Party/SuspectProcessing/AddParty/returnSuspect
测试 2 的结果:特性开销
标准化
下面的表显示了针对仅 MDM Server 场景的 Standardization 开销。当启用 Suspect Duplicate Processing 时,使用两个数据集(100% 干净和 60% 干净的数据集)运行测试。在这些测试期间启用 History triggers。
表 7. Standardization 的开销
| 开销 | SDP OFF | SDP ON(100% 干净的数据集) | SDP ON(60% 干净的数据集) |
|---|
| Name standardization 的开销 | 2% | 3% | 3% | | Address standardization 的开销 | 2% | 2% | 0% | | Name and Address standardization 的开销 | 4% | 3% | 2% |
注意:使用 60% 干净的数据集时,唯一的地址更少。这会导致更少的开销。
Suspect duplicate processing
表 8 显示在仅 MDM Server 场景中启用或不启用 Standardization 的 Suspect duplicate processing 的开销。使用两个数据集(100% 干净和 60% 干净的数据集)运行测试。在测试期间启用 History triggers。
表 8. Suspect duplicate processing 的开销
| 开销 | 100% 干净的数据集 | 60% 干净的数据集 |
|---|
| Suspect duplicate processing 的开销 | 3% | 20% | | 启用 Name and Address standardization 的 Suspect duplicate processing 的开销 | 6% | 21% |
History triggers
如果启用 History triggers,数据库服务器上的 I/O 需求将显著增加(几乎增加一倍)。如果 I/O 带宽充足,开销就会很小(大约 5%)。
表 3:可伸缩性测试
根据定义,可伸缩性是度量在系统上使用多个负载时吞吐量的增长程度。不过在示例测试中,处理器的数量实际上没有变化,而是通过改变批处理器中的提交器的数量来改变对 InfoSphere MDM Server 的并行请求数量。在 1 至 24 个提交器之间的数据点上收集数据。很明显,使用 24 个提交器时系统会饱和。
针对仅 MDM Server 和 MDM Server + QS 场景进行了测试。使用不同的配置运行测试,所有测试都表明可伸缩性是呈线性的。
表 9 显示了第三次测试的配置设置。
表 9. 测试 3 的配置
| 参数 | 值 |
|---|
| Hardware/Software stack | 如示例测试环境所述 | | InfoSphere MDM Server heap size | Initial: 512MB; Max 1024MB | | InfoSphere MDM Server JVM GC policy | Default | | Number of submitters in batch processor | Varied between 1 to 24 | | Batch processor JVM memory | 512MB | | ISD job configurations (applicable to the MDM Server + QS scenario
only) | Default | | Type of transaction used | MaintainContractPlus | | Total volume | 15000 to 100,000 records | | Input data quality | 60% clean | | Name standardization | ON (default) | | Address standardization | ON (StandardFormatingIndicator to N in the requestXML) | | Suspect duplicate processing | ON | | History triggers | Enabled |
测试 3 的结果:可伸缩性结果
图 13 显示了仅 MDM Server 场景下的可伸缩性。如绿色线条所示,增加提交器的数量时,吞吐量的增长几乎是呈线性的。示例配置利用了运行 InfoSphere MDM Server 的服务器 90% 以上的 CPU 能力。对于 MDM Server + QS 场景,结果是相似的。
图 13. 启用 SDP 时 InfoSphere MDM Server 的可伸缩性
结束语
InfoSphere Master Data Management Server 是使用前沿技术开发的,致力于在部署过程中提供灵活性,在运行过程中提供高性能和高可伸缩性,它是许多行业在实现 MDM 解决方案时的首要选择。作为领先者,IBM 在今天的市场成功部署了最大份额的 MDM 实现。通过提供两种加速初始和增量数据装载的可伸缩快速部署方法,IBM MDM 解决方案帮助客户实现更快的投资收益,并且增强了自身的领导地位。作为两种可用的初始装载方法之一,RDP 维护服务批处理为装载大量初始 MDM 数据提供快速便捷的方法。这种方法还可用于增量装载,这是非常有用的。
本文解释了什么是维护服务,以及如何在 InfoSphere MDM Server 环境中设置 RDP 维护服务。本文提供大量关于配置和调优的详细技巧,您可以利用它们改进 RDP 维护服务并获得更高的运行性能。本文还讨论了为执行标准化和匹配设置 Information Server QualityStage 的步骤,如果需要该配置的话。此外,还描述了来自各种常见场景的关键性能数据点,它们显示在初始装载中使用 RDP 维护服务能够提供持续的高性能和出色的可伸缩性。最后,本文总结了 MDM Server 实现中一些常用的关键特性的性能开销度量。它们对根据所选的特性规划 MDM Server 系统的容量或在初始装载期间确保所需的性能非常有用。
致谢
我们感谢 Lena Woolf、Berni Schiefer 和 Karen Chouinard 为本文提供支持和建议。此外,我们也感谢其他 MDM Server 团队成员对这个项目的支持。
公告
©IBM Corporation 2009。版权所有。
本文档中所包含的信息仅用于提供信息的目的。虽然在检查本文信息时尽量保证其完整性和准确性,但它只根据 “现状” 提供,没有任何隐含或者明确的担保。此外,本文包含的信息根据当前产品计划和策略提供,如有变更,恕不通知。
不承担因为使用此本文内容和其他相关内容而造成损害的责任。本文中包含的内容不打算、也不应该作为 IBM 或其供应商或其许可证销售商的担保或表示,或者修改适用于 IBM 软件的许可证协议的条款和条件。
本文包含的所有性能数据均来自特定的操作环境,并且仅用于演示目的。在其他操作系统中可能得到不同的性能,客户应该自己进行测试。
本文的性能数据是在受控环境中使用 IBM 标准基准测试度量得出的。受众多因素的影响,包括用户作业流中的多进程、I/O 配置、储存配置和工作负载等,用户获得的实际吞吐量或性能将有所不同。因此,不能保证每个用户都能得出类似本文提供的结果。
有关非 IBM 产品的信息是通过这些产品的供应商获得的。IBM 没有测试这些产品,不能确认与非 IBM 产品相关的性能、兼容性或任何其他声明的准确性。关于非 IBM 产品的问题应该由这些产品的供应商解决。
本出版物中对 IBM 产品或服务的引用不代表它们可用于所有 IBM 运营的国家。本文中引用的所有产品发布日期和/或功能可能在任何时候变更,这根据 IBM 对市场机遇或其他因素的判断决定,不代表 IBM 对未来产品或功能可用性的承诺。本文包含的任何内容都没有暗示或表明您采取某种行为就会获得特定的销售、收益增长、成本节约或其他结果。
参考资料 学习
获得产品和技术
- 使用可直接从 developerWorks 下载的 IBM 试用软件 构建您的下一个开发项目。
讨论
作者简介  | 
|  | Neeraj R Singh 目前是一名关注 InfoSphere Master Data Management Server 性能的高级性能工程师。他还是技术主管和测试项目主管,领导 Java Technologies 测试团队进行功能性、系统和性能测试。他于 2000 年加入 IBM,拥有电子通信工程学士学位。 |
 | 
|  | Yongli An 是一位关注 Master Data Management 产品和解决方案的高级性能工程师。他还具有 DB2 数据库服务器和 WebSphere 性能调优和基准测试经验。他是 IBM 认证的应用程序开发人员和数据库管理员。他于 1998 年加入 IBM。他拥有计算机科学学士和硕士学位。Yongli 目前是 MDM 性能和基准测试团队的经理,同时也帮助客户实现 MDM 系统的最佳性能。 |
对本文的评价
|