彩票走势图

文 | 刘汉槟

大数据量和高吞吐是银行内容管理系统长期设计的核心问题，本文通过内容管理系统在农信银行后督系统的设计和实现实例 (基于 DB2V97 数据库)，描述对于内容管理系统如何针对每天大约 400 万个图片、可能存放 15 年达到 2PB 文件规模的大数据量系统进行数据模型设计、表分区以及压缩的具体设计实现，以及系统在高并发下一些实际问题的处理，系统上线后吞吐量和性能得到了客户的认可，可以为类似的银行系统提供重要的参考。

前言

本文是对使用 IBM 内容管理系统为平台的广东农信银行客户后督系统的分析和介绍，以及对大数据量和高吞吐的基于 DB2 数据库的 IBM Content Manager 系统的一些设计上的分析以及一些实际问题的解决，系统在调优后性能和吞吐量满足的客户的需求，可以作为类似系统的参考，但是要注意，每一个系统都有自己独特的需求和实际情况.。

本文无法涵盖您在系统建设过程中的所有问题，欢迎联系我们做进一步探讨。另外，将来实际系统中在数据量达到一定量级时，可能会碰到新的难题，我们希望能和客户一起协作解决并将经验分享给大家。第一部分, 我们将着重介绍系统背景需求以及设计。

中英文术语对照表/缩略语

IBM 内容管理系统：英文名 IBM Content Manager，简称 CM。

广东农信影像化事后监督系统：简称广东农信后督系统。

库数据库：英文名 Library server database，简称 LSDB。

资源数据库：英文名 Resource manager database，简称 RMDB。

资源管理应用程序：英文名 Resource manager application，简称 RMApp。

项类型：英文名 Itemtype。

资源项类型：英文名 Resource itemtype。

文档项类型：英文名 Document itemtype。

项：英文名 Item。

项级别：英文名 Item Level。

访问控制列表：英文名 Access control list，简称 ACL。

本地索引：英文名 Local index。

表分区分离：英文名 Detach partition。

级联目录：英文名 Hierarchical folder。

系统及架构简述

IBM 内容管理系统，是一套基于数据与内容的企业级整体行业解决方案平台，它能够帮助企业快速地解决复杂的问题，在当今瞬息万变的市场环境中更快速地制定高效的决策。客户可以利用 IBM 内容管理系统产品方便的做到：对各种原始票据、凭证、档案、影像等海量的非结构化数据的存储和管理;数据的生命周期管理;并且可以支持基于内容的分析与查找，高级案例管理，和流行的社交内容管理。

广东农信影像化事后监督系统是提供给全省各农合机构事后监督中心和网点使用，是监督各项业务处理的正确性、合规性、真实性和完整性，及时发现各种核算差错事故，暴露业务核算中发生的各种违章、违纪、违法行为，完善业务操作风险控制体系，实现差错处理的电子化流转，实现凭证的电子化管理的一整套管理系统。

系统主要包括影像处理、重点监督、再监督、风险预警、差错处理流程管理，实物档案流程管理等功能，使用 IBM 内容管理平台实现对影像数据存储的生命周期管理，满足用户对大数据量历史影像数据的实时在线调阅需求。

经过前期的数据收集和业务估算，广东农信后督系统全省上线后，日均凭证影像张数将达到 400 万张，最近 60 天的凭证影像经常会发生调整、修改信息、整改差错的业务操作。而从系统建设层面考虑，日均 400 万张的凭证影像将导致系统的记录数和数据量非常庞大，需要考虑多个影像文件打包成一个大文件后部份读取的可能性，恰好 CM 的聚合迁移支持这种打包操作。

如果按照会计档案需保管十五年的要求，广东农信后督系统影像文件的总存储空间将达到 2PB，为保证数据的读取效率同时兼顾项目建设成本，广东农信规划了如下的后督系统影像文件总体存储策略：

根据广东农信后督系统的实际使用需求，广东农信还规划了影像数据的生命周期管理时间窗口要求，具体为：后督系统影像文件装载至 CM(两个小时) CM 影像文件迁移至 TSM(两个小时) TSM 存储卷迁移至磁带卷(四个小时)。

针对广东农信后督系统影像文件的总体存储策略和影像数据生命周期管理的时间窗口要求，结合后督系统、CM 内容管理平台的扩展性(除了 CM 的索引库不能扩展，其他都可以扩展)，加上 IBM 工程师的指导，广东农信设计了满足此高吞吐大数据量的 CM 系统架构。

具体为：

CM 数据库服务器采用 HA(High Available) 架构，每个数据库服务器节点包含 1 个库数据库和 4 个资源数据库、每个资源数据库对应的资源管理应用程序采用 WAS cluster 架构，保证资源管理应用程序的并发性和扩展性，每个 WAS cluster 由一个 Dmgr 管理并分配 2 台物理服务器，每个物理服务器节点下有两个应用服务器，这样对于每个 WAS cluster 共四个应用服务器。

同时，整套 CM 系统内部采用万兆网连接，TSM(Tivoli Storage Manager) 服务器也采用 HA 架构，确保影像数据生命周期管理的时间窗口要求以及高可用要求。下图 1 展示了一个内容管理系统比较通用基于 AIX 的 HA 系统架构图 (包含多个 RM 和 RMApp)：

图 1. 系统架构图

数据模型的选型以及表分区的设计

根据计算，广东农信后督系统如果满负荷上线，大约每天需要装载 400 万条数据，每月 1.1 亿，每年约 13 亿数据，IBM 内容管理系统的一些表会相应的有这个数量级的记录，如此大的表会带来可能的一些问题，比如维护 (备份、Runstats、Reorg 等) 时间长等。

另外当数据量达到一定的量级时，整个系统也可能会有一定的性能下降。我们要从数据模型设计以及数据库逻辑物理设计上尽量降低这种发生的可能性，或者能支持更大量的数据，比如银监会要求的 15 年数据。首先，我们根据业务的需要去设计数据模型，以下是几点可供参考的考虑：

• 选择合适的项类型

内容管理系统支持两种主要带文件的项类型：资源项类型和文档项类型。资源项类型相对简单，每个项只能带一个文件，但是相对文档项类型来说，每一个资源项类型可以减少操作至少 2 张大表，相对应的在超过 10 亿的海量数据量的系统来说，同样的设计，装载和其他业务的效率会更高，也更能节省空间，同时降低维护时间。

所以对于海量数据的系统，如果能满足业务需求，我们更建议使用资源项类型存放扫描的文件。另外，对于需要建立多个类似项类型的设计，建议把一些共用的属性先建立一个属性组存放起来，这样能更方便的建立项类型。

• 资源数据库均衡负载设计

对于多个营业网点的数据，有时候为了便于管理，希望通过一定的机制把不同的营业网点的数据通过不同的资源管理应用程序导入到不同的资源数据库里，这样便于权限管理和分担一定的负载。

我们可以把库数据库的默认存储设置为用户级别，如图 2 所示，然后为每一个营业网点或网点组建立一个装载用户，为每一个装载用户设置一个默认的 Collection 和相应的默认项访问控制列表，然后对于新建的项类型，选择使用项级别的检查级别，并使用用户默认 ACL 检查 (User’s default ACL)，参考图 3，然后用相应的用户做装载数据，就可以控制数据装载在不同的资源数据库。

• 建立合适索引

对于业务查询常用的属性项，需要建立相应的索引以加快查询和获取数据的速度。

减少不必要的关系如果没有需求，可以不建立目录、连接、引用、级联目录等复杂的关系，这些都会影响将来可能会实现的表分区分离的可能性。

• 文件聚合迁移到 TSM

如果对文件没有修改的需求，并且都是最大几兆的小文件，大数据影像系统可以考虑使用 CM 提供的聚合迁移功能，聚合迁移会将文件按照打包大小的设置进行打包后迁移到 TSM 中，会大大减少过量小文件产生的网络问题和 TSM 服务器的压力，并大大降低 TSM 数据库的数据量和维护成本。

图 2. 库数据库默认存储设置

图 3. 项级别 ACL 检查以及用户默认 ACL 设置

另外，对于可预见的大表将来的使用和维护，我们建议使用 DB2V97FP1 以上的表分区方案，好处是可以更好的分时间段存放数据，更灵活的分配物理资源 (盘阵等)，同时可以利用 DB2V97FP1 之后支持的表分区中的本地索引减少维护的时间空间，对于业务模型合适的系统，将来甚至可以做到将超过一定时间不常用或者只读的数据从在线业务系统之中分离出去，然后导入到另一个内容管理系统中，降低在线系统的数据量。

对于表分区的设计，我们已经有相应的白皮书和文章 (请参考参考资源) 做了系统的介绍，本文这里只介绍一下广东农信的现在应用的实例，也就是在 CM843 系统里对于一个只包含一个资源项类型的实例系统的表分区设计。

1.首先找到固定的大表

固定的大表包括库数据库的 ICMSTITEMS001001 和资源数据库的 RMOBJECTS 表。

2.其次找可能的大表

对于激活了历史版本文档的设计，库数据库需要增加大表 ICMSTITEMVER001001 表，对于使用的连接关系的表 (比如使用了目录文档结构) 需要增加大表 ICMSTLINKS001001 表，如果使用了文档类型的项类型，需要增加大表 ICMUT00300001 表和 ICMRI001001 表，如果使用了级联目录关系，那么需要增加大表 ICMSTHLINKS 表。

3.动态表名的大表

下面介绍一下如何找到一个具体项类型元数据实例表。

注意：1004 应该是第一步取得的值，请用实际值替换。假如 COMPONENTTYPEID 实际值是 1007，项组件类型实例表就为 ICMUT01007001。有几个 COMPONENTTYPEID，就对应有几张 ICMUT0XXXX001 表，其中 XXXX 为 COMPONENTTYPEID。

表分区分区频率设计

根据内容管理系统数据库的特点，上述大表都有包含有时间戳的 ITEMID 字段或者类似字段，以及 DB2 对表分区键选取按时间分区的建议，我们可以选取 ITEMID 或者类似的字段作为表分区的分区键，表分区可以按一定时间间隔分区，比如按月分区、按季度分区、按年分区等，对于一个月有 1 亿数据量的系统来说，我们可以选取一个月一个分区的设计。

表分区初始分区以及结束分区的考虑

分区并不是无限的，所以总会有开始分区并且有结束分区，那么我们又希望结束分区不要包含太多时间段的数据，那么最好先和客户沟通一个第一次做表分区的时间段，比如客户希望系统至少运行 10 年，以 2013 年 1 月到 2022 年 12 月为例，我们先要为 0-2013 年 1 月 1 日 (不包含结束日期) 建立初始分区，这个初始分区包含内容管理系统的一些初始数据和可能的临时数据，假设命名为 PSTART。

然后中间是每个月一个分区一直建立到 2023 年 1 月 1 日 (同样不包含结束日期)，最后需要建立一个结束分区 (如名字为 PEND) 从 2023 年 1 月 1 日一直到 MAX(最大时间) 作为封尾分区。

需要注意的是，如果在系统使用年限接近到达第一次划分预期的结尾时间时，比如提前 1 年的 2021 年底选取业务空闲时期停止业务，分离现有封尾分区 PEND, 创建新的 5 年或者其他年数的表分区，然后用新的预期系统最终使用时间一直到 MAX 重新封尾。

表分区中用户自定义的索引设计

如果用户的数据模型中需要对一些字段做检索，最好使用系统管理客户端去为这些字段建立相应的索引，这样索引内就会自动加入 ITEMID 作为索引的一部分，这样就可以使用本地索引，这样会对分区维护和性能对会有好处。

如果用户想自己使用数据库命令为数据模型的相关实例表建立自己的索引，应该在 IBM 服务团队的支持下进行，对于表分区的情况，建议尽量在索引定义中加入 ITEMID 字段，当然具体情况需要具体分析。

表及索引压缩

对于有海量数据的表，在做表分区的同时可以考虑做表的压缩，也可以考虑同时压缩索引，这样会降低磁盘的使用空间，对于瓶颈主要在 I/O 而 CPU 资源充足的系统，表压缩也会以牺牲一定量 CPU 资源的情况下减少 I/O 占用，理论上会产生一定好的效果，实际情况，应该根据性能测试是否满足客户需要去决定最终的方案。

表空间及缓冲池设计

为表分区的数据和索引分别建立独立的表空间和缓冲池。为索引建立单独的缓冲池好处是，对于海量数据调整数据表空间所在的缓冲池无法调优的情况下，单独调整需要内存较小的索引表空间所在的缓冲池，可能会有比较好的效果。

另外即使使用了条带化的磁盘阵列作为数据库物理存储，已经可以做到将数据打散到不同的磁盘已达到 I/O 并行访问的效果，我们还是建议为数据和索引建立不同的表空间 (组)，这样方便维护和管理，比如可以对每年或者每季度的表分区建立一个或几个数据表空间，为所有大表的索引每年建立一个表空间。

ICMSTITEMS001001 表分区示例

我们下面以库数据库里存放所有项基本信息的大表 ICMSTITEMS001001 表为例介绍按月分表分区 (2013 年和 2014 年共 2 年) 的示例，其他大表的表分区可以类似去设计和撰写。

首先，创建存储过程 SET_CONSTRAINTS 可以暂时不检查外键，便于数据表重建。

其次，为 ICMSTITEMS001001 所在的库数据库增大部分缓冲池，并增加一个索引单独使用的缓冲池。注意下列所有缓冲区具体每个缓冲区的大小需要根据你系统实际可以分配给库数据库的内存大小去调整。

第三，为 ICMSTITEMS001001 表及其他类似的大表创建单独数据表空间，每年都会用一个表空间存放。表数据将会存放到 LSSTPART20YY(YY 表示年号的后两位，下同) 表空间，索引将会存放在 LSIDXPART20YY 表空间。

第四，生成 ICMSTITEMS001001 分区前表的定义。

第五，修改 items_part.sql，为每个表每个月建立表分区，总共创建到 2014 年底共 2 年的表分区。修改后的代码见附件 items_part.sql。

以此为范例，我们可以类似的为所有需要分区的表定义和设计不同分区年数，分区使用的缓冲池，表空间以及分区频率等。

小结

通过本系列第 1 部分的介绍，我们可以了解到如下知识： 银行后督实例系统的业务需求和大数据量高吞吐以及相关性能的非业务需求。 应对实例系统的高吞吐的系统架构和数据模型设计。 应对实例系统的大数据量数据的表分区的设计和示例。 通过本系列第 1 部分介绍的方案及设计，可以对高吞吐大数据方面有要求的 CM 系统的设计有所帮助。