Query parameter determination method, storage medium, equipment and program product

Abstract

The invention discloses a query parameter determination method, a storage medium, equipment and a program product. According to the method, the number of edges, belonging to different query dimensions and different value intervals, of each vertex contained in the to-be-tested graph database is counted in advance and serves as statistical data of the vertexes to be stored, and therefore when query parameters needed for testing the to-be-tested graph database are determined, the query parameters can be accurately determined, and the test efficiency is improved. The method comprises the following steps: determining a query cost value corresponding to a query statement obtained after configuring different query parameters for a query statement template according to a target value interval and vertex statistical data used in the query statement template; according to the query cost value corresponding to the query statement obtained when each query parameter is configured into the query statement template, a group of corresponding query parameters with consistent query cost are selected from the query parameters to serve as target query parameters, and the to-be-tested graph database is effectively tested according to the target query parameters.

Description

Technical Field

[0001] The present specification relates to the field of database technology, and in particular to a method for determining query parameters, a storage medium, a device, and a program product. Background Art

[0002] At present, different graph databases have different applicability in different application scenarios such as social network analysis, recommendation systems, finance, network security, etc., due to the differences in data structures, query modes, performance requirements and functional characteristics when they are designed. The graph database benchmarking method can evaluate the performance, efficiency and stability of different graph databases when processing specific types of data and complex queries based on standardized testing processes and indicators, thereby helping developers and enterprises optimize graph databases for different application scenarios.

[0003] Normally, when using the graph database benchmark test method to test a graph database, it is necessary to simulate the formal working scenario of the graph database, generate multiple read query statements in advance according to the query statement template and input them into the graph database to be tested, and obtain the test results for the graph database to be tested based on indicator data such as the response time when the graph database to be tested executes these read query statements, and the accuracy of the query results obtained by the graph database to be tested when executing these read query statements.

[0004] However, because the distribution of vertices and edges stored in the graph database is not uniform, and in the process of generating each read query statement for testing, the query parameters configured for the query statement template are often random, which leads to very different test results obtained by testing the graph database based on different read query statements generated by the same query statement template.

[0005] For example, in the query statement template MATCH(p:Account{account_id:$ID})-[:TRANSFER]->(other:Account)RETURN other.account_id, which is used to query accounts with direct transfer relationships, $ID is a placeholder for the query parameter that needs to be determined. When different starting vertices are configured for the above query statement template, the following results can be obtained: MATCH(p:Account{account_id:'0001'})-[:TRANSFER]->(other:Account)RETURN other.account_id (i.e., query other account vertices that have a direct transaction relationship with the account vertex numbered 0001), MATCH(p:Account{account_id:'0002'})-[:TRANSFER]->(other:Account)RETURN other.account_id (i.e., query other account vertices that have a direct transaction relationship with the account vertex numbered 0002), and since the distribution of vertices and edges stored in the graph database is not uniform, at this time, the account vertex numbered 0001 may have a transaction relationship with multiple other account vertices, while the account vertex numbered 0002 may have almost no transaction relationship with other account vertices, resulting in the graph database to be tested executing a query statement for the account vertex numbered 0001 to traverse more vertices than executing a query statement for the account vertex numbered 0002, and the corresponding query cost is also greater, which leads to a large difference between the test results determined by the query statement for the account vertex numbered 0001 and the test results determined by the query statement for the account vertex numbered 0002.

[0006] It is precisely because the test results obtained by testing the graph database using different read query statements generated according to the same query statement template are quite different, which makes it impossible to effectively test the performance of the graph database. Summary of the invention

[0007] The embodiments of this specification provide a method, storage medium, device and program product for determining a query parameter to partially solve the problems existing in the above-mentioned prior art.

[0008] The embodiments of this specification adopt the following technical solutions:

[0009] This specification provides a method for determining a query parameter, including:

[0010] Obtaining statistical data of each vertex, each candidate query parameter, and a query statement template, wherein the statistical data of each vertex is used to characterize the number of edges belonging to different value intervals of each vertex in the graph database to be tested under a preset query dimension;

[0011] According to the target value interval under the preset query dimension contained in the query statement template, determining the target vertex statistical data matching the query statement template from the vertex statistical data;

[0012] Determine a query cost value of each candidate query parameter according to the target vertex statistical data; wherein the query cost value of each candidate query parameter is used to represent: the number of vertices and the number of edges to be traversed when executing a query statement obtained after configuring the query statement template according to the candidate query parameter;

[0013] According to the query cost value, a target query parameter is determined from the candidate query parameters for use in testing the graph database to be tested.

[0014] This specification provides a computer-readable storage medium, wherein the storage medium stores a computer program, and when the computer program is executed by a processor, the above-mentioned method for determining a query parameter is implemented.

[0015] The present specification provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the above-mentioned method for determining a query parameter when executing the program.

[0016] At least one of the above technical solutions adopted in the embodiments of this specification can achieve the following beneficial effects:

[0017] In an embodiment of the present specification, firstly, vertex statistics, candidate query parameters and query statement templates are obtained to characterize the number of edges belonging to different value intervals for each vertex in the graph database to be tested under a preset query dimension, so as to determine target vertex statistics matching the query statement template from the vertex statistics according to the target value interval under the preset query dimension contained in the query statement template, and then determine the query cost value of each candidate query parameter according to the target vertex statistics, wherein the query cost value of each candidate query parameter is used to characterize the number of vertices and the number of edges to be traversed when executing a query statement obtained after configuring the query statement template according to the alternative query parameter, and finally, according to the query cost value, the target query parameter is determined from the candidate query parameters for use in testing the graph database to be tested.

[0018] In this method, the number of edges belonging to different query dimensions and different value ranges for each vertex included in the graph database to be tested can be counted in advance and saved as statistical data of each vertex. Therefore, when determining the query parameters required to test the graph database to be tested, the query cost corresponding to the query statement obtained after configuring different query parameters for the query statement template can be determined based on the target value range used in the query statement template and the statistical data of each vertex. Then, based on the query cost corresponding to the query statement obtained when each query parameter is configured in the query statement template, a group of corresponding query parameters with consistent query costs can be selected from each query parameter as target query parameters, and the graph database to be tested can be effectively tested based on the target query parameters. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The drawings described herein are used to provide a further understanding of this specification and constitute a part of this specification. The illustrative embodiments and descriptions of this specification are used to explain this specification and do not constitute an improper limitation on this specification. In the drawings:

[0020] Figure 1 is a schematic diagram of a graph database benchmarking method provided by an exemplary embodiment;

[0021] Figure 2 is a flowchart of a method for determining a query parameter provided by an exemplary embodiment;

[0022] Figure 3 is a schematic diagram of data distribution characteristics in a financial scenario provided by an exemplary embodiment;

[0023] Figure 4 is a schematic diagram of a method for determining vertex statistics of a first vertex provided by an exemplary embodiment;

[0024] Figure 5 is a schematic diagram of a method for determining vertex statistics of a second vertex provided by an exemplary embodiment;

[0025] Figure 6 is a schematic diagram of a method for determining vertex statistics of a third type of vertex provided by an exemplary embodiment;

[0026] Figure 7 is a schematic diagram of a method for determining vertex statistics of a fourth type of vertex provided by an exemplary embodiment;

[0027] Figure 8 is a structural schematic diagram of a device provided by an exemplary embodiment;

[0028] Fig. 9It is a block diagram of a device for determining a query parameter provided by an exemplary embodiment. DETAILED DESCRIPTION

[0029] In order to make the purpose, technical solutions and advantages of this specification more clear, the technical solutions of this specification will be clearly and completely described below in combination with the specific embodiments of this specification and the corresponding drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this specification.

[0030] At present, due to the differences in data structures, query modes, performance requirements and functional characteristics of different graph databases when they are designed, different graph databases have different applicability in different application scenarios such as social network analysis, recommendation systems, finance, network security, etc. The graph database benchmarking method can evaluate the performance, efficiency and stability of different graph databases when processing specific types of data and complex queries based on standardized testing processes and indicators, thereby helping developers and enterprises to optimize graph databases used in different application scenarios. When benchmarking graph databases, you can use the preset benchmark suite toolkit (LDBC Social Network Benchmark, LDBCSNB) to perform the test. Figure 1 shown.

[0031] Figure 1 It is a schematic diagram of a graph database benchmarking method provided by an exemplary embodiment.

[0032] Combination Figure 1It can be seen that SNB includes a data generator, a parameter generator, and a test driver. First, before starting to test the graph database to be tested, in order to simulate the real application scenario, it is necessary to first generate large-scale complex graph data with the characteristics of the specified application scenario (for example, social network analysis, recommendation system, finance, network security, etc.) through the data generator, so that the generated graph data can be loaded into the graph database to be tested in a bulk load manner to initialize the graph database to be tested, and then the query parameters can be generated through the parameter generator, and the generated query parameters can be sent to the test driver, so that the test driver can determine the read query statement for testing the graph database to be tested according to the received query parameters, and test the performance of the graph database to be tested when processing large-scale data in the specified application scenario according to the read query statement. Finally, the test result for the graph database to be tested can be determined according to the response time of the graph database to be tested when executing the read query statement and the accuracy of the query result obtained by executing the read query statement.

[0033] Among them, since the distribution of vertices and edges of the graph data in the graph database to be tested is not uniform, the query cost of the graph database to be tested when executing read query statements that traverse queries from different starting vertices is also different, resulting in randomness in the final test results for the graph database to be tested, which in turn makes it difficult for developers and enterprises to optimize the graph database. When it is determined that the graph database to be tested has an abnormality based on the test results of the graph database to be tested, it is impossible to determine whether the cause of the abnormality is a problem with the graph database to be tested itself or a problem with the query parameter settings.

[0034] The technical solutions provided by the embodiments of this specification are described in detail below in conjunction with the accompanying drawings.

[0035] Figure 2 The following is a flowchart of a method for determining a query parameter provided by an exemplary embodiment, including:

[0036] S200: Obtaining statistical data of each vertex, each candidate query parameter and a query statement template, wherein the statistical data of each vertex is used to characterize the number of edges belonging to different value intervals under a preset query dimension for each vertex in the graph database to be tested.

[0037] In this specification, the business platform can obtain the statistical data of each vertex, each alternative query parameter and the query statement template, and then can determine the query cost value of the query statement obtained after configuring the query statement template according to each alternative query parameter according to the statistical data of each vertex, as the query cost value corresponding to each alternative query parameter, and then according to the query cost value corresponding to each alternative query parameter, screen out the alternative query parameters with similar corresponding query cost values ​​from the alternative query parameters for testing the graph database to be tested, thereby avoiding randomness in the test results of the graph database to be tested, and then effectively testing the graph database to be tested.

[0038] Prior to this, the business platform can receive the test request sent by the user, and determine the graph database to be tested based on the received test request, and then determine whether the graph database to be tested has been installed and running in the preset test environment. If not, the graph database to be tested can be installed.

[0039] The test request may be an instruction or script for starting a benchmark test on the graph database to be tested, and the test request may include identification information of the graph database to be tested.

[0040] Furthermore, the business platform can determine the target application scenario required for testing the graph database to be tested, and can generate full data that meets the data distribution characteristics under the target application scenario, and then can import the generated full data into the graph database to be tested, and test the graph database to be tested based on the imported full data.

[0041] In the above content, there are multiple methods for the business platform to determine the target application scenario required for testing the graph database to be tested. For example: determine the target application scenario based on the identification information used to characterize the target application scenario specified by the user contained in the received test request. Another example: use the preset specified application scenario as the target application scenario.

[0042] In the above content, the full amount of data that meets the data distribution characteristics in the target application scenario may refer to a data set containing entities, attributes of entities, and relationships between entities involved in the target application scenario. The following takes the target application scenario as an example of a financial scenario to explain in detail the full amount of data that meets the data distribution characteristics in the target application scenario. Figure 3 shown.

[0043] Figure 3 It is a schematic diagram of data distribution characteristics in a financial scenario provided by an exemplary embodiment.

[0044] Combination Figure 3It can be seen that in the financial scenario, the entities contained in the graph data that need to be saved in the graph database may include: user Person, account Account, company Company, loan Loan, login medium (login device) Medlum, etc. Among them, the relationship between entities may include: transfer relationship (transaction relationship) between accounts, withdrawal relationship between accounts, guarantee relationship between users, holding relationship between users and accounts, investment relationship between users and companies, guarantee relationship between companies, investment relationship between companies, application relationship between companies and loans, holding relationship between companies and accounts, deposit relationship between loans and accounts, payment relationship between accounts and loans, signin relationship between accounts and media, etc.

[0045] For each entity, the entity may contain a series of attributes. For example, for an account entity, the attributes contained in the entity may include: the unique identifier of the account id, the creation time of the account createTime, whether the account is blacklisted isBlock, the account type type, the account nickname nickname, the contact information phoneNumber, etc.

[0046] For another example, for a user entity, the attributes contained in the entity may include: the user's unique identifier id, the user's name name, whether the user is blacklisted isBlock, the time when the user record is created createTime, etc.

[0047] Furthermore, the business platform may generate full data for initializing the graph database to be tested based on the data distribution characteristics in the above-mentioned financial scenario.

[0048] Specifically, the business platform can generate vertices corresponding to each entity according to the attributes contained in the entity, and thus can generate edges between vertices according to the relationship between entities to obtain the full amount of data. The values ​​of the attributes contained in different vertices of the entity are not exactly the same, and the values ​​of the attributes contained in different edges are also not exactly the same.

[0049] For example, for the user entity, each vertex can be generated according to the attributes of the user entity, such as: the user's unique identifier is 009, the user name is Mr. Zhang, whether the user is blacklisted is No, the user record was created on October 13, 2023, the user's gender is male, and the user's birthday is June 19, 1982. The user's unique identifier is 005, the user name is Ms. Li, whether the user is blacklisted is No, the user record was created on January 27, 2012, the user's gender is female, and the user's birthday is April 5, 1995. The user vertex, etc.

[0050] As another example: for the edge between the account entity and the login medium entity, the edge between the account vertex and the login medium vertex can be generated according to the preset attributes of the edge between the account entity and the login medium entity (such as: login time, login address, login authentication method, login Internet Protocol address (IP)). For example, the specific values ​​of the attributes of the edge between the account vertex uniquely identified as 10001 and the login medium uniquely identified as X0005 can be: login time is January 1, 2024, login address is Beijing, login authentication method is password authentication, and login IP address is 192.168.1.1.

[0051] It should be noted that there are many ways for the business platform to generate the above-mentioned full data, for example: through the data generation tool contained in the pre-installed SNB, each vertex and edge is generated as the full data according to the data distribution characteristics under the above-mentioned target application scenario.

[0052] For another example: through the preset large language model, according to the data distribution characteristics in the above-mentioned target application scenario, each vertex and each edge are generated as the full data.

[0053] Furthermore, after the business platform imports the generated full data into the graph database to be tested, it can determine the query dimensions that match the full data imported into the graph database to be tested from the preset reference query dimensions, and then, based on the query dimensions that match the full data imported into the graph database to be tested, it can perform statistics on the graph data contained in the graph database to be tested to obtain statistical data of each vertex.

[0054] Among them, different vertex statistics are used to reflect the number of edges belonging to different value ranges for each vertex in the graph database to be tested under each query dimension in different preset query dimensions.

[0055] The above-mentioned preset query dimensions may refer to different attributes or features used to organize and filter data when performing data query. The query dimensions here may be attribute value dimensions, path length dimensions, edge type dimensions, edge weight dimensions, etc. Among them, the above-mentioned attribute value dimension is used to filter the vertices and edges that need to be traversed according to the value of the target attribute field contained in each edge of the vertex. The above-mentioned path length dimension is used to filter the vertices and edges that need to be traversed according to the path length between two vertices, where the path length is used to represent the number of edges contained in the path formed by the edges between the two vertices connected in sequence. The above-mentioned edge type dimension is used to filter the vertices and edges that need to be traversed according to the type of each edge contained in the vertex. The above-mentioned edge weight dimension is used to filter the vertices and edges that need to be traversed according to the weight of each edge contained in the vertex.

[0056] The following is a detailed description of the methods for determining the statistical data of each vertex according to different query dimensions.

[0057] First, when determining the statistics of each vertex according to the attribute value dimension, for each vertex contained in the graph database to be tested, the edges of the vertex can be divided according to the value of the target attribute field contained in each edge of the vertex to obtain each first-class edge set, and then the vertex statistics of the vertex can be determined according to the number of edges contained in each edge set.

[0058] The target attribute field mentioned above can be determined according to actual needs, and the target attribute field here can be any attribute field contained in the edge of the vertex.

[0059] For example, for an edge used to represent a transaction relationship, it may contain attribute fields such as transaction time, transaction amount, transaction type, etc. In this case, the attribute field used to represent the transaction amount contained in the edge can be used as the target attribute field. Of course, the field used to represent the transaction time contained in the edge can also be used as the target attribute field.

[0060] The above-mentioned edge sets can be determined according to the range of the value of the target attribute field obtained in advance, that is, the business platform can obtain the reference range of the value of the target attribute field, and thus can determine each first-class edge set according to the reference range. Different first-class edge sets can correspond to different intervals in the reference range, that is, different value intervals.

[0061] Furthermore, for each vertex contained in the graph database to be tested, the edges of the vertex can be divided into first-class edge sets according to the value of the target attribute field contained in each edge of the vertex, and the vertex statistics of the vertex can be obtained according to the number of edges divided into each first-class edge set by the vertex.

[0062] For ease of understanding, the following describes in detail the method for determining the vertex statistics of the vertex, taking the target attribute field as the transaction amount field. Figure 4 shown.

[0063] Figure 4 It is a schematic diagram of a method for determining vertex statistics of a first vertex provided by an exemplary embodiment.

[0064] Combination Figure 4 It can be seen that the business platform can pre-acquire the value range of the target attribute field of each edge contained in the test graph database as a reference range, and then divide the reference range into various value intervals, and determine each first-class edge set according to each value interval, such as Figure 4 The transaction amount shown in the table is less than 10,000, greater than 10,000 and less than 30,000, greater than 30,000 and less than 100,000, etc.

[0065] Among them, the range of values ​​of the target attribute field of each edge contained in the test graph database obtained by the business platform may refer to the range set by the user for the target attribute field, or may be a range composed of the maximum and minimum values ​​of the target attribute field of each edge contained in the test graph database.

[0066] There are many ways to divide the reference range into value intervals, such as equal width interval division, that is, the reference range is evenly divided into a number of value intervals of equal width. Another example is percentile-based division, that is, the percentile corresponding to the reference range is determined (such as quartiles, deciles, etc.), and then the reference range can be divided into value intervals according to the percentiles of the reference range.

[0067] In the above content, after determining the value ranges corresponding to the value of the target attribute field, the business platform can, for each vertex contained in the test graph database, divide each edge of the vertex into different first-class edge sets according to the value of the transaction amount field contained in each edge of the vertex, and obtain the vertex statistics of the vertex according to the number of edges divided into each first-class edge set by the vertex.

[0068] like Figure 4As shown, the number of edges among the edges of the account vertex that are divided into the edge set with a value interval of transaction amount less than 10,000 is 23, the number of edges among the edges of the account vertex that are divided into the edge set with a value interval of transaction amount greater than 10,000 and less than 30,000 is 5, and the number of edges among the edges of the account vertex that are divided into the edge set with a value interval of transaction amount greater than 30,000 and less than 100,000 is 56. At this time, the number of edges of the vertex divided into each first-class edge set counted here is the vertex statistical data of the vertex.

[0069] In addition, the business platform can also determine the order of the edges of each vertex contained in the graph database to be tested according to the value of the target attribute field contained in each edge of the vertex, and divide the edges of the vertex according to the order of the edges of the vertex to obtain first-class edge sets, and determine the value range corresponding to each first-class edge set according to the value of the target attribute field of the edges contained in each first-class edge set.

[0070] For example, according to the order of the edges of the vertex, the maximum value of the target attribute field of the first 50 edges of the edges of the vertex is determined to be 10000, and the value range corresponding to the first-class edge set composed of these edges can be determined to be 0-10000. According to the order of the edges of the vertex, the maximum value of the target attribute field of the 50th to 100th edges of the edges of the vertex is determined to be 30000, and the minimum value is 10001, and the value range corresponding to the first-class edge set composed of these edges can be determined to be 10001-30000. According to the order of the edges of the vertex, the maximum value of the target attribute field of the 100th to 150th edges of the edges of the vertex is determined to be 100000, and the minimum value is 30001, and the value range corresponding to the first-class edge set composed of these edges can be determined to be 30001-100000. By analogy, each first-class edge set and the data range corresponding to each first-class edge set are determined.

[0071] When it is determined that the statistics of each vertex are determined according to the path length dimension, for each vertex included in the test graph database, the edges between the vertex and other vertices can be divided according to the path length between the vertex and other vertices to obtain each second-class edge set, and then the vertex statistics of the vertex can be obtained according to the number of edges required to connect the vertex and other vertices included in each second-class edge set. Specifically, Figure 5 shown.

[0072] Figure 5 It is a schematic diagram of a method for determining vertex statistics of a second type of vertex provided by an exemplary embodiment.

[0073] Combination Figure 5 It can be seen that for each vertex in the graph database to be tested, the vertex can be directly connected to other vertices through an edge, or indirectly connected through one or more intermediate vertices, such as Figure 5 As shown in the figure, the A account vertex, the B account vertex, and the D account vertex are directly connected through an edge, the A account vertex and the C account vertex are connected in sequence through two edges, wherein the D account vertex is indirectly connected as an intermediate vertex, the A account vertex and the F account vertex are connected in sequence through two edges, wherein the B account vertex is indirectly connected as an intermediate vertex, and the A account vertex and the E account vertex are connected in sequence through three edges, wherein the B account vertex and the F account vertex are indirectly connected as intermediate vertices.

[0074] In actual application scenarios, the query statements obtained by the graph database to be tested can be used to filter the vertices and edges that need to be traversed according to the path length between two vertices. For example, when it is necessary to query which other account vertices have a direct transaction relationship with the A account vertex, the "direct transaction relationship" here means that the other vertices that are directly connected to the vertex through an edge are limited, that is, the vertices with a path length of 1 between the vertex and the vertex.

[0075] For another example: when it is necessary to query which other account vertices are indirectly transacting with account vertex A through an intermediate account vertex (that is, account vertex A first trades money to the intermediate account vertex, and then trades the money to other account vertices through the intermediate account vertex, or other account vertices first trade money to the intermediate account vertex, and then trade the money to account vertex A through the intermediate account vertex), it is to limit the other vertices connected to the vertex through two edges in sequence, that is, the vertices whose path length between the vertex and the vertex is 2.

[0076] Based on this, the business platform can divide the edges between each vertex contained in the graph database to be tested and other vertices according to the path length between the vertex and other vertices to obtain each second type edge set.

[0077] like Figure 5 Among the edges of vertex A shown, the number of edges divided into the edge set with a path length of 1 with vertex A is 2, the number of edges divided into the edge set with a path length of 2 with vertex A is 4, and the number of edges divided into the edge set with a path length of 3 or more with vertex A is 3, and thus the vertex statistics of the vertex can be obtained.

[0078] When determining the statistics of each vertex according to the edge type dimension, for each vertex included in the test graph database, the edges of the vertex can be divided according to the type of each edge of the vertex to obtain the third type edge sets, such as Figure 6 shown.

[0079] Figure 6 It is a schematic diagram of a method for determining vertex statistics of a third type of vertex provided by an exemplary embodiment.

[0080] Combination Figure 6 It can be seen that the business platform can divide the edges of each vertex contained in the test graph database into different third-class edge sets according to the type of each edge of the vertex, and determine the vertex statistics of the vertex according to the number of edges contained in the third-class edge set. Figure 6 As shown, the number of edges used to represent transaction relationships among the edges included in the A account vertex is 2, and the number of edges used to represent loan application relationships among the edges included in the A account vertex is 1, and the vertex statistics of the vertex can be obtained.

[0081] When determining the statistical data of each vertex according to the edge weight dimension, for each vertex included in the test graph database, the edges of the vertex can be divided according to the weight of each edge of the vertex to obtain the fourth type edge sets, such as Figure 7 shown.

[0082] Figure 7 It is a schematic diagram of a method for determining vertex statistics of a fourth type of vertex provided by an exemplary embodiment.

[0083] Combination Figure 7 It can be seen that the business platform can divide the edges of each vertex included in the test graph database into different fourth edge sets according to the weight of each edge of the vertex, and determine the vertex statistics of the vertex according to the number of edges included in the fourth edge set. Figure 6 As shown, among the edges contained in the A account vertex, the number of edges with weight 5 is 4, and among the edges contained in the A account vertex, the number of edges with weight 3 is 2, and thus the vertex statistics of the vertex can be obtained.

[0084] It is worth noting that the server can set the value intervals under the path length dimension, edge type dimension, and edge weight dimension according to actual needs. For example, the server can use each path length as a separate value interval, such as: a path length of 1 is one value interval, and a path length of 2 is another value interval. For another example, the server can also use each path length range as a value interval, such as: a path length of 1 to 2 is one value interval, and a path length of 3 or more is another value interval.

[0085] It should be noted that the business platform can determine the number of edges that belong to different value ranges for each vertex in the test graph database under a single query dimension in each query dimension, and can also determine the number of edges that belong to different value ranges for each vertex in the test graph database under at least two query dimensions in each query dimension.

[0086] For ease of understanding, the following describes in detail a method for determining the number of vertices and edges that need to be traversed when performing a query operation on each vertex in the graph database to be tested according to both the attribute value dimension and the path length dimension.

[0087] Specifically, when the business platform determines the number of vertices and edges that need to be traversed when executing the query operation for each vertex in the graph database to be tested according to the attribute value dimension and the path length dimension at the same time, it can determine each first-class edge set according to the attribute value dimension, and determine each second-class edge set according to the path length dimension and save them.

[0088] In addition, the business platform can also, for each vertex included in the graph database to be tested, divide the edges between the vertex and other vertices according to the path length between the vertex and other vertices and the predetermined value ranges corresponding to each path length to obtain second-category edge sets, and then, for each second-category edge set, divide the edges contained in the second-category edge set into sub-edge sets according to the value of the target attribute field of each edge contained in the second-category edge set and the predetermined value ranges corresponding to each target attribute field, and then obtain the vertex statistics of the vertex according to the number of edges contained in each sub-edge set and the number of edges contained in each second-category edge set.

[0089] It should be noted that, for the second type of edge set whose path length between the vertex and other vertices is greater than or equal to 2, when the edges in the second type of edge set are divided into sub-edge sets according to the value of the target attribute field of each edge, the two or more edges connecting the vertex and other vertices can be regarded as a whole for division. Specifically, the business platform can regard the two or more edges connecting the vertex and other vertices as the edge set to be divided, and then the sum of the values ​​of the target attribute field of each edge included in the edge set to be divided can be used as the value of the target attribute field of the edge set to be divided, and then each edge set to be divided can be divided into corresponding sub-edge sets according to the value of the target attribute field of each edge set to be divided.

[0090] In this specification, the execution subject used to implement the method for determining query parameters may refer to a designated device set up on a business platform by a server, or may refer to a terminal device such as a desktop computer or a laptop computer. For ease of description, the method for determining query parameters provided in this specification is described below using the server as the execution subject as an example.

[0091] S202: According to the target value range under the preset query dimension contained in the query statement template, determine the target vertex statistical data matching the query statement template from the vertex statistical data.

[0092] S204: Determine a query cost value of each candidate query parameter based on the target vertex statistics; wherein the query cost value of each candidate query parameter is used to represent: the number of vertices and the number of edges to be traversed when executing a query statement obtained after configuring the query statement template according to the alternative query parameter.

[0093] In this specification, the server can determine to generate a query statement template required for testing the test graph database based on the received test request, and then parse the query statement template to determine the query dimension used in the query statement template, and based on the target value range under the query dimension used in the query statement template, determine from the predetermined vertex statistics the vertex statistics that reflect the number of edges of each vertex belonging to different value ranges under the query dimension used in the query statement template, as the target vertex statistics that match the query statement template.

[0094] It should be noted that the above-mentioned query statement template usually includes query conditions used when performing query operations on each vertex in the graph database to be tested. The query conditions here refer to parameters used to specify graph data retrieval rules. The graph data retrieval rules here are used to instruct the server how to traverse all vertices and edges contained in the graph data starting from the specified starting vertex based on the connection relationship between the vertices and edges contained in the graph data and the attributes of the vertices and / or edges, so as to filter out a set of vertices and edges that meet specific requirements.

[0095] The above-mentioned query parameters are parameters included in the query conditions and used to instruct the graph database to be tested to determine the starting vertex of the graph query.

[0096] The above-mentioned query dimension and target value range are parameters included in the query condition for indicating how to traverse all vertices and edges included in the graph data to filter out a set of vertices and edges that meet specific requirements.

[0097] For example, if the query statement template is MATCH(p:Account{account_id:$ID})-[:TRANSFER{amount:amount}]->(other:Account)WHERE amount<10000RETURN other.account_id, that is, to query which other accounts have a transfer relationship with $ID with a transfer amount less than 10000. Here, account_id:$ID is used to indicate that the starting vertex of the graph query is the vertex with identification information $ID, and TRANSFER{amount:amount}]->(other:Account) is used to indicate that other vertices that have a transfer relationship with the vertex with identification information $ID are queried. Here, amount<10000 is used to indicate that the transfer amount attribute value in the above transfer relationship needs to be less than 10000.

[0098] From the above content, it can be seen that in the above query statement template, the parameters account_id:$ID, TRANSFER{amount:amount}, other:Account, and amount<10000 jointly indicate how the server traverses all vertices and edges contained in the graph data starting from the specified starting vertex according to the connection relationship between the vertices and edges contained in the graph data and the attributes of the vertices and / or edges, so as to filter out a set of vertices and edges that meet specific requirements. That is, account_id:$ID, TRANSFER{amount:amount}, other:Account, and amount<10000 are query conditions, and $ID in the above query conditions is a placeholder used to replace the query parameters and has no practical meaning. TRANSFER{amount:amount} in the above query conditions is used to indicate that the query dimension used in the above query statement template is the attribute value dimension, and the target attribute field used is the transfer amount field amount. In the above query conditions, amount<10000 is used to indicate that the target value range under the above query dimension is 0 to 10000.

[0099] Furthermore, the server can determine, from the vertex statistics, the vertex statistics for characterizing the number of edges belonging to different value ranges for each vertex in the test graph database under the transfer amount dimension based on the determined query dimension, as target vertex statistics, such as: for each vertex, determine the number of edges whose corresponding transfer amount is less than 10,000, the number of edges whose corresponding transfer amount is greater than 10,000 and less than 100,000, and so on.

[0100] Furthermore, when the server needs to obtain each candidate query parameter, it can randomly determine each candidate query parameter according to a preset query parameter range, and for each candidate query parameter, determine a query cost value corresponding to the candidate query parameter according to target vertex statistical data.

[0101] The query cost value is used to represent the number of vertices and edges to be traversed when executing the query statement corresponding to the candidate query parameter. The query statement corresponding to the candidate query parameter is a query statement obtained by configuring the query statement template according to the candidate query parameter.

[0102] The above-mentioned alternative query parameters can be used to represent the starting vertex when executing the query operation corresponding to the query statement template. In other words, the above-mentioned query parameters can be used to represent which vertex in the graph database to be tested is to be query-operated on according to the query statement template.

[0103] For example, when querying other account vertices that have a transaction relationship with the account vertex numbered 0001, the account vertex numbered 0001 here is the starting vertex, and the number 0001 here is the alternative query parameter.

[0104] In the above content, there may be multiple methods for the server to randomly determine each candidate query parameter, for example: randomly selecting at least some vertices from the vertices contained in the test graph database through a greedy algorithm as each starting vertex, and generating each candidate query parameter based on each randomly selected starting vertex.

[0105] For another example: from among the vertices included in the graph database to be tested, vertices whose out-degree is greater than a preset threshold are determined as starting vertices, and candidate query parameters are generated according to each starting vertex.

[0106] S204: Determine a target query parameter from the candidate query parameters according to the query cost value, for use in testing the graph database to be tested.

[0107] Furthermore, the server may select, from among the candidate query parameters, a plurality of candidate query parameters whose differences between corresponding query cost values ​​are within a preset range as target query parameters.

[0108] Of course, the server may also divide the candidate query parameters into different query parameter groups according to the query cost value corresponding to each candidate query parameter, determine a target query parameter group from the query parameter groups according to a preset screening strategy, and use the candidate query parameters included in the target query parameter group as the target query parameters.

[0109] There may be multiple preset screening strategies, for example: a first screening strategy for determining a weight coefficient of each query parameter grouping according to the query cost value of each candidate query parameter contained in each query parameter grouping, and determining a target query parameter grouping from each query parameter grouping according to the weight coefficient of each query parameter grouping. For each query parameter grouping, the weight coefficient of the query parameter grouping is determined according to the position of the query cost value of each candidate query parameter contained in the query parameter grouping in the target data distribution, wherein the target data distribution is used to characterize the arrangement characteristics of the query cost values ​​of all query parameters contained in each query parameter grouping.

[0110] Another example is: a second screening strategy for determining a weight coefficient of each query parameter grouping according to the number of query parameters included in each query parameter grouping, and determining a target query parameter grouping from each query parameter grouping according to the weight coefficient of each query parameter grouping. For each query parameter grouping, the more query parameters included in the query parameter grouping, the greater the weight coefficient of the query parameter grouping.

[0111] Another example is: determining the weight coefficient of each query parameter grouping according to the summed average value of the vertex weights of the vertices corresponding to the query parameters contained in each query parameter grouping, and determining the third screening strategy of the target query parameter grouping from the query parameter groups according to the weight coefficient of each query parameter grouping. Wherein, for each query parameter grouping, the larger the summed average value of the vertex weights of the vertices corresponding to the query parameters contained in the query parameter grouping, the larger the weight coefficient of the query parameter grouping.

[0112] Furthermore, after determining the target query parameter grouping, the server can use the alternative query parameters contained in the target query parameter grouping as target query parameters, and configure the query statement template according to the target query parameters to obtain test query statements, and then test the test graph database according to the test query statements.

[0113] From the above content, it can be seen that the data profiling of the graph database to be tested can be performed in advance to count the data after bucketing the edges of each vertex according to different value intervals of different query dimensions, and save them as the statistical data of each vertex. Therefore, when testing the graph database to be tested, the query cost corresponding to the query statement obtained after configuring different query parameters for the query statement template can be determined based on the target value interval under the query dimension used in the query statement template and the statistical data of each vertex. Then, according to the query cost corresponding to the query statement obtained when each query parameter is configured in the query statement template, a set of corresponding query parameters with consistent query costs can be selected from each query parameter as the target query parameters, and the graph database to be tested can be effectively tested based on the target query parameters.

[0114] Figure 8 is a schematic structural diagram of a device provided by an exemplary embodiment. Figure 8 At the hardware level, the device includes a processor 802, an internal bus 804, a network interface 806, a memory 808, and a non-volatile memory 810, and may also include hardware required for other functions. One or more embodiments of this specification may be implemented based on software, such as the processor 802 reading the corresponding computer program from the non-volatile memory 810 into the memory 808 and then running it. Of course, in addition to the software implementation, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0115] Please refer to Fig. 9 , a query parameter determination device can be applied to Figure 8 The device shown in the figure is used to implement the technical solution of this specification. The query parameter determination device may include:

[0116] An acquisition module 901 is used to acquire statistical data of each vertex, each candidate query parameter, and a query statement template, wherein the statistical data of each vertex is used to characterize the number of edges belonging to different value intervals of each vertex in the graph database to be tested under a preset query dimension;

[0117] A first determination module 902 is used to determine target vertex statistics matching the query statement template from the vertex statistics data according to the target value interval under the preset query dimension contained in the query statement template;

[0118] The second determination module 903 is used to determine the query cost value of each candidate query parameter according to the target vertex statistical data; wherein the query cost value of each candidate query parameter is used to represent: the number of vertices and the number of edges to be traversed when executing the query statement obtained after configuring the query statement template according to the candidate query parameter;

[0119] The execution module 904 is used to determine a target query parameter from the candidate query parameters according to the query cost value, for use in testing the graph database to be tested.

[0120] Optionally, the acquisition module 901 is specifically used to receive a test request, which carries identification information for characterizing a target application scenario specified by a user; determine the target application scenario based on the test request, and generate target full data for initializing the graph database to be tested, wherein the target full data satisfies the data distribution characteristics under the target application scenario; import the target full data into the graph database to be tested, and obtain statistical data of each vertex of the graph database to be tested.

[0121] Optionally, the query dimension includes: an attribute value dimension, the attribute value dimension is used to filter the vertices and edges that need to be traversed according to the value of the target attribute field contained in each edge of the vertex;

[0122] The acquisition module 901 is specifically used to, for each vertex contained in the graph database to be tested, divide the edges of the vertex according to the value of the target attribute field contained in each edge of the vertex to obtain each first-class edge set; and determine the vertex statistics of the vertex according to the number of edges contained in each first-class edge set.

[0123] Optionally, the acquisition module 901 is specifically used to obtain a reference range corresponding to the value of the target attribute field; determine each first-class edge set based on the reference range, and for each vertex contained in the graph database to be tested, divide each edge of the vertex into the first-class edge sets based on the value of the target attribute field contained in each edge of the vertex.

[0124] Optionally, the query dimension includes: a path length dimension, wherein the path length dimension is used to filter vertices and edges to be traversed according to a path length between two vertices, wherein the path length is used to represent the number of edges contained in a path formed by sequentially connecting the edges between the two vertices;

[0125] The acquisition module 901 is specifically used to, for each vertex contained in the graph database to be tested, divide the edges between the vertex and other vertices according to the path length between the vertex and other vertices to obtain each second-class edge set; and obtain the vertex statistics of the vertex according to the number of edges required to connect the vertex and other vertices contained in each second-class edge set.

[0126] Optionally, the execution module 904 is specifically used to divide the candidate query parameters into different query parameter groups according to the query cost value corresponding to each candidate query parameter; determine the weight coefficient corresponding to each query parameter group according to a preset screening strategy, and determine a target query parameter group from each query parameter group according to the weight coefficient, and use the candidate query parameters contained in the target query parameter group as the target query parameters.

[0127] Optionally, the screening strategy includes: a first screening strategy or a second screening strategy, wherein the first screening strategy is used to determine the weight coefficient of each query parameter grouping according to the query cost value of each alternative query parameter contained in each query parameter grouping, and the second screening strategy is used to determine the weight coefficient of each query parameter grouping according to the number of alternative query parameters contained in each alternative query parameter grouping.

[0128] Based on the same concept as the above method, this specification also provides an electronic device, including: a processor; a memory for storing processor executable instructions; wherein the processor implements the steps of the method described in any of the above embodiments by running the executable instructions.

[0129] Based on the same concept as the above method, this specification also provides a computer-readable storage medium on which computer instructions are stored. When the instructions are executed by a processor, the steps of the method described in any of the above embodiments are implemented.

[0130] Based on the same concept as the above method, this specification also provides a computer program product, including a computer program / instruction, which implements the steps of the method described in any of the above embodiments when executed by a processor.

Claims

1. A method for determining a query parameter, comprising: Obtaining statistical data of each vertex, each candidate query parameter, and a query statement template, wherein the statistical data of each vertex is used to characterize the number of edges belonging to different value intervals of each vertex in the graph database to be tested under a preset query dimension; According to the target value interval under the preset query dimension contained in the query statement template, determining the target vertex statistical data matching the query statement template from the vertex statistical data; Determine a query cost value of each candidate query parameter according to the target vertex statistical data; wherein the query cost value of each candidate query parameter is used to represent: the number of vertices and the number of edges to be traversed when executing a query statement obtained after configuring the query statement template according to the candidate query parameter; According to the query cost value, a target query parameter is determined from the candidate query parameters for use in testing the graph database to be tested.

2. The method according to claim 1, obtaining the statistical data of each vertex, specifically comprising: Receiving a test request, wherein the test request carries identification information for characterizing a target application scenario specified by a user; According to the test request, a target application scenario is determined, and target full data used to initialize the graph database to be tested is generated, wherein the target full data satisfies the data distribution characteristics under the target application scenario; The target full amount of data is imported into the test graph database, and the statistical data of each vertex of the test graph database is obtained.

3. The method according to claim 1, wherein the query dimensions include: An attribute value dimension, which is used to filter the vertices and edges that need to be traversed according to the value of the target attribute field contained in each edge of the vertex; Get statistics for each vertex, including: For each vertex included in the graph database to be tested, dividing the edges of the vertex according to the value of the target attribute field included in each edge of the vertex to obtain first-category edge sets; The vertex statistics of the vertex are determined according to the number of edges included in each first-type edge set.

4. The method according to claim 3, for each vertex contained in the graph database to be tested, dividing the edges of the vertex according to the value of the target attribute field contained in each edge of the vertex to obtain each first-category edge set, specifically comprising: Obtaining a reference range corresponding to the value of the target attribute field; According to the reference range, each first-category edge set is determined, and for each vertex included in the graph database to be tested, each edge of the vertex is divided into the first-category edge sets according to the value of the target attribute field included in each edge of the vertex.

5. The method according to claim 1 or 3, wherein the query dimensions include: A path length dimension, which is used to filter the vertices and edges that need to be traversed according to the path length between two vertices. The path length is used to represent the number of edges contained in a path formed by sequentially connecting the edges between two vertices. Get statistics for each vertex, including: For each vertex included in the graph database to be tested, the edges between the vertex and other vertices are divided according to the path length between the vertex and other vertices to obtain second-category edge sets; According to the number of edges required for connecting the vertex and other vertices contained in each second-category edge set, vertex statistics of the vertex are obtained.

6. The method according to claim 1, determining a target query parameter from the query parameters according to the query cost, specifically comprising: According to the query cost value corresponding to each candidate query parameter, the candidate query parameters are divided into different query parameter groups; According to a preset screening strategy, a weight coefficient corresponding to each query parameter group is determined, and according to the weight coefficient, a target query parameter group is determined from each query parameter group, and the candidate query parameters included in the target query parameter group are used as the target query parameters.

7. The method of claim 6, wherein the screening strategy comprises: A first screening strategy or a second screening strategy, wherein the first screening strategy is used to determine the weight coefficient of each query parameter grouping according to the query cost value of each alternative query parameter contained in each query parameter grouping, and the second screening strategy is used to determine the weight coefficient of each query parameter grouping according to the number of alternative query parameters contained in each alternative query parameter grouping.

8. An electronic device comprising: processor; A memory for storing processor-executable instructions; wherein the processor implements the steps of the method according to any one of claims 1 to 7 by executing the executable instructions.

9. A computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the steps of the method according to any one of claims 1 to 7.

10. A computer program product, comprising a computer program / instruction, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 7.

Images