基于交易场景的数据库基准测试方法及装置

摘要

本发明提供一种基于交易场景的数据库基准测试方法及装置，可用于金融技术领域对数据库进行基准测试。测试方法包括：接收输入的预设参数；初始化后，根据所述预设参数生成初始测试数据；通过至少两个线程来模拟交易柜员连接到存储所述初始测试数据的被测数据库；在目标交易场景下周期性获取性能统计指标；其中，目标交易场景包括：每个线程按照预设比例执行目标交易处理流程；每天进行一次对账处理、每月进行一次结息处理以及每个线程的账户支付处理是向同一账户进行支付。本发明能够提高数据库基准测试的准确性和安全性。

说明书

技术领域

本发明涉及数据库测试技术领域，具体涉及一种基于交易场景的数据库基准测试方法及装置。

背景技术

在数据库产品选型测评时，必须开展数据库基准测试，以评估数据库能支撑的性能(如交易吞吐量、响应时间等)和容量(如并发数、存储容量等)。目前常用的数据库基准测试方案包括基于随机读写模型的Sysbench工具，基于仓库进销存模型的TPC-C测试。Sysbench工具是一款开源的基准测试工具，可执行CPU/内存/线程/IO/数据库等方面的性能基准测试。TPC-C是由事务处理性能委员会(Transaction Processing PerformanceCouncil,TPC)发布的针对数据库联机事务处理性能的基准测试。

但是，以上这些基准测试的业务模型和业务逻辑过于简单，难以体现一个真实商用信息系统访问数据库的特点，而且不能满足现代复杂商业环境对数据库的负载需求。因此，业界需要一种场景更加丰富的数据库基准测试方法，用于指导数据库选型测评和开展系统性能容量评估等工作。

发明内容

针对现有技术中的问题，本发明提供一种基于交易场景的数据库基准测试方法及装置，能够提高数据库基准测试的准确性和安全性。

为解决上述技术问题，本发明提供以下技术方案：

第一方面，本发明提供一种基于交易场景的数据库基准测试方法，包括：

接收输入的预设参数；

初始化后，根据所述预设参数生成初始测试数据；

通过至少两个线程来模拟交易柜员连接到存储所述初始测试数据的被测数据库；

在目标交易场景下周期性获取性能统计指标；其中，目标交易场景包括：每个线程按照预设比例执行目标交易处理流程；每天进行一次对账处理、每月进行一次结息处理以及每个线程的账户支付处理是向同一账户进行支付。

第二方面，本发明提供一种基于交易场景的数据库基准测试装置，包括：

接收模块，用于接收输入的预设参数；

初始化模块，用于初始化后，根据所述预设参数生成初始测试数据；

模拟模块，用于通过至少两个线程来模拟交易柜员连接到存储所述初始测试数据的被测数据库；

测试模块，用于在目标交易场景下周期性获取性能统计指标；其中，目标交易场景包括：每个线程按照预设比例执行目标交易处理流程；每天进行一次对账处理、每月进行一次结息处理以及每个线程的账户支付处理是向同一账户进行支付。

第三方面，本发明提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现所述的基于交易场景的数据库基准测试方法的步骤。

第四方面，本发明提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现所述的基于交易场景的数据库基准测试方法的步骤。

由上述技术方案可知，本发明提供一种基于交易场景的数据库基准测试方法及装置，通过接收输入的预设参数；初始化后，根据所述预设参数生成初始测试数据；通过至少两个线程来模拟交易柜员连接到存储所述初始测试数据的被测数据库；在目标交易场景下周期性获取性能统计指标；其中，目标交易场景包括：每个线程按照预设比例执行目标交易处理流程；每天进行一次对账处理、每月进行一次结息处理以及每个线程的账户支付处理是向同一账户进行支付，能够提高数据库基准测试的准确性和安全性。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例应用的银行业务场景示意图。

图2为本发明实施例中的基于交易场景的数据库基准测试方法的流程示意图。

图3为本发明实施例中的基于交易场景的数据库基准测试方法中的数据结构关系示意图。

图4为本发明实施例中的基于交易场景的数据库基准测试装置的结构示意图。

图5为本发明实施例中的电子设备的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整的描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在对本发明的实施例进行说明之前，对本发明实施例的应用场景和关键术语进行说明。参见图1，基于真实银行业核心系统，一个银行有M个机构、N个柜员，初始有P个账户，每个账户有一定初始金额。同一时刻有T个操作柜员并发地发起业务交易。如图1所示，网银、手机银行等渠道的交易操作柜员为虚拟柜员。金融行业通存通兑，每个柜员执行的交易可能服务任一账户，当多个交易集中访问同一个账户，即出现热点账户的现象。

其中，计息指利息得计算。对于银行来说，提前计算出利息。目前，金融机构一般采用两种计息方法：一是对年、对月、对日计息法，即对一笔存款或贷款，先按整年、整月和整日分别计算利息，然后相加计算出整个存款期或贷款期得全部利息。二是日积数法，即以本金乘以天数算出日积数，再根据日积数程序日利率得到全部利息。

结息指利息得实际给付，将客户存款所得利息转入到客户账户上。金融机构对一笔存款或贷款，并不是每天支付或收取利息，通常是集中在特定日期才实际收付利息。

法定货币是指不代表实质商品或货物，发行者亦没有将货币兑现为实物义务；只依靠政府的法令使其成为合法通货的货币。

例如：根据《中华人民共和国中国人民银行法》，人民币的单位为元，人民币辅币单位为角、分。因此，人民币的法定最小货币单位为分。厘、毫等单位非法定货币单位。

本文中金额都是整数类型，单位为指定币种的法定最小货币，系统中结息等金额处理都基于最小货币单位。比如人民币账户的金额单位为1分钱，不涉及元、角、分等单位换算。

本发明提供一种基于交易场景的数据库基准测试方法的实施例，参见图2，所述基于交易场景的数据库基准测试方法具体包含有如下内容：

S101：接收输入的预设参数；

在本步骤中，预设参数包括：并发线程数、银行客户的账户数量、柜员数量、机构数量和业务发生金额。

并发线程数(i_threads)，默认值为1，一个线程代表一个办理业务的柜员。银行客户的账户数量(i_total_accounts)，该参数决定生成初始测试数据的大小，默认值为1000000000。机构数量小于或等于柜员数量(i_teller_num)，_num，默认值为柜员数量(i_teller_num)除以100向上取整。本实施例中业务发生金额(i_amount)在[100,10000000]范围内取随机值。

需要说明的是，预设参数是通过测试工具输入的。

S102：初始化后，根据所述预设参数生成初始测试数据；

在本步骤中，初始化包括：初始化预存储的系统序号表、机构表、柜员表、币种表和当前基准利率。具体SQL示例如下：

(1)初始化系统序号表：

(2)初始化机构表：

(3)初始化柜员表：

将i_teller_num个柜员分配给i_institution_num个机构，同一个机构中的柜员号连续。

(4)初始化币种表：

(5)初始化当前基准利率v_baserate，取值为实际利率·10

本步骤中，还根据预设参数生成初始测试数据，具体包括：并发线程数个交易柜员并发地通过账户开立处理生成银行客户的账户数量个账户的数据；

其中，业务唯一编号由交易渠道上送，模拟程序应实现全局唯一id生成器。

并发线程数个交易柜员并发地通过账户存款处理为银行客户的账户数量个账户存入特定金额的初始数据；执行对账处理交易，确认初始状态下的对账平衡数据。

S103：通过至少两个线程来模拟交易柜员连接到存储所述初始测试数据的被测数据库；

S104：在目标交易场景下周期性获取性能统计指标；其中，目标交易场景包括：每个线程按照预设比例执行目标交易处理流程；每天进行一次对账处理、每月进行一次结息处理以及每个线程的账户支付处理是向同一账户进行支付。

在本步骤中，目标交易处理流程，包括：账户开立处理、账户存款处理、账户取款处理、账户转账处理、账户信息查询处理、账户明细查询处理和账户支付处理。具体地，i_threads个线程模拟交易柜员连接到被测数据库，每个并发线程按一定比例执行如下7个联机交易处理流程：

需要说明的是，实际中每月最后一天自动进行结息处理。模拟测试时可根据测试时长进行调整。要求测试时长至少覆盖1次“账户结息(ACCINTSETTLE)”交易。实际中每天进行一次对账处理。模拟测试时可根据测试时长进行调整。要求测试时长至少覆盖4次“对账处理(ACCVERIFY)”交易，且“对账处理(ACCVERIFY)”交易之间的时间间隔固定。

采用“账户支付(ACCPAY)”交易模拟热点账户的场景。i_threads个并发线程中的“账户支付(ACCPAY)”交易有10％向同一个账户进行支付。具体实施时，模拟程序每10秒输出一次性能统计指标。性能统计指标交易吞吐量TPS(Transactions Per Second)和交易响应时间(latency)。

进一步地，在并发线程数个交易柜员并发地通过账户开立处理生成银行客户的账户数量个账户的数据之后，还包括：

所有账户开立处理后，在日志文件中记录一笔应用日志；其中，所述应用日志通过数据库表的方式进行记录。

需要说明的是，所有的账户开立(ACCOPEN)操作之后需在日志文件(app.log文件)中记录一笔应用日志。实际中应用日志通过数据库表的方式进行记录(比如业务登记簿TABLE2)，这里是为了在数据库外记录已提交交易，在持久性测试中与数据库执行崩溃恢复操作之后的数据进行对比。

进一步说明的是，实施例中确定金融行业核心系统最具有代表性的9个核心交易场景，其中，7个为联机交易处理流程；2个为后台批量处理流程，具体如下：

其中，核心交易场景中，任一账户的客户通过任一操作柜员执行如上表中的7个联机交易。“账户支付”交易中的10％集中访问某个特定账户，从而模拟热点交易的场景。银行后台定期跑批执行“账户结息”和“对账处理”交易。通过“对账处理”交易检测系统的数据一致性。

基于如上9个核心交易场景，对真实银行核心系统进行抽象和简化后，设计如下14张表：

需要说明的是，初始测试数据的生成：

(1)根据系统输入参数初始化机构表、柜员表。将系统序号表、币种表置初值。这5张表数据量较小且基本不变。(2)通过“账户开立”交易生成指定数目的账户，然后通过“账户存款”为账户赋随机的初始金额。这两个交易可以逻辑自洽地插入和更新所有表的数据。通过指定初始账户数目，即可限定初始数据集的大小。(3)初始数据生成后，跑一遍“对账处理”的批量，确保系统初始状态的数据一致。

初始测试数据关系可表示如图3所示，其中，(1)初始开户数量P，决定了各个业务表的初始数据量。(2)连线1表示“账户开立”交易。开立初始账户。(3)连线2表示“账户存款”交易。为账户赋初始金额。(4)连线3表示“对账处理”交易。确保初始对账平衡，且为对账登记簿赋初值。(5)连线4表示“账户结息”交易。初始并未执行，因此结息明细表和内部记账表初始数据量为0行。

可以理解的是，本发明实施例提供的基于交易场景的数据库基准测试方法，需要满足测试基本要求，具体包括如下几个方面的约束：

(1)数据量，建议开户数量10亿。该参数决定了初始数据集大小。

明细表数据量受(测试时长·交易吞吐量)影响会持续增长，需预留足够存储空间。被测系统需证明数据副本数不少于3副本，数据同步方式为强同步。

(2)数据分布，若是分布式数据库系统，要求业务登记簿(TABLE2)、账户信息表(TABLE3)、账户余额表(TABLE4)、账户明细表(TABLE5)、账户存款协议表(TABLE6)、账户计息明细表(TABLE7)、账户结息明细表(TABLE8)、对账结果登记簿(TABLE9)的数据都分布在至少10个物理节点之上。通过数据分布分析或交易监控等方式，被测系统需证明有不少于20％的交易是分布式交易。

(3)测试时长，除去数据初始化时间和系统性能预热时间不计，要求“核心交易执行阶段”(包括批量)的性能平稳运行时间不少于8小时。

(4)系统稳定性，要求在8小时平稳运行期间，各项性能指标v满足如下条件：

稳定性衡量公式不采用方差、平均差等计算方法，避免性能毛刺现象被平均。

(5)性能采集，“账户结息(ACCINTSETTLE)”交易和“对账处理(ACCVERIFY)”交易属于批量，需输出交易起止时间，以便于测试结果将联机交易性能表现与包含批量处理时的性能表现区分开。

(6)持久化和灾难恢复，要求checkpoint时间间隔不超过30分钟，且checkpoint操作时长不超过checkpoint时间间隔。

(7)事务ACID要求，包括：原子性、一致性、隔离性和持久性。

原子性，必须保证数据库事务是原子的，原子性测试如下：

发起一笔“账户转账(ACCTRANSFER)”交易并提交，确认业务登记簿(TABLE2)、账户信息表(TABLE3)、账户余额表(TABLE4)、账户明细表(TABLE5)、账户计息明细表(TABLE7)中的数据都被正确修改。

发起一笔“账户转账(ACCTRANSFER)”交易并用ROLLBACK操作替换COMMIT操作，确认业务登记簿(TABLE2)、账户信息表(TABLE3)、账户余额表(TABLE4)、账户明细表(TABLE5)、账户计息明细表(TABLE7)中的数据都完全没有变化。

若被测系统是分布式数据库系统，需证明当相关数据记录位于不同节点上时，原子性也能得到保证。

一致性，若初始处于某种一致状态，一致性要求执行任何数据库事务会使系统从一个一致状态转移到另一个一致状态。一致性测试如下：

在系统运行金融核心交易场景的同时，按周期定时执行“对账处理(ACCVERIFY)”交易，要求错账金额全部为0。

若被测系统是分布式数据库系统，需证明以下条件下，一致性也能得到保证：

业务登记簿(TABLE2)、账户信息表(TABLE3)、账户余额表(TABLE4)、账户明细表(TABLE5)、账户计息明细表(TABLE7)、账户结息明细表(TABLE8)、对账结果登记簿(TABLE9)的数据都分布在多个节点上，“对账处理(ACCVERIFY)”交易为分布式事务。

分布式系统任意节点引入单点故障，包括而不限于服务器断电或重启、网络断线、磁盘写满、文件系统崩溃等各种可能出现的服务器故障场景。

隔离性通过并发执行数据库事务时可能出现的现象来定义。

脏写(Dirty Write)：事务T1读取一个数据元素R并修改它。此时事务T2修改或删除R，并执行一个COMMIT。事务T1再次读取R，得到的是T2修改后的值或者发现R已被删除。

脏读(Dirty Read)：事务T1修改一个数据元素R。在T1执行COMMIT之前事务T2读取R得到的是T1修改之后的值。如果T1执行ROLLBACK操作，则T2读到了一个从未提交过的记录值。

被测系统必须证明至少满足ISO/SQL:2016标准Read Committed(RC)隔离级别(或以上)，验证如上(1)、(2)场景，不允许出现脏读、脏写现象。

持久性，被测系统必须保证持久性：数据库执行崩溃恢复过程之后处于一致性状态，且所有已提交事务都已持久化。持久性测试如下：

在基准测试的最大性能压力下，让被测系统的所有服务器同时断电。被测系统重启之后完成崩溃恢复，然后对比日志文件app.log中已记录提交的交易记录是否在账户明细表(TABLE5)、业务登记簿(TABLE2)的数据中有所体现，然后执行“对账处理(ACCVERIFY)”交易验证错账金额是否都为0。

需要说明的是，实际中应用日志记录在数据库表(比如业务登记簿TABLE2)，此处需采用数据库之外的记录方式与数据库内部数据进行比对。

从上述描述可知，本发明实施例提供的基于交易场景的数据库基准测试方法，通过接收输入的预设参数；初始化后，根据所述预设参数生成初始测试数据；通过至少两个线程来模拟交易柜员连接到存储所述初始测试数据的被测数据库；在目标交易场景下周期性获取性能统计指标；其中，目标交易场景包括：每个线程按照预设比例执行目标交易处理流程；每天进行一次对账处理、每月进行一次结息处理以及每个线程的账户支付处理是向同一账户进行支付，能够提高数据库基准测试的准确性和安全性。

本发明实施例提供了上述基于交易场景的数据库基准测试方法实施例中，数据结构详细的定义和交易处理流程详细定义，具体包括如下内容：

数据结构详细的定义：

系统序号表(TABLE1)：

(1)字段定义：

(2)索引定义：

业务登记簿(TABLE2)：

(1)字段定义：

(2)索引定义

(3)表说明，金额都是整数类型，单位为指定币种的最小货币单位，比如人民币账户的金额单位为1分钱。FIELD18最后更新日期可能与FIELD1交易日期不同，比如发生日切交易在第二天完成。

账户信息表(TABLE3)：

(1)字段定义：

(2)索引定义：

(3)表说明，FIELD4-开户时需预留一个账户密码(可选择在开户环节设置，也可在账户启用前单独申请设置)，该密码为后续购买票据等凭据时使用，作为核验客户身份的辅助手段，更好地保证客户资金安全。

账户余额表(TABLE4)：

(1)字段定义：

(2)索引定义：

(3)表说明，账户余额表无需时间戳字段。

账户明细表(TABLE5)：

(1)字段定义：

(2)索引定义：

账户存款协议表(TABLE6)：

(1)字段定义：

(2)索引定义

(3)表说明，基准利率的类型为INT。赋值为实际利率·10

账户计息明细表(TABLE7)：

(1)字段定义：

(2)索引定义：

账户结息明细表(TABLE8)：

(1)字段定义：

(2)索引定义：

对账结果登记簿(TABLE9)：(1)字段定义：

(2)索引定义：

账户序号表(TABLE10)：

(1)字段定义：

(2)索引定义：

机构表(TABLE11)：

(1)字段定义：

(2)索引定义：

柜员表(TABLE12)：

(1)字段定义：

(2)索引定义：

币种表(TABLE13)：

(1)字段定义：

(2)索引定义：

银行内部记账表(TABLE14)：

(1)字段定义：

(2)索引定义：

(3)表说明，一类交易对应一个内部户，比如现金交易对应都是一个内部户，结息也是一个内部户。日终只会有一笔记录，每种内部户只有一个处理方向，所以不会出现因处理方向不同导致唯一键冲突。

交易处理流程详细定义：

账户开立(ACCOPEN)，包括：前置操作和处理流程。

前置操作：从系统序号表生成账号。为避免序号表成为热点，一个线程一次取100个序号，按需分配使用，“账户开立”交易回滚序号不回滚。示例SQL如下：

处理流程：(1)获取交易日期v_workdate，取系统时间。(2)获取业务唯一编号v_seq，交易渠道上送的全局唯一id。(3)获取当前线程的执行柜员v_teller、执行机构v_institution。(4)获取账户币种v_currency＝1。客户要求开立的账户币种，可能是银行支持的币种(币种表)中任意一种(随机)。(5)检查机构是否存在。示例SQL如下：

如果记录不存在则报错。

(6)检查柜员是否存在。示例SQL如下：

如果记录不存在则报错。

(8)业务防重控制。示例SQL如下：

如果记录已存在，则报错提示：业务重复发起。

(9)取用一个账号v_account。

(10)账号防重控制。示例SQL如下：

如果记录存在，则提示账号已使用。

(11)账户信息表TABLE3新增一条记录。示例SQL如下：

示例SQL备注：

-账户名称做了简化处理，将账号转换为字符串类型的值表示账户名称。

-密码做了简化处理，用命令echo Pass12#$|base64的输出表示密码。

-注销日期用特殊值'1900-01-01'表示赋值为空，即未注销。

(12)账户余额表TABLE4中插入一条记录

(13)存款协议表TABLE6中插入一条记录

结息日期就是计息开始日，开户交易中最后结息日期赋交易当天。

(14)账户序号表中新增相关记录

(15)业务登记簿TABLE2新增记录。示例SQL如下：

账户存款(ACCDEPOSIT)：(1)获取系统日期、时间作为交易日期v_workdate。(2)获取业务唯一编号v_seq，交易渠道上送的全局唯一id。(3)获取当前线程的执行柜员v_teller、执行机构v_institution(4)设置业务发生账号v_account、业务发生币种v_currency、业务处理金额v_amount等业务信息。(5)检查机构是否存在。示例SQL如下：

如果记录不存在则报错。

(6)检查柜员是否存在。示例SQL如下：

如果记录不存在则报错。

(7)检查币种是否支持。示例SQL如下：

如果记录不存在则报错。

(8)业务防重控制。示例SQL如下：

如果记录已存在，则报错提示：业务重复发起。

(9)查询账户信息表

如果账户不存在，则报错提示账户不存在。如果账户存在，但状态不正常，则报错提示账户状态不正常。

(10)查询账户余额表TABLE4。示例SQL如下：

如果记录不存在，则报错。如果记录存在，则获取账户余额赋值给v_balance。

(11)查询账户明细序号v_seq_account。示例SQL如下：

将查询结果赋值给账户明细序号v_seq_account。

查询计息明细序号v_seq_interest_accrual：

将查询结果赋值给计息明细序号v_seq_interest_accrual。

(12)登记账户计息明细表table7：

如果账户余额表的最后交易日field5不等于当前交易日期v_workdate，则登记一笔计息明细。示例SQL如下：

计息明细表只需登记一笔。如果账户余额表的最后交易日field5等于当前交易日期v_workdate，说明本日已变更过余额，无需再插入或更新计息明细表。

(13)账户余额更新：

v_balance_old＝v_balance。

v_balance+＝v_amount。//当前余额+＝当前发生额。

如果账户余额表TABLE4的最后交易日FIELD5不等于当前交易日期v_workdate，则需要将当前余额更新到上期余额字段。

如果账户余额表TABLE4的最后交易日FIELD5等于当前交易日期v_workdate，则上期余额不变；将当前余额更新为当前余额加上业务处理金额：

(14)插入账户明细表TABLE5。示例SQL如下：

(15)业务登记簿TABLE2插入一条记录。示例SQL如下：

其中，存款人是贷方，借贷双方币种金额必须一致。

账户取款(ACCDRAW)：(1)获取系统日期、时间作为交易日期v_workdate。(2)获取业务唯一编号v_seq，交易渠道上送的全局唯一id。(3)获取当前线程的执行柜员v_teller、执行机构v_institution。(4)设置业务发生账号v_account、业务发生币种v_currency、业务处理金额v_amount等业务信息。(5)检查机构是否存在。示例SQL如下：

如果记录不存在则报错。

(6)检查柜员是否存在。示例SQL如下：

如果记录不存在则报错。

(7)检查币种是否支持。示例SQL如下：

如果记录不存在则报错。

(8)业务防重控制。示例SQL如下：

如果记录已存在，则报错提示：业务重复发起。

(9)查询账户信息表

如果账户不存在，则报错提示账户不存在。如果账户存在，但状态不正常，则报错提示账户状态不正常。

(10)查询账户明细序号v_seq_account。示例SQL如下：

将查询结果赋值给账户明细序号v_seq_account。

查询计息明细序号v_seq_interest_accrual：

将查询结果赋值给计息明细序号v_seq_interest_accrual。

(11)查询账户余额表TABLE4。示例SQL如下：

如果记录不存在，则报错。如果记录存在，则获取账户当前余额赋值给v_balance。然后进行账户余额不足判断，如果v_balance

(12)登记账户计息明细表：如果账户余额表的最后交易日field5不等于当前交易日期v_workdate，则登记一笔计息明细。示例SQL如下：

(13)账户余额更新：

v_balance_old＝v_balance。

v_balance-＝v_amount。//当前余额-＝当前发生额。

如果账户余额表TABLE4的最后交易日FIELD5不等于当前交易日期v_workdate，则需要将当前余额更新到上期余额字段。

如果账户余额表TABLE4的最后交易日FIELD5等于当前交易日期v_workdate，则上期余额不变；将当前余额更新为当前余额加上业务处理金额：

(14)插入账户明细表TABLE5。示例SQL如下：

(15)业务登记簿TABLE2插入一条记录，交易成功则插入成功，交易失败也要插入失败记录。示例SQL如下：

账户转账(ACCTRANSFER)：

(1)数据初始化和检查处理：a)获取系统日期作为交易日期v_workdate；b)设置业务唯一编号v_seq；c)设置执行机构v_institution、执行柜员v_teller、付方账号v_account_out、收方账号v_account_in、业务发生币种v_currency、业务处理金额v_amount等业务信息。d)检查机构是否存在。示例SQL如下：

如果记录不存在则报错。

e)检查柜员是否存在。示例SQL如下：

如果记录不存在则报错。

f)检查币种是否支持。示例SQL如下：

如果记录不存在则报错。

g)业务防重控制。示例SQL如下：

如果记录已存在，则报错提示：业务重复发起。

(2)付方处理：a)查询账户信息表。

如果账户不存在，则报错提示账户不存在。如果账户存在，但状态不正常，则报错提示账户状态不正常。

b)查询账户明细序号v_seq_account_out。示例SQL如下：

将查询结果赋值给账户明细序号v_seq_account_out。

查询计息明细序号v_seq_interest_accrual_out：

将查询结果赋值给计息明细序号v_seq_interest_accrual_out。

c)查询账户余额表TABLE4。示例SQL如下：

如果记录不存在，则报错。如果记录存在，则获取账户当前余额赋值给v_balance_out。如果付方账户余额v_balance_out<业务发生金额v_amount，则报错提示余额不足。

d)登记账户计息明细表TABLE7：如果付方账户余额表的最后交易日field5不等于当前交易日期v_workdate，则登记一笔计息明细：

e)付方账户余额更新：

v_balance_out_old＝v_balance_out；

v_balance_out-＝v_amount；

如果付方的账户余额表TABLE4的最后交易日FIELD5不等于交易日期v_workdate，则需要将当前余额FIELD3更新到上期余额FIELD4。

如果付方的账户余额表TABLE4的最后交易日FIELD5等于交易日期v_workdate，则上期余额FIELD4不变，并更新当前余额。示例SQL如下：

f)账户明细表插入付方记录：

付款方是借钱给银行。收款方从银行贷出资金。

(3)收方处理，a)查询账户信息表：

如果账户不存在，则报错提示账户不存在。如果账户存在，但状态不正常，则报错提示账户状态不正常。

b)查询账户明细序号v_seq_account_in。示例SQL如下：

将查询结果赋值给账户明细序号v_seq_account_in。

查询计息明细序号v_seq_interest_accrual_in：

将查询结果赋值给计息明细序号v_seq_interest_accrual_in。

c)查询账户余额表TABLE4。示例SQL如下：

如果记录不存在，则报错。如果记录存在，则获取账户当前余额赋值给v_balance_in。

d)登记账户计息明细表TABLE7：如果收方账户余额表的最后交易日field5不等于当前交易日期v_workdate，则登记一笔计息明细：

e)账户余额更新：

v_balance_in_old＝v_balance_in；

v_balance_in+＝v_amount；

如果付方的账户余额表TABLE4的最后交易日FIELD5不等于交易日期v_workdate，则需要将当前余额FIELD3更新到上期余额FIELD4。

如果付方的账户余额表TABLE4的最后交易日FIELD5等于交易日期v_workdate，则上期余额FIELD4不变，并当前余额。示例SQL如下：

f)账户明细表插入收方记录：

收款方从银行贷款。

(4)插入业务登记簿，操作成功则登记成功，失败则登记失败。示例SQL如下：

借贷双方的币种、金额必须一致。

账户信息查询(ACCQUERY)：(1)数据初始化和检查处理：a)获取系统日期作为交易日期v_workdate；b)生成业务唯一编号v_seq；c)设置执行架构v_institution、执行柜员v_teller、业务发生账号v_account、业务发生币种v_currency等业务信息。d)检查机构是否存在。示例SQL如下：

如果记录不存在则报错。

e)检查柜员是否存在。示例SQL如下：

如果记录不存在则报错。

(2)业务登记簿插入一条记录，业务类型为查询：

查询交易可以先插入业务登记簿。

(3)查询账户信息表TABLE3：

如果账户不存在，则报错提示账户不存在。如果账户存在，将查询到的账户信息返回。

(4)查询账户余额表：

账户明细查询(ACCDETQUERY)：

(1)数据初始化和检查处理：a)获取系统日期作为交易日期v_workdate；b)生成业务唯一编号v_seq；c)设置执行机构v_institution、执行柜员v_teller、业务发生账号v_account、业务发生币种、起始日期v_date_start、结束日期v_date_end。d)设置查询翻页序号v_seq_query＝1。一次查询5页，上一次查询的最大翻页序号用于下次翻页。e)检查机构是否存在。示例SQL如下：

如果记录不存在则报错。

f)检查柜员是否存在。示例SQL如下：

如果记录不存在则报错。

(2)业务登记簿插入一条记录，业务类型为查询：

(3)查询账户明细表：

将查询到的明细记录返回。

账户结息(ACCINTSETTLE)-批量：(1)获取系统日期作为交易日期v_workdate；(2)设置业务唯一编号v_seq；(3)设置执行机构v_institution、执行柜员v_teller；(4)对账户计息明细表按照账号和日期排序。

(5)按账户进行计算利息处理，获取利息金额v_interest_amount：

对于每个账号(当前处理账号赋值给变量v_account，当前处理币种赋值给变量v_currency)，顺序获取一个账号的计息明细记录R1......Rn。

(6)对每个账户v_account+币种v_currency计算出利息金额后更新账户余额表：

现金交易和结算交易都是基于账号+币种。

(7)对每个账户v_account+币种v_currency登记账户结息明细表。示例SQL如下：

(8)对每个账户v_account登记账户明细表：

(9)对每个账户更新计息明细表状态：

(10)对每个账号更新账户存款协议表：

基于账号币种更新账户存款协议表中的最后结息日期字段field4，机构号、柜员号等字段不用修改。

(11)更新银行内部记账表：结息总金额v_interest_all＝所有账户计息金额之和。

首先查询是否存在银行内部记账表记录：

若以上记录不存在则先插入一笔：

更新银行内部记账表：

对账处理(ACCVERIFY)-批量：

(1)每日日终启动对账；(2)获取系统时间作为交易日期v_workdate；(3)查询账户明细表，对每个账户计算当日汇总轧差金额；

后续对每个账户进行处理：

将上述查询的账号field1赋值给v_account、币种field2赋值给v_currency、当日汇总轧差金额AMT赋值给v_detail_amount_total：

(4)查询当前对账账户的当前余额和上期余额：

(5)计算RESAMT＝(当前余额-上期余额)-v_detail_amount_total。如果RESAMT！＝0则对账有误。

登记对账结果登记簿：

账户支付(ACCPAY)：(1)获取系统日期、时间作为交易日期v_workdate。(2)获取业务唯一编号v_seq，交易渠道上送的全局唯一id。(3)获取当前线程的执行柜员v_teller、执行机构v_institution；(4)设置业务发生账号v_account、业务发生币种v_currency、业务处理金额v_amount等业务信息。(5)检查机构是否存在。示例SQL如下：

如果记录不存在则报错。

(6)检查柜员是否存在。示例SQL如下：

如果记录不存在则报错。

(7)检查币种是否支持。示例SQL如下：

如果记录不存在则报错。

(8)业务防重控制。示例SQL如下：

如果记录已存在，则报错提示：业务重复发起。

(9)查询账户信息表：

如果账户不存在，则报错提示账户不存在。

如果账户存在，但状态不正常，则报错提示账户状态不正常。

(10)查询账户明细序号v_seq_account。示例SQL如下：

将查询结果赋值给账户明细序号v_seq_account。

查询计息明细序号v_seq_interest_accrual：

将查询结果赋值给计息明细序号v_seq_interest_accrual。

(11)查询账户余额表TABLE4。示例SQL如下：

如果记录不存在，则报错。如果记录存在，则获取账户当前余额赋值给v_balance。若账户余额v_balance<业务发生金额v_amount，则报错余额不足。

(12)登记账户计息明细表：如果账户余额表的最后交易日field5不等于当前交易日期v_workdate，则登记一笔计息明细：

(13)账户余额更新：

v_balance_old＝v_balance。

v_balance-＝v_amount。//当前余额-＝当前发生额。

如果账户余额表TABLE4的最后交易日FIELD5不等于当前交易日期v_workdate，则需要将当前余额更新到上期余额字段。

如果账户余额表TABLE4的最后交易日FIELD5等于当前交易日期v_workdate，则上期余额不变；并更新当前余额。示例SQL如下：

(14)插入账户明细表TABLE5。示例SQL如下：

(15)业务登记簿TABLE2插入一条记录，交易成功则插入成功，交易失败也要插入失败记录。示例SQL如下：

从上述描述可知，针对数据库基准测试领域现有技术存在的不足，本发明提供了一种场景丰富、指标全面的数据库基准测试方法，以交易场景为基础，通过抽象设计，涵盖吞吐量、交易响应时间、ACID事务等测试指标，涵盖数据库测评更多考察指标的数据库基准测试方法。具备如下有益效果：1.基于真实金融核心交易场景，详细披露金融系统交易处理流程和数据结构，基本可作为一个小型金融应用的详细设计说明书。2.覆盖联机热点交易、大批量处理等数据库高负载场景。3.系统可自举：真实金融系统一般存在对上下游系统的数据依赖，本发明通过经过脱敏抽象、简化设计和规范化处理，通过“账户开户”、“账户存款”交易完成测试初始化数据准备，通过“对账处理”交易实现数据一致性的校验，实现交易流程的闭环。

本发明实施例提供一种能够实现所述基于交易场景的数据库基准测试方法中全部内容的基于交易场景的数据库基准测试装置的具体实施方式，参见图4，所述基于交易场景的数据库基准测试装置具体包括如下内容：

接收模块10，用于接收输入的预设参数；

初始化模块20，用于初始化后，根据所述预设参数生成初始测试数据；

模拟模块30，用于通过至少两个线程来模拟交易柜员连接到存储所述初始测试数据的被测数据库；

测试模块40，用于在目标交易场景下周期性获取性能统计指标；其中，目标交易场景包括：每个线程按照预设比例执行目标交易处理流程；每天进行一次对账处理、每月进行一次结息处理以及每个线程的账户支付处理是向同一账户进行支付。

本发明提供的基于交易场景的数据库基准测试装置的实施例具体可以用于执行上述实施例中的基于交易场景的数据库基准测试方法的实施例的处理流程，其功能在此不再赘述，可以参照上述方法实施例的详细描述。

从上述描述可知，本发明实施例提供的基于交易场景的数据库基准测试装置，通过接收输入的预设参数；初始化后，根据所述预设参数生成初始测试数据；通过至少两个线程来模拟交易柜员连接到存储所述初始测试数据的被测数据库；在目标交易场景下周期性获取性能统计指标；其中，目标交易场景包括：每个线程按照预设比例执行目标交易处理流程；每天进行一次对账处理、每月进行一次结息处理以及每个线程的账户支付处理是向同一账户进行支付，能够提高数据库基准测试的准确性和安全性。

本申请提供一种用于实现所述基于交易场景的数据库基准测试方法中的全部或部分内容的电子设备的实施例所述电子设备具体包含有如下内容：

处理器(processor)、存储器(memory)、通信接口(Communications Interface)和总线；其中，所述处理器、存储器、通信接口通过所述总线完成相互间的通信；所述通信接口用于实现相关设备之间的信息传输；该电子设备可以是台式计算机、平板电脑及移动终端等，本实施例不限于此。在本实施例中，该电子设备可以参照实施例用于实现所述基于交易场景的数据库基准测试方法的实施例及用于实现所述基于交易场景的数据库基准测试装置的实施例进行实施，其内容被合并于此，重复之处不再赘述。

图5为本申请实施例的电子设备9600的系统构成的示意框图。如图5所示，该电子设备9600可以包括中央处理器9100和存储器9140；存储器9140耦合到中央处理器9100。值得注意的是，该图5是示例性的；还可以使用其他类型的结构，来补充或代替该结构，以实现电信功能或其他功能。

一实施例中，基于交易场景的数据库基准测试功能可以被集成到中央处理器9100中。其中，中央处理器9100可以被配置为进行如下控制：

接收输入的预设参数；初始化后，根据所述预设参数生成初始测试数据；通过至少两个线程来模拟交易柜员连接到存储所述初始测试数据的被测数据库；在目标交易场景下周期性获取性能统计指标；其中，目标交易场景包括：每个线程按照预设比例执行目标交易处理流程；每天进行一次对账处理、每月进行一次结息处理以及每个线程的账户支付处理是向同一账户进行支付。

在另一个实施方式中，基于交易场景的数据库基准测试装置可以与中央处理器9100分开配置，例如可以将基于交易场景的数据库基准测试配置为与中央处理器9100连接的芯片，通过中央处理器的控制来实现基于交易场景的数据库基准测试功能。

如图5所示，该电子设备9600还可以包括：通信模块9110、输入单元9120、音频处理器9130、显示器9160、电源9170。值得注意的是，电子设备9600也并不是必须要包括图5中所示的所有部件；此外，电子设备9600还可以包括图5中没有示出的部件，可以参考现有技术。

如图5所示，中央处理器9100有时也称为控制器或操作控件，可以包括微处理器或其他处理器装置和/或逻辑装置，该中央处理器9100接收输入并控制电子设备9600的各个部件的操作。

其中，存储器9140，例如可以是缓存器、闪存、硬驱、可移动介质、易失性存储器、非易失性存储器或其它合适装置中的一种或更多种。可储存上述与失败有关的信息，此外还可存储执行有关信息的程序。并且中央处理器9100可执行该存储器9140存储的该程序，以实现信息存储或处理等。

输入单元9120向中央处理器9100提供输入。该输入单元9120例如为按键或触摸输入装置。电源9170用于向电子设备9600提供电力。显示器9160用于进行图像和文字等显示对象的显示。该显示器例如可为LCD显示器，但并不限于此。

该存储器9140可以是固态存储器，例如，只读存储器(ROM)、随机存取存储器(RAM)、SIM卡等。还可以是这样的存储器，其即使在断电时也保存信息，可被选择性地擦除且设有更多数据，该存储器的示例有时被称为EPROM等。存储器9140还可以是某种其它类型的装置。存储器9140包括缓冲存储器9141(有时被称为缓冲器)。存储器9140可以包括应用/功能存储部9142，该应用/功能存储部9142用于存储应用程序和功能程序或用于通过中央处理器9100执行电子设备9600的操作的流程。

存储器9140还可以包括数据存储部9143，该数据存储部9143用于存储数据，例如联系人、数字数据、图片、声音和/或任何其他由电子设备使用的数据。存储器9140的驱动程序存储部9144可以包括电子设备的用于通信功能和/或用于执行电子设备的其他功能(如消息传送应用、通讯录应用等)的各种驱动程序。

通信模块9110即为经由天线9111发送和接收信号的发送机/接收机9110。通信模块(发送机/接收机)9110耦合到中央处理器9100，以提供输入信号和接收输出信号，这可以和常规移动通信终端的情况相同。

基于不同的通信技术，在同一电子设备中，可以设置有多个通信模块9110，如蜂窝网络模块、蓝牙模块和/或无线局域网模块等。通信模块(发送机/接收机)9110还经由音频处理器9130耦合到扬声器9131和麦克风9132，以经由扬声器9131提供音频输出，并接收来自麦克风9132的音频输入，从而实现通常的电信功能。音频处理器9130可以包括任何合适的缓冲器、解码器、放大器等。另外，音频处理器9130还耦合到中央处理器9100，从而使得可以通过麦克风9132能够在本机上录音，且使得可以通过扬声器9131来播放本机上存储的声音。

本发明的实施例还提供能够实现上述实施例中的基于交易场景的数据库基准测试方法中全部步骤的一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中的基于交易场景的数据库基准测试方法的全部步骤，例如，所述处理器执行所述计算机程序时实现下述步骤：

接收输入的预设参数；初始化后，根据所述预设参数生成初始测试数据；通过至少两个线程来模拟交易柜员连接到存储所述初始测试数据的被测数据库；在目标交易场景下周期性获取性能统计指标；其中，目标交易场景包括：每个线程按照预设比例执行目标交易处理流程；每天进行一次对账处理、每月进行一次结息处理以及每个线程的账户支付处理是向同一账户进行支付。

虽然本发明提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或客户端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

本发明是参照根据本发明实施例的方法、装置(系统)和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。需要说明的是，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。本发明并不局限于任何单一的方面，也不局限于任何单一的实施例，也不局限于这些方面和/或实施例的任意组合和/或置换。而且，可以单独使用本发明的每个方面和/或实施例或者与一个或更多其他方面和/或其实施例结合使用。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围，其均应涵盖在本发明的权利要求和说明书的范围当中。