论文部分内容阅读
摘 要：在考虑一个系统的非功能性需求之前通常我们需要了解系统的属性，对数据库系统来说，通常分为联机事务处理（OLTP）和联机分析处理（OLAP）两大类。不同类型系统对容量、性能、可用性、安全有不同的要求。
关键词：数据库;DB2;架构设计;设计规范
一、数据库应用系统的非功能需求。
OLTP系统：典型OLTP系统面向大量并发用户，支持日常业务处理，每个事务通常只涉及少量记录;系统要求响应时间尽量短，在高并发情况下要求一定的事务处理吞吐能力;有的OLTP系统中有批处理的需求，要求在特定的时间窗口内能够完成涉及大量数据的运算;通常OLTP数据库只保留当前数据，数据量在100MB到几个TB之间。
OLAP系统：OLAP系统面向管理、决策层人员，数据来源于OLTP系统，通过抽取、装载、转换的处理过程按不同主题重新组织数据，系统支持复杂查询，在SQL运行时涉及大量数据，数据库保留历史数据，数据量在几百GB到几百TB之间。
（一）容量需求。数据库容量必须保障应用系统在运营期间（三年到五年为一个跨度）满足并支撑相关业务推广发展蓝图的存储空间需求。数据库大小评估是在数据库初始大小（满足应用系统运行的基础数据大小）的基础上根据业务部门制定的业务推广发展蓝图来计算数据库在运营期间（三年到五年为一个跨度）的数据增长后的大小。容量使用方面必须具备灵活分配、均衡利用、循环使用、兼顾性能的特点，精确判断表数据的增长趋势，灵活均衡地放置数据，引入数据生命周期管理循环使用空间、兼顾性能，避免出现表空间利用率不均衡、数据增长带来的性能下降等现象。
（二）性能需求。与数据库性能最相关的指标是响应时间和吞吐量。应用系统在投产前，SQL必须在符合业务推广发展蓝图数据量的环境上经过严格的压力测试，数据库的响应时间和吞吐量必须符合业务要求，且系统负载不能为满负载。
（三）可用性需求。必须考虑到各种应用系统各种不可用性场景（硬件故障、软件故障、操作系统/数据库/应用升级、在线维护、性能问题）及其应对或规避方式，并必须有从不可用场景恢复生产后的完整性、功能性验证步骤。
（四）安全性需求。数据库的安全通过授权、控制、审计来保障。使用授权和认证，要坚持“最小特权”原则，即：只允许用户做他们真正需要做的。注意收回PUBLIC的权限。对敏感数据设置正确的权限和访问控制。用审计及时发现不合规的数据访问。
二、应用架构设计。
（一）逻辑数据模型设计。OLTP系统逻辑数据模型设计必须遵守关系型数据库3范式，OLAP系统遵循星型模型或雪花模型;某些关键数据模型可通过反规式的方式减少复杂性或进行表连接的数目。在做逻辑数据模型设计的时候，首先考虑系统的属性。对于OLTP系统，更多的逻辑设计遵守关系型数据库3范式;对于OLAP系统，通常面向主题采用星型模型或雪花模型，同时数据又是分层存储的，分细节数据、轻度汇总、高度汇总。
（二）交易系统架构设计。交易系统的架构设计中应该采用成熟的商业化交易中间件产品。DB2数据库系统作为整个交易系统的重要组成部分应该提供高可用、高性能、可扩展性等非功能特性。对于运行关键业务的交易系统，在设计中必须采用高可用集群架构。具体包含如下方面：数据库服务器的高可用集群设计、应用服务器的高可用集群设计。
（三）事务设计。对于联机业务，应尽量使事务短小简洁，请遵循如下规则：数据发生改变后尽快提交、在事务中尽量使得访问的记录最小、不要在事务处理期间要求用户输入、在浏览数据时，尽量不要打开事务。对于批量业务，除了需要遵循上述规则外，如果处理的业务笔数比较多，如超过100笔，则应该考虑设计多个事务来完成，而不应该将所有的业务处理都放在一个事务里完成。
（四）应用日志设计。应用日志为应用系统运行时信息，主要用于跟踪、分析应用系统运行状况，请遵循以下规则：同一交易的日志应该连续完整，中间不能穿插其他交易的日志，易于辨别不同交易的日志;日志应该格式化且显示友好，控制日志行宽，避免行宽过长、自动换行，便于分析、定位问题;日志应该包含详细的运行时信息（交易名/子模块名/开始标志/开始时间/结束时间/执行时间/完整SQL信息/存储过程输入输出参数值/完整的错误信息/结束标志）;引入日志分级策略，使之不同嚴重级别的日志存放于不同的日志文件;日志应具备按日志文件大小上限自动归档功能，能根据时间点方便日志定位及管理，避免大文件读写带来的性能问题;实现日志文件的保留删除策略，只保留最近一段时间的日志。
（五）安全设计。严禁使用实例用户作为应用系统的数据库连接用户，应用系统的数据库连接用户应该权限最小化;严禁数据库相关用户的密码与用户名一致、使用默认密码。
三、数据库物理设计。
数据库物理设计是把逻辑模型在物理环境实现的过程。一个好的物理设计应该考虑达成下面目标：最小化IO、均衡设计功能，考虑系统特征，可能需要在事务处理，批处理，查询性能及维护操作之间均衡、满足管理任务性能、使备份恢复时间最小化。具体物理设计需从以下方面入手：表空间设计、选择合适的数据类型、数据生命周期管理、索引设计、表分区设计、日志设计、内存设计、LOB内容存储设计、压缩技术采用等。
四、部署架构。
部署主要按照系统要求的数据库版本，在给定硬件环境中安装并配置数据库运行环境。主要从以下方面考虑：操作系统版本及补丁级别、数据库服务器版本及补丁级别、其它数据库辅助功能部件、数据库客户端或连接驱动（JDBC Driver， ODBC， CLI， .Net Driver）、环境参数、本地高可用方案部署、异地灾备方案部署。
参考文献：
[1]IBM. IBM? Db2 V11.1 Knowledge Center.
作者简介：朱京瑞（1989—），男，汉族，山东临沂市人，工程师，大专，单位：山东省农村信用社联合社，数据库性能优化与实践。
关键词：数据库;DB2;架构设计;设计规范
一、数据库应用系统的非功能需求。
OLTP系统：典型OLTP系统面向大量并发用户，支持日常业务处理，每个事务通常只涉及少量记录;系统要求响应时间尽量短，在高并发情况下要求一定的事务处理吞吐能力;有的OLTP系统中有批处理的需求，要求在特定的时间窗口内能够完成涉及大量数据的运算;通常OLTP数据库只保留当前数据，数据量在100MB到几个TB之间。
OLAP系统：OLAP系统面向管理、决策层人员，数据来源于OLTP系统，通过抽取、装载、转换的处理过程按不同主题重新组织数据，系统支持复杂查询，在SQL运行时涉及大量数据，数据库保留历史数据，数据量在几百GB到几百TB之间。
（一）容量需求。数据库容量必须保障应用系统在运营期间（三年到五年为一个跨度）满足并支撑相关业务推广发展蓝图的存储空间需求。数据库大小评估是在数据库初始大小（满足应用系统运行的基础数据大小）的基础上根据业务部门制定的业务推广发展蓝图来计算数据库在运营期间（三年到五年为一个跨度）的数据增长后的大小。容量使用方面必须具备灵活分配、均衡利用、循环使用、兼顾性能的特点，精确判断表数据的增长趋势，灵活均衡地放置数据，引入数据生命周期管理循环使用空间、兼顾性能，避免出现表空间利用率不均衡、数据增长带来的性能下降等现象。
（二）性能需求。与数据库性能最相关的指标是响应时间和吞吐量。应用系统在投产前，SQL必须在符合业务推广发展蓝图数据量的环境上经过严格的压力测试，数据库的响应时间和吞吐量必须符合业务要求，且系统负载不能为满负载。
（三）可用性需求。必须考虑到各种应用系统各种不可用性场景（硬件故障、软件故障、操作系统/数据库/应用升级、在线维护、性能问题）及其应对或规避方式，并必须有从不可用场景恢复生产后的完整性、功能性验证步骤。
（四）安全性需求。数据库的安全通过授权、控制、审计来保障。使用授权和认证，要坚持“最小特权”原则，即：只允许用户做他们真正需要做的。注意收回PUBLIC的权限。对敏感数据设置正确的权限和访问控制。用审计及时发现不合规的数据访问。
二、应用架构设计。
（一）逻辑数据模型设计。OLTP系统逻辑数据模型设计必须遵守关系型数据库3范式，OLAP系统遵循星型模型或雪花模型;某些关键数据模型可通过反规式的方式减少复杂性或进行表连接的数目。在做逻辑数据模型设计的时候，首先考虑系统的属性。对于OLTP系统，更多的逻辑设计遵守关系型数据库3范式;对于OLAP系统，通常面向主题采用星型模型或雪花模型，同时数据又是分层存储的，分细节数据、轻度汇总、高度汇总。
（二）交易系统架构设计。交易系统的架构设计中应该采用成熟的商业化交易中间件产品。DB2数据库系统作为整个交易系统的重要组成部分应该提供高可用、高性能、可扩展性等非功能特性。对于运行关键业务的交易系统，在设计中必须采用高可用集群架构。具体包含如下方面：数据库服务器的高可用集群设计、应用服务器的高可用集群设计。
（三）事务设计。对于联机业务，应尽量使事务短小简洁，请遵循如下规则：数据发生改变后尽快提交、在事务中尽量使得访问的记录最小、不要在事务处理期间要求用户输入、在浏览数据时，尽量不要打开事务。对于批量业务，除了需要遵循上述规则外，如果处理的业务笔数比较多，如超过100笔，则应该考虑设计多个事务来完成，而不应该将所有的业务处理都放在一个事务里完成。
（四）应用日志设计。应用日志为应用系统运行时信息，主要用于跟踪、分析应用系统运行状况，请遵循以下规则：同一交易的日志应该连续完整，中间不能穿插其他交易的日志，易于辨别不同交易的日志;日志应该格式化且显示友好，控制日志行宽，避免行宽过长、自动换行，便于分析、定位问题;日志应该包含详细的运行时信息（交易名/子模块名/开始标志/开始时间/结束时间/执行时间/完整SQL信息/存储过程输入输出参数值/完整的错误信息/结束标志）;引入日志分级策略，使之不同嚴重级别的日志存放于不同的日志文件;日志应具备按日志文件大小上限自动归档功能，能根据时间点方便日志定位及管理，避免大文件读写带来的性能问题;实现日志文件的保留删除策略，只保留最近一段时间的日志。
（五）安全设计。严禁使用实例用户作为应用系统的数据库连接用户，应用系统的数据库连接用户应该权限最小化;严禁数据库相关用户的密码与用户名一致、使用默认密码。
三、数据库物理设计。
数据库物理设计是把逻辑模型在物理环境实现的过程。一个好的物理设计应该考虑达成下面目标：最小化IO、均衡设计功能，考虑系统特征，可能需要在事务处理，批处理，查询性能及维护操作之间均衡、满足管理任务性能、使备份恢复时间最小化。具体物理设计需从以下方面入手：表空间设计、选择合适的数据类型、数据生命周期管理、索引设计、表分区设计、日志设计、内存设计、LOB内容存储设计、压缩技术采用等。
四、部署架构。
部署主要按照系统要求的数据库版本，在给定硬件环境中安装并配置数据库运行环境。主要从以下方面考虑：操作系统版本及补丁级别、数据库服务器版本及补丁级别、其它数据库辅助功能部件、数据库客户端或连接驱动（JDBC Driver， ODBC， CLI， .Net Driver）、环境参数、本地高可用方案部署、异地灾备方案部署。
参考文献：
[1]IBM. IBM? Db2 V11.1 Knowledge Center.
作者简介：朱京瑞（1989—），男，汉族，山东临沂市人，工程师，大专，单位：山东省农村信用社联合社，数据库性能优化与实践。