CN113849372A - 一种数据库容量的确定方法和装置 - Google Patents

Abstract

本申请公开了一种数据库容量的确定方法和装置，该方法包括：获取系统调用链路中每个系统的链路信息，所述链路信息用于表征与系统操作相关的信息；根据所述每个系统的链路信息，确定具有数据库操作的第一系统；获取所述第一系统对数据库的操作日志；根据所述操作日志，确定所述数据库的容量。

Description

一种数据库容量的确定方法和装置

本文件是申请号为“201811228120.1”、申请日为“2018年10月22日”、申请名称为“一种数据库容量的确定方法和装置”的专利申请的分案申请。

技术领域

本申请涉及计算机技术领域，尤其涉及一种数据库容量的确定方法和装置。

背景技术

在互联网中，在为不同的业务提供服务时，可以采用分布式服务体系。分布式服务体系中通常包含多个系统，在为业务提供服务时，可以调用其中的一个或多个系统，被调用的一个或多个系统可以对不同的数据库进行操作，进而实现该业务。

分布式服务体系中系统被调用的先后顺序可以由系统调用链路表示，通常，为了更好地为业务提供服务，可以对系统调用链路进行压力测试。在进行压力测试之前，需要确定系统调用链路中系统操作的数据库的容量，即确定系统调用链路涉及到的每个数据库的容量，以便根据数据库的容量确定对系统调用链路的压力测试参数。

然而，在使用现有的方法确定系统调用链路涉及到的每个数据库的容量时，往往会遗漏掉其中一个或多个数据库，导致不能准确得到每个数据库的容量，进而无法有效地对系统调用链路进行压力测试。

发明内容

本申请实施例提供一种数据库容量的确定方法和装置，用于解决在使用现有的方法确定系统调用链路涉及到的数据库的容量时，由于会遗漏掉其中一个或多个数据库，导致不能准确得到每个数据库的容量的问题。

为解决上述技术问题，本申请实施例是这样实现的：

第一方面，提出一种数据库容量的确定方法，包括：

获取系统调用链路中每个系统的链路信息，所述链路信息用于表征与系统操作相关的信息；

根据所述每个系统的链路信息，确定具有数据库操作的第一系统；

获取所述第一系统对数据库的操作日志；

根据所述操作日志，确定所述数据库的容量。

第二方面，提出一种数据库容量的确定装置，包括：

第一获取单元，获取系统调用链路中每个系统的链路信息，所述链路信息用于表征与系统操作相关的信息；

第一确定单元，根据所述每个系统的链路信息，确定具有数据库操作的第一系统；

第二获取单元，获取所述第一系统对数据库的操作日志；

第二确定单元，根据所述操作日志，确定所述数据库的容量。

第三方面，提出一种电子设备，该电子设备包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，该可执行指令在被执行时使该处理器执行以下操作：

获取系统调用链路中每个系统的链路信息，所述链路信息用于表征与系统操作相关的信息；

根据所述每个系统的链路信息，确定具有数据库操作的第一系统；

获取所述第一系统对数据库的操作日志；

根据所述操作日志，确定所述数据库的容量。

第四方面，提出一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行以下方法：

获取系统调用链路中每个系统的链路信息，所述链路信息用于表征与系统操作相关的信息；

根据所述每个系统的链路信息，确定具有数据库操作的第一系统；

获取所述第一系统对数据库的操作日志；

根据所述操作日志，确定所述数据库的容量。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

本申请实施例提供的技术方案，在确定系统调用链路涉及到的数据库的容量时，由于可以获取系统调用链路中每个系统的链路信息，并根据链路信息确定具有数据库操作的系统，因此，可以避免系统遗漏的问题；在确定具有数据库操作的系统后，由于可以根据这些系统对数据库的操作日志确定数据库的容量，因此，不仅可以避免数据库遗漏的问题，还可以准确得到系统调用链路涉及到的每个数据库的容量；在得到系统调用链路涉及到的每个数据库的容量后，可以进一步得到对系统调用链路的较为准确的压力测试参数，进而有效地对系统调用链路进行压力测试。

附图说明

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

图1是本申请的一个实施例数据库容量的确定方法的流程示意图；

图2是本申请的一个实施例系统调用链路的示意图；

图3是本申请的一个实施例系统调用链路的示意图；

图4是本申请的一个实施例裁剪后的系统调用链路的示意图；

图5是本申请的一个实施例数据库容量的确定方法的流程示意图；

图6是本申请的一个实施例电子设备的结构示意图；

图7是本申请的一个实施例数据库容量的确定装置的结构示意图。

具体实施方式

分布式服务体系在为业务提供服务时，可以调用内部的多个系统，被调用的多个系统可以对数据库进行读写操作，以实现该业务。以互联网交易为例，在为互联网交易提供服务时，可以调用用于接收交易请求的系统、用于存储用户信息的系统、用于进行支付的支付系统、用于记录支付信息的系统、用于记录交易流水号的系统等，在调用这些系统时，不同的系统可以对不同的数据库进行读写操作，以完成互联网交易。

分布式服务系统中系统被调用的先后顺序可以由系统调用链路表示，通常，为了更好地为业务提供服务，可以对系统调用链路进行压力测试，特别是在业务高峰到达之前进行压力测试，这样，可以确定系统调用链路是否可以为业务提供稳定的服务。

在进行压力测试之前，需要确定系统调用链路中系统操作的每个数据库的容量，即确定系统调用链路涉及到的每个数据库的容量。在现有技术中，通常采用人工的方法确定每个数据库的容量。具体地，可以人工收集业务调用的系统以及这些系统操作的数据库等信息，基于这些信息确定系统调用链路涉及到的每个数据库的容量。

然而，在实际应用中，采用人工的方法往往会遗漏掉系统操作的一个或多个数据库，导致无法得到被遗漏的数据库的容量，进而无法有效地对对系统调用链路进行压力测试。

其中，数据库的遗漏问题主要体现在以下两个方面：

第一，遗漏掉系统调用链路中一个或多个具有数据库操作的系统，导致遗漏数据库。

例如，系统调用链路中实际有3个系统，但是人工仅收集到其中2个系统，遗漏掉1个系统，若被遗漏的系统具有数据库操作，则会遗漏掉该系统操作的一个或多个数据库。

第二，针对系统调用链路中某个系统，遗漏掉该系统操作的一个或多个数据库。

例如，系统实际对3个数据库进行了读写操作，但是人工仅收集到其中2个数据库，导致遗漏掉1个数据库。

在遗漏掉数据库的情况下，一方面，将无法得到被遗漏的数据库的容量，另一方面，如果被遗漏的数据库的容量较低，那么，在后续对系统调用链路进行压力测试时，由于压力测试参数是基于其他容量较高的数据库确定得到的，因此，针对被遗漏的数据库而言，压力测试参数的量级会超过数据库能够承受的最大量，导致数据库被压垮，当压力测试环境为线上环境时，还会导致业务出现问题。

由此可见，现有的确定数据库容量的方法不能准确得到系统调用链路涉及到的每个数据库的容量，从而不能有效地进行后续的压力测试。

为了解决上述技术问题，本申请实施例提供一种数据库容量的确定方法和装置，该方法包括：获取系统调用链路中每个系统的链路信息，所述链路信息用于表征与系统操作相关的信息；根据所述每个系统的链路信息，确定具有数据库操作的第一系统；获取所述第一系统对数据库的操作日志；根据所述操作日志，确定所述数据库的容量。

本申请实施例提供的技术方案至少可以达到如下有益效果：

(1)在确定系统调用链路涉及到的数据库的容量时，由于可以获取系统调用链路中每个系统的链路信息，并根据链路信息确定具有数据库操作的系统，因此，可以避免系统遗漏的问题；

(2)在确定具有数据库操作的系统后，由于可以根据这些系统对数据库的操作日志确定数据库的容量，因此，不仅可以避免数据库遗漏的问题，还可以准确得到系统调用链路涉及到的每个数据库的容量；

(3)在得到系统调用链路涉及到的每个数据库容量的后，可以进一步得到对系统调用链路的较为准确的压力测试参数，进而有效地对系统调用链路进行压力测试。

为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

本申请实施例中记载的分布式服务体系可以包含多个系统，并可以为互联网业务提供服务。分布式服务体系在为业务提供服务时，可以调用内部的一个或多个系统，这些系统被调用的先后顺序可以由系统调用链路表示，其中，这些系统被调用时可以对不同的数据库进行读写操作，这些系统操作的所有数据库可以视为所述系统调用链路涉及到的数据库。

数据库的容量可以包括以下至少一种：数据库的最大存储量，数据库在高并发场景下能够支持的最大连接数，其中，所述最大连接数可以理解为能够同时与数据库连接的系统的最大数量。

应理解，在其他实现方式中，数据库的容量也可以包括数据库其他指标，例如tps(transaction per second，每秒执行的事务数量)峰值、tps均值等，这里不再一一举例说明。

本申请实施例的提供的技术方案，可以应用于上述记载的分布式服务体系的应用场景中，并准确得到分布式服务体系中系统调用链路涉及到的每个数据库的容量，此外，也可以应用于需要确定数据库容量的其他应用场景中，这里也不再一一举例说明。

以下结合附图，详细说明本申请各实施例提供的技术方案。

图1是本申请的一个实施例数据库容量的确定方法的流程示意图。本实施例的应用场景可以是上述记载的分布式服务体系，所述方法如下所述。

S102：获取系统调用链路中每个系统的链路信息。

在S102中，在确定分布式服务体系中系统调用链路涉及到的每个数据库的容量时，可以获取该系统调用链路中每个系统的链路信息。

所述系统调用链路可以表征分布式服务体系中，为某个业务提供服务的多个系统被调用的先后顺序，其中，在为不同的业务提供服务时，不同的业务可以对应不同的系统调用链路，本申请实施例以一个业务对应的系统调用链路为例进行说明。

在一种实现方式中，所述系统调用链路的结构可以是链式结构。

以图2为例，图2中，系统调用链路中包括三个节点，一个节点可以代表一个系统，三个节点可以代表A、B、C三个系统，系统调用链路中的箭头可以表征系统被调用的先后顺序。

在另一种实现方式中，所述系统调用链路的结构还可以是树状结构。

以图3为例。图3中，系统调用链路可以包含八个节点，一个节点可以代表一个系统，八个节点可以代表A、B、C、D、E、F、G、H八个系统，系统调用链路中的箭头可以表征系统被调用的先后顺序。

应理解，系统调用链路的结构除了上述记载的链式结构和树状结构外，还可以是其他结构，这里不再一一举例说明。在实际应用中，系统调用链路的结构通常较为复杂，当系统调用链路的结构为链式结构和树状结构时，也不限于上述图2或图3记载的形状。

所述链路信息可以表征系统被调用并执行相应操作时，与系统操作相关的信息。

本申请实施例中，针对系统调用链路中的一个系统而言，该系统的链路信息可以包括系统标识、系统操作的数据库的标识、系统的数据库操作信息中的至少一种，其中，系统的数据库操作信息可以表征系统对数据库进行操作时的具体操作信息，例如对数据库中的某个数据表进行的读写操作等。

应理解，系统的链路信息还可以包含与系统操作相关的其他信息，这里不再一一举例说明。

本申请实施例在获取系统调用链路中每个系统的链路信息时，可以包括：

基于调用链路信息搜集系统，获取所述系统调用链路中每个系统的链路信息。

所述调用链路信息搜集系统可以理解为一种服务治理能力的底层中间件系统，能够通过日志埋点搜集业务一次调用的所有系统以及每个系统的操作信息，并提供业务被调用的先后顺序列表(即所述系统调用链路)，以及每个系统都执行了什么样的操作(即所述链路信息)。

本申请实施例中，针对一个业务，可以基于所述调用链路信息搜集系统搜集到该业务相关的日志，基于这些日志可以确定业务调用的系统对应的系统调用链路，基于系统调用链路，可以从这些日志中获取系统调用链路中每个系统的操作日志，基于每个系统的操作日志，可以分析得到系统调用链路中每个系统的链路信息。

在一种实现方式中，系统调用链路中每个系统的链路信息可以如下所示：

{

链路：[

{

系统名称：A，

数据源：[DB1，DB2]，

远程调用信息：{……}，

……

}，

{

系统名称：B，

数据源：NULL，

远程调用信息：{……}，

……

}，

{

系统名称：C，

数据源：[DB3]，

远程调用信息：{……}，

……

}，

……

]

}

上述记载的系统名称可以理解为系统标识，数据源可以理解为数据库的标识，远程调用信息等可以理解为与系统操作相关的信息。

在基于上述记载的方法获取到系统调用链路中每个系统的链路信息后，可以执行S104。

S104：根据所述每个系统的链路信息，确定具有数据库操作的第一系统。

在S104中，在获取到系统调用链路中的每个系统的链路信息后，可以基于每个系统的链路信息，从系统调用链路的多个系统中确定具有数据库操作的一个或多个系统。

本申请实施例中，为了便于区别，可以将具有数据库操作的一个或多个系统称为第一系统，基于每个系统的链路信息，确定具有数据库操作的第一系统，可以包括：

根据所述每个系统的链路信息，确定链路信息中包括数据库操作信息的至少一个系统；

将所述至少一个系统确定为所述第一系统。

具体地，针对每个系统，可以分析该系统的链路信息中是否包括数据库操作信息，如果是，则可以说明该系统对数据库进行了操作，即该系统为具有数据库操作的系统；如果否，则可以说明该系统没有对数据库进行操作，即该系统为不具有数据库操作的系统。

在得到具有数据库操作的一个或多个系统后，可以将这些系统作为所述第一系统。

应理解，在其他实现方式中，还可以通过其他方法确定具有数据库操作的第一系统，例如，可以将链路信息中包括数据库标识的至少一个系统作为所述第一系统(系统的链路信息中包括数据库的标识，可以意味着该系统具有相应的数据库操作)，等，这里不再一一举例说明。

本申请实施例中，由于可以获取系统调用链路中每个系统的链路信息，并根据链路信息确定具有数据库操作的第一系统，因此，可以准确得到系统调用链路中哪些系统进行了数据库操作，从而避免系统遗漏的问题。

在确定具有数据库操作的第一系统后，可以执行S106。

S106：获取所述第一系统对数据库的操作日志。

在S106中，在确定具有数据库操作的第一系统后，可以进一步获取第一系统对数据库进行操作时生成的操作日志。这样，可以便于后续基于数据库的操作日志确定数据库的容量。

本申请实施例中，可以获取第一系统操作的每个数据库的操作日志，以下以其中一个数据库为例进行说明。

通常，在获取第一系统对数据库的操作日志时，可以基于系统调用链路全量获取与系统调用链路相关的日志，并从全量获取的日志中获取第一系统对数据库的操作日志。

然而，系统调用链路中通常既包括具有数据库操作的第一系统，也包括不具有数据库操作的其他系统，由于不具有数据库操作的系统的日志与后续获取到的数据库操作日志以及确定数据库容量无关，因此，在一种实现方式中，为了简化获取数据库操作日志的步骤，在获取第一系统对数据库的操作日志之前，所述方法可以包括：

将所述系统调用链路中除所述第一系统以外的其他系统进行裁剪，得到裁剪后的系统调用链路。

所述第一系统以外的其他系统可以理解为系统调用链路中不具有数据库操作的系统，由于不具有数据库操作的系统并不影响后续步骤，因此，可以将系统调用链路中不具有数据操作的系统进行裁剪。

以图4为例，图4中，系统调用链路包括A、B、C、D、E、F、G、H八个系统，其中，系统A、C、D、G和H为具有数据库操作的系统，系统B、E和F为不具有数据库操作的系统。

图4中，在获取系统A、C、D、G和H各自对数据库的操作日志之前，可以将系统调用链路中的系统B、E和F裁剪掉，得到仅包含系统A、C、D、G和H的裁剪后的系统调用链路。

本申请实施例在得到裁剪后的系统调用链路后，可以全量获取与裁剪后的系统调用链路相关的目标日志，由于目标日志均为与第一系统相关的日志，因此，可以直接从目标日志中获取第一系统对数据库的操作日志，从而简化获取数据库操作日志的步骤。

在基于上述记载的方法获取到第一系统对其操作的每个数据库的操作日志后，可以执行S108.

S108：根据所述操作日志，确定所述数据库的容量。

在S108中，可以根据S106中获取的操作日志，确定第一系统操作的每一个数据库的容量，以下以其中一个数据库为例进行说明。

所述数据库的容量可以包括以下至少一种：数据库的最大存储量，数据库在高并发场景下能够支持的最大连接数。其中，所述最大存储量可以理解为数据库能够存储的最大数据量，所述最大连接数可以理解为能够同时与数据库连接的系统的最大数量。

在根据所述操作日志，确定所述数据库的容量时，可以包括：

根据所述操作日志，确定所述数据库的访问指标，所述访问指标包括所述数据库连接的系统个数、每秒执行的事务数量tps峰值以及tps均值中的至少一种；

根据所述访问指标，确定所述数据库的容量。

具体地，可以根据第一系统对数据库的操作日志，确定系统对数据库的具体访问情况，进而确定该数据库的访问指标，所述访问指标可以是数据库连接的系统个数，数据库的tps峰值以及tps均值中的至少一种，此外，所述访问指标还可以是与数据库访问相关的其他指标，例如，数据库的查询率QPS等，这里不再一一举例说明。

需要说明的是，在其他实现方式中，数据库的访问指标还可以从监控平台获取得到。其中，所述监控平台可以用于对数据库进行监控，在第一系统对数据库执行操作时，监控平台可以基于第一系统的操作日志，分析并记录第一系统对数据库的访问指标。这样，在确定数据库的容量时，可以从监控平台中获取相应的数据库访问指标。

在确定数据库的访问指标后，可以根据所述访问指标进一步确定数据库的容量。

本申请实施例中，由于可以根据系统对数据库的操作日志确定数据库的容量，因此，一方面可以避免数据库遗漏的问题，另一方面还可以准确得到系统调用链路涉及到的每个数据库的容量。

在本申请的一个实施例中，在确定系统调用链路涉及到的每个数据库的容量后，可以根据数据库的容量以及业务的变化规律，预测数据库在未来时间内的容量。

例如，数据库A的tps峰值为20万，业务在未来某段时间内将按照1:1.5的比例增长，那么，可以预测在未来的该段时间内，数据库A的tps峰值可以达到为30万。

这样，通过预测数据库在未来时间内的容量，可以为评估数据库提供准确有效的数据，同时为数据库中关键指标的容量规划提供数据支撑。

在本申请的另一个实施例中，在确定系统调用链路涉及到的每个数据库的容量后，还可以根据数据库的容量以及对该系统调用链路的压力测试条件，确定对系统调用链路的压力测试参数，并基于压力测试参数对系统调用链路进行压力测试。

这样，由于系统调用链路中每个数据库的容量可以基于上述记载的方法准确得到，因此，基于数据库容量得到的压力测试参数也较为准确，从而基于压力测试参数可以有效地对系统调用链路进行压力测试。

本申请实施例提供的技术方案，在确定系统调用链路涉及到的数据库的容量时，由于可以获取系统调用链路中每个系统的链路信息，并根据链路信息确定具有数据库操作的系统，因此，可以避免系统遗漏的问题；在确定具有数据库操作的系统后，由于可以根据这些系统对数据库的操作日志确定数据库的容量，因此，不仅可以避免数据库遗漏的问题，还可以准确得到系统调用链路涉及到的每个数据库的容量；在得到系统调用链路涉及到的每个数据库的容量后，可以进一步得到对系统调用链路的较为准确的压力测试参数，进而有效地对系统调用链路进行压力测试。

为了便于理解整个技术方案，可以参见图5。图5为本申请的一个实施例数据库容量的确定方法的流程示意图。所述方法如下所述。

S501：获取系统调用链路中每个系统的链路信息。

在S510中，可以基于调用链路信息搜集系统，获取系统调用链路中每个系统的链路信息，所述调用链路信息搜集系统与上述图1所示实施例中记载的调用链路信息搜集系统相同，这里不再重复说明。

所述链路信息与图1所示实施例中记载的链路信息相同，可以表征与系统操作相关的信息，针对一个系统，该系统的链路信息可以包括系统标识，系统操作的数据库的标识以及系统的数据库操作信息中的至少一种。

具体地，可以根据业务，基于所述调用链路信息搜集系统获取该业务的系统调用链路，同时，也可以获取到系统调用链路中每个系统的链路信息。其中，所述系统调用链路的结构可以是链式结构，也可以是树状结构，具体可以参见图2或图3，这里不再重复说明。

本申请实施例中，针对不同的业务，基于所述调用链路信息搜集系统可以获取到不同的系统调用链路以及不同的链路信息，这里仅以一个业务为例进行说明。

S502：根据所述每个系统的链路信息，确定具有数据库操作的第一系统。

在S502中，根据系统调用链路中每个系统的链路信息，可以将链路信息中具有数据库操作信息的一个或多个系统作为具有数据库操作的第一系统。

此外，也可以将链路信息中具有数据库标识的一个或多个系统作为具有数据库操作的第一系统。

S503：将所述系统调用链路中除所述第一系统以外的其他系统进行裁剪，得到裁剪后的系统调用链路。

系统调用链路中通常可以包括具有数据库操作的系统，也可以包括不具有数据库操作的系统，由于不具有数据库操作的系统的日志与后续获取到的数据库操作日志以及确定数据库容量无关，因此，可以裁剪掉不具有数据库操作的系统，以简化后续获取数据库操作日志的步骤。

S504：基于裁剪后的系统调用链路，获取所述第一系统对数据库的操作日志。

在S504中，可以获取第一系统对每一个数据库的操作日志。

以一个数据库为例，可以首先获取与所述裁剪后的系统调用链路相关的目标日志，其次从所述目标日志中获取所述第一系统对数据库的操作日志。

S505：根据所述操作日志，确定所述数据库的访问指标。

以一个数据库为例，所述访问指标包括所述数据库连接的系统个数、每秒执行的事务数量tps峰值以及tps均值中的至少一种，所述访问指标可以基于数据库的操作日志分析得到。

需要说明的是，在其他实现方式中，也可以直接从监控平台获取数据库的访问指标，其中，所述监控平台可以基于数据库的操作日志对数据库的访问情况进行监控，并基于数据库的操作日志分析并记录数据库的访问指标。

S506：根据所述访问指标，确定所述数据库的容量。

上述以确定一个系统调用链路涉及到的数据库的容量为例进行说明，在实际应用中，不同的业务可以对应不同的系统调用链路，针对每个系统调用链路，在确定其涉及到的每个数据库的容量时，都可以通过上述记载的方法确定得到，这里不再重复说明。

在确定系统调用链路涉及到的每个数据库的容量后，在一种实现方式中，可以根据数据库的容量以及业务的变化规律，预测数据库在未来时间内的容量；在另一种实现方式中，可以根据数据量的容量以及对系统调用链路的压力测试条件，确定压力测试参数，并基于压力测试参数对系统调用链路进行压力测试，具体可以参见图1所示实施例记载的内容，这里都不再重复说明。

本申请实施例提供的技术方案，在确定系统调用链路涉及到的数据库的容量时，一方面可以避免系统遗漏和数据库遗漏的问题，另一方面还可以提供工具化的评估手段，准确得到系统调用链路涉及到的每个数据库的容量。在得到系统调用链路涉及到的每个数据库的容量后，可以进一步得到对系统调用链路的较为准确的压力测试参数，进而有效地对系统调用链路进行压力测试。

上述对本申请特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

图6是本申请的一个实施例电子设备的结构示意图。请参考图6，在硬件层面，该电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(Random-Access Memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。

处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是ISA(Industry Standard Architecture，工业标准体系结构)总线、PCI(PeripheralComponent Interconnect，外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。

处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成数据库容量的确定装置。处理器，执行存储器所存放的程序，并具体用于执行以下操作：

获取系统调用链路中每个系统的链路信息，所述链路信息用于表征与系统操作相关的信息；

根据所述每个系统的链路信息，确定具有数据库操作的第一系统；

获取所述第一系统对数据库的操作日志；

根据所述操作日志，确定所述数据库的容量。

上述如本申请图6所示实施例揭示的数据库容量的确定装置执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(Central ProcessingUnit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(DigitalSignal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

该电子设备还可执行图1和图5的方法，并实现数据库容量的确定装置在图1和图5所示实施例中的功能，本申请实施例在此不再赘述。

当然，除了软件实现方式之外，本申请的电子设备并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

本申请实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的便携式电子设备执行时，能够使该便携式电子设备执行图1和图5所示实施例的方法，并具体用于执行以下操作：

获取系统调用链路中每个系统的链路信息，所述链路信息用于表征与系统操作相关的信息；

根据所述每个系统的链路信息，确定具有数据库操作的第一系统；

获取所述第一系统对数据库的操作日志；

根据所述操作日志，确定所述数据库的容量。

图7是本申请的一个实施例数据库容量的确定装置70的结构示意图。请参考图7，在一种软件实施方式中，所述数据库容量的确定装置70可包括：第一获取单元71、第一确定单元72、第二获取单元73和第二确定单元74，其中：

第一获取单元71，获取系统调用链路中每个系统的链路信息，所述链路信息用于表征与系统操作相关的信息；

第一确定单元72，根据所述每个系统的链路信息，确定具有数据库操作的第一系统；

第二获取单元73，获取所述第一系统对数据库的操作日志；

第二确定单元74，根据所述操作日志，确定所述数据库的容量。

可选地，针对所述系统调用链路中的一个系统，所述系统的链路信息包括以下至少一种：

所述系统的系统标识；

所述系统操作的数据库的标识；

所述系统的数据库操作信息，所述数据库操作信息用于表征所述系统对数据库的具体操作。

可选地，所述第一确定单元72，根据所述每个系统的链路信息，确定具有数据库操作的第一系统，包括：

根据所述每个系统的链路信息，确定链路信息中包括数据库操作信息的至少一个系统；

将所述至少一个系统确定为所述第一系统。

可选地，所述数据库容量的确定装置70还包括：裁剪单元75，其中：

所述裁剪单元75，在所述第二获取单元73获取所述第一系统对数据库的操作日志之前，将所述系统调用链路中除所述第一系统以外的其他系统进行裁剪，得到裁剪后的系统调用链路；

其中，所述第二获取单元73获取所述第一系统对数据库的操作日志，包括：

获取与所述裁剪后的系统调用链路相关的目标日志；

从所述目标日志中获取所述第一系统对数据库的操作日志。

可选地，所述第二确定单元74根据所述操作日志，确定所述数据库的容量，包括：

根据所述操作日志，确定所述数据库的访问指标，所述访问指标包括所述数据库连接的系统个数、每秒执行的事务数量tps峰值以及tps均值中的至少一种；

根据所述访问指标，确定所述数据库的容量。

可选地，所述第一获取单元71获取系统调用链路中每个系统的链路信息，包括：

基于调用链路信息搜集系统，获取所述系统调用链路中每个系统的链路信息。

可选地，所述数据库容量的确定装置70还包括：预测单元76，其中：

所述预测单元76，在所述第二确定单元74根据所述操作日志，确定所述数据库的容量后，根据所述数据库的容量以及所述业务的变化规律，预测所述数据库在未来时间内的容量。

可选地，所述数据库容量的确定装置70还包括：压力测试单元77，其中：

所述压力测试单元77，在所述第二确定单元74根据所述操作日志，确定所述数据库的容量后，根据所述数据量的容量以及对所述系统调用链路的压力测试条件，确定压力测试参数；

基于所述压力测试参数，对所述系统调用链路进行压力测试。

本申请实施例提供的数据库容量的确定装置70还可执行图1和图5的方法，并实现数据库容量的确定装置在图1和图5所示实施例的功能，本申请实施例在此不再赘述。

总之，以上所述仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本申请中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

Claims (17)

1.一种数据库容量的确定方法，包括：

确定系统调用链路中具有数据库操作的第一系统；

获取所述第一系统对数据库的目标操作信息；

根据所述目标操作信息，确定所述数据库的容量。

2.如权利要求1所述的方法，确定系统调用链路中具有数据库操作的第一系统，包括：

获取所述系统调用链路中每个系统的链路信息，所述链路信息用于表征与系统操作相关的信息；

根据所述每个系统的链路信息，确定具有数据库操作的第一系统。

3.如权利要求2所述的方法，针对所述系统调用链路中的一个系统，所述系统的链路信息包括以下至少一种：

所述系统的系统标识；

所述系统操作的数据库的标识；

所述系统的数据库操作信息，所述数据库操作信息用于表征所述系统对数据库的具体操作。

4.如权利要求3所述的方法，根据所述每个系统的链路信息，确定具有数据库操作的第一系统，包括：

根据所述每个系统的链路信息，确定链路信息中包括数据库操作信息的至少一个系统；

将所述至少一个系统确定为所述第一系统。

5.如权利要求3所述的方法，根据所述每个系统的链路信息，确定具有数据库操作的第一系统，包括：

根据所述每个系统的链路信息，确定链路信息中包括数据库的标识的至少一个系统；

将所述至少一个系统确定为所述第一系统。

6.如权利要求1所述的方法，获取所述第一系统对数据库的目标操作信息，包括：

获取所述第一系统对数据库的操作日志。

7.如权利要求6所述的方法，在获取所述第一系统对数据库的操作日志之前，所述方法还包括：

将所述系统调用链路中除所述第一系统以外的其他系统进行裁剪，得到裁剪后的系统调用链路；

其中，获取所述第一系统对数据库的操作日志，包括：

获取与所述裁剪后的系统调用链路相关的目标日志；

从所述目标日志中获取所述第一系统对数据库的操作日志。

8.如权利要求6所述的方法，根据所述目标操作信息，确定所述数据库的容量，包括：

根据所述操作日志，确定所述数据库的访问指标，所述访问指标包括所述数据库连接的系统个数、每秒执行的事务数量tps峰值以及tps均值中的至少一种；

根据所述访问指标，确定所述数据库的容量。

9.如权利要求2所述的方法，获取系统调用链路中每个系统的链路信息，包括：

基于调用链路信息搜集系统，获取所述系统调用链路中每个系统的链路信息。

10.如权利要求9所述的方法，基于调用链路信息搜集系统，获取所述系统调用链路中每个系统的链路信息，包括：

基于所述调用链路信息搜集系统中的日志埋点获取与业务相关的日志；

基于所述与业务相关的日志，获取所述系统调用链路中每个系统的链路信息，所述系统调用链路为所述业务调用的系统所对应的调用链路。

11.如权利要求1所述的方法，所述数据库的容量包括以下至少一种：

数据库的最大存储量；

数据库在高并发场景下能够支持的最大连接数；

其中，所述最大存储量表征数据库能够存储的最大数据量，所述最大连接数表征能够同时与数据库连接的系统的最大数量。

12.如权利要求1所述的方法，在根据所述目标操作信息，确定所述数据库的容量后，所述方法还包括：

根据所述数据库的容量以及业务的变化规律，预测所述数据库在未来时间内的容量。

13.如权利要求1所述的方法，在根据所述目标操作信息，确定所述数据库的容量后，所述方法还包括：

根据所述数据库的容量以及对所述系统调用链路的压力测试条件，确定压力测试参数；

基于所述压力测试参数，对所述系统调用链路进行压力测试。

14.如权利要求1所述的方法，

所述系统调用链路为分布式服务体系中包括的多个系统的调用链路，所述分布式服务体系用于为互联网业务提供服务，所述系统调用链路的链路结构包括链式结构和树状结构中的至少一种。

15.一种数据库容量的确定装置，包括：

第一确定单元，确定系统调用链路中具有数据库操作的第一系统；

第二获取单元，获取所述第一系统对数据库的目标操作信息；

第二确定单元，根据所述目标操作信息，确定所述数据库的容量。

16.一种电子设备，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，该可执行指令在被执行时使该处理器执行以下操作：

确定系统调用链路中具有数据库操作的第一系统；

获取所述第一系统对数据库的目标操作信息；

根据所述目标操作信息，确定所述数据库的容量。

17.一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行以下方法：

确定系统调用链路中具有数据库操作的第一系统；

获取所述第一系统对数据库的目标操作信息；

根据所述目标操作信息，确定所述数据库的容量。

Images