Database management system and method for graph view selection in relational graph database

Abstract

The present invention discloses a database management system for executing graph queries based on one or more graph views in a relational graph database. The database management system is used to: determine multiple graph views in the relational graph database based on one or more previous graph queries in the relational graph database to obtain multiple candidate graph views in the relational graph database. In addition, the database management system is used to: store a subset of the multiple candidate graph views in the relational graph database; and execute graph queries in the relational graph database based on the subset of the multiple candidate graph views in the relational graph database. By selecting the subset of the multiple candidate graph views in the relational graph database, the database management system can improve the processing speed of graph queries.

Description

Technical Field

[0001] The present invention relates to database systems and, more particularly, to a database management system and method for executing one or more graph queries. Background Art

[0002] Graph data is becoming increasingly prevalent in many application domains, including social networking, biology and medicine, and real-time routing and tracing. This trend has driven a surge in graph databases, as they often excel in these scenarios. Two key factors contributing to the success of graph databases are the property graph model (PGM) and accompanying graph query languages, such as the Gremlin query language. The property graph model represents graph data in a natural way, associating vertices and edges with a set of properties, where each property is a key-value pair. Graph query languages ​​like Gremlin enable users to concisely query their application's property graphs, offering rich functionality and unique features, including declarative pattern matching, graph traversals, and reachability queries. With the rapid adoption of the property graph model and graph query languages ​​for graph data management, relational databases have implemented these two graph technologies on top of relational stores. These systems, referred to as relational graph databases, implement the property graph model on a relational store, convert graph queries into relational queries, such as SQL queries, and finally execute the relational queries in a relational query engine, such as SQL queries. Figure 1 An exemplary relational graph database 100 is shown. The relational graph database 100 is used to process a graph query 101 on a relational database management system (RDBMS) 105 according to a property graph (ie, a property graph model 103).

[0003] However, traditional relational graph databases have several limitations when processing (i.e., answering) graph queries. First, these approaches are limited to specialized graph queries that can be translated into or mixed with SQL, thus failing to support mature graph query capabilities. Second, these approaches inefficiently execute complex graph queries due to the performance overhead of computing the graph from the relational store at runtime. Finally, these approaches fail to consider the resource budget required to house graph data, which is critical to end users and often cannot be compromised. Summary of the Invention

[0004] The object of the present invention is to provide an improved database management system and method to improve the performance of graph queries in a relational graph database.

[0005] The above and other objects are achieved by the subject matter claimed in the independent claims. Other implementations are apparent from the dependent claims, the description and the drawings.

[0006] According to a first aspect, a database management system for executing one or more graph queries based on one or more graph views in a relational graph database is provided. The database management system includes a memory and a processor. The processor is used to determine a plurality of graph views in the relational graph database based on one or more previously processed graph queries in the relational graph database to obtain a plurality of candidate graph views in the relational graph database. In addition, the processor in the database management system is used to: store a selected subset of the plurality of candidate graph views in the relational graph database in the memory; and execute one or more graph queries in the relational graph database based on the subset of the plurality of candidate graph views in the relational graph database. Advantageously, the database management system provided by the first aspect can select and maintain a subset of "optimized" candidate graph views in the relational graph database within the memory constraints of the database management system, thereby improving the performance of graph queries. The database management system can be used to execute the one or more graph queries sequentially or substantially in parallel.

[0007] The relational graph database used in this article implements the property graph model on a relational database and is used to convert graph queries into SQL queries, which are then executed in a relational query engine. Therefore, a relational graph database is a database that supports both graph and relational models. The graph queries can be Gremlin graph queries.

[0008] In one possible implementation, each candidate graph view may occupy a corresponding portion of the memory in the database management system of possibly different sizes. The processor in the database management system may also be used to determine the subset of the multiple candidate graph views in the relational graph database based on the total size of the memory that can be used to store the selected subset of the multiple candidate graph views in the relational graph database and / or one or more performance indicators associated with the multiple candidate graph views. As described in detail below, the one or more performance indicators (or performance metrics) may be one or more local performance indicators associated with the corresponding candidate graph views and / or one or more global performance indicators associated with a group of candidate graph views.

[0009] In another possible implementation, the database management system may also include a graph query engine and a relational query engine; the database management system is further used to determine the local performance indicators of each of the multiple candidate graph views by comparing one or more queries processed by the graph query engine using the corresponding candidate graph views with the same one or more queries processed by the relational query engine without using the corresponding candidate graph views.

[0010] In another possible implementation, the database management system is further used to: when the one or more graph queries cannot be processed by the graph query engine (i.e., cannot be answered), convert the one or more graph queries used for the graph query engine into one or more relational queries used for the relational query engine.

[0011] In another possible implementation, the database management system is further used to determine the subset of the multiple candidate graph views in the relational graph database based on the multiple local performance indicators of the multiple candidate graph views and the total size of the memory that can be used to store the selected subset of the multiple candidate graph views in the relational graph database.

[0012] In yet another possible implementation, the database management system is further configured to determine whether the one or more graph queries can be processed by the graph query engine using the corresponding candidate graph views.

[0013] In another possible implementation, the one or more performance indicators associated with the multiple candidate graph views include multiple global performance indicators, wherein each global performance indicator is associated with a corresponding different combination of the multiple candidate graph views. The database management system is further configured to determine the subset of the multiple candidate graph views in the relationship graph database based on the multiple global performance indicators. In other words, the database management system may be configured to determine the subset of the multiple candidate graph views in the relationship graph database within the constraints for storing the selected candidate graph views in the memory by selecting the combination of candidate graph views that provides the maximum benefit (i.e., the maximum global performance indicator). The corresponding combinations of candidate graph views and their global performance indicators (i.e., the total benefit) may define a state, and the process of determining the subset of the multiple candidate graph views in the relationship graph database is defined as a state search. An initial state may correspond to an input candidate view set, i.e., multiple candidate graph views with a certain benefit (i.e., the global performance indicator). By adding, modifying, and removing views from the initial state, another state, i.e., a combination of candidate graph views, may be obtained based on the initial state. The benefit (i.e., the global performance indicator) of the other state may be higher than that of the initial state, and so on.

[0014] In another possible implementation, the database management system is further configured to determine a global performance indicator for a corresponding combination of the plurality of candidate graph views by splitting the corresponding candidate graph view into at least two candidate subgraph views. Splitting the corresponding candidate graph view into at least two candidate subgraph views is referred to herein as a fission operation.

[0015] In another possible implementation, the database management system is further configured to generate a new candidate graph view by merging subgraphs of at least two graph views from the plurality of candidate graph views, and determine a global performance indicator for a corresponding combination (i.e., a corresponding state) of the plurality of candidate graph views. The process of merging the subgraphs of at least two graph views from the plurality of candidate graph views is referred to herein as a fusion operation. The main purpose of the splitting operation and the fusion operation is to identify and merge common subgraph components of at least two graph views from the plurality of candidate graph views.

[0016] In another possible implementation, each candidate graph view includes a candidate graph view mode and a candidate graph view content; the database management system is also used to: determine the multiple candidate graph views based on the one or more previous graph queries by mapping one or more previous graph queries to one or more candidate graph view modes.

[0017] In another possible implementation, the database management system is further configured to map (i.e., convert) the one or more previous graph queries to the one or more candidate graph view schemas by sequentially mapping the nodes and edges of the one or more previous graph queries to the nodes and edges of the one or more candidate graph view schemas. The database management system may also implement a filtering-and-verification framework for checking whether a given graph query can be answered by the candidate graph views thus constructed.

[0018] In another possible implementation, the database management system is further configured to: generate a corresponding edge derivation graph based on the one or more previous graph queries to generate corresponding candidate graph view content for the corresponding candidate graph view. In one implementation, the database management system is further configured to: sequentially traverse edges starting from a starting edge based on a query pattern; and for each accessed pattern edge, add edges and end points from all matching results in the data graph to the view graph until all patterns have been accessed. Because the matching results of an edge depend on its previous traversal, the database management system can copy the previous traversal and cache the accessed end points as intermediate results, and then use these results to calculate the matching results of subsequent traversals.

[0019] In another possible implementation, the database management system is further configured to: determine a cost metric value for each candidate graph view; and limit the number of candidate graph views by removing candidate graph views whose cost metric value exceeds a cost metric threshold. Thus, the database management system can be configured to prune the candidate graphs based on their cost metric values.

[0020] In another possible implementation, the database management system is further used to: receive one or more other graph queries; and dynamically adjust the subset of the multiple candidate graph views in the relational graph database stored in the memory based on the one or more other graph queries in the relational graph database. When a new query is included in a previous candidate graph view, the database management system may update the benefits of the corresponding view. When a new query is not included in a previous candidate graph view, the database management system may store a newly selected subset of the updated candidate graph views in the relational graph database in the memory. In other words, if there is insufficient memory space, newly selected candidate graph views that are not in the previous view selection may be cached, and outdated views may be deleted.

[0021] According to a second aspect, a method for executing a graph query based on one or more graph views in a relational graph database is provided. The method comprises the following steps: determining a plurality of graph views in the relational graph database based on one or more previously processed graph queries in the relational graph database to obtain a plurality of candidate graph views in the relational graph database. In addition, the method comprises the following steps: storing a selected subset of the plurality of candidate graph views in the relational graph database. In addition, the method comprises the following steps: executing a graph query in the relational graph database based on the subset of the plurality of candidate graph views in the relational graph database. Advantageously, the method provided by the second aspect can select and maintain a subset of "optimized" graph views in the relational graph database, thereby improving the performance of graph queries.

[0022] The method provided in the second aspect of the present invention can be performed by the system provided in the first aspect of the present invention. Therefore, the other features of the method provided in the second aspect of the present invention are directly derived from the functionality of the system provided in the first aspect of the present invention and its different implementations described above and below.

[0023] The following drawings and description set forth in detail one or more embodiments. Other features, objects, and advantages are apparent from the description, drawings, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The embodiments of the present invention are described in detail below with reference to the accompanying drawings, in which:

[0025] Figure 1 It is a diagram of the general architecture of a relational graph database;

[0026] Figure 2a is a schematic diagram of a database management system for executing graph queries provided by an embodiment;

[0027] Figure 2bis a schematic diagram of structural and functional components in a database management system for executing graph queries provided by an embodiment;

[0028] Figure 3 is a flow chart of processing steps implemented by a database management system provided by an embodiment;

[0029] Figure 4 A first algorithm implemented by a database management system provided by an embodiment is shown;

[0030] Figure 5 A second algorithm implemented by a database management system provided by an embodiment is shown;

[0031] Figure 6 A third algorithm implemented by a database management system provided by an embodiment is shown;

[0032] Figure 7 An indexing scheme implemented by a database management system provided by an embodiment for maintaining multiple candidate graph views is shown;

[0033] Figure 8 Comparing query performance of multiple queries between a database management system provided by an embodiment and a relational database management system;

[0034] Figure 9a and Figure 9b The view size and running time of the two algorithms implemented by the database management system provided by different embodiments are compared;

[0035] Figure 10 The view benefits and resource budgets of two algorithms implemented by database management systems provided by different embodiments are compared;

[0036] Figure 11 The present invention is a flowchart of a database management method provided by an embodiment.

[0037] In the following, identical reference numerals refer to identical features or at least functionally equivalent features. DETAILED DESCRIPTION

[0038] In the following description, reference is made to the accompanying drawings that form a part of the present invention, which illustrate, by way of illustration, specific aspects of embodiments of the present invention or specific aspects in which embodiments of the present invention may be used. It should be understood that the embodiments of the present invention may be used in other aspects and may include structural or logical changes not depicted in the drawings. Therefore, the following detailed description should not be understood in a restrictive sense, and the scope of the present invention is defined by the appended claims.

[0039] For example, it should be understood that the disclosure related to the described method also applies to the corresponding device or system for performing the method, and vice versa. For example, if one or more specific method steps are described, the corresponding device may include one or more units (e.g., functional units) to perform the one or more method steps described (e.g., one unit performs one or more steps, or multiple units each perform one or more of the multiple steps), even if such one or more units are not explicitly described or shown in the drawings. On the other hand, for example, if a specific device is described in terms of one or more units (e.g., functional units), the corresponding method may include a step to perform the function of the one or more units (e.g., a step to perform the function of the one or more units, or multiple steps that each perform the function of one or more of the multiple units), even if such one or more steps are not explicitly described or illustrated in the drawings. In addition, it should be understood that unless otherwise explicitly stated, the features of the various exemplary embodiments and / or aspects described herein may be combined with each other.

[0040] Figure 2a 2 is a schematic diagram of a database management system 200 provided by an embodiment. The database management system 200 includes a processor 200a and a memory 200b. The processor 200a is used to execute one or more graph queries, such as Gremlin queries, based on one or more graph views in a relational graph database. The relational graph database used in this article implements a property graph model (PGM) on a relational database and is used to convert graph queries into SQL queries, which are then executed in a relational query engine. Therefore, a relational graph database is a database that supports both graph and relational models.

[0041] Gremlin is a widely supported query language in graph databases, serving as the equivalent of SQL for graph database systems. Gremlin is a graph traversal language for traversing property graphs, allowing queries to be expressed as one or more graph traversals. Specifically, declarative traversals are represented by a set of traversal patterns, which can be mapped to subgraph queries. Gremlin's pattern matching is a generalized traversal that can also be mapped from other traversals, such as linear traversals, nested traversals, and path traversals.

[0042] Figure 2b The diagram is a schematic diagram of the structure and functional components (i.e., the overall architecture) of a database management system 200 for executing graph queries provided by an embodiment. Figure 2a and Figure 2bAs described in detail in the context of , the processor 200a in the database management system 200 is used to determine multiple graph views in the relationship graph database based on one or more previously processed graph queries in the relationship graph database 205 to obtain multiple candidate graph views 203a to 203n in the relationship graph database 205. In addition, the processor 200a in the database management system 200 is used to: store a selected subset of the multiple candidate graph views 203a to 203n in the relationship graph database in the memory 200b; and execute a graph query in the relationship graph database based on the subset of the multiple candidate graph views 203a to 203n in the relationship graph database. As described in detail below, Figure 2b In the illustrated embodiment, the relational graph database includes an SQL converter 208, an SQL query engine 210, and a relational database, i.e., relational tables 211. Advantageously, the database management system 200 can select and maintain a subset of "optimized" candidate graph views in the relational graph databases 208, 210, 211 within the memory constraints of the database management system 200, thereby improving the performance of graph queries.

[0043] Therefore, the database management system 200 takes full advantage of the materialized graph views that can be pre-cached to speed up the relational graph database (e.g., Figure 2b Graph query speed in the relational graph database (208, 210, and 211) shown in Figure 2. Materialized views (or simply "views") store and maintain query results to facilitate access to data in their underlying base tables. Materialized views are a natural embodiment of the concept of precomputation and caching in databases. Instead of computing queries from the underlying data, the database system can use results that have already been computed, stored, and maintained.

[0044] Before describing in detail the different embodiments of the database management system 200, some aspects of the database management system 200 provided by one embodiment are first outlined below. The graph view automatic selector implemented by the database management system 200 provided by one embodiment can quickly and reasonably recommend views that are beneficial to a specified graph workload in a relational graph database. Candidate graph views can be constructed from query history records through a query-to-schema mapping mechanism. The benefit of a view can be calculated by evaluating queries in the relational engine and the in-memory graph engine 205. The database management system 200 provided by one embodiment can implement one of two methods for selecting a graph view based on a view benefit value defined by one or more local performance indicators or global performance indicators. Incremental view maintenance can be implemented by the database management system 200 provided by one embodiment to handle incoming new data and workloads.

[0045] Candidate views are obtained from the query history, where each view can be associated with a weight based on query frequency. Based on a threshold of query cost and the size of the set of tables used, uninteresting views can be pruned or eliminated. The remaining subset that meets the user-defined resource budget can be considered as candidate views to determine the best view selection, i.e., the candidate graph view subset.

[0046] In one embodiment of the database management system 200, a query-to-schema mapping mechanism converts Gremlin queries into graph query schemas and then stores all subgraphs isomorphically embedded within the data graph g for a given query, thereby obtaining a graph view. A filtering and validation framework can be used to check whether a given query can be answered by the constructed view. In one embodiment, the database management system 200 can utilize materialized views to evaluate the costs and benefits of included queries. The view benefit assessment can be calculated based on the view and the relational graph database.

[0047] Optionally, the Gremlin and Gremlin2SQL optimizers can be used to obtain a benefit value and view size for each view, given the query workload, a set of candidate views, and a memory budget. Benefit can define the cost savings from using candidate views to answer queries. View size measures the memory space occupied by a view. A knapsack dynamic programming method can be implemented by the database management system 200 provided in one embodiment to generate candidate view recommendations, i.e., a subset of candidate views 203a through 203n given a given memory budget.

[0048] Optionally, taking into account the query workload, a set of candidate views 203a to 203n, and a memory space budget, a graph genetic algorithm is implemented by the database management system 200 provided by an embodiment to explore the inclusion relationship and common parts between the candidate graph views 203a to 203n. A smaller subset of views can be generated accordingly. According to an embodiment, in a two-stage framework, each graph pattern is decomposed into a set of small subgraph fragments, and then the common fragments are merged, and the remaining fragments are merged. Finally, the database management system 200 provided by an embodiment can implement a greedy method to recommend view selection, that is, select a subset of the candidate graph views 203a to 203n.

[0049] In one embodiment, the database management system 200 implements an incremental view maintenance process in the event of data and workload updates. For data updates, the in-memory view can be updated accordingly, and if the number of updates reaches an update threshold, the materialized view can be recalculated from the base table for update efficiency. Regarding workload updates, in one embodiment, the graph gene index can be used to determine whether the new workload is included in the previous graph or gene. If so, the benefits associated with the used view are updated. Otherwise, a greedy selection algorithm can be called to select a new set of candidate views. If there is insufficient memory space, the newly selected views that are not in the previous view selection can be cached and outdated views can be deleted.

[0050] The following provides detailed descriptions of various embodiments of the database management system 200. The first portion of the following description provides a high-level architectural description of how the database management system 200, provided in one embodiment, selects candidate graph views 203a through 203n under a given workload. Another portion of the following description provides details regarding candidate view selection, query mapping, candidate view recommendation, and view maintenance implemented by various embodiments of the database management system 200.

[0051] 1. System Overview

[0052] like Figure 2b As shown, the most important part of the database management system 200 is the abstraction layer 201 implemented by the processor 200a. The abstraction layer 201 is located above the RDBMS 210, receives a set of graph queries, especially Gremlin queries, and constructs one or more graph views in the memory 200b, which can then be used to speed up future graph queries. The first component in the abstraction layer 201 is the automatic view manager 206, which can be implemented by the processor 200a and can be responsible for three tasks. The first task is to extract view data 207 from the underlying base table 211. This is achieved by converting between queries and views. The second task is to select views and store them in the memory 200b according to one or more selection algorithms described in detail below. The third task is to incrementally maintain view definitions and data as data and workloads change.

[0053] In addition to the view manager 206, another component is the in-memory graph view component 202, which caches a selected subset of candidate graph views that can be used to answer queries using a graph query engine 205 (e.g., TinkerPop graph engine 205). In one embodiment, the view structure can adopt the structure of TinkerPop, i.e., TinkerPop's in-memory property graph implementation. After mapping the query and view to the graph schema, the graph query engine 205 can use a modified subgraph inclusion algorithm to determine whether the query is included in the view, as described in detail below.

[0054] Another component in addition to the graph view component 202 is a SQL converter, such as Gremlin2SQL converter 208, which converts graph queries (e.g., Gremlin queries) into SQL queries and then sends the SQL queries to the relational query engine 210 for execution when the graph view cannot answer the query. In one embodiment, this conversion can be achieved by mapping the vertex set and edge set of the graph to relational tables 211 and converting a set of Gremlin pipelines into predefined SQL templates. As described above, in Figure 2b In the illustrated embodiment, the relational graph database includes an SQL converter 208 , an SQL query engine 210 , and a relational database, namely, a relational table 211 .

[0055] The above concepts are illustrated using the following example of a graph query in a social network. For a person p (id = 4145), find p's two-hop friends. This query helps recommend new friends to the target person in a social network. Specifically, this query can be expressed using Gremlin as follows:

[0056] gV().has('personid','4145').out("knows").out("knows")

[0057] Typically, this Gremlin query is converted to a SQL query using Gremlin2SQL technology, as shown below:

[0058] WITH friends AS(SELECT*FROM customer c INNER JOIN knows k1 on c.id=k1.personid1 where c.id='4145')

[0059] WITH 2hopfriends AS(SELECT k2.personid2 as id from friends f JOINknows k2 on f.personid2=k2.personid1")

[0060] SELECT 2f.name from 2hopfriends 2f JOIN customer c on c.id=2f.id;

[0061] As can be seen from the above example, a simple Gremlin traversal query is converted into a SQL query with three inner joins, which incurs significant overhead. As described above and in more detail below, the database management system 200 can select and maintain a subset of "optimized" candidate graph views in the relational graph database within the memory constraints of the database management system 200, thereby improving the performance of graph queries in the relational graph databases 208, 210, and 211.

[0062] Figure 3 Flowchart of the processing stages or steps implemented by a database management system 200 for selecting and maintaining a subset of candidate graph views 203a to 203n according to one embodiment. In a first stage 301, a set of Gremlin queries is obtained. In another stage 303, a set of candidate graph views with view modes and view contents are generated, as described in detail below. In another stage 305, view benefits and sizes are determined based on a filtering and validation framework, and finally, an optimized view selection is determined, as described in detail below. In a final stage 307, the candidate view selection is maintained and refreshed if new workloads arise.

[0063] 2. Query-driven view construction

[0064] The following uses the following data graph, Gremlin schema query, and Gremlin graph view definitions to describe in more detail how the database management system 200 provided by one embodiment performs query-driven construction on the candidate graph views 203 a to 203 n.

[0065] The data graph is a multi-relational, attributed, directed graph G = (V, E, L, P), where:

[0066] (1) V is a set of vertices;

[0067] (2) Among them, (v, v') represents the edge from vertex v to v';

[0068] (3) L is a labeling function such that for each vertex v∈V and edge e∈E, L(v) or L(e) is a label in the alphabet Σ;

[0069] (4) P is a function such that for each node v∈V and each edge e∈E, P(v) or P(e) is a set of key / value pairs called attributes. Intuitively, P represents the attributes of a vertex, e.g., name, age, gender, or the attributes of an edge, e.g., timestamp.

[0070] A Gremlin schema query is a directed graph Q over a data graph G. g =(V p ,E p ,L,f), where:

[0071] (1)V p and E p They are the set of pattern vertices and the set of ordered pattern edges;

[0072] (2) L is a label function such that for each vertex v∈V p and edge e∈E p , L(v) or L(e) is a label in the alphabet Σ;

[0073] (3) f is a Boolean predicate such that for every vertex v∈V p and edge e∈E p , f(v) and f(e) apply.

[0074] Expressed as V(Q g ) is derived from the Gremlin schema query Q g , with Q g The same definition and expression is given by V G (Q g )'s view content, which includes the view content of Q g All subgraphs composed of edges and nodes are embedded. Therefore, V G (Q g ) can be used to answer Q g , without accessing the data graph g or other materialized data.

[0075] In one exemplary embodiment, a graph query may be a graph query in a social network that finds the friends of a person with id '001' and also returns the friend's workplace and school. The corresponding Gremlin graph query pattern may be expressed as:

[0076] gV().match(

[0077] __.as('p').has('id','001').out('knows').as('f'),

[0078] __.as('f').out('workAt').as('c'),

[0079] __.as('f').out('studyAt').as('s'))

[0080] .select('p','f','c','s')

[0081] It should be understood that in this example, the Gremlin graph query pattern consists of two components: the data graph g and a match() step that declares a set of connected traversal patterns, where the first pattern is a start edge with the outgoing node having the Boolean function has('id','001'); the as() step labels the query nodes, and the out() step defines the labeled outgoing edges of each traversal pattern.

[0082] A graph view, such as a Gremlin graph view, consists of two parts, namely, a view schema and a view content. As described above, an embodiment of the database management system 200 adopts a query-driven approach that generates candidate views based on a workload, i.e., queries that the database management system 200 has previously processed. However, all materialized views of a workload are generally not feasible because this would overwhelm the enumeration space for query cost evaluation. Therefore, in one embodiment, the database management system 200 is used to trim candidate views. In one embodiment, the database management system 200 can be used to trim candidate views using three trimming stages or conditions. In one embodiment, the database management system 200 can be used to use one or more of the following three trimming stages or conditions.

[0083] The database management system 200 can be configured to determine, in the first pruning phase, whether the cost of the corresponding candidate views 203 a to 203 n is a small fraction of the total cost of the workload, or whether its cost is less than a small threshold, such as 1 second (intuitively, low-cost queries that can be well processed by the underlying relational engine should not be considered). The cost can be obtained from historical statistics (if available) or can be a cost estimated by the underlying database through the optimizer.

[0084] In an optional or additional pruning phase, the database management system 200 can determine whether the reference table set of the candidate graph views 203a to 203n is small in size and infrequently appears. This criterion is based on the observation that if a graph query involves an infrequently appearing subset of tables, it is unlikely that the query will be reused in the future.

[0085] During an optional or additional pruning phase, the database management system 200 can determine whether the number of rows it uses exceeds the upper limit of the memory resource budget. This means that the maximum memory resource budget for accommodating graph data cannot be affected, and therefore, such queries will not be considered. One way to obtain the row size used by a query is to call the relational optimizer to estimate the rows used by a given query.

[0086] Given a set of Gremlin graph queries, the database management system 200, in one embodiment, is used to derive graph traversals parsed from the queries and normalize the Gremlin graph queries into Gremlin pattern queries. In another step, the database management system 200 is used to map the Gremlin pattern queries to graph query patterns by gradually adding traversal patterns starting from a starting vertex. Since, in one embodiment, query nodes have given aliases, the mapping process can also map alias labels to node labels in the pattern graph. For example, for the above example, the first traversal pattern can be derived as p(id=001)->f, and the following two patterns f->c, f->s can be added to the pattern graph. Finally, the labels p, f, c, s can be mapped to person, person, company, and school inferred from the pattern graph.

[0087] In another stage, the database management system 200 is used to generate view content. In one embodiment, the database management system 200 is used to create an edge-derived graph as view content by the following steps: (1) traversing the edges sequentially from the starting edge according to the query pattern; (2) for each accessed pattern edge, adding all matching results between the edge in the data graph g and its end point to the view graph; (3) when all patterns have been accessed, the process terminates. Since the matching results of an edge depend on its previous traversal, the previous traversal can be copied and the accessed end points can be cached as intermediate results, and then these results can be used to calculate the matching results of subsequent traversals.

[0088] 3. Benefit-based view evaluation

[0089] In the following, v represents a candidate view 203a to 203b under a given workload Q. To quantify the positive impact of caching view v, the database management system 200 can be configured to use benefit b as a local performance metric for view v, as defined below. The benefit b of view v is the cost savings of processing a query using view v compared to using the underlying relational store (i.e., database R). Mathematically, this can be expressed using the following equation:

[0090]

[0091] Among them, w i Denotes query q in workload Q i The weights, cost(q|R) and cost(q|v) represent the cost of query evaluation on the relational graph databases 208, 210, 211 and the cost of the view, respectively.

[0092] To calculate the view benefit, i.e., the local performance metric, in one embodiment, the database management system 200 can be configured to use the PROFILE feature of the Gremlin query to obtain the corresponding query evaluation cost. In the case where the total benefit of a view is negative or small, the database management system 200 can prune these views during the candidate view selection process.

[0093] However, before evaluating the query cost through the view, the database management system 200 can be used to determine whether the query can be answered by the view. In one embodiment, the database management system 200 can be used to implement a filtering and validation framework, described in detail below, to achieve this goal.

[0094] In one embodiment, the filtering and validation framework implemented by database management system 200 includes two main phases, described in detail below. In the first phase, database management system 200 checks whether the view pattern is contained within the query pattern. If not, the corresponding query is filtered out (i.e., clipped) and not evaluated on the checked view. In the second phase, database management system 200 also verifies whether the view content contains all matching results for a given query. The two phases of the filtering and validation framework implemented by database management system 200, provided in one embodiment, are described in more detail below.

[0095] In one embodiment, the database management system 200 can be used to verify whether a query pattern is contained in a view pattern according to the following definition of pattern inclusion. Query Q' is valid if and only if the following conditions hold: g The pattern is contained in another query Q g In the model, it is represented as

[0096] 1. Existence from Q' g to Q g The subgraph isomorphism mapping M, such that Q' g It's Q g Subgraph embedding of ;

[0097] 2. For each query node v'∈Q' g , mapping node v=M(v') has the same label and the same Boolean predicate as v';

[0098] 3. For each edge e'∈Q' g , the mapping edge e=M(e') has the same label and the same Boolean predicate as e'.

[0099] Although finding all subgraph isomorphism mappings is NP-Hard, several practical algorithms can be implemented to find subgraph isomorphisms in polynomial time. In one embodiment, the database management system 200 can be used to implement the VF2 algorithm or its variants (which can run in quadratic time to check for pattern inclusion between two queries) disclosed in "A (sub)graph isomorphism algorithm for matching large graphs" published by L.P. Cordella, P. Foggia, C. Sansone, and M. Vento in 2004, IEEE Transactions on Pattern Analysis and Machine Intelligence, 26(10), pp. 1367-1372. More specifically, in one embodiment, the database management system 200 can implement the VF2 algorithm to find subgraph isomorphisms under the above condition 1. If so, the database management system 200 can check whether the above conditions 2 and 3 also hold.

[0100] Assumptions And V G (Q g ) is expressed as Q g The database management system 200 can be used to determine whether V can be used by determining that the following two conditions are met: G (Q g ) Answer Q' g , expressed as

[0101] 1. There exists from every edge e'∈E' p To edge pattern e∈E p Mapping M, where Ep is V P (Q g ) is a set of edge patterns.

[0102] 2. For e'∈Q' g There is no mapped edge e∈Q g , if the end point v in edge e e With v'∈Q' g If there is a mapping, then node v e =M(v') must appear in Q g in the previous traversal pattern of .

[0103] As described above, the above conditions 1 and 2 can enable the database management system 200 to verify the view content V G (Q g ) including Q' g All subgraphs of g and Q gThere are subgraph isomorphisms between them). This is because the graph view V G (Q g ) is an edge-derived graph, which is generated by the database management system 200 by querying Q g Therefore, it is possible to traverse some g The edge of the pattern edge, thus losing Q' g This can be further illustrated based on the following simple example of chain traversal. Assume two pattern queries: Q1: a→b→c and Q2: a→b→c→d. It can be understood that the pattern of Q1 is contained in the pattern of Q2. However, if the starting edge of Q2 is c→d and there is no mapping with Q1, then due to the constraint on the query node d, the view V G (Q2) It is not guaranteed that all matching vertices of the query node c are included. In this case, the view V G (Q2) cannot be used to answer graph query Q1. However, if the starting edge of graph query Q2 is not c→d, it can be understood that c→d must be traversed after the pattern b→c. Therefore, in this case, graph query Q1 can use view V G (Q2) to answer.

[0104] Using the definitions introduced above, Figure 4 A first algorithm implemented by the database management system 200 for determining whether a graph query can be answered using a view is shown. Figure 4 The algorithm shown queries Q with the pattern g , view V(Q' g ) and query Q g and Q' g Takes the subgraph isomorphism M between as input and performs the following steps:

[0105] (1) By checking Q' g Whether each edge of E exists in M(Ep) to verify whether the above condition 1 is true, where E p Indicates V P (Q g )’s edge pattern set;

[0106] (2) Identify Q' through iteration g The access vertex map M(V p ), and add the visited vertices to D v In the dictionary, verify whether the above condition 2 is true;

[0107] (3) Once a Boolean value is returned, terminate the process.

[0108] If the dictionary D v Including M(V p), then the database management system 200 is used to verify the graph query Q g View V G (Q' g )answer.

[0109] 4. Automatic view selection

[0110] The following describes in more detail an embodiment of view selection implemented by database management system 200. More specifically, the first portion of the following description explains in more detail the general view selection problem solved by database management system 200. The second and third portions of the following description describe in more detail a benefit-driven algorithm (BDA) (using a local performance metric) and a graph genetic algorithm (GGA) (using a global performance metric) implemented by an embodiment of database management system 200 for selecting a subset of candidate views.

[0111] The general view selection problem solved by the database management system 200 can be formulated as follows. Given a set V of candidate views under a specific workload Q and a number S (defined as the available space in the memory 200b), the view selection problem is to select a set V of views derived from V. s , so that b(V s ,Q) is maximized, with the constraint that V s The total memory space occupied is less than S. The size of view V or view size s v It can be defined as the total number of edges and nodes of the view content of the corresponding view.

[0112] Even in V s is a subset of V and V s The view selection problem is also NP-hard in the special case where each view in is independent (i.e., cannot be merged with other views). For this static case, the database management system 200 can reduce the knapsack problem to finding a set of k items with space usage s1…sk and benefits b1…bk such that the sum of the benefits of the selected items that fill the memory space budget S is maximized. In one embodiment, the database management system 200 can also be used to handle dynamic cases where V s The views in the table can be changed by adding, modifying, or removing views. The computation of this embodiment is more complex because the space of potential view sets is very large, and exploring all possible combinations is generally not feasible in practice. The following describes in more detail the corresponding algorithms implemented by database management system 200 for each setting.

[0113] Figure 5A possible algorithm implemented by the database management system 200 for graph view selection is shown, which is referred to herein as the Benefit-Driven Algorithm (BDA). The BDA considers the view selection problem as a static case of the knapsack problem. It uses a dynamic programming strategy to implement the following stages: (i) obtaining the size of each view v in the candidate view set V (for example, in one embodiment, the size of the memory graph can be directly used as the view size because the memory graph is constructed); (ii) by enumerating S V To evaluate the benefit (i.e., local performance index) of each view v in the candidate view set V, where B V represents the view benefit vector, S V Representing the size vector; (iv) using a bottom-up approach opposite to step (iii) to obtain a selected subset of candidate views.

[0114] This can be further illustrated by the following example of three graph queries Q1, Q2, Q3 in a social network:

[0115] Q1: gV().has('personid','001').as('p').out('knows').as('f').select('p','f')

[0116] Q2: gV().has('personid','001').as('p').out('knows')

[0117] .as('f').out('isLocatedIn').as('c').select('p','f','c')

[0118] Q3: gV().has('personid','001').as('p').match(

[0119] __.as('p').out('knows').as('f'),

[0120] __.as('f').out('workAt').as('c'),

[0121] __.as('f').out('studyAt').as('u'))

[0122] .select('p','f','c','u')

[0123] Q1 is used to find the friends of a person (id = '001'), Q2 is used to find the friends of the same person and their locations, and Q3 is used to return the workplaces and universities that the friends of the person (id = '001') graduated from. By invoking the VF2 algorithm with a validation framework implemented in database management system 200 according to one embodiment for checking schema inclusion, it is determined that Q1 is included in both Q2 and Q3. Therefore, the candidate view set is reduced to {Q2, Q3}.

[0124] The following is Figure 6 The graph genetic algorithm (GGA) implemented by an embodiment of the database management system 200 for selecting a subset of candidate views is described in more detail in the context of Figure 6 GGA is shown. It can be understood that the database management system 200 implements GGA to model the view selection process as a state search, where each state includes a selected view set and a total benefit (i.e., a global performance indicator). The initial state corresponds to the original candidate view set V, which has a certain benefit b(V). By adding, modifying, and removing views from the initial state, the database management system 200 is used to obtain another state V from the view set V. k , which can have a greater benefit b(V k ), and so on. In one embodiment, the database management system 200 is used to: If the state V k If the benefit of is not greater than the benefit of the original candidate view set V, then cancel the state V k , and continue to apply other view transformations starting from the previously obtained state. In one embodiment, the database management system 200 can be configured to cache all candidate views if sufficient memory space is available. However, in practice, available memory space is typically limited. Therefore, in one embodiment, the database management system 200 is configured to determine a subset of the plurality of candidate graph views in the relationship graph databases 208, 210, 211 based on the benefits associated with the corresponding view sets, within the constraints defined by the total size of the memory 200b available for storing the subset of candidate graph views 203a to 203n.

[0125] In order to add, modify and remove views to the initial state, the database management system 200 provided by one embodiment is used to implement two atomic probabilistic operations for transforming graph views, namely a split operation and a merge operation. In one embodiment, the split operation is a transformation that splits the graph view into multiple subgraph views, and the merge operation is a transformation that merges and connects the subgraphs of multiple views. Through the split operation and the merge operation, the database management system 200 is used to identify and merge common subgraph parts across views. This type of transformation is the most interesting because finding common subgraphs of a graph is an NP-hard problem. Since an exhaustive search for common subgraphs in a graph can be very costly, especially for large workloads, the database management system 200 provided by one embodiment is used to implement a probabilistic optimization algorithm to balance efficiency and optimality.

[0126] In one embodiment, the splitting operation implemented by the database management system 200 uses a vertex cutting method based on depth-first search (DFS) to find the attachment points of the graph, and then decomposes the graph into multiple subgraphs based on the attachment points of the graph. These subgraphs can be called genes of the graph. For example, in the above example, the attachment point of Q2 is the node f that can decompose Q2 into two genes: p(id='001')→f and f→c. In the DFS method, a vertex u is a attachment point if one of the following two conditions is met: (i) vertex u is the root of the DFS tree and has at least two child vertices; (ii) vertex u is not the root and has a child vertex v, so that no vertex in the subtree with v as the root has a back edge to one of the parent vertices of u.

[0127] In one embodiment, the merge operation implemented by the database management system 200 merges and joins views through the following steps.

[0128] (i) Call the VF2 algorithm with the verification method to check the subgraph inclusion between the graph gene and other graphs. If included, continue with step (ii), otherwise continue with step (iii).

[0129] (ii) Check whether the remaining genes have commonalities with genes in other maps. If so, merge these genes into the map. Otherwise, connect these genes to genes in the same map.

[0130] (iii) Merge the remaining genes into the graph.

[0131] It can be understood that, unlike BDA, which only considers a single-view case (associated with a local performance metric), GGA involves a multi-view response (associated with a global performance metric), in which the graph gene has been partitioned and connected to different graph views. In one embodiment, the database management system 200 is used to implement a greedy approach as follows.

[0132] (1) For each query q in workload Q, check whether each query can be answered by a single view. If so, evaluate the benefit and go to step (3). Otherwise, check whether each query can be contained in multiple views with genes, and these views can include the hypergraph of query q. If so, go to step (2). Otherwise, go to step (3).

[0133] (2) The total benefit of the view set V is evaluated by the following equation:

[0134]

[0135] Among them, the cost includes part of the evaluation cost∑ v∈V cost(q|v) and combined cost The sum of cost(q|R) represents the query cost on the relational graph databases 208, 210, and 211.

[0136] After evaluating the total benefit b(V,q), the benefit is distributed to each v∈V in proportion to the partial evaluation cost (i.e., cost(q|v)).

[0137] (3) Repeat this process until all queries are answered.

[0138] (4) Iteratively select the view with the largest benefit until the total size exceeds the memory size constraint S.

[0139] 5. Index-based view maintenance

[0140] In one embodiment, the database management system 200 is used to support view maintenance in the case of data update and workload update. In one embodiment, this is achieved through a two-level graph-based index (referred to as a GG index in this article). Figure 7 A plurality of two-level graph gene indices 203a1 to 203ai, 203b1 to 203bj, and 203N1 to 203Nk for a plurality of candidate graph views 203a to 203n are shown. Advantageously, the GG index is the result of the GGA described above and therefore does not need to be generated from scratch. Once the subset of candidate graph views has been determined through the GGA, the GG index is automatically generated and can be cached in the memory 200b of the database management system 200 to maintain the view. As described in detail below, Figure 7 As shown, the GG index may include two integers or levels, and the database management system 200 may be configured to use a first integer (or level) of the GG index to identify graph views 203a to 203n and a second integer (or level) of the GG index to identify included graph genes.

[0141] To handle view data updates and ensure consistency between the view data and the underlying base data, the database management system 200 can be used to update the base data and then synchronize the updates to the view data. Updating the data of a selected subset of candidate views is generally simple because the data is stored in the memory 200b of the database management system 200. Therefore, these can be updated directly. However, updating the data of materialized views requires special handling because a large number of updates will incur a huge cost due to random disk I / O operations. To address this problem, the database management system 200 provided by one embodiment implements a lazy update strategy that delays updates for a fixed period of time and recalculates the materialized view from the underlying base data if the number of updates reaches the view size.

[0142] In the case of a workload update, the database management system 200 can be used to use the GG index to determine whether the new workload is included in the selected views or genes. If so, that is, the new workload is included in the selected views or genes, the database management system 200 can be used to update only the benefits of the used views and genes. Otherwise, the benefits of the new workload are calculated, and the last step of the greedy selection is called again to select a new view set. Selected views that are not in the new view set are replaced by views in the new view set. More specifically, considering the new query q, the verification process implemented by the database management system 200 can include the following stages.

[0143] (1) For each view v in the first level of the GG index, use Algorithm 1 to check whether If yes, update the view yield accordingly. Otherwise, go to (2).

[0144] (2) Iteratively check each gene If so, the gene is added to the matched set M(g) and a fusion operation is performed on the remaining items in the set.

[0145] (3) Check if it exists If yes, update the view set's payoff accordingly, since the new query can be answered by the gene. Otherwise, go to (4).

[0146] (4) Call Algorithm 3 to generate a new generation and new selections. If there is insufficient memory space, cache the newly selected views that are not in the previous view selections and delete the obsolete views.

[0147] 6. Performance

[0148] The performance of an embodiment of the database management system 200 was tested using the following setup. The database management system 200 was implemented on a machine with a quad-core i5-4590 CPU and 16GB of RAM. Tinkerpop v3.3.0 was selected as the graph computation engine. In-memory graph views are implemented as TinkerGraph structures, and views are materialized as graphml files. The underlying SQL engine is SQLG v2.0.2, which supports Gremlin2SQL functionality.

[0149] We created an LDBC graph dataset with a scale factor of SF1, resulting in a graph with approximately 1 million vertices and 2 million edges. The exemplary workload includes a total of 9 Gremlin schema queries Q1 to Q9.

[0150] Figure 8 The performance of all queries Q1 to Q9 between a database management system 200 provided by an embodiment (referred to as "GRView") and an SQL engine SQLG are compared (for each query, the bar chart on the left shows the performance of the database management system 200 provided by an embodiment, while the bar chart on the right shows the SQLG performance). The results clearly show that the method implemented by the database management system 200 provided by an embodiment can significantly speed up the answering of graph queries compared to the relational method (i.e., SQLG). There are two reasons for the 16-fold speedup. First, the increase in the number of traversed edges corresponds directly to the query cost because the view method has a relatively small graph size, thus avoiding unnecessary graph traversals (for example, both views v1 and v2 can answer query q, and because view v1 is smaller than view v2, view v1 will answer query q faster because its query processing must process less data). Second, because the database management system 200 provided by an embodiment utilizes in-memory graph views and a native graph execution engine to execute input graph queries, it can speed up the execution of complex graph queries in relational storage areas by avoiding high-cost joins.

[0151] Figure 9a and Figure 9b A comparison between the performance of embodiments of the database management system 200 implementing BDA and GGA is shown. More specifically, Figure 9a The view sizes used by embodiments of the database management system 200 that implement BDA and GGA are compared, and Figure 9bThe runtime for answering queries was compared. The first observation was that the embodiment of the database management system 200 implementing GGA reduced the view size space by 58% compared to the embodiment of the database management system 200 implementing BDA, demonstrating that GGA is effective in identifying common portions of graph views. The second observation was that, overall, GGA was faster than BDA in answering queries. This is because GGA's view set is smaller than BDA's, resulting in shorter view construction and query evaluation times.

[0152] Figure 10 A comparison is shown between the performance of embodiments of the database management system 200 implementing BDA and GGA in optimizing the overall view benefit. More specifically, the memory space budget is adjusted from 100,000 to 400,000 (by 100,000 each time) to compare the view benefits obtained by the two different embodiments. Figure 10 As can be seen, the results show that GGA converges faster than BDA and has higher benefits. When the space budget reaches 200,000, as Figure 9a As shown, the view size of GGA is less than 150,000, so all views in GGA can be cached in memory, resulting in better performance in answering queries. On the other hand, as the space budget further increases to 400,000, BDA can have a constant benefit, that is, all views in BDA can be cached for a space budget of 400,000. However, GGA always has a larger view benefit than BDA, which confirms that GGA can provide better view selection through view state transitions.

[0153] Although several embodiments of the database management system 200 have been described above within the Gremlin framework, it will be appreciated that embodiments of the database management system 200 may be used to accelerate other types of graph queries, such as Cypher queries in relational graph databases. Cypher queries also use the MATCH syntax to declare graph pattern matches. In general, the above-described embodiments of the database management system 200 may also be implemented using the Cypher framework or a variant thereof. This may simply require modifying query parsing to identify ordered patterns and generate graph views. With respect to view selection, the view benefits calculated by the database management system 200 provided by the above-described embodiments may be calculated differently. For example, a possible variant of the above-described embodiments of the database management system 200 is a cost model approach that may incorporate other view factors such as maintenance costs.

[0154] Embodiments of the database management system 200 can be implemented in other applications for more complex graph analysis, such as online analytical processing (OLAP) for graph analysis. Although the embodiments described above focus on graph pattern matching, the embodiments can be extended to support more complex Gremlin graph query steps, such as control (repetition, branching, ...) or algorithms (e.g., shortest path, web page ranking). The main challenge is how to check the query inclusion of the view in such cases. In addition, although it has been considered above that views can fully answer queries, embodiments of the database management system 200 can also be used to partially answer queries. In other words, embodiments of the database management system 200 are able to answer more queries in combination with the underlying base tables.

[0155] Figure 11 1 is a schematic diagram of a method 1100 for performing a graph query based on one or more graph views 203a to 203n in a relationship graph database 208, 210, 211. The method 1100 includes step 1101 of determining, based on one or more graph queries in the relationship graph database 208, 210, 211, a plurality of graph views 203a to 203n in the relationship graph database 208, 210, 211 to obtain a plurality of candidate graph views 203a to 203n in the relationship graph database 208, 210, 211. Furthermore, the method 1100 includes step 1103 of storing a subset of the plurality of candidate graph views 203a to 203n in the relationship graph database 208, 210, 211, for example, in the memory 200b. The method 1100 comprises a further step 1105 of performing a graph query in the relational graph databases 208 , 210 , 211 based on a subset of the plurality of candidate graph views in the relational graph databases 208 , 210 , 211 .

[0156] Those skilled in the art will understand that the "blocks" ("units") in the various figures (methods and devices) represent or describe the functions of an embodiment of the present invention (and not necessarily independent "units" in hardware or software), thereby equally describing the functions or features of the device embodiments and the method embodiments (unit = step).

[0157] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the embodiments of the devices described are merely exemplary. For example, the unit division is merely a logical function division, and in actual implementation, it may be another division. For example, multiple units or components can be merged or integrated into another system, or some features can be ignored or not performed. In addition, the mutual coupling or direct coupling or communication connection shown or described can be implemented through some interfaces. The direct coupling or communication connection between devices or units can be implemented through electronic, mechanical or other forms.

[0158] Units described as discrete components may or may not be physically separate, and components shown as units may or may not be physical units, and may be located in one location or distributed across multiple network units. Some or all of the units may be selected based on actual needs to achieve the objectives of the embodiments.

[0159] In addition, the functional units in the embodiments of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

Claims

1. A database management system (200) for executing graph queries based on one or more graph views in a relational graph database, characterized in that The database management system (200) includes: Memory (200b); A processor (200a) configured to: determining a plurality of graph views in the relationship graph database according to one or more graph queries in the relationship graph database ( 203 a to 203 n ) to obtain a plurality of candidate graph views in the relationship graph database; storing a subset of the plurality of candidate graph views in the relationship graph database in the memory (200b); executing a graph query in the relational graph database based on the subset of the plurality of candidate graph views in the relational graph database; The database management system further includes a graph query engine (205) and a relational query engine (210); The database management system (200) is further configured to: determine a performance metric for each of the plurality of candidate graph views by comparing one or more queries processed by the graph query engine (205) using the corresponding candidate graph views with the same one or more queries processed by the relational query engine (210); The relational graph database is used to convert the one or more graph queries into SQL queries so as to execute the SQL queries in the relational query engine (210). The relational graph database is a database that supports both graph and relational models.

2. The database management system (200) according to claim 1, characterized in that Each candidate graph view occupies a corresponding portion of the memory (200b); The database management system (200) is further configured to determine the subset of the multiple candidate graph views in the relational graph database based on a total size of the memory (200b) that can be used to store the selected subset of the multiple candidate graph views in the relational graph database and / or one or more performance indicators associated with the multiple candidate graph views.

3. The database management system (200) according to claim 2, characterized in that The database management system (200) is further configured to convert the one or more graph queries for the graph query engine (205) into one or more relational queries for the relational query engine (210) when the one or more graph queries cannot be processed by the graph query engine (205).

4. The database management system (200) according to claim 3, characterized in that The database management system (200) is further configured to determine the subset of the multiple candidate graph views in the relational graph database based on the multiple performance indicators of the multiple candidate graph views and the total size of the memory (200b) that can be used to store the selected subset of the multiple candidate graph views in the relational graph database.

5. The database management system (200) according to claim 1, characterized in that: The database management system (200) is further configured to determine whether the one or more graph queries can be processed by the graph query engine (205) using corresponding candidate graph views.

6. The database management system (200) according to claim 2, characterized in that The one or more performance indicators associated with the multiple candidate graph views include multiple global performance indicators, wherein each global performance indicator is associated with a corresponding combination of the multiple candidate graph views; the database management system (200) is also used to: determine the subset of the multiple candidate graph views in the relational graph database based on the multiple global performance indicators.

7. The database management system (200) according to claim 6, characterized in that The database management system (200) is further configured to determine a global performance indicator of a corresponding combination of the plurality of candidate graph views by dividing the corresponding candidate graph view into at least two candidate sub-graph views.

8. The database management system (200) according to claim 6 or 7, characterized in that: The database management system (200) is further configured to generate a new candidate graph view by merging subgraphs of at least two graph views among the multiple candidate graph views, and determine a global performance indicator of a corresponding combination of the multiple candidate graph views.

9. The database management system (200) according to any one of claims 1 to 7, characterized in that: Each candidate graph view also includes candidate graph view content; the database management system (200) is further used to: determine the multiple candidate graph views according to the one or more graph queries by mapping the one or more graph queries to one or more candidate graph view patterns.

10. The database management system (200) according to claim 9, characterized in that The database management system (200) is further configured to map the one or more graph queries to the one or more candidate graph view modes by sequentially mapping the nodes and edges of the one or more graph queries to the nodes and edges of the one or more candidate graph view modes.

11. The database management system (200) according to claim 10, characterized in that The database management system (200) is further configured to generate a corresponding edge-derived graph according to the one or more graph queries, so as to generate corresponding candidate graph view content of the corresponding candidate graph view.

12. The database management system (200) according to any one of claims 1 to 7, characterized in that: The database management system (200) is further configured to: determine a cost metric value for each of the candidate graph views; The number of candidate graph views is limited by removing candidate graph views having a cost metric value greater than a cost metric threshold.

13. The database management system (200) according to any one of claims 1 to 7, characterized in that: The database management system (200) is further configured to: receive one or more other graph queries; and adjust the subset of the one or more candidate graph views in the relational graph database in the memory (200b) based on the one or more other graph queries in the relational graph database.

14. A method (1100) for performing a graph query based on one or more graph views (203a to 203n) in a relational graph database, characterized in that The method (1100) comprises: determining (1101) a plurality of graph views (203a to 203n) in the relational graph database according to one or more graph queries in the relational graph database to obtain a plurality of candidate graph views in the relational graph database; storing (1103) a subset of the plurality of candidate graph views in the relationship graph database; executing ( 1105 ) a graph query in the relational graph database based on the subset of the plurality of candidate graph views in the relational graph database; determining a performance metric for each of the plurality of candidate graph views by comparing one or more queries processed using the corresponding candidate graph view with the same one or more queries processed by a relational query engine (210); The relational graph database is used to convert the one or more graph queries into SQL queries so as to execute the SQL queries in the relational query engine (210). The relational graph database is a database that supports both graph and relational models.

Images