AS400银行核心系统开发中的技术总结--多成员表

*多成员表

    银行核心系统通常生命周期在10年左右，现在随着银行系统的数量和复杂度增加，系统的生命期也有逐渐变长的趋势。通常核心系统上线时，很多数据表的记录数并不太多，而当系统运行年限越来越长，巨型数据表就越来越多。另外，随着城商、农信的省级集中，用以前针对城市级商业银行的系统，来应对省级的数据量，原先规模合理的表，也会变成巨型表。在实际项目中，已经遇到记录数上亿，和十亿级别的表了，不光严重影响系统性能，在7*24小时不间断运行条件下，数据清理都是个难题。以往的系统，在这方面考虑是比较少的，大概是因为系统设计实现者通常只管上线，不会长期维护，而且原先系统面向银行的规模较小。因此，要么没考虑大数据量表的拆分，要么常处理方法也只是简单区分下当前表和历史表，在日终时做个当前倒历史的批量（历史表巨大的话，倒历史时间也会变得很长）。

    分析银行的数据表，容易产生很多记录数的案例，就会发现通常有两种状况比较常见。一种是明细流水性质的表，产生一笔就会新增一条记录，日积月累就会变得很大。这里面大多数都可以用日期时间为顺序和查询依据的，例如账户明细表，传票表等。这类表很明显可以按日期进行划分。超过一定的期限以后，历史的数据就可以清理了，通常历史查询功能由ODS之类的数据仓库系统提供。经过清理后，数据量可以保持稳定。另一种是账户主表，凭证主表，客户信息表等，随着系统多年使用逐渐增长，而且可清理的不多，数据量随业务发展总体呈增长趋势。

    这里我们看看在Firebird系统中巨型表的解决办法。从根本上说，应当将大表分小，并且要适合使用的情景。在开放平台数据库，有分区表的概念，而在400平台，对应的就是*FILE的多MEMBER。对于可按日期划分的表，我们可以带日期为MEMBER名，每日一个MEMBER，预先创建好，无需倒历史切换，解决了7*24小时和数据清理的问题。对于主表，可按主键号码或某些字段hash计算分MEMBER。例如，客户表按客户号的hash分区，凭证表按凭证号的hash分区。但账户表要按账户所属机构号分区，这是为了优化结息批处理性能，利于每个按机构并发的结息程序只访问一个MEMBER。
    400系统对多MEMBER的限制有哪些呢？首先，同一个*FILE支持的MEMBER数量，最大为32767个。按每日分区计算，大约可以支持90年。按hash计算，10亿级别的表hash到100个MEMBER，每个MEMBER仅1000万记录数量。其次，单个MEMBER最多记录数为2^32，大约42亿。但实际上记录数过多，访问操作性能会指数级下降。单个MEMBER内记录数在1000万级别比较合适。最后，对于LF文件的单个MEMBER，能关联PF的MEMBER数量是有限制的，大概是32个，但实