数据中心系统性能设计方案

1、数据中心系统性能设计方案市场监管数据中心及管理决策系统工程应用系统开发项目投标方案 项目编号：0702-0941CITC2902- PAGE I-目 录 TOC o 1-3 h z u HYPERLINK l _Toc56975971 第1章 数据中心设计 PAGEREF _Toc56975971 h 2 HYPERLINK l _Toc56975972 1.1. 设计原则 PAGEREF _Toc56975972 h 2 HYPERLINK l _Toc56975973 1.2. 设计策略 PAGEREF _Toc56975973 h 4 HYPERLINK l _Toc56975974 1

2、.3. 数据库设计方法论 PAGEREF _Toc56975974 h 7 HYPERLINK l _Toc56975975 1.4. 数据库总体架构 PAGEREF _Toc56975975 h 10 HYPERLINK l _Toc56975976 第2章 系统性能设计 PAGEREF _Toc56975976 h 13 HYPERLINK l _Toc56975977 2.1. 性能承诺 PAGEREF _Toc56975977 h 14 HYPERLINK l _Toc56975978 2.2. 设计原则 PAGEREF _Toc56975978 h 15 HYPERLINK l _T

3、oc56975979 2.3. 总体设计 PAGEREF _Toc56975979 h 15 HYPERLINK l _Toc56975980 2.4. 性能优化过程管理 PAGEREF _Toc56975980 h 17 HYPERLINK l _Toc56975981 2.5. 系统性能优化方案 PAGEREF _Toc56975981 h 20 HYPERLINK l _Toc56975982 2.5.1. 应用系统架构性能优化 PAGEREF _Toc56975982 h 20 HYPERLINK l _Toc56975983 2.5.2. 数据库性能优化 PAGEREF _Toc56

4、975983 h 24 HYPERLINK l _Toc56975984 2.5.3. 应用服务器性能优化 PAGEREF _Toc56975984 h 30 HYPERLINK l _Toc56975985 2.5.4. 操作系统性能优化 PAGEREF _Toc56975985 h 34 HYPERLINK l _Toc56975986 2.5.5. 主机性能优化 PAGEREF _Toc56975986 h 38 HYPERLINK l _Toc56975987 2.6. 系统存储能力设计 PAGEREF _Toc56975987 h 40 HYPERLINK l _Toc5697598

5、8 2.7. 网络带宽设计 PAGEREF _Toc56975988 h 41数据中心设计数据中心应用系统开发项目数据架构设计依据数据中心数据中心信息资源规划框架，进行应用系统业务数据库与数据中心数据库的设计（EDW数据平台）。对于新建应用系统，根据信息资源规划框架设计应用系统业务数据库；遵从数据中心数据库设计方案设计数据中心数据库，在设计阶段与配合共同进行数据中心数据库的规划工作，创建数据库库表结构并加载数据；在项目建设阶段与配合，在的指导下对数据中心数据库设计方案进行细化与扩充，与共同完成方案的设计工作，并在应用集成成的指导和配合下完成数据中心数据库的建设工作。市场监管局数据中心业务涉及登

6、记许可、市场监管、执法办案、公共服务、政务管理等系统业务，根据本项目的建设目标建设业务子系统，并对原有业务系统数据库进行数据整合与集成，在数据层面分为两个部分：应用系统业务数据库、数据中心数据库；应用系统业务数据库为支撑各数据中心业务系统业务办理的数据库，存储原始业务明细数据，是数据中心数据库分析主题的数据来源；以EDW（操作性数据存储）核心理念为指导构建数据中心数据库（EDW数据平台），业务系统将原始业务明细数据推送入数据中心数据库中，在这个过程中对原始业务信息进行抽取，整合，转换及加载，供数据中心数据库进行数据的加工与汇总，数据中心数据库对原始业务数据进行轻度汇总，形成分析主题，通过对数据

7、中心业务的理解与分析，构建适合数据中心的业务规则模型，为应用系统提供数据中心规则数据服务；数据中心数据库汇集市场主体数据以及知识信息，使市场监管局能够对企业信息进行分析与汇总统计，实现对中企业业的监管，并为市场监管提供了依据。设计原则数据中心应用系统开发项目数据库设计将遵照数据中心数据中心信息资源规划，并按照数据中心数据库设计方案的总体框架，进行数据库的设计与开发。数据库设计主要遵循如下原则：1.完整性原则本项数据库设计遵循完整性原则，防止合法用户使用数据库时向数据库加入不合语义的数据。对输入到数据库中的数据进行审核，并建立约束机制；在系统建设过程中，依据标准先行的原则，先建立数据元，然后根据

8、数据元约束条件在程序中进行完整性检验。通过建立一致的完整性原则，保证数据的正确性和相容性。2.安全性原则本项目数据库设计依据安全性原则，将充分考虑到数据安全性，实现不同权限的用户看到的数据是存在差异的，通过制定对数据库的各类操作的标准，建立具有统一的管理和控制功能，如，即使是系统管理员也无法知道用户的口令，因此无法以用户的身份进行登录。达到保护数据，防止非法用户使用数据库或合法用户非法使用数据库造成数据泄露、更改或破坏。3.经济与实用性原则数据库设计以追求实用性为原则，切合市场监管局网络建设的实际情况，充分考虑系统的实用性，在保证系统能够安全、可靠运行的前提下，做到与现有的业务系统的最大限度的

9、兼容，并且充分利用资源，最大限度地降低系统造价，保护计算机设备及应用系统的投资。系统具有较高的性能价格比，不盲目追求不实用的技术，以经济实用为主。同时，在设计和策划过程中作到统一规划，避免不必要的投资。充分考虑到系统的可扩充性，避免重复投资。4.先进性原则系统设计将采用先进的、成熟的且可持续发展的技术方法，并充分体现先进的管理思想和理念。保证系统联机查询响应时间在秒级以内。5.统一管理原则由于整个系统是一个较为复杂的系统，依据统一管理原则，提供的系统具有简单、直观、方便的维护和管理手段，尽量减少维护和管理环节，使系统具有良好的可管理性和可维护性，制定对数据库的各类操作的标准，具有统一的管理和控

10、制功能。6.开放、扩展性原则使用广泛、先进、成熟的标准和协议，并使整体具有良好的开放性，以便以后能方便、简单地进行维护和升级。遵循国际标准，支持多种网络协议，提供开放的数据接口，实现系统间互连。支持各种硬件平台、不同操作系统和数据库管理系统。7.高可用性原则数据库设计依据高可用性原则，任何一个运行应用的主机发生故障时，该应用系统能够在保证数据不丢失的情况下自动切换到其他主机上运行，即做到集群功能，保证应用及数据中心的高可用性，8.满足行业要求将符合市场监管局已经制订的相关方针和政策的原则、符合市场监管局的业务模式和管理模式的原则、符合经济实用并适度超前的原则、符合信息集成和信息共享的原则。设计

11、策略采用关系数据模型进行设计，设计阶段消除实体关系模型中的命名冲突、属性冲突和结构冲突； 关系模式规范化，数据表结构设计合理，通过对关系模式的分解，消除冗余属性和冗余联系，达到3NF或BCNF；数据库的设计范式是数据库设计所需要满足的规范，满足这些规范的数据库简洁、结构明晰，同时，不会发生插入（insert）、删除（delete）和更新（update）操作异常。反之则是杂乱无章的，不仅给数据库的编程人员制造麻烦，而且难于维护，可能存储了大量不需要的冗余信息。对存储效率和处理效率有特殊要求的部分关系模式，可适当增加部分冗余，以避免过分分解使数据库系统性能变坏；应通过下列措施实现数据完整性：1通过

12、主键定义确保数据库表中每一行是唯一的，实现实体完整性；2通过主外键关系的定义实现引用完整性；3通过属性值的约束保证字段值合法有效，实现域完整性；4通过约束、限制、缺省、规则、存储过程等保证数据库的完整性。5对于经常访问的数据库表应建立索引，以提高访问效率；6常用业务查询尽量避免跨库检索；7数据结构应具有适应性和可扩展性，系统验收移交后应避免修改数据库结构。在进行数据库设计时，需要对数据库索引进行规划与设计，使用索引可快速访问数据库表中的特定信息。索引是对数据库表中一列或多列的值进行排序的一种结构。在进行数据查询时索引会帮助您更快地获得该信息，提高系统性能。所以数据库索引的设计至关重要，需要遵循

13、如下原则：1.在尽量少的占用资源的同时，采用索引来提高系统性能数据库管理员若要采用索引来提高系统的性能，需要考虑占用系统资源的大小。数据库管理员要考虑的就是如何在这两个之间取得一个均衡，找到一个回报与投入的临界点。2. 对于查询中很少涉及的列或者重复值比较多的列，不建立索引在查询的时候，如果无需对某个字段去查询，则不在这个字段上建立索引。因为，即使在这个字段上建立索引，也不能够提高查询的速度。相反，增加了系统维护时间和占用了系统空间。另外，有些字段重复值比较多。如性别字段主要就是“男”、“女”;职位字段中也是有限的几个内容。此时，在这些字段上添加索引也不会显著的增加查询速度，减少用户响应时间。

14、相反，因为需要占用空间，反而会降低数据库的整体性能。3. 对于按范围查询的列，建立索引在信息化管理系统中，很多时候需要按范围来查询。对于这些需要在指定范围内快速或者频繁查询的数据列，需要为其建立索引。因为索引已经排序，其保存的时候指定的范围是连续的，查询可以利用索引的排序，加快查询时间，减少用户等待时间。4. 表中若有主键或者外键，一定要为其建立索引定义有主键的索引列，一定要为其建立索引。主键可以加速定位到表中的某一行。结合索引的作用，可以使得查询的速度加倍。另外，若要使得某个字段的值唯一，可以通过两种索引方式实现。一种就是上面所提到的的主键索引。还有一种就是唯一索引，利用UNIQUE关键字指

15、定字段内容的唯一性。这两种方式都会在表中的指定列上自动创建唯一索引。若某张表中的数据列定义有外键，则最好也要为这个字段建立索引。外键的主要作用就在于表与表之间的连接查询。若在外键上建立索引，可以加速表与表之间的连接查询。5.对于一些特殊的数据类型，不建立索引数据库表中的特殊字段。如文本字段(TXT)、图像类型字段(IMAGE)等。如果表中的字段属于这些数据类型，则不为其建立索引。数据库设计方法论市场监管局一期应用系统开发项目中数据纷繁复杂，需要对数据中心业务进行合理、科学的数据架构设计，本次项目中数据中心业务涉及到登记许可、市场监管、执法办案、政务管理、公共服务块，36个业务条线，通过对业务处

16、理过程中各类数据资源进行分析，并采用我公司先进的数据架构方法，将数据架构分为：数据建模、数据存储、数据交换、数据访问四个方面，并且提供对全过程数据的数据管理体系。数据架构方法论一数据建模层数据模型主要包括数据中心业务中整体数据模型、概念数据模型、逻辑数据模型、物理数据模型以及数据分析、挖掘和数据装载接口规范等。针对数据中心应用系统开发项目中涉及到的数据可从结构化数据与非结构化数据两方面分析。针对结构化数据首先对数据中心所有结构化数据进行分类，从数据中心业务实际出发，同时结合本次项目建设的内容，将数据中心机构化数据分为：基础数据、事物型数据、监管数据、统计分析型数据四类，在对数据分类的基础上设计

17、市场监管局整体数据模型，从不同的视点出发，对数据中心数据的需求和数据之间关系进行抽象，同时结合数据中心业务，形成数据中心整体数据模型。针对市场监管局业务处理过程中涉及到的非结构化数据，采用将分散的数据和信息，进行整理和加工，将非结构化数据分类，形成目录管理，最终达到数据共享的目标。二数据使用数据的使用主要关注根据数据中心业务的需求与招标文件中的功能需求，合理、科学的规划数据，建立监管模型，并通过数据封装与数据交换，将数据提供各应用系统进行日常业务办理与日常统计分析。数据中心应用系统开发项目中涉及的数据主要分为两个层面，一个层面是36个业务条线进行日常业务办理所需的业务数据，36个业务条线在业务

18、办理过程中都有支撑各自应用的业务数据库，日常业务办理的数据存储在业务数据库中；另一个层面是支撑业务系统进行日常统计分析应用的数据，这些数据来源于对业务数据库的抽取与转换加工，数据中心日常统计分析类应用包括对数据的查询分析、多维分析、统计报表、预警监测等应用。三数据存储数据中心业务系统开发项目数据库部分包括业务数据库、数据整合库、数据仓库数据库，此三种数据库满足数据中心应用系统开发项目的需求，同时能够更好的与数据中心对接并进行数据交换。业务数据库主要承担数据中心36个业务条线的日常业务办理业务流程类数据的存储工作，包括：审核、审批、上报、数据收集、更新等与业务密切相关的应用数据，业务数据库承载的

19、数据也是数据中心其他数据的基础来源。数据整合库与数据仓库数据库主要采用EDW的设计理念，按基础主题集成了跨系统的当前和近期明细操作数据。为各系统提供一个实时或准实时的一致的数据共享平台和同步机制，支持业务办理日常操作（特别是跨系统的复杂业务流程）以及近期的分析和统计。EDW和各个交易系统之间都可能存在单向或双向的实时/准实时数据同步，和数据仓库之间也可能存在单向或双向的数据流动。四数据交换针对数据中心应用系统开发项目，数据交换基于两个层面，第一层面是业务系统中，各业务数据库中的数据在业务系统间进行数据交换，实现信息共享。第二层面是将业务数据库中的基础业务数据进行整合、汇总形成面向主题的数据，集

20、中存储到数据中心数据库，并以接口方式向各业务系统提供数据服务，支撑日常统计分析类应用。五数据管理在任何信息系统中，数据是不断变化的，因此数据必需得到有效地管理，能够及时地反映整体信息系统环境的变化。数据管理包括技术手段和管控手段，针对数据中心应用系统开发项目，我们要从数据采集、基础数据整合、数据交换等方面为数据中心数据提供全过程管控的技术手段和管控手段。从技术上重视数据采集后对数据准确性、实时性、合理性等一系列的技术校验，同时重视元数据管理，通过元数据技术保障信息系统特别是数据应用各个环节的设计、构建和运行质量。管控方面应该建立专门的组织和统一的流程、标准，保障数据的准确性、完整性和一致性。数

21、据库总体架构数据中心应用系统开发项目数据库遵照数据中心数据库设计方案总体框架，与配合共同规划数据中心数据库。本项目数据中心应用系统数据库是面向市场监管局所有应用系统和信息发布系统进行数据处理和存储的基础载体，基于数据中心的总体框架，构建综合数据服务体系，是市场监管局局内各处室之间以及与其它政府机关之间进行数据交换和共享的基础平台，为各类业务的开展提供完整、统一和准确的数据支持。数据库设计总体架构图如下图所示：根据数据中心业务需求，应用系统建设涵盖登记许可、市场监管、执法办案、公共服务、政务管理等系统业务涉及36个业务条线，数据库总体架构遵照信息资源规划与数据中心的总体框架，按照数据中心数据库设

22、计方案进行设计，基于数据综合服务体系构建以数据中心数据库为核心的EDW数据平台，遵循应用集成所指定的数据采集与交换体系，实现新旧系统间的信息共享与交换，支撑数据中心日常统计分析业务。实现对基础数据的统一管理，利用数据中心基础数据库为数据中心数据库提供数据服务管理。一应用系统业务数据库业务数据库主要为业务系统进行日常业务处理操作提供基础业务数据支撑，通过采集系统接收并存储由区级市场监管局、其他政府机构上报的业务数据，业务数据库包括：市场监管局产品质量监督管理信息系统、信用分类监管系统、网格监管系统、认证监管系统、维修行业监管系统、市场食品准入监管系统、食品安全日常监管系统、食品安全抽样检验系统、

23、大运会食品安全保障系统、流通环节食品安全追溯系统、舆情分析系统、数字工商电子地图监管系统、商品交易市场信用分类监管系统、广告监测系统、特种设备电子监管信息系统、特种设备安全监察系统、特种设备检验业务管理系统、电梯部件型式试验管理系统、检测校验管理系统、商标预警及服务系统、咨询举报申诉平台、案件管理系统、财产管理软件、财政综合业务系统（资产管理系统）、依申请公开预警系统、办公自动化系统、廉政风险防控系统、行政审批电子监察系统、绩效评估与管理系统、人事培训系统、人事信息管理系统、用户管理系统、统计报表系统、IT运维管理系统、法律法规查询系统的业务数据库；以及本次项目需要新建的登记许可系统、市场监管

24、系统、执法办案系统、政务管理系统、公共服务系统五个系统的业务数据库。二数据中心数据库（EDW数据平台）应用系统业务数据库中的原始业务明细数据根据数据中心业务需要，将数据中心数据库所需的业务明细数据推送入数据中心数据库中，根据数据中心数据交换体系，结合数据交换平台总体框架，构建信息服务总线（ISB），ISB根据数据中心数据库数据的需要将业务数据库推送的数据进行抽取、加工与转换，统一数据口径，为数据中心数据库提供数据基础。数据中心数据库包括原始业务数据整合域、主题数据域两部分1原始业务数据整合域原始业务数据整合域主要针对数据中心业务数据库，将数据中心业务明细数据进行抽取与转换加工。基础数据整合层首

25、先将业务数据库按照数据中心数据库需求推送的业务明细数据进行抽取，存放数据中心业务系统产生的业务明细数据，包括：登记许可、市场监管、执法办案、政务管理、公共服务的业务处理过程数据，主要是源系统的增量数据，数据结构贴近源系统的结构，并且数据存储上只作暂时性保存；其次对抽取的明细业务数据进行转换、加工，对数据进行标准化处理，主要有公共代码标准化、数据类型标准化和数据格式标准化，消除各个源系统在信息表达上的差异，为后续的数据整合和应用整合提供标准化基础。例如对企业代码与名称的统一标准等； 原始业务数据整合流程为：第一步对数据的整合将原始业务明细数据抽取入数据中心数据库；第二步通过进行数据标准化对业务系

26、统抽取过来的明细业务数据进行数据口径的统一与整合；第三步将加工过程中的脏数据进行清理，最后将加工后的原始业务明细数据加载入整合数据库中。2主题数据域主题数据域将原始业务数据进行主题划分，对业务明细数据进行汇总，形成各分析主题，支撑数据中心日常统计分析应用。在进行主题划分之前对数据中心业务进行理解与分析，分析数据中心业务逻辑与支撑数据，进行业务建模，按各业务类型分为主题数据库，服务于数据中心五大业务链的数据多维分析、数据统计、数据挖掘等应用，数据中心数据库包括：市场主体信息主题库、商标主题库、广告主题库、食品主题库、知识产权主题库、年检主题库、信用主题库、投诉主题库、案管主题库、其他业务数据库。

27、主题数据域包括主题数据库、基础数据库、监管规则库三个部分。（1）基础数据库基础数据库提供数据中心数据库中所需的指标与代码，主要包括指标库与代码库，在数据中心应用系统开发项目中，基础数据库设计符合数据中心的总体框架，遵照数据中心信息资源规划设计，基于数据中心指标体系与代码体系，进行指标库与代码库的建设，是对数据中心指标、代码的细化与扩充，这里的基础数据库中的指标库和代码库作为数据中心基础数据库的子集，为数据中心基础数据库的一部分，服务于数据中心数据库并为数据中心基础数据库进行细化与扩充。（2）共享交换主题库数据中心数据中心数据库数据封装是为市场监管局各业务系统提供数据传输接口，将监管数据传送给业

28、务系统日常统计分析应用。市场监管局业务系统在业务办理时业务办理数据存储在各业务数据库中，通过数据抽取进入数据中心数据中心数据库，并对业务明细数据进行加工、汇总等，将加工汇总后形成数据中心统计分析业务需要的监管数据通过数据封装接口实现业务系统与数据中心数据库的数据交换，同时也通过接口为数据中心数据中心提供业务分析类数据，为数据中心决策系统提供数据支撑。（3）主题数据库按主题对各业务系统的关键基础数据进行整合、归类、汇总，再进行存储，数据来源于基础数据整合库，为数据中心日常统计分析类应用提供汇总分析数据。主题数据库存储多个应用相同的汇总数据或者多个应用汇总计算的结果。有重复汇总的数据可以纳入该区域

29、进行汇总，形成应用共享的汇总结果。主题数据库针对应用的需求，将应用需求进行统一分析，提炼出相同的指标，根据这些指标建立汇总中间表，为数据中心业务系统日常分析类应用提供便利，根据数据中心业务需求，对主题数据库进行主题划分，共分为主题数据库，分别为：市场主体信息主题库、商标主题库、广告主题库、食品主题库、知识产权主题库、年检主题库、信用主题库、投诉主题库、案管主题库、其他业务数据库。根据数据中心分析业务需要，并依托监管规则库中的数据中心模型，从各主题域中产生监管数据，如：统计分析数据、预警数据、多维查询数据、报表数据等，服务于业务系统的分析类应用。数据接口层：数据接口层将监管数据进行封装，并通过多

30、种方式将监管数据提供给数据中心各业务系统，主要方式包括：数据视图、应用接口、数据文件等。通过将准备好的数据存放在数据接口层，以便让数据交换平台交换出去。系统性能设计数据中心项目应用系统承载着市场监管局核心业务，涵盖市场五大业务链，系统同时面向场监管局、区级市场监管局，具有用户面广、量大的特点，所以项目建设过程中对系统稳定性有着很高的要求，系统的性能设计也是整个设计方案的一个挑战。本设计方案从数据中心应用系统的性能要求出发，基于对应用集成成项目总体架构规划及产品选型的充分理解，从应用系统架构、应用服务器、数据库、操作系统等层面进行性能设计，并提出系统运维过程中性能优化方案，保证业务系统性能的持续

31、改进，适应数据中心业务的不断发展。在应用系统架构层面，基于应用支撑平台的分层架构，提升系统扩展能力。开发过程注重数据结构优化，选择良好算法，促进代码性能优化。利用缓存技术减少数据访问，提高资源重复利用率，从而降低业务操作对系统所带来的压力。采用异步处理方式缩短系统交互过程，提高系统访问效率。通过文件系统优化减少文件的频繁操作。系统采用分布式部署方案，提高系统吞吐能力，支持更多用户访问。在应用服务器层面，通过合理设置堆的大小和垃圾回收设置，提高JVM的处理性能。通过为应用系统配置线程池、数据库连接池，实现应用服务器资源重复利用，满足应用负载。通过应用服务器支持的负载均衡能力，实现应用系统扩展，提

32、高系统处理能力。通过应用服务器的语句缓存，减少数据访问，降低系统压力。在数据库层面，对数据库配置参数进行针对性调整，减少各种等待事件；采用反范式设计库表，库表结构设计适当冗余，提高数据表访问速度；合理分配数据文件物理存储，以减少磁盘 I/O 竞争；对数据库表与索引进行有效地重组，以获得更优的查询效率；合理使用SQL 语句，提高应用的响应时间。在操作系统层面，根据预期的性能指标进行操作系统参数预设，系统运行过程中进行日常性能管理。跟踪并提取系统各项性能指标，根据指标值判断系统当前运行状态。对于出现操作系统性能瓶颈的将通过调整系统参数或者增加硬件加以解决。性能承诺1一般数据查询响应时间小于3秒，简

33、单汇总处理时间小于1分钟，固定指标时间小于10秒。2各个信息资源共享数据库分别支持超过20-100个用户的并发访问能力。3系统运行高效、可靠。在各应用系统中建立便捷和快速连接，能够进行高效和可靠的数据交换。设计原则1可靠性系统的可靠性指系统硬件和软件在运行过程中抵抗异常情况的干扰及保证系统正常工作的能力。系统的设计采用的N层架构，可以在应用层、数据层等各层实现负载均衡，保证系统运行稳定，并提供可靠的灾难性恢复和数据备份的措施，保障系统可靠性。2先进性系统架构应采用符合发展趋势的主流技术，技术先进并趋于成熟，系统建设基于优质开发和应用平台；3可持续改进系统性能优化是个系统的工程，贯穿系统的设计、

34、开发、运行全过程，可通过系统扩展提升性能，满足系统用户规模的扩大、业务量的增长。总体设计本项目的性能设计涵盖应用系统架构、应用服务器、数据库、操作系统等多个层面，设计过程分别从这几个层面提出性能优化方案。性能设计总体架构图在应用系统架构层面，基于应用支撑平台的分层架构，提升系统扩展能力。开发过程注重数据结构优化，选择良好算法，促进代码性能优化。利用缓存技术减少数据访问，提高资源重复利用率，从而降低业务操作对系统所带来的压力。采用异步处理方式缩短系统交互过程，提高系统访问效率。通过文件系统优化减少文件的频繁操作。系统采用分布式部署方案，提高系统吞吐能力，支持更多用户访问。在应用服务器层面，通过合

35、理设置堆的大小和垃圾回收设置，提高JVM的处理性能。通过为应用系统配置线程池、数据库连接池，实现应用服务器资源重复利用，满足应用负载。通过应用服务器支持的负载均衡能力，实现应用系统扩展，提高系统处理能力。通过应用服务器的语句缓存，减少数据访问，降低系统压力。在数据库层面，对数据库配置参数进行针对性调整，减少各种等待事件；采用反范式设计库表，库表结构设计适当冗余，提高数据表访问速度；合理分配数据文件物理存储，以减少磁盘 I/O 竞争；对数据库表与索引进行有效地重组，以获得更优的查询效率；合理使用SQL 语句，提高应用的响应时间。在操作系统层面，根据预期的性能指标进行操作系统参数预设，系统运行过程

36、中进行日常性能管理。跟踪并提取系统各项性能指标，根据指标值判断系统当前运行状态。对于出现操作系统性能瓶颈的将通过调整系统参数或者增加硬件加以解决。性能优化过程管理数据中心应用系统性能管理是一个系统的工程，涉及主机、存储、操作系统、数据库、网络、应用服务器、应用程序等环节，以上各环节彼此关联影响，系统优化需充分考虑各环节，综合平衡各方面性能。此外，性能管理中的优化工作又是一个动态、持续改进的过程，需要经过递归分析、优化、测试，以求获得最优系统。根据我们公司以往的性能管理经验，性能管理是由容量规划、测试、调优和监控四个环节组成的闭环流程。性能优化过程管理示意图一容量规划根据给定的指标（通常是应用系

37、统的响应时间设计要求），选择合适的系统架构和平台。容量规划通常要基于工具软件进行，一般流程是首先确定架构并进行建模，设置好平台的参数（服务器型号，广域网带宽，软件），接着工具软件可以计算出在该模型下某个业务流程的系统响应时间，通过和系统性能需求指标进行对比，对平台参数相应调整，使得响应时间满足系统的设计要求。容量规划最大的好处是摆脱了项目架构和设备选择中的“拍脑袋”，做到了用数字说话，避免了不必要的资源浪费。 二测试测试特别是性能测试是验证系统性能的一个重要手段，不管是在系统设计期间还是在系统运行期间的调优都可以通过性能测试发现系统的瓶颈，从而有针对性的对各系统参数作出调整，并最终达到所需要的

38、性能指标。以下是性能测试的示意图：性能测试示意图三调优由于测试通常是在实验环境下进行的，跟实际生产环境还是有很大的区别，所以在应用系统上线过程中，我们还需要根据实际情况对系统进行微调，也就是调优。与测试阶段不同的是我们面对的是生产系统，所以调优往往是加一点点的压力，同时监控后台的性能，找出系统的性能瓶颈，在解决完这个瓶颈后，继续寻找下一个，直到性能达到预定目标。四性能监控典型的IT性能监控系统如下：IT性能监控系统架构图管理中心：解决管理者关心的问题，如服务水平、业务可用性、系统可用性、报表等。技术中心：在充分收集性能数据的基础上，分析系统的性能瓶颈，进行定位，专家系统可以给出系统调整的建议，

39、并通过调优实现性能的提升。在这里面，还有个很重要的是用户行为的仿真（或称业务流程的仿真），它的基本原理是通过脚本录制工具录制典型的业务流程，通过对脚本的回放，取得如响应时间等用户体验数据，一方面可以直接评测出应用的实际使用状态，另一方面通过与服务等级管理相结合，评测出整个应用系统的性能和可用性等。性能指标数据库：主要是收集IT系统各个构件的性能参数。系统性能优化方案应用系统架构性能优化系统架构是一个软件系统中的核心元素，是系统中最难改变的部分，也是构建软件系统中其他部分所依赖的基础，因此系统架构的好坏会从根本上决定基于这个架构所构建的软件系统的质量。系统架构的是应用系统开发过程中的一项重要工作

40、，同时也是一项很困难的工作，架构设计实际是一个平衡设计，在可用性、可扩展性、可维护性、可靠性、高性能等之间做个妥协选择。单就性能设计来说，在架构设计初期就一定要把系统性能考虑在内，以避免开发完成后才发现系统存在性能问题，项目后期发现性能问题就要耗费大量时间进行性能瓶颈诊断，为了提升性能可能需要修改架构并涉及大量代码修改，所以在项目初期就应着手系统性能设计。根据以往的系统架构性能设计经验，影响系统性能主要瓶颈在I/O，包括数据库，Socket，网络通信，文件等。在I/O设计方面，应考虑响应一个事务过程需要经过的往返次数、I/O层次，为提高性能需合理分配这些I/O的调用，降低不必要的I/O。另外，

41、CPU时间也是影响系统性能的一个重要因素，比如要避免频繁查询数据库并返回大量结果集，频繁操作大文件等，因为这些操作会占用大量的CPU时间。有些性能问题在初期并不会表现出来，但当拿到实际上线环境下，存在多用户并发、大数据量的情况下就会暴露出严重的问题。所以进行性能设计的时候这些情况都应该考虑在内，除了上述提到的I/O操作，CPU时间，性能设计还应该考虑数据库设计、数据结构、算法设计、同步、并发、资源争用等因素，并尽可能避免对低效资源的调用。为了提高系统架构的性能表现，具体可以的设计策略有：一数据结构与算法设计1尽量采用整数类型 整数是最常用的数据类型，在运算字符串变量时计算机先把字符串中的每一个

42、字符逐一转换为整数，然后再对每一个整数分别进行运算。计算机软件处理整数的效率要比处理字符串快2倍，其中是字符串中字符的个数。 所以，在设计表结构时，一些计算时频繁用到的字段，如分支机构代码、系统用户代码、客户代码等，应尽量采用整数类型。 2少用可变长字符串 对少于或等于30个字节的字段，应避免使用可变长字符串（Varchar）数据类型。在这种情况下，Varchar类型通常会浪费空间，所以建议使用Char 类型。如果数据量很大，空间的浪费往往会对查询时间造成影响。 3数据模型 为了减少数据冗余，数据建模时一般都需要规格化达到第三范式，如果需要冗余也是因为外键关系和数据引用完整性的需要。适当的非规

43、格化虽然需要占用更多的空间，但通过减少频繁的连接、聚集和推导可以提高数据查询的性能。例如，客户经理号与客户经理名，客户经理名依赖客户经理号，如果在客户经理业绩表中仅有客户经理号，在查询客户经理业绩时就需要做表的关联，从而降低查询响应速度。非规格化以数据更新和数据空间的损失为代价换取数据访问的优化。一般的非规格化形式有：列复制，创建数据阵列，预连接表，预聚集数据。4算法设计 良好的算法，对提高性能有很大的帮助。对于一个业务功能，可以用多种算法去实现，因此应该评估每种算法的执行效率，从而选择最优算法。 这里说一下排序。是排序，就要耗费资源，所以应尽量减少排序，避免不必要的排序，简化排序。可以将数据

44、放在临时表中以避免排序，减少所需排序的行数，用简单关键字排序，排序较少或较小的列，以简化排序。 如果要排序应尽量使用内排序，避免使用外排序。外排序和内排序相比较要慢很多，而且磁盘排序会消耗临时表空间中的资源。二缓存缓存的使用是为了减少数据访问，提高资源重复利用率，从而降低业务操作对系统所带来的压力。市场监管局本期项目架构设计将符合SOA设计理念，采用基于SOA的组件化开发框架和基于J2EE的多层体系架构。在总体架构的各个层次都可以引入缓存技术。如下图所示：在上图中web层、应用层、服务层、数据层所对应的1、2、3、45节点都考虑增加缓存。在1这个位置采用缓存，通常采用Apache相关的缓存扩展

45、。在2、3、4这些位置采用缓存，可以使用本地缓存，或者远程缓存。例如：ehcache、Memcached等。在5这个位置，可以通过增加服务器内存，调整数据库缓存；或者通过数据库伸缩性实现性能提升。每个位置缓存的内容如下所示：在2这个位置，可以缓存web页面，业务数据对象等。在3这个位置，可以缓存业务数据对象、服务相关配置信息、路由规则、消息数据等。在4这个位置，可以实现通用数据访问层，实现统一数据源查询，业务数据对象可以缓存起来。具体在那一层实施缓存以提高性能，需要依据自身系统的特点来实施。以内容为主的系统，考虑在1，2处采用缓存；以业务为主的系统，考虑位置2、3、4、5处采用缓存；采用SOA

46、架构的业务，考虑位置3、4、5处采用缓存，如果数据库存在切分，多源的情况，可适当倾向位置3，4 。三多线程(multi-threading)现在基本上大部分软件实现多线程或多进程，多线程对单CPU系统还只是顺序利用CPU时间和改善用户体验，多CPU系统才是真正的并行。要注意的是多线程不要争抢访问同一资源而导致部分串行操作。另外，在多线程间同步一个庞大的资源，过多创建线程又没有实现线程池也会导致系统性能下降。四异步处理异步处理是通过缩短那些在将控制返回给用户之前必须处理的时间来提高性能。虽然都做同样多的事情，但是用户不必等到整个过程完成就可以继续发出请求了。但这种方式降低了服务器的处理压力，使服

47、务器可以接收更多用户的申报请求。五文件系统优化频繁打开关闭文件对系统性能下降程度是惊人的，可以通过一些变通办法来减少文件的频繁操作。例如，原来的缓存持久化实现是保存在XML文件，每次要获得一个配置项，都打开XML文件，通过XPath拿到这个配置项的值，这样效率不高，而且容易把这个XML文件锁住；改进的方法是：通过比较XML文件的修改时间判断是否要再次打开文件，大大提高了效率；另一个可以改进的方法是：启动时读取所有配置到一个静态的哈希表，每次要获得一个配置项都从内存哈希表获取，在最后或适当的时候持久化到XML。另外日志的处理也对性能影响较大，比如关闭写log的功能，性能有可能提高很多。因为频繁的

48、打开关闭大日志文件时I/O开销非常大，同样记录日志到数据库也一样。所以，正式发布版尽量减少写日志，或干脆移到裸设备上。六代码性能优化在编程实现上，代码性能设计也很重要，一些昂贵的操作会占用大量的资源和CPU时间。例如，字符串相加没用StringBuilder, 频繁创建对象，差劲的排序或递归算法，过多的装箱拆箱，过多的使用反射（Reflection），频繁创建哈希表或大的数组，用异常（Catch Exception）用做正常的逻辑，使用复杂的正则表达式，等等。七页面静态化在Web应用中效率最高、消耗最小的就是纯静态化的html页面，所以在Web发布系统中尽可能采用静态页面来实现，这个最简单的方

49、法其实也是最有效的方法。但是对于大量内容并且频繁更新的站点，无法全部手动去挨个实现，于是出现了常见的信息发布系统CMS，数据中心项目应用集成阶段基础平台建设也已建成CMS平台。通过站点的各个频道，都可以通过信息发布系统来管理和实现。信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能。同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现，比如业务系统中某些需要定期发布的统计报表，这些信息频繁被访问，访问过程会对系统造成较大的压力，但是更新频率很小。可以考虑将这部分内容进行

50、后台更新的时候进行静态化，定期在业务系统上生成报表，并转化成静态报表，最终发布到CMS系统。这样避免了大量的数据库访问请求，有更新的时候再重新静态化。数据库性能优化通过分析市场监管局本期项目应用系统开发项目需求，本次系统建设主要是面向数据库的应用的开发，所以数据库响应速度直接影响了业务系统的性能表现。根据招标文件提及的内容得知数据库平台将采用目前使用最为广泛的大型数据库管理系统Oracle。提高数据库系统的运行效率，是整个计算机信息系统高效运转的前提和保证。影响数据库应用系统性能的因素很多，既有软件方面的因素，也包括数据运行的硬件环境、网络环境、数据库管理和维护方面的因素等。软件方面的因素除了

51、数据库的设计之外，实际上还有很多其他的影响因素。例如，程序的编码逻辑，实际使用的SQL语句，但这些都被划分在应用程序设计范围内了。除此之外，影响数据库系统性能的因素还包括了数据库平台自身的配置，例如安装选项、缓冲池规模、数据库相关的地址空间的分配优先级等。在性能优化时机方面，数据库系统设计开发阶段是对应用进行优化的最佳阶段，也是主动优化阶段，能达到以最小成本获得最大性能增益的目的。通过对其逻辑存储结构和物理存储结构设计进行优化，使之在满足需求条件下性能最佳，可以解决数据库系统运行过程中性能的渐进性下降或性能突降等问题，以保证系统运行的优良性能。在系统运行阶段，可以通过对于 Oracle等数据库

52、性能监控可以发掘来自于数据库自身与数据库之外的性能问题，从而有针对性的进行数据库性能调优，比如：1.对数据库内存参数调整，以更有效地使用内存；2.对数据库其它配置参数进行针对性调整，减少各种等待事件；3.合理分配数据文件物理存储，以减少磁盘 I/O 竞争；4.对数据库表与索引进行有效地重组，以获得更优的查询效率；5.如有需要可将数据库由单点模式迁移至多节点集群为应用提供并行处理，等多方面全面调整使数据库反应时间在整个系统反应时间的比例降至最低。一数据库查询性能优化实践表明，大部分 IT 系统性能问题主要来自于低效的应用，不合理的应用程序 SQL 语句是引起数据库反应缓慢的主要原因，通过对于数据

53、库的详细监控，可以捕获引起特定性能较差的应用对应的 SQL 语句，对其进行具有针对性的分析与重新书写，以显著提高特定应用的响应时间。人们在使用SQL时有时候会陷入一个误区，即太关注于SQL得到的结果是否正确，而忽略了不同的实现方法之间的可能存在的性能差异，特别是Web较复杂的报表系统中用到的Select命令或大型的复杂的数据库环境中(如联机事务处理OLTP)表现得尤为明显。经过对相关应用程序中SQL分析及相关数据收集。我们发现不良的SQL语句往往来自于不恰当的索引设计，不充分的连接条件和不可优化的where子句。在对它们进行适当的优化后，其运行速度有了明显的提高。以下是一些常用的优化原则:1.

54、尽量少用IN操作符，基本上所有的IN操作符都可以用EXISTS代替。 2.不用NOT IN操作符，可以用NOT EXISTS或者外连接+替代。 3.Oracle在执行IN子查询时，首先执行子查询，将查询结果放入临时表再执行主查询。而EXIST则是首先检查主查询，然后运行子查询直到找到第一个匹配项。NOT EXISTS比NOT IN效率稍高。但具体在选择IN或EXIST操作时，要根据主子表数据量大小来具体考虑。 4.不用“”或者“!=”操作符。对不等于操作符的处理会造成全表扫描，可以用“”代替。 5.Where子句中出现IS NULL或者IS NOT NULL时，Oracle会停止使用索引而执行

55、全表扫描。可以考虑在设计表时，对索引列设置为NOT NULL。这样就可以用其他操作来取代判断NULL的操作。 6.当通配符“%”或者“_”作为查询字符串的第一个字符时，索引不会被使用。 7.对于有连接的列“|”，最后一个连接列索引会无效。尽量避免连接，可以分开连接或者使用不作用在列上的函数替代。 8.如果索引不是基于函数的，那么当在Where子句中对索引列使用函数时，索引不再起作用。 9.Where子句中避免在索引列上使用计算，否则将导致索引失效而进行全表扫描。 10.对数据类型不同的列进行比较时，会使索引失效。 11.用“=”替代“”。 12.UNION操作符会对结果进行筛选，消除重复，数据

56、量大的情况下可能会引起磁盘排序。如果不需要删除重复记录，应该使用UNION ALL。 13.Oracle从下到上处理Where子句中多个查询条件，所以表连接语句应写在其他Where条件前，可以过滤掉最大数量记录的条件必须写在Where子句的末尾。 14.Oracle从右到左处理From子句中的表名，所以在From子句中包含多个表的情况下，将记录最少的表放在最后。（只在采用RBO优化时有效，下文详述） 15.Order By语句中的非索引列会降低性能，可以通过添加索引的方式处理。严格控制在Order By语句中使用表达式。 16.不同区域出现的相同的Sql语句，要保证查询字符完全相同，以利用SG

57、A共享池，防止相同的Sql语句被多次分析。 17.多利用内部函数提高Sql效率。 18.当在Sql语句中连接多个表时，使用表的别名，并将之作为每列的前缀。这样可以减少解析时间。 二建立索引 建索引是提高数据访问效率的重要途径，但建索引有时并不一定能起到作用，索引不能满足未知需求，有时会适得其反，降低系统性能。关于索引，可归纳出以下几点： 1索引数尽量少。当要在一个合理的时间内结束查询时，应避免添加索引。过多的索引会降低更新操作的速度并消耗额外的空间，使磁盘有效使用率降低，增加系统的复杂性和管理成本。低速查询不一定表示数据库或索引有问题，很可能是程序有问题。 2基数较大的列很适合用来做索引。如果

58、索引的惟一值有限（如），则不宜使用索引。 3最好不选择大的列作索引。 4考虑到管理上的开销，应避免在索引中使用多于五个列，避免覆盖多个查询的大型索引。 5对于多列索引，将查询中引用最多的列放在定义的前面。 6添加与已有索引相似的索引会给优化器带来更多的工作，降低更新操作的速度。如果需要，可以修改已有的索引，使其包含附加的列。 7在经常进行连接，但没有指定为外键的列上建立索引。 8在频繁进行排序或分组的列上建立索引。 9在需要时建群集索引。群集索引允许对数据页采用更线性的访问模式，允许更有效的预取，并且有助于避免排序。这样查询操作会更快，但插入操作会慢。适合插入更新频率不高的表。 10)确保最优

59、的索引使用。三优化实例以下以Oracle为例展开数据库优化的详细介绍：Oracle 数据库的逻辑结构是由一些数据库对象组成，如数据库表空间、表、索引、段、视图、存储过程、触发器等。数据库的逻辑存储结构(表空间等)决定了数据库的物理空间是如何被使用的，数据库对象如表、索引等分布在各个表空间中。Oracle 数据库的物理结构从操作系统一级查看，是由一个个的文件组成，从物理上可划分为:数据文件、日志文件、控制文件和参数文件。数据文件中存放了所有的数据信息;日志文件存放数据库运行期间产生的日志信息，它被重复覆盖使用，若不采用归档方式的话，已被覆盖的日志信息将无法恢复;控制文件记录了整个数据库的关键结构

60、信息，它若被破坏，整个数据库将无法工作和恢复;参数文件中设置了很多Oracle 数据库的配置参数，当数据库启动时，会读取这些信息。优化Oracle 数据库对提高计算机系统的可用性和效率,具有非常重要的意义, 特别是在Oracle数据库设计开发阶段，对逻辑结构和物理结构进行有效的优化设计，创建一个规划布局合理的数据库，可以获得最小的系统开销，能从根本上大大提高应用系统的整体性能，对于以后的数据库性能调整和利用都有很大的益处。1.逻辑结构的优化逻辑结构优化用通俗的话来说就是通过增加、减少或调整逻辑结构来提高应用的效率，下面通过对基本表的设计及索引、聚簇的讨论来分析Oracle逻辑结构的优化。（1）