Ø 高峰期有哪些操作？
Ø 中间件操作有多少？数据库操作有多少？
Ø 如果任务失败，那么商业风险有多少？
Ø 有没有涉及保密系数高的数据？
测试选型标准：高吞吐量、高I/O、高商业风险
二、数据库能力需求
1、高吞吐量
满足高并发下的大数据量交互需求，满足数据备份或ETL过程的大数据量迁移。具体需求信息获取参照以上数据库应用需求。
2、负载均衡
满足高并发下数据库的负载均衡能力，需求分析需要收集数据库的部署架构、负载均衡策略等数据信息。
3、读写分离
获取需求的要点是明确哪些是写节点，哪些是读节点，并且切换的策略什么，数据同步的策略是什么。
4、分区分片（分库分表）
获取需求的要点是把握数据的垂直切换和水平分库概念。明确需要对哪些数据块进行切分，分别分散到哪几台数据库主机上；需要对哪些大表进行数据水平切分，并且分布到哪些DB或table中。通过需求分析，做出数据切分的合理性判断，以及做出系统可测性的判断。
5、高并发
根据以上的数据库应用需求，进一步制定数据库的高并发需求，估算出单台数据库的API接口压力和需要满足的并发能力。
6、高可用性
高可用性可能也综合涉及到数据的多项能力，主要应用的是集群技术，HA容错及互备技术，体现的是无故障运行。获取需求的要点是明确高可用性技术架构，了解HA采用的工作方式，以及掌握故障切换方法和数据一致性验证需求。
三、数据库评估模型
（一）关键业务时间指标
在我们的印象中，应用的关键业务能够提供真正的用户行为洞察——他们捕捉实时性能数据，展现真实用户在交互时的用户体验。衡量一个关键业务的性能包括捕捉交易的整体响应时间以及测量其不同层面的响应时间。这些时间都可以满足你业务需要的基准做比较。
如果你只想测量应用的某个方面，关键业务流程是最佳选择。虽然容器指标可以提供丰富的信息，可以帮助你确定何时自动缩放您的环境，但业务流程交易还是决定着你的应用性能最终效果。不管你作为什么规模公司的程序“猿”，都应该首先关心你的用户是否可以完成他们的关键业务流程。
一旦你定义了整个关键业务，性能好坏就是衡量整个应用生态系统的最好标准。我们需要设定低于平均关键业务响应时间的交易为异常行为，这样就能更好的观察应用的性能了，如下图所示。
那么问题来了，怎么设定关键业务的标准呢？
这里提供一个简单的方法供大家参考：假设关键业务在周三13：00~14:00是一个常见的高峰，那么选择这个时段平均响应时间作为标准，等到下周三的同一个时段，再将这周的这个时段的所有关键业务平均响应时间与前一周相比得到一个平均值，如此循环。通过这个机制，应用可以随时间而发展，而原始的关键业务数据也变得更有意义。关键业务的监测是用户体验中最具反思性的测量方法，因此它们是能捕捉到的最重要的指标之一。
（二）SQL性能指标
查询的性能主要体现为SQL查询缓慢和数据返回时间过长。那么我们要怎么解决它呢？下面是测试需要重定关注的：
1、数据的查询方式对传输效率的影响，比如选用了更多的数据：查询返回的列太多的话会导致在选择行和检索数据时造成缓慢（如使用了SELECT*，没有列出所需的列）。此外，在结果中列出所需的列，也能减少数据传输，有利于性能的提升。
2、重点关注索引的应用，对于只是访问表中的几个字段，并且字段内容较少，可以为这几个字段单独建立一个组合索引，这样就可以直接只通过访问索引得到数据，一般索引占用的磁盘空间比表小很多，所以这种方式可以大大减少磁盘IO开销。
3、关注慢SQL执行计划及优化：SQL执行计划是关系型数据库最核心的技术之一，它表示SQL执行时的数据访问算法。当业务需求越来越复杂，表数据量越来越大，SQL也需要支持非常复杂的业务逻辑，但SQL的性能还需要提高，因此，优秀的关系型数据库除了需要支持复杂的SQL语法及更多函数外，还需要有一套优秀的算法库来提高SQL性能。
4、关注批处理对性能影响：读取大量的数据或生产复杂的分析报告时通常都是在批量操作。这些操作是资源密集型，可能会影响在线用户的性能。想要解决这个问题需要将这些操作在低负载下进行，如在夜间；或使用单独的数据库来处理和分析报告。
（三）锁及粒度
数据库一般都允许多用户的存在，多个用户同时活动必然会导致冲突，然而正常工作中这种情况又无法避免，所以测试需要关注的是锁的应用与性能的平衡关系：
1、页/行锁定：当一个用户试图读取另一个用户正在修改的数据，或修改另一个用户正在读取的数据时，又或者尝试修改另一个事务正在尝试修改的数据时，就会出现并发问题。这时候资源就会被锁定。
可以锁定的资源在粒度（granularity）上差异很大。从细（行）到粗（数据库）。细粒度锁允许更大的数据库并发，因为用户能对某些未锁定的行执行查询。然而，每个由数据库系统产生的锁都需要内存，所以数以千计独立的行级别的锁也会影响数据库的性能。粗粒度的锁降低了并发性，同时消耗的资源也较少。
2、死锁：死锁是数据库性能的重量级杀手之一，然而死锁却是不同事务之间抢占数据资源造成的。死锁耗时耗资源，然而在大型数据库中，高并发带来的死锁是不可避免的，所以我们只能让其变的更少。
①按照同一顺序访问数据库资源
②保持事务的简短，尽量不要让一个事务处理过于复杂的读写操作。事务过于复杂，占用资源会增多，处理时间增长，容易与其它事务冲突，提升死锁概率。
③尽量不要在事务中要求用户响应，比如修改新增数据之后再完成整个事务的提交，这样延长事务占用资源的时间，也会提升死锁概率。
④尽量减少数据库的并发量（通过优化架构实现）。
⑤尽可能使用分区表，分区视图，把数据放置在不同的磁盘和文件组中，分散访问保存在不同分区的数据，减少因为表中放置锁而造成的其它事务长时间等待。
⑥避免占用时间很长并且关系表复杂的数据操作。
⑦使用较低的隔离级别，使用较低的隔离级别比使用较高的隔离级别持有共享锁的时间更短。这样就减少了锁争用。
（四）硬件资源指标
然而并不是所有的数据库性能问题都是来自数据库本身，我们日常工作中最常见的另一个情景就是数据库的硬件有若干问题，这里我们简单的介绍一下可能会出现的情况，毕竟市面上有已经有很多工具可以监测这些问题了。
1、没有足够的CPU或CPU速度太慢：更多的CPU可以分担服务器的负载，从而提高性能。
2、慢的磁盘没有足够的IOPS：磁盘性能可以描述为每秒输入/输出操作（IOPS），它表示每秒磁盘的吞吐量。
3、配置不正确的磁盘：数据库需要效果明显的磁盘访问，配置不正确的磁盘会造成相当大的性能影响。
4、没有足够的内存：受限或不好的物理内存影响数据库性能，可用的内存越多，性能越好。
（五）NoSQL
NoSQL发展到今天，已经有了很大的吸引力，因为它处理大规模数据和高并发的能力非常显著。但是，NoSQL却很难测试，也不容易监控。
1、NoSQL特性：关系型SQL已经成熟，有行业标准接口，但是每一个NoSQL都是独一无二的存在，并且都不支持复杂的数据库模型。所以简洁、有效、速度是它的业务应用标准。
2、集群化和负载均衡：NoSQL数据库相比关系型数据库通常更多的是资源密集型。它们需要更多的内存和内存分配，集群化和分布式是评估要点；
3、扩展性要求：随着数据库的需求增加，硬件也必须扩展，可扩展性是一项评估要点。
4、高可用性要求：可以说NoSQL对稳定性的要求更为苛刻（因为它们有些是基于内存的数据库），高可用性是重要评估点。
5、监控要求：相对于已经成熟的关系SQL，NoSQL现在的监控可以说是比较困难的，国内也只有听云一家公司能够支持主流的Memcached, MongoDB, Redis等非关系型数据库服务（但是NoSQL监控部分要收费）；ApplicationsManager也支持对Memcached, MongoDB,Redis、HBase、Oracle NoSQL的监控（这些的监控指标还不够丰富，有待完善）。
（六）扩展架构模型
1、数据切分和分布式
数据切分可以是物理上的，对数据通过一系列的切分规则将数据分布到不同的DB服务器上，通过路由规则路由访问特定的数据库，这样一来每次访问面对的就不是单台服务器了，而是N台服务器，这样就可以降低单台机器的负载压力。数据切分也可以是数据库内的，对数据通过一系列的切分规则，将数据分布到一个数据库的不同表中。
（1）数据垂直切分
数据的垂直切分，也可以称之为纵向切分。将数据库想象成为由很多个一大块一大块的“数据块”（表）组成，我们垂直的将这些“数据块”切开，然后将他们分散到多台数据库主机上面。这样的切分方法就是一个垂直（纵向）的数据切分。
（2）数据水平切分
数据的垂直切分基本上可以简单的理解为按照表、按照模块来切分数据，而水平切分就不再是按照表或者是功能模块来切分了。一般来说，简单的水平切分主要是将某个访问极其平凡的表再按照某个字段的某种规则来分散到多个表之中，每个表中包含一部分数据。
除了垂直切分、水平切分，还有其他的切分或分片方式，如导出切分、混合切分。
（3）负载均衡和读写分离
一般是通过负载均衡器，其职责就是定位到一台具体的DB服务器。具体的规则如下：负载均衡器会分析当前sql的读写特性，如果是写操作或者是要求实时性很强的操作的话，直接将查询负载分到Master，如果是读操作则通过负载均衡策略分配一个Slave。
其中Master负责写操作的负载资产管理系统性能需求，也就是说一切写的操作都在Master上进行，而读的操作则分摊到Slave上进行。这样一来的可以大大提高读取的效率。在一般的互联网应用中，经过一些数据调查得出结论，读/写的比例大概在 10：1左右 ，也就是说大量的数据操作是集中在读的操作，这也就是为什么我们会有多个Slave的原因。
但是为什么要分离读和写呢？熟悉DB的技术人员都知道，写操作涉及到锁的问题，不管是行锁还是表锁还是块锁，都是会降低系统执行的效率。我们这样的分离是把写操作集中在一个节点上，而读操作在其他的N个节点上进行，从另一个方面有效的提高了读的效率，保证了系统的高可用性。
（4）分布式存储
分布式存储是将数据分散存储在多台独立的设备上。传统的网络存储系统采用集中的存储服务器存放所有数据，存储服务器成为系统性能的瓶颈，也是可靠性和安全性的焦点，不能满足大规模存储应用的需要。分布式网络存储系统采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，它不但提高了系统的可靠性、可用性和存取效率，还易于扩展。
分布式存储利用的就是数据的切分，也叫数据分片，数据分片将达到以下三个目的：
Ø分布均匀，即每台设备上的数据量要尽可能相近；
Ø负载均衡，即每台设备上的请求量要尽可能相近；
Ø扩缩容时产生的数据迁移尽可能少。
有了分布式存储，就会有分布式计算，这就是大数据的范畴了，在这里不多说。
2、Cache与Search的利用
（1）结合传统关系型数据库和NoSQL两种类型数据库的优缺点，对于Oracle、Mysql这些数据库，可以通过引入Cache（Redis、Memcached），减少数据库的访问，增加性能（主要是解决传统关系型数据库的IO性能瓶颈，Cache都是基于内存的，大大减少了磁盘读写）。特别说明一下，这里说的Cache不是指数据库底层对应的Cache缓存，数据库层次的缓存一般针对的是查询内容，而且粒度也太小，一般只有表中数据没有变更的时候才发挥作用。我们这里说的Cache，是指外部引入的数据库缓存。
（2）通过引入Search（Lucene、Solr、ElasticSearch），利用搜索引擎高效的全文索引和分词算法，以及高效的数据检索实现，来解决数据库和传统的Cache软件完全无法解决的全文模糊搜索、分类统计查询等功能。
通过以上的数据库性能评估模型分析，我们就能把握数据库系统将要有的性能能力，并分析具体的测试范围和指标评估范围资产管理系统性能需求，以决定后期需要采用的测试方法、策略和工具。毕竟性能不是靠测试和调优出来的，是靠设计出来的，如果我们不了解数据库的能力模型和相应的架构要求，我们将很难深入开展相应的性能测试和性能调优工作。
伴随企业快速发展，企业在信息化方面持续投入，先后建设和应用了各业务管理及数据应用分析系统，在信息化建设和应用方面初步奠定了一定基础，沉淀了大量的数据。而数据被称为“未来新石油”，已经渗透到当今企业生产经营和各业务职能发展领域，成为企业数字化转型的基础。
为进一步稳固取得的成绩及成果，企业需要以数据质量为核心，数据安全为保障，数据服务为目标实现数据资产化管理并对数据资产加强专门管控，强化组织和制度保障，进一步明确数据生命周期过程的相关权责，实施标准化、规范化、体系化的管理，确保数据生产、使用的全过程受控。将数据质量提升工作和实用化成果，通过构建良好的数据管理文化氛围和完备的数据管理机制，形成常态化的员工重视数据和应用数据的习惯，迫切需要立足企业生产经营实际和信息化现状建设企业数据资产管理体系。
中翰软件打破传统的数据资产管理思路，从业务的实际出发结合企业的实际情况，实现“用数据管理企业，用信息驱动业务”目标，借助先进的数据管理手段来促进运营数据的增值。
友情提示，不建议在前期项目中涉及全部数据的资产化管理，应按照先结构化数据然后非结构化数据的治理原则逐步推进，不可一步到位，防止因跨度大造成的结构性障碍。
中翰数据资产管理整体架构
具体如下图所示。
图 数据资产管理整体架构
上图可以看出，中翰数据资产管理整体架构主要包括数据资产环境管理、源端数据治理、末端数据治理、数据安全管理、元数据管理、数据仓库（数据湖）、血缘分析、数据资产目录及实体关系、数据应用分析和知识管理。
其中数据资产环境管理是指数据资产管理体系；源端数据治理是指基于业务系统的静态数据治理，包括主数据管理和业务场景数据治理，末端数据治理是指基于ODS层（全量数据中心）的数据质量检测、改造处理，二者合起来为数据质量管理；数据安全管理是指针对数据的防泄漏、加密和脱敏管理等；元数据管理是指针对元数据标准进行统一管控（采集、存储、分发）。数据仓库（数据湖）是指汇集存储数据。血缘分析、数据资产目录及实体关系是数据资产服务的内容，数据应用分析是指基于业务主题的数据加工、展示。知识管理是指数据治理相关的过程及成果知识，是数据治理能力转化的有效载体。
根据《DAMA数据管理知识体系指南》和《企业数据治理那些事》的相关理论基础，中翰数据资产管理定义以数据资产管理体系为基础，数据质量为核心，数据安全为保障，数据服务为目标并且要确保数据治理能力的有效转移。
中翰数据管控平台概述
图 中翰数据管控平台v8.0登录页
中翰数据管控平台v8.0是以数据资产管理体系为基础，数据质量为核心，数据安全为保障数据资产目录示例，数据服务为目标以及确保数据治理能力的有效转移五个方面为基础的数据资产化管控平台数据资产目录示例，全面满足DAMA以及DCMM数据治理标准规范。内含11大组件，具体如下：
中翰EDP—体系构建平台（数据治理知识平台）：数据管控平台的核心组成部分，实现构建数据标准、模型等的过程化管理，实现数据治理项目调研、咨询过程的线上管控，记录调研、咨询过程、结果，提供数据治理知识的常态化转移，解决数据治理后运维过程无法有效完善和拓展以往延续体系咨询思路的难题；
中翰MDC—静态数据中心管理平台：数据管控平台的核心组成部分，用于静态数据管理体系的落地和静态数据日常维护的管控操作，实现数据全生命周期的一体化管理；
中翰MMP—元数据管理平台：数据管控平台的核心组成部分，解决元数据标准规范统一采集、存储、分发的管理，为数据血缘分析等提供工具基础；
中翰ODC—数据清洗平台：数据管控平台的核心组成部分，用于历史数据的清洗，能够彻底解决历史数据的不一致、不完整、不合规、数据冗余等问题，最终通过ODC可以生成新老数据以及重复老数据的映射关系表，为BI提供分析参照；
中翰Exchange—数据交换平台：数据管控平台的核心组成部分，用于数据治理平台和其他业务系统的数据交换，包括数据的采集和分发；
中翰BPM—工作流平台：数据管控平台的核心组成部分，用于实现企业静态数据的申请、审核、变更等过程的任务流转，此平台为国际最先进的BPMn2.0规范；
中翰TWEET—海量数据安全及推送机制平台：数据管控平台的核心组成部分，用于数据治理平台在海量数据下各组件间的数据快速推送交互及安全保障；
中翰DAC—数据资产目录：数据管控平台的核心组成部分，实现数据资产的目录以及数据资产实体关系生成、展示等，真正解决数据资产化服务的难题；
中翰DAM—数据保养平台：数据管控平台的核心组成部分，也称数据评估监测平台，数据治理项目结束后可以实时地进行深层次数据质量的异动探知，解决数据治理后数据质量无法持续良好的难题。当然数据质量项目前也可以进行存量数据质量的分析；
中翰Report—报表平台组件：数据管控平台的核心组成部分，解决平台固有报表无法满足特殊展示要求的问题，实现前台可视化报表自定义设置；
中翰APP—移动端组件：数据管控平台的核心组成部分，实现移动端数据申请、查询以及二维码扫描等管理，便捷日常数据管理操作。
同时，数据服务功能可以合理、科学地支撑数据中台、数据仓库、数据交易等，实现静态数据的共享交换统一管理。
a、 技术特点
中翰数据管控平台v8.0采用微服务架构技术，基于SpringCloud框架的大型分布式应用，可选择多种系统环境，满足不同类型、不同规模企业的需要。定位技术高端，全面支持Enterprise JavaBeans标准。提供了对 EJB、Servlets、JSP、JDBC、CORBA以及XML技术的全面支持。系统支持Oracle11g、SQL Server 2000及以上版本，以及MY SQL、Sybase、DB2等大型数据库产品。（山东中翰软件有限公司）
本文内容整理收集与网络，仅供学习交流使用，不代表CRM论坛观点。如有侵权,请联系我们,我们将会及时删除处理。
云呐固定资产管理系统是专业销售和研发各种固定资产管理系统,固定资产管理软件，企业条码固定资产管理系统等软件产品，产品作用功能优势明显欢迎来选购！咨询电话：13157126221