A method for determining a query parameter, a storage medium, an apparatus, and a program product

Abstract

The specification discloses a method for determining query parameters, a storage medium, an equipment and a program product. In the method, the number of edges of each vertex in a to-be-tested graph database belonging to different query dimensions and different value intervals is counted in advance as vertex statistical data and saved, so that when determining the query parameters needed for testing the to-be-tested graph database, the query cost value corresponding to the query statement obtained after configuring different query parameters for the query statement template can be determined according to the target value interval used in the query statement template and the vertex statistical data, and then a group of query parameters corresponding to the same query cost value can be selected from the query parameters as target query parameters according to the query cost value corresponding to the query statement obtained when each query parameter is configured into the query statement template, and the to-be-tested graph database is effectively tested according to the target query parameters.

Description

Technical Field

[0001] This 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 Technology

[0002] Currently, due to differences in data structures, query patterns, performance requirements, and functional characteristics designed for different graph databases, their applicability varies across various application scenarios, such as social network analysis, recommendation systems, finance, and cybersecurity. Graph database benchmarking methods, based on standardized testing processes and metrics, can evaluate the performance, efficiency, and stability of different graph databases when handling specific data types and complex queries. This helps developers and enterprises optimize graph databases for different application scenarios.

[0003] Typically, when using graph database benchmarking methods to test graph databases, it is necessary to simulate the actual working scenario of the graph database. Multiple read query statements are generated in advance based on the query statement template and input into the graph database to be tested. The test results for the graph database to be tested are obtained based on indicators such as the response time of the graph database to execute these read query statements and the accuracy of the query results obtained by the graph database to execute these read query statements.

[0004] However, because the distribution of vertices and edges stored in the graph database is not uniform, and the query parameters configured for the query statement template are often random during the generation of various read query statements for testing, the test results obtained by testing the graph database based on different read query statements generated according to the same query statement template are quite different.

[0005] For example, in the query template MATCH(p:Account{account_id:$ID})-[:TRANSFER]->(other:Account)RETURN other.account_id, which is used to query accounts with a direct transfer relationship, $ID is a placeholder used to replace the query parameters that need to be determined. By configuring different starting vertices for the above query template, we can obtain results such as: MATCH(p:Account{account_id:'0001'})-[:TRANSFER]->(other:Account)RETURN other.account_id (i.e., querying other account vertices that have a direct transaction relationship with account vertex number 0001), and MATCH(p:Account{account_id:'0002'})-[:TRANSFER]->(other:Account)RETURN The query statement `other.account_id` (i.e., querying other account vertices that have a direct transaction relationship with account vertex number 0002) is used. However, because the distribution of vertices and edges stored in the graph database is not uniform, account vertex number 0001 may have transaction relationships with multiple other account vertices, while account vertex number 0002 may have almost no transaction relationships with other account vertices. As a result, the graph database under test needs to traverse more vertices to execute the query statement for account vertex number 0001 compared to the query statement for account vertex number 0002, resulting in a higher query cost. Consequently, there is a significant difference between the test results determined by the query statement for account vertex number 0001 and the test results determined by the query statement for account vertex number 0002.

[0006] The fact that even when different read query statements generated from the same query template are used to test graph databases, the test results can vary significantly, making it impossible to effectively test the performance of graph databases. Summary of the Invention

[0007] This specification provides a method, storage medium, device, and program product for determining query parameters, in order to partially solve the problems existing in the prior art.

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

[0009] This manual provides a method for determining query parameters, including:

[0010] Obtain statistical data for each vertex, alternative query parameters, and query statement templates. The statistical data for each vertex is used to characterize the number of edges belonging to different value ranges for each vertex in the graph database under the preset query dimension.

[0011] Based on the target value range under the preset query dimension contained in the query statement template, the target vertex statistics that match the query statement template are determined from the vertex statistics.

[0012] Based on the target vertex statistics, the query cost of each alternative query parameter is determined; wherein, the query cost of each alternative query parameter is used to characterize the number of vertices and edges to be traversed when executing the query statement obtained after configuring the query statement template according to the alternative query parameter.

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

[0014] This specification provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method for determining query parameters.

[0015] This specification provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the above-described method for determining query parameters.

[0016] The above-described at least one technical solution adopted in the embodiments of this specification can achieve the following beneficial effects:

[0017] In this embodiment, the following steps are first taken: First, vertex statistics, candidate query parameters, and query statement templates are obtained to represent the number of edges belonging to different value ranges for each vertex in the graph database under the preset query dimension. Then, based on the target value range under the preset query dimension contained in the query statement template, target vertex statistics matching the query statement template are determined from the vertex statistics. Next, based on the target vertex statistics, the query cost of each candidate query parameter is determined. The query cost of each candidate query parameter represents the number of vertices and edges to be traversed when executing the query statement obtained after configuring the query statement template according to the candidate query parameter. Finally, based on the query cost, the target query parameter is determined from the candidate query parameters for use when testing the graph database under the test.

[0018] In this method, the number of edges belonging to different query dimensions and different value ranges for each vertex in the graph database to be tested can be pre-counted and saved as vertex statistics. This allows for the determination of query parameters needed to test the graph database, based on the target value range used in the query template and the vertex statistics. This determines the query cost corresponding to the query statement obtained after configuring different query parameters for the query template. Furthermore, based on the query cost corresponding to the query statement obtained when each query parameter is configured in the query template, a set of query parameters with consistent query costs can be selected as the target query parameters. Finally, the graph database to be tested can be effectively tested based on the target query parameters. Attached Figure Description

[0019] The accompanying drawings, which are included to provide a further understanding of this specification and form part of this specification, illustrate exemplary embodiments and are used to explain this specification, but do not constitute an undue limitation thereof. In the drawings:

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

[0021] Figure 2 This is a flowchart illustrating a method for determining query parameters provided in an exemplary embodiment;

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

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

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

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

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

[0027] Figure 8 This is a schematic diagram of the structure of a device provided in an exemplary embodiment;

[0028] Figure 9This is a block diagram of a query parameter determination device provided in an exemplary embodiment. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of this specification clearer, the technical solutions of this specification will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.

[0030] Currently, due to differences in data structures, query patterns, performance requirements, and functional characteristics designed for different graph databases, their applicability varies across various application scenarios such as social network analysis, recommendation systems, finance, and cybersecurity. Graph database benchmarking methods, based on standardized testing processes and metrics, can evaluate the performance, efficiency, and stability of different graph databases when handling specific data types and complex queries. This helps developers and enterprises optimize graph databases for different application scenarios. Benchmarking graph databases can be performed using a pre-defined benchmarking toolkit (LDBC Social Network Benchmark, LDBCSNB), as detailed below. Figure 1 As shown.

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

[0032] Combination Figure 1As can be seen, SNB includes a data generator, a parameter generator, and a benchmark driver. First, before testing the graph database under test, to simulate real-world application scenarios, the data generator needs to generate large-scale, complex graph data with characteristics specific to the application scenario (e.g., social network analysis, recommendation systems, finance, cybersecurity). This generated graph data can then be loaded into the graph database under test using a bulk load to initialize it. Next, the parameter generator generates query parameters and sends them to the benchmark driver. The benchmark driver then determines the read query statements used to test the graph database based on these parameters, and performs performance testing on the graph database when processing large-scale data under the specified application scenario. Finally, the test results for the graph database under test can be determined based on the response time and accuracy of the read query results.

[0033] One issue is that the uneven distribution of vertices and edges in the graph data of the graph database under test results in different query costs when executing read queries that traverse from different starting vertices. This leads to randomness in the final test results for the graph database, making it difficult for developers and enterprises to optimize the graph database. Furthermore, when an anomaly is identified in the graph database based on the test results, it is impossible to determine whether the cause of the anomaly is a problem with the graph database itself or a problem with the query parameter settings.

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

[0035] Figure 2 This is a flowchart illustrating a method for determining query parameters provided in an exemplary embodiment, including:

[0036] S200: Obtain the statistical data of each vertex, each alternative query parameter, and the query statement template. The statistical data of each vertex is used to represent the number of edges belonging to different value ranges for each vertex in the graph database to be tested under the preset query dimension.

[0037] In this specification, the business platform can obtain statistical data for each vertex, alternative query parameters, and query statement templates. Based on the statistical data for each vertex, it can determine the query value of the query statement obtained after configuring the query statement template according to each alternative query parameter. This value serves as the query value for each alternative query parameter. Furthermore, based on the query value for each alternative query parameter, alternative query parameters with similar query values ​​can be selected from the alternative query parameters for testing the graph database under test. This avoids randomness in the test results for the graph database under test, thus enabling effective testing of the graph database under test.

[0038] Prior to this, the business platform can receive test requests sent by users and determine the graph database to be tested based on the received test requests. Then it can determine whether the graph database to be tested has been installed and is running in the preset test environment. If not, it can install the graph database to be tested.

[0039] The aforementioned test request may be an instruction or script used to initiate benchmark testing on the graph database to be tested, and the test request may contain 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 under test, and can generate full data that meets the data distribution characteristics under the target application scenario. Then, the generated full data can be imported into the graph database under test, and the graph database under test can be tested based on the imported full data.

[0041] The above describes several methods by which the business platform can determine the target application scenario required for testing the graph database under test. For example, it can determine the target application scenario based on the identifier information contained in the received test request, which represents the target application scenario specified by the user. Another example is using a pre-defined, specified application scenario as the target application scenario.

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

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

[0044] Combination Figure 3As can be seen, in a financial scenario, the entities contained in the graph data that need to be stored in the graph database can include: Person, Account, Company, Loan, Medlum, etc. The relationships between these entities can include: transfer relationships (transaction relationships) between accounts, withdrawal relationships between accounts, guarantee relationships between users, ownership relationships between users and accounts, investment relationships between users and companies, guarantee relationships between companies, investment relationships between companies, application relationships between companies and loans, ownership relationships between companies and accounts, deposit relationships between loans and accounts, payment relationships between accounts and loans, and login relationships between accounts and mechanisms, etc.

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

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

[0047] Furthermore, the business platform can generate full data for initializing the graph database to be tested, based on the data distribution characteristics in the aforementioned financial scenarios.

[0048] Specifically, the business platform can generate vertices corresponding to each entity based on its attributes, and then generate edges between these vertices according to the relationships between entities to obtain the full dataset. Note that the attribute values ​​in different vertices of the same entity are not entirely the same, and the attribute values ​​in different edges are also not entirely the same.

[0049] For example, for a user entity, vertices can be generated based on the user entity's attributes. For instance, a user vertex might have the unique identifier 009, username "Mr. Zhang," no blacklist status, created on October 13, 2023, male gender, and born on June 19, 1982. Another example is a user vertex with the unique identifier 005, username "Ms. Li," no blacklist status, created on January 27, 2012, female gender, and born on April 5, 1995.

[0050] For example, regarding the edge between an account entity and a login medium entity, the edge between the account vertex and the login medium vertex can be generated based on the preset attributes of the edge between the account entity and the login medium entity (such as login time, login address, login authentication method, and login Internet Protocol address (IP)). For example, the specific values ​​of the attributes of the edge between the account vertex with unique identifier 10001 and the login medium with unique identifier 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 multiple ways for the business platform to generate the above full data. For example, it can use the data generation tools included in the pre-installed SNB to generate each vertex and edge as the full data based on the data distribution characteristics of the target application scenario.

[0052] For example, by using a pre-defined large language model, based on the data distribution characteristics of the target application scenario mentioned above, each vertex and each edge is generated as the full dataset.

[0053] Furthermore, after importing the generated full data into the graph database to be tested, the business platform can determine the query dimensions that match the full data imported into the graph database from the preset reference query dimensions. Then, based on the query dimensions that match the full data imported into the graph database to be tested, the platform can perform statistics on the graph data contained in the graph database to be tested and obtain the 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 under test in each of the preset different query dimensions.

[0055] The aforementioned preset query dimensions refer to different attributes or features used to organize and filter data during data queries. These query dimensions can be attribute value dimensions, path length dimensions, edge type dimensions, edge weight dimensions, etc. Specifically, the attribute value dimension is used to filter the vertices and edges to be traversed based on the value of the target attribute field contained in each edge of a vertex. The path length dimension is used to filter the vertices and edges to be traversed based on the path length between two vertices, where path length represents the number of edges contained in the path formed by sequentially connecting the edges between the two vertices. The edge type dimension is used to filter the vertices and edges to be traversed based on the type of each edge contained in a vertex. The edge weight dimension is used to filter the vertices and edges to be traversed based on the weight of each edge contained in a vertex.

[0056] The following sections provide detailed explanations of the methods for determining the statistical data of each vertex according to different query dimensions.

[0057] First, when determining the statistical data of each vertex according to the attribute value dimension, for each vertex contained in the database of the graph 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. Then, the vertex statistical data 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. Here, the target attribute field can be any attribute field contained in the edge of the vertex.

[0059] For example, an edge representing a transaction relationship might contain attribute fields such as transaction time, transaction amount, and transaction type. In this case, the attribute field representing the transaction amount can be used as the target attribute field. Similarly, the field representing the transaction time can also be used as the target attribute field.

[0060] The aforementioned edge sets can be determined based on the range of values ​​for the target attribute fields obtained in advance. That is, the business platform can obtain a reference range of values ​​for the target attribute fields, and thus determine each first-type edge set based on the reference range. Different first-type edge sets can correspond to different intervals within the reference range, i.e., 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 different first-class edge sets according to the value of the target attribute field contained in each edge of the vertex, and the vertex statistics can be obtained according to the number of edges of the vertex in each first-class edge set.

[0062] To facilitate understanding, the following explanation uses the target attribute field as the transaction amount field to illustrate the method for determining vertex statistics. Specifically, as follows... Figure 4 As shown.

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

[0064] Combination Figure 4 It can be seen that the business platform can pre-obtain the range of values ​​for the target attribute field of each edge in the database of the graph to be tested, as a reference range. This reference range can then be divided into value intervals, and each set of first-type edges can be determined based on these intervals. Figure 4 The values ​​shown are: transaction amount less than 10,000, transaction amount greater than 10,000 but less than 30,000, and transaction amount greater than 30,000 but less than 100,000.

[0065] The range of values ​​for the target attribute field of each edge in the database of the graph to be tested, obtained by the business platform, can refer to the range set by the user for the target attribute field, or it can be the range consisting of the maximum and minimum values ​​of the target attribute field of each edge in the database of the graph to be tested.

[0066] There are several methods for dividing a reference range into value intervals. For example, equal-width interval division, which divides the reference range evenly into several value intervals of equal width. Another example is percentile-based division, which determines the percentiles (e.g., quartiles, decimals) corresponding to the reference range, and then divides the reference range into value intervals according to the percentiles of the reference range.

[0067] In the above content, after determining the value ranges corresponding to the target attribute fields, the business platform can, for each vertex contained in the graph database to be tested, 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 data of the vertex based on the number of edges of the vertex divided into each first-class edge set.

[0068] like Figure 4As shown, the number of edges in the edge set of the account vertex that fall into the value range of transaction amount less than 10,000 is 23; the number of edges in the edge set of the account vertex that fall into the value range of transaction amount greater than 10,000 and less than 30,000 is 5; and the number of edges in the edge set of the account vertex that fall into the value range of transaction amount greater than 30,000 and less than 100,000 is 56. At this point, the number of edges that the vertex falls into each of the first type of edge set is the vertex statistics data of that vertex.

[0069] In addition, the business platform can also determine the order of the edges of a vertex for each vertex in the graph database to be tested, based on the value of the target attribute field in each edge of that vertex. Based on the order of the edges of that vertex, the platform can divide the edges of that vertex into sets of first-class edges. Based on the value of the target attribute field of the edges in each set of first-class edges, the platform can determine the value range corresponding to each set of first-class edges.

[0070] For example: Based on the order of the edges of a vertex, if the maximum value of the target attribute field of the first 50 edges of that vertex is determined to be 10000, then the value range of the first type of edge set formed by these edges can be determined to be 0 to 10000. Based on the order of the edges of that vertex, if the maximum value of the target attribute field of the 50th to 100th edges of that vertex is determined to be 30000 and the minimum value to be 10001, then the value range of the first type of edge set formed by these edges can be determined to be 10001 to 30000. Based on the order of the edges of that vertex, if the maximum value of the target attribute field of the 100th to 150th edges of that vertex is determined to be 100000 and the minimum value to be 30001, then the value range of the first type of edge set formed by these edges can be determined to be 30001 to 100000. And so on, thus determining each first type of edge set and the corresponding data range for each first type of edge set.

[0071] When determining the vertex statistics based on path length, for each vertex in the test graph database, the edges between that vertex and other vertices can be divided according to the path length between that vertex and other vertices, resulting in sets of secondary edges. Then, based on the number of edges required to connect that vertex to other vertices in each set of secondary edges, the vertex statistics for that vertex can be obtained. Specifically, as follows... Figure 5 As shown.

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

[0073] Combination Figure 5 It can be seen that for each vertex in the graph database under test, this vertex can be directly connected to other vertices through an edge, or indirectly connected through one or more intermediate vertices, such as... Figure 5 The diagram shows that account A vertices are directly connected to account B and account D vertices by one edge; account A vertices are connected to account C vertices by two edges in sequence, with account D vertices used as intermediate vertices for indirect connection; account A vertices are connected to account F vertices by two edges in sequence, with account B vertices used as intermediate vertices for indirect connection; and account A vertices are connected to account E vertices by three edges in sequence, with account B and account F vertices used as intermediate vertices for indirect connection.

[0074] In practical applications, the query statement obtained from the graph database under test can be used to filter the vertices and edges to be traversed based on the path length between two vertices. For example, when querying which other account vertices have a direct transaction relationship with account A, "have a direct transaction relationship" here limits the query to which other vertices are directly connected to this vertex by an edge, that is, which vertices have a path length of 1 with this vertex.

[0075] For example, when it is necessary to query which other account vertices are indirectly transacted with account vertex A through intermediate account vertices (i.e., account vertex A first transacts money to intermediate account vertex, and then transacts money to other account vertices through intermediate account vertex, or other account vertices first transact money to intermediate account vertex, and then transact money to account vertex A through intermediate account vertex), it is necessary to limit which other vertices are connected to this vertex through two edges in sequence, that is, which vertices have a path length of 2 with this vertex.

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

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

[0078] When determining the statistical data for each vertex according to its edge type, for each vertex in the database of the graph under test, the edges of that vertex can be divided according to the type of each edge, resulting in sets of each third type of edge, such as... Figure 6 As shown.

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

[0080] Combination Figure 6 As can be seen, the business platform can, for each vertex contained in the database of the graph under test, divide the edges of that vertex into different third-category edge sets according to the type of each edge of that vertex, and determine the vertex statistics based on the number of edges contained in the third-category edge set. For example... Figure 6 As shown, the number of edges representing transaction relationships in the vertex of account A is 2, and the number of edges representing loan application relationships in the vertex of account A is 1. Thus, the vertex statistics of this vertex can be obtained.

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

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

[0083] Combination Figure 7 As can be seen, the business platform can, for each vertex contained in the database of the graph to be tested, divide the edges of that vertex into different sets of fourth edges based on the weight of each edge of that vertex, and determine the vertex statistics based on the number of edges contained in the sets of fourth edges. For example... Figure 6 As shown, the number of edges with a weight of 5 among the edges contained in the vertex of account A is 4, and the number of edges with a weight of 3 among the edges contained in the vertex of account A is 2. Thus, the vertex statistics of this vertex can be obtained.

[0084] It's worth noting that the server can set the value ranges for path length, edge type, and edge weight dimensions according to actual needs. For example, the server can treat each path length as a separate value range, such as a path length of 1 as one value range and a path length of 2 as another. Alternatively, the server can treat each path length range as a single value range, such as a path length of 1 to 2 as one value range and a path length of 3 or more as another.

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

[0086] For ease of understanding, the following section details the 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 under test, based on both attribute value and path length dimensions.

[0087] Specifically, when the business platform determines the number of vertices and edges that need to be traversed when performing a query operation on each vertex in the graph database under test, based on both the attribute value dimension and the path length dimension, it can determine and save the first type of edge set based on the attribute value dimension and the second type of edge set based on the path length dimension, respectively.

[0088] In addition, the business platform can also, for each vertex contained in the test graph database, 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 each second type of edge set. Then, for each second type of edge set, divide the edges contained in the second type of edge set into each sub-edge set according to the value of the target attribute field of each edge contained in the second type of edge set and the predetermined value ranges corresponding to each target attribute field. Finally, based on the number of edges contained in each sub-edge set and the number of edges contained in each second type of edge set, the vertex statistics of the vertex can be obtained.

[0089] It should be noted that for a second-type edge set where the path length between the vertex and other vertices is greater than or equal to 2, when dividing the edges in this second-type edge set into sub-edge sets according to the value of the target attribute field of each edge, two or more edges connecting the vertex and other vertices can be treated as a whole for division. Specifically, the business platform can take two or more edges connecting the vertex and other vertices as the edge set to be divided, and then take the sum of the values ​​of the target attribute fields of each edge in the edge set to be divided as the value of the target attribute field of the edge set to be divided. Then, based on the value of the target attribute field of each edge set to be divided, each edge set to be divided can be assigned to the corresponding sub-edge set.

[0090] In this specification, the executing entity used to implement the method for determining query parameters can refer to a designated device set up on the business platform by a server or other means, or it can refer to a terminal device such as a desktop computer or a laptop computer. For ease of description, the following will only use the server as the executing entity as an example to explain the method for determining query parameters provided in this specification.

[0091] S202: Based on the target value range under the preset query dimension contained in the query statement template, determine the target vertex statistics that match the query statement template from the vertex statistics.

[0092] S204: Based on the target vertex statistics, determine the query cost of each alternative query parameter; wherein, the query cost of each alternative query parameter is used to characterize the number of vertices and edges to be traversed when executing the query statement obtained after configuring the query statement template according to the alternative query parameter.

[0093] In this specification, the server can determine the query statement template needed for testing the graph database to be tested based on the received test request. Then, it can parse the query statement template to determine the query dimension used in the query statement template. Based on the target value range under the query dimension used in the query statement template, it can determine the vertex statistics data reflecting the number of edges of each vertex belonging to different value ranges under the query dimension used in the query statement template from the pre-determined vertex statistics data. This data is used as the target vertex statistics data that match the query statement template.

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

[0095] The query parameters mentioned above are the parameters included in the query conditions that instruct the graph database under test to determine the starting vertex of the graph query.

[0096] The query dimensions and target value range mentioned above are parameters included in the query conditions that indicate how to traverse all vertices and edges contained in the graph data in order to filter out a set of vertices and edges that meet specific requirements.

[0097] For example, if the query template is MATCH(p:Account{account_id:$ID})-[:TRANSFER{amount:amount}]->(other:Account)WHERE amount<10000RETURN other.account_id, then the query will find other accounts that have a transfer relationship with $ID where the transfer amount is less than 10000. Here, account_id:$ID indicates that the starting vertex of the graph query is the vertex with the identifier $ID. TRANSFER{amount:amount}]->(other:Account) indicates that the query will find other vertices that have a transfer relationship with the vertex with the identifier $ID. Amount<10000 indicates that the transfer amount attribute value in the above transfer relationship must be less than 10000.

[0098] As can be seen from the above, the parameters account_id:$ID, TRANSFER{amount:amount}, other:Account, and amount<10000 in the query template together instruct the server how to traverse all vertices and edges in the graph data, starting from a specified starting vertex, based on the connection relationships between vertices and edges contained in the graph data and the attributes of vertices and / or edges, 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 the query conditions. In the above query conditions, $ID is a placeholder used to replace the query parameter and has no actual meaning. TRANSFER{amount:amount} in the above query conditions indicates that the query dimension used in the above query template is the attribute value dimension, and the target attribute field used is the transfer amount field amount. Amount<10000 in the above query conditions indicates that the target value range under the above query dimension is 0 to 10000.

[0099] Furthermore, based on the determined query dimension, the server can determine the vertex statistics from the vertex statistics to represent the number of edges belonging to different value ranges under the transfer amount dimension for each vertex in the graph database under test. This data can be used as the target vertex statistics. For example, for each vertex, the server can determine the number of edges with a transfer amount less than 10,000, the number of edges with a transfer amount greater than 10,000 and less than 100,000, and so on.

[0100] Furthermore, when the server needs to obtain each alternative query parameter, it can randomly determine each alternative query parameter according to the preset query parameter range, and for each alternative query parameter, determine the corresponding query cost value based on the target vertex statistics.

[0101] The query cost mentioned above is used to represent the number of vertices and edges to be traversed when executing the query statement corresponding to the alternative query parameter. The query statement corresponding to the alternative query parameter is the query statement obtained after configuring the query statement template according to the alternative query parameter.

[0102] The aforementioned alternative query parameters can be used to characterize the starting vertex when executing the query operation corresponding to the query statement template. In other words, the aforementioned query parameters can be used to characterize which vertex in the graph database to be queried according to the query statement template.

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

[0104] In the above content, there are multiple ways for the server to randomly determine each candidate query parameter. For example, at least some vertices can be randomly selected from the vertices contained in the database of the graph to be tested using a greedy algorithm as each starting vertex, and each candidate query parameter can be generated based on each randomly selected starting vertex.

[0105] For example, from the vertices in the database of the graph to be tested, determine the vertices whose out-degree is greater than a preset threshold, and use them as starting vertices. Then, generate alternative query parameters based on each starting vertex.

[0106] S204: Based on the query value, determine the target query parameter from the candidate query parameters for use when testing the graph database to be tested.

[0107] Furthermore, the server can filter out multiple alternative query parameters from the alternative query parameters whose differences between corresponding query values ​​are within a preset range, and use them as the target query parameters.

[0108] Of course, the server can also divide each alternative query parameter into different query parameter groups based on the query cost value corresponding to each alternative query parameter, determine the target query parameter group from each query parameter group according to the preset filtering strategy, and use the alternative query parameters contained in the target query parameter group as the target query parameter.

[0109] The aforementioned preset filtering strategy can be varied. For example, a first filtering strategy could be used to determine the weight coefficient of each query parameter group based on the query cost value of each candidate query parameter contained in each query parameter group, and then determine the target query parameter group from each query parameter group based on the weight coefficient of each query parameter group. Specifically, for each query parameter group, the weight coefficient is determined based on the position of the query cost value of each candidate query parameter contained in that query parameter group within the target data distribution. Here, the target data distribution represents the arrangement characteristics of the query cost values ​​of all query parameters contained in each query parameter group.

[0110] For example, a second filtering strategy is used to determine the weight coefficient of each query parameter group based on the number of query parameters contained in each group, and then to determine the target query parameter group from each group based on the weight coefficient of each group. Specifically, for each query parameter group, the more query parameters it contains, the greater its weight coefficient.

[0111] For example, a third filtering strategy is used to determine the weight coefficient of each query parameter group based on the sum of the average vertex weights of the vertices corresponding to each query parameter contained in that group, and then to determine the target query parameter group from each group based on the weight coefficient of that group. Specifically, for each query parameter group, the larger the sum of the average vertex weights of the vertices corresponding to each query parameter contained in that group, the larger the weight coefficient of that query parameter group.

[0112] Furthermore, after determining the target query parameter group, the server can use each alternative query parameter contained in the target query parameter group as the target query parameter, and configure the query statement template according to each target query parameter to obtain each test query statement. Then, the graph database to be tested can be tested according to each test query statement.

[0113] As can be seen from the above, data profiling of the graph database to be tested can be performed in advance to collect data on each vertex's edges after bucketing according to different value ranges for different query dimensions. This data is then saved as vertex statistics. When testing the graph database, the target value range under the query dimension used in the query template and the vertex statistics can be used to determine the query cost corresponding to the query statement after configuring different query parameters for the query template. Furthermore, based on the query cost corresponding to the query statement obtained when each query parameter is configured in the query template, a set of query parameters with consistent query costs can be selected 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 This is a schematic structural diagram of a device provided in an exemplary embodiment. Please refer to... Figure 8 At the hardware level, the device includes a processor 802, an internal bus 804, a network interface 806, memory 808, and non-volatile memory 810, and may also include other hardware required for its functions. One or more embodiments of this specification can be implemented in software, for example, the processor 802 reads the corresponding computer program from the non-volatile memory 810 into memory 808 and then runs it. Of course, besides software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution entity of the following processing flow is not limited to individual logic units, but can also be hardware or logic devices.

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

[0116] The acquisition module 901 is used to acquire the statistical data of each vertex, each alternative query parameter, and the query statement template. The statistical data of each vertex is used to represent the number of edges belonging to different value ranges for each vertex in the graph database to be tested under the preset query dimension.

[0117] The first determining module 902 is used to determine the target vertex statistics that match the query statement template from the vertex statistics based on the target value range under the preset query dimension contained in the query statement template.

[0118] The second determining module 903 is used to determine the query cost of each candidate query parameter based on the target vertex statistics; wherein, the query cost of each candidate query parameter is used to characterize the number of vertices and 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 the target query parameter from the candidate query parameters based on the query value, for use when testing the graph database to be tested.

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

[0121] Optionally, the query dimension includes: an attribute value dimension, which is used to filter the vertices and edges to be traversed based on the values ​​of the target attribute fields 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 into first-class edge sets according to the value of the target attribute field contained in each edge of the vertex; and determine the vertex statistics data 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: acquire the reference range corresponding to the value of the target attribute field; determine each first type edge set according to the reference range; and for each vertex contained in the graph database to be tested, classify each edge of the vertex into each first type edge set according to the value of the target attribute field contained in each edge of the vertex.

[0124] Optionally, the query dimension includes a path length dimension, which is used to filter the vertices and edges to be traversed based on the path length between two vertices, and the path length is used to represent the number of edges contained in the path formed by connecting the edges between two vertices in sequence.

[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 type of 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 type of edge set.

[0126] Optionally, the execution module 904 is specifically used to: divide each candidate query parameter 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 filtering strategy; determine the target query parameter group from each query parameter group according to the weight coefficient; and take the candidate query parameters contained in the target query parameter group as the target query parameters.

[0127] Optionally, the filtering strategy includes a first filtering strategy or a second filtering strategy, wherein the first filtering strategy is used to determine the weight coefficient of each query parameter group based on the query cost value of each candidate query parameter contained in each query parameter group, and the second filtering strategy is used to determine the weight coefficient of each query parameter group based on the number of candidate query parameters contained in each candidate query parameter group.

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

[0129] Based on the same concept as the methods described above, this specification also provides a computer-readable storage medium having computer instructions stored thereon that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

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

Claims

1. A method for determining a query parameter, comprising: obtaining vertex statistics, candidate query parameters, and a query statement template, wherein the vertex statistics are used to represent a number of edges of each vertex in a preset query dimension in a different value interval in a to-be-tested graph database; determining target vertex statistics matching the query statement template from the vertex statistics according to a target value interval in the preset query dimension contained in the query statement template; determining a query cost of each candidate query parameter according to the target vertex statistics, wherein the query cost of each candidate query parameter is used to represent a number of vertices and edges to be traversed when a query statement obtained by configuring the query statement template according to the candidate query parameter is executed; and determining a target query parameter from the candidate query parameters according to the query cost, so as to be used for testing the to-be-tested graph database, to limit randomness of a test result of the to-be-tested graph database. 2.The method of claim 1, wherein the vertex statistics are obtained by: receiving a test request carrying identification information representing a target application scenario specified by a user; determining the target application scenario according to the test request, and generating target full data used for initializing the to-be-tested graph database, wherein the target full data meets a data distribution feature in the target application scenario; and importing the target full data into the to-be-tested graph database, and obtaining the vertex statistics of the to-be-tested graph database. An attribute value dimension is used to filter vertices and edges to be traversed according to a value of a target attribute field contained in each edge of a vertex. The vertex statistics are obtained by: dividing edges of each vertex in the to-be-tested graph database according to the value of the target attribute field contained in each edge of the vertex, to obtain a first edge set; and determining vertex statistics of the vertex according to a number of edges contained in each first edge set. 4.The method of claim 3, wherein the edges of each vertex in the to-be-tested graph database are divided according to the value of the target attribute field contained in each edge of the vertex, to obtain the first edge set, by: obtaining a reference range corresponding to the value of the target attribute field; and determining the first edge set according to the reference range, and dividing edges of each vertex in the to-be-tested graph database into the first edge set according to the value of the target attribute field contained in each edge of the vertex. A 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 a number of edges in a path composed of edges connected in sequence between the two vertices. The vertex statistics are obtained by: ​ ​ 3. The method of claim 1, the query dimension comprising: ​ ​ ​ ​ ​ ​ ​ 5. The method of claim 1 or 3, the query dimension comprising: ​ ​ For each vertex contained in the to-be-tested graph database, edges between the vertex and other vertices are divided according to path lengths between the vertex and the other vertices, to obtain a second-type edge set; According to a number of edges required to connect the vertex and other vertices contained in each second-type edge set, vertex statistical data of the vertex is obtained. 6.The method of claim 1, wherein the target query parameter is determined from the candidate query parameters according to the query cost values, and specifically comprising: dividing the candidate query parameters into different query parameter groups according to the query cost values corresponding to the candidate query parameters; determining a weight coefficient corresponding to each query parameter group according to a preset screening strategy, and determining a target query parameter group from the query parameter groups according to the weight coefficient, and taking candidate query parameters contained in the target query parameter group as the target query parameter.

7. The method of claim 6, the screening strategy comprising: The first screening strategy or the second screening strategy, wherein the first screening strategy is used to determine the weight coefficient of each query parameter group according to the query cost values of the candidate query parameters contained in each query parameter group, and the second screening strategy is used to determine the weight coefficient of each query parameter group according to a number of candidate query parameters contained in each query parameter group.

8. An electronic device, comprising: a processor; a memory for storing processor-executable instructions, wherein the processor implements the steps of the method of any one of claims 1-7 by running 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 of any one of claims 1-7. 10.A computer program product comprising computer program / instructions, which, when executed by a processor, implement the steps of the method of any one of claims 1-7.

Images