A method and apparatus based on SQL Extended Graph Database Query Language

Abstract

This invention relates to the field of databases, and in particular to a method and apparatus based on an extended SQL graph database query language. It mainly includes: establishing corresponding schema objects using SQL based on the associations and adjacency relationships of all vertices and edges in the graph database, wherein the schema object includes any one of the graph, edge table, and vertex table; splitting the MATCH clause in the query statement into independent traversal steps, splitting the filtering conditions in the WHERE clause into sub-conditions corresponding to each traversal step, and assembling the traversal steps and corresponding sub-conditions into a traversal step array; pushing the traversal step array down to the storage engine of the graph database, completing the query for each schema object in the graph database according to the traversal steps, and returning a filtered and merged query result set chain. This invention can utilize existing standard SQL to process complex relationship queries in graph databases.

Description

Technical Field

[0001] This invention relates to the field of databases, and in particular to a method and apparatus based on the SQL Extended Graph Database Query Language. Background Technology

[0002] Structured Query Language (SQL) is the standardized query language for relational databases, primarily used for retrieving, storing, and modifying data within them. SQL is a high-level, non-procedural programming language that allows users to manipulate data at a high-level data model without needing to concern themselves with how or specifically the data is stored. Based on relational algebra and tuple-based relational calculus, SQL mainly consists of Data Definition Language (DDL), Data Manipulation Language (DML), and Data Query Language (DQL). SQL allows the output of one SQL statement to be used as the input of another, supporting SQL nesting, which gives it flexibility and powerful functionality.

[0003] Graph databases are databases that use graph models as their data model, belonging to the category of non-relational databases. Mainstream graph databases employ attribute graph models, which consist of vertices, edges, and attributes. Compared to traditional relational databases, graph databases store adjacency relationships as part of the data, improving the performance of multi-level relational queries. They are primarily used in data mining and analysis scenarios with massive amounts of data.

[0004] Graph query languages ​​are the query languages ​​used to interact with graph databases. Currently, there is no unified standard for graph query languages; the mainstream ones are Cypher and Gremlin. Cypher is a SQL-like declarative graph query language that allows you to construct queries to handle update, insert, and delete operations without precise descriptions. Gremlin is a path-oriented, functional data flow language that allows you to express complex traversals and queries in a concise way. Gremlin's core traversal steps include transforming objects in the data flow (map), filtering objects in the data flow (filter), and performing statistics on objects in the data flow (sideEffect).

[0005] With the rapid growth of big data businesses such as the internet, social networks, and intelligent recommendations, standard SQL faces challenges in handling relationships within big data. On one hand, standard SQL keywords struggle to express complex relational queries; frequent use of the JOIN keyword leads to complex and verbose SQL statements. On the other hand, traditional relational databases lack optimizations for distributed scenarios in relational processing, resulting in overall low efficiency. Therefore, standard SQL cannot meet the query needs of graph databases.

[0006] On the other hand, current graph database query languages ​​are generally based on specific graph databases, such as Cypher based on Neo4j and Gremlin based on JanusGraph. There is no unified standard for graph query languages, forcing users to learn multiple languages ​​when handling relational relationships, resulting in high learning costs. Furthermore, most major graph query languages ​​on the market are incompatible with standard SQL, cannot be used in conjunction with SQL, and cannot utilize the powerful features already present in SQL.

[0007] Therefore, how to overcome the shortcomings of existing technologies and solve the problem of low compatibility between standard SQL language and graph databases is a problem to be solved in this technical field. Summary of the Invention

[0008] In view of the above-mentioned defects or improvement needs of the existing technology, the present invention solves the problem of low compatibility between standard SQL language and graph database.

[0009] The embodiments of the present invention adopt the following technical solutions:

[0010] Firstly, this invention provides a method based on SQL extended graph database query language, specifically: Based on the associations and adjacency relationships of all vertices and edges in the graph database, corresponding schema objects are established using SQL language, wherein the schema objects include any one of the graph, edge table, and vertex table; the match clause in the query statement is split into independent traversal steps, the filtering conditions in the where clause are split into sub-conditions corresponding to each traversal step, and the traversal steps and corresponding sub-conditions are assembled into a traversal step array; the traversal step array is pushed down to the storage engine of the graph database, the query for each schema object in the graph database is completed according to the traversal steps, and a filtered and merged query result set chain is returned.

[0011] Preferably, the corresponding schema objects are established using SQL, specifically including: when the schema object is a graph, each graph corresponds to a graph database instance, the graph contains a vertex table and an edge table of the graph database, and the association and adjacency relationships of all vertices and edges in the graph database are stored through graph data index; when the schema object is a vertex table, each item in the vertex table corresponds to a vertex in the graph database, and each vertex table stores data of a specified type of vertex in the graph database; when the schema object is an edge table, each item in the edge table corresponds to an edge in the graph database, and each edge table stores data of a set of edges in the graph database with the same starting point type and the same ending point type, and the vertex tables of the starting point and the ending point are specified.

[0012] Preferably, the filtering conditions in the WHERE clause are broken down into sub-conditions corresponding to each traversal step. Specifically, this includes: sorting the conditional expressions in the WHERE clause according to the traversal step order, generating an ordered conditional expression tree according to the logic of the conditional expressions; and decomposing the expression branches in the ordered conditional expression tree into sub-expressions from left to right. Each sub-expression represents a sub-condition. Except for the root node, all other sub-expressions consist of an edge and a node in the conditional expression tree.

[0013] Preferably, the traversal steps and corresponding sub-conditions are assembled into a traversal step array, which specifically includes: traversing the ordered conditional expression tree and assigning each decomposed sub-expression to the corresponding traversal step; assembling the traversal steps according to the logic of the ordered conditional expression tree and the execution order of the traversal steps to generate a traversal step array, wherein the traversal step array includes at least one of the following: projection information, expression information, traversal direction, and reserved variables from the previous step or multiple steps.

[0014] Preferably, the query for each schema object in the graph database is completed according to the traversal steps, which specifically includes: pushing the entire traversal step array down to the distributed storage engine and generating a unique step handle for the traversal step array; starting from the head node of the traversal step array, scheduling the traversal steps in the traversal step data group in sequence through the step handle, and completing the traversal query for each schema object in the graph database according to the sub-conditions corresponding to each traversal step.

[0015] Preferably, the returned result set chain after filtering and merging includes: obtaining the result set found in the current traversal step as the first batch of data, generating a first batch result chain with the same number of data as the first batch; using the first batch result chain as the starting information for the next traversal step to complete the query for the next traversal step, and continuously backtracking to execute each subsequent traversal step in the traversal step array, integrating all the obtained batch data into the complete result chain of the current traversal step; using the next traversal step as the new current traversal step, continuously backtracking to execute each traversal step in the traversal step array, iterating until the last traversal step.

[0016] Preferably, generating a first batch result chain with the same number of data as the first batch includes: returning the result set found in the current traversal step to the pushdown engine; the pushdown engine merging the data stream channels and passing the data stream channels upward to the query engine; wherein the data stream channels include the projection column data of each sub-condition query result in the result set, as well as the Key information corresponding to the query result; the query layer obtaining the result set and generating a first batch result chain with the same number of data as the first batch based on the first batch of data in the result set of the current traversal step.

[0017] Preferably, the first batch of result chains is used as the starting information for the next traversal step to complete the query for the next traversal step. Specifically, this includes: the pushdown engine distributing the execution command for the next traversal step to the storage engine cluster; the pushdown engine obtaining the filtered and unfiltered results of each cluster node in the first batch of result chains; using an asynchronous thread approach to stream the filtered data to the query engine; simultaneously sending the unfiltered data and intermediate information to the storage engine corresponding to the cluster node where the data resides; and continuously pushing the filtered data into the filtered data stream; the query layer obtaining the filtered data from the data stream of the next traversal step and merging the filtered data as a batch of data into the result chain of the current traversal step.

[0018] Preferably, the execution of each subsequent traversal step in the traversal step array is continuously backtracked. Specifically, this includes: when executing each subsequent traversal step, the latest batch of results in the result chain of the previous traversal step is used as the starting information of the subsequent traversal step, and the required parameters are obtained from the latest result chain; the pushdown engine will distribute the execution command of the corresponding traversal step, carrying the required parameters of the traversal step to the distributed cluster node, and the storage node will filter the data according to the known data to complete the query of the traversal step.

[0019] On the other hand, the present invention provides an apparatus based on the SQL extended graph database query language, specifically comprising at least one processor and a memory, wherein the at least one processor and the memory are connected via a data interface, the memory stores instructions that can be executed by the at least one processor, and the instructions, after being executed by the processor, are used to complete the method based on the SQL extended graph database query language in the first aspect.

[0020] Compared with the prior art, the beneficial effects of the embodiments of the present invention are as follows: Vertices and edges in the graph database are converted into pattern objects; the match and where clauses are decomposed into independent traversal steps and sub-conditions; the traversal steps and sub-conditions are reassembled into a traversal step array; and the pattern objects are queried based on the traversal step array. This converts the query process expressed in standard SQL into a graph database query instruction, extends standard SQL, and designs a syntax for graph database queries based on standard SQL. It associates the query plan of the SQL language with the topological structure of the graph database, enabling it to simultaneously possess SQL query capabilities and graph database relation query capabilities. It can utilize existing standard SQL to process complex relation queries in graph databases.

[0021] Furthermore, regarding query efficiency, this invention also provides a method for optimizing graph query steps and pushing them down to the distributed storage engine for computation. Attached Figure Description

[0022] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments of the present invention will be briefly described below. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.

[0023] Figure 1 A flowchart of a method based on SQL Extended Graph Database Query Language provided in an embodiment of the present invention;

[0024] Figure 2 This is a schematic diagram of the MSPD operation steps of the pushdown engine in this embodiment;

[0025] Figure 3 A flowchart illustrating another method based on the SQL Extended Graph Database Query Language provided in this embodiment of the invention;

[0026] Figure 4 This is a schematic diagram of a storage cluster and graph data model in a specific scenario of this embodiment;

[0027] Figure 5This is a schematic diagram of the disjunction normal form structure of graph data labels and relations in the WHERE clause in a specific scenario of this embodiment;

[0028] Figure 6 This is a schematic diagram of the MatchStep structure in the Match clause of a specific scenario in this embodiment;

[0029] Figure 7 This is a schematic diagram of the syntax tree for the WHERE condition expression in a specific scenario of this embodiment;

[0030] Figure 8 This is a schematic diagram of the decomposition of the left subtree in the WHERE clause in a specific scenario of this embodiment;

[0031] Figure 9 This is a schematic diagram of the right subtree decomposition in the WHERE clause in a specific scenario of this embodiment;

[0032] Figure 10 This is a schematic diagram of the ordered condition groups corresponding to the split subtrees in a specific scenario of this embodiment;

[0033] Figure 11 This is a schematic diagram illustrating the sorting process of the WHERE expression in the orderedExprTrees function within a specific scenario of the Match model in this embodiment.

[0034] Figure 12 This is a schematic diagram illustrating the sorting process of the WHERE expression in the orderedExprTrees function within a specific scenario of the Match model in this embodiment.

[0035] Figure 13 This is a schematic diagram illustrating the sorting process of the WHERE expression in the orderedExprTrees function within a specific scenario of the Match model in this embodiment.

[0036] Figure 14 This is a schematic diagram illustrating the allocation process of the sorting syntax tree in the OrderDistributeLaw function in a specific scenario of this embodiment;

[0037] Figure 15 This is a schematic diagram illustrating the allocation process of the sorting syntax tree in the OrderDistributeLaw function in a specific scenario of this embodiment;

[0038] Figure 16 This is a schematic diagram illustrating the allocation process of the sorting syntax tree in the OrderDistributeLaw function in a specific scenario of this embodiment;

[0039] Figure 17This is a schematic diagram illustrating the allocation process of the sorting syntax tree in the OrderDistributeLaw function in a specific scenario of this embodiment;

[0040] Figure 18 This is a schematic diagram illustrating the filtered and unfiltered data formats in a specific scenario of this embodiment;

[0041] Figure 19 This is a schematic diagram illustrating the filtered and unfiltered data formats in a specific scenario of this embodiment;

[0042] Figure 20 A schematic diagram of a device structure based on the SQL extended graph database query language provided in an embodiment of the present invention;

[0043] The accompanying figure is labeled as follows:

[0044] 11: Processor; 12: Memory. Detailed Implementation

[0045] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0046] This invention is an architecture of a specific functional system. Therefore, the specific embodiments mainly describe the functional logic relationship of each structural module, and do not limit the specific software and hardware implementation methods.

[0047] Furthermore, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0048] Example 1:

[0049] This embodiment provides a method based on an extended SQL graph database query language, which integrates attribute graph models and relational models to extend SQL, providing an extended SQL query language that supports both relational and attribute graph models. The extended language remains compatible with existing SQL syntax and supports use with keywords such as `where` and `order by`. During graph traversal queries, a unified filtering clause is used. The query conditions provided by the `where` clause are decomposed according to the traversal steps. Filtering conditions are prioritized according to the order of the traversal steps, and parse normal form is sorted by sub-conditions to avoid complete disjunctive normal form decomposition. The graph traversal query steps, including the filtering predicate normal forms decomposed into steps, are pushed down to the distributed storage engine for execution using a pushdown engine. The query results are then returned to the graph database query engine, and the complete traversal query results are obtained after backtracking and merging.

[0050] like Figure 1 As shown, the specific steps of the method based on the SQL extended graph database query language provided in this embodiment of the invention are as follows:

[0051] Step 101: Based on the associations and adjacency relationships of all vertices and edges in the graph database, use SQL to create the corresponding schema objects. The schema objects include any one of the following: graph, edge table, and vertex table.

[0052] To integrate the relational model of relational databases and the attribute graph model of graph databases, the relationships between vertices and edges in the graph database need to be introduced into the SQL language. This embodiment records these relationships using a graph, edge table, and vertex table, converting the graph structure into a table structure for easy querying via SQL. The graph corresponds to a graph database, with its topology recorded through graph attributes. The edge table corresponds to edges of the same type in the graph database; each data item in the edge table corresponds to an edge in the graph database. In addition to the edge table, a vertex-edge adjacency table is implicitly recorded, generating adjacency tuples between vertices and vertex-edges based on information such as the start and end points of the edges and the edge ID. The vertex table corresponds to vertices of the same type in the graph database; each data item in the vertex table corresponds to a vertex in the graph database. In specific implementations, the `as` keyword can be used to map the graph, edges, vertices, and schema objects.

[0053] When performing queries, the standard SQL `SELECT` statement can be used directly as the query (`MATCH`) statement, employing the same syntax structure as standard SQL, specifying filtering conditions using keywords such as `MATCH`, `FROM`, and `WHERE`. To improve query efficiency, this embodiment does not use complete predicates for matching, but instead decomposes the `MATCH` clause into independent traversal steps. After the pattern object mapping is complete, the `MATCH` clause specifies the topological pattern of the traversal steps and indicates the vertex-edge association and vertex-adjacency constraints used during graph traversal. In addition to specifying the topological pattern, attributes can also be used as filtering conditions to filter the results of each traversal step during the traversal process. Attribute filtering conditions can be written in the attributes of each traversal step or uniformly in the `WHERE` clause. This embodiment preferably uses a uniformly written `WHERE` clause, which can comprehensively consider attribute filtering conditions and simplify the expression of the traversal pattern.

[0054] Step 102: Split the match clause in the query statement into independent traversal steps, split the filtering conditions in the WHERE clause into sub-conditions corresponding to each traversal step, and assemble the traversal steps and corresponding sub-conditions into a traversal step array.

[0055] In practical applications, graph databases are typically managed using distributed storage engines. Most existing distributed storage engines employ a separation of computation and storage, where each storage engine node only retrieves the current data, while data filtering is performed by the query engine node. Therefore, during the traversal and query process, much data that does not meet the filtering criteria also participates in network transmission.

[0056] To reduce network data transmission, this embodiment splits the match clause in the query statement into independent traversal steps, and the filtering conditions in the where clause into sub-conditions corresponding to each traversal step. The filtering conditions corresponding to each traversal step, as well as the projection information of the traversal step, are integrated into the traversal step. The filtering conditions, projection information, and traversal step instructions are pushed down to the corresponding graph database storage engine node. The related data is retrieved and filtered locally, and only the filtered results are returned to the query engine node. This eliminates the transmission of unnecessary intermediate data and unnecessary projection data, reduces the time complexity of condition filtering and network bandwidth consumption, and thus significantly reduces network transmission, achieving optimization of predicate pushdown.

[0057] For a uniformly written WHERE clause, to ensure that the attribute filtering conditions of each traversal step correspond to the traversal step, the query conditions need to be decomposed according to the traversal step. The attribute filtering conditions are then decomposed according to the traversal step, and the resulting set of sub-conditions is integrated into the corresponding traversal step after decomposition, so that each storage engine node can perform data filtering. In practice, the sub-conditions in the filtering conditions can be sorted according to the order of the traversal steps, and then the predicate normal form of each sub-condition can be decomposed to avoid potential mismatches with the traversal steps when directly decomposing the complete disjunctive normal form. For a complete WHERE clause, the complete normal form is generated by combining logical operators such as AND, OR, and NOT. The WHERE clause can be decomposed into a standard disjunctive normal form, and the sub-expressions corresponding to each logical operator in the disjunctive normal form can ultimately be decomposed into each traversal step. Furthermore, if the standard disjunctive normal form is directly and completely decomposed, its time complexity is O(2^3). n In this embodiment, the OR subcondition does not need to be completely decomposed. It is only necessary to allocate it to the corresponding traversal step according to the distributive law, which can reduce the time complexity of the expression decomposition process to O(n).

[0058] Step 103: Push the traversal step array down to the graph database's storage engine, complete the query for each schema object in the graph database according to the traversal steps, and return the filtered and merged query result set chain.

[0059] In query statements using the `SELECT` keyword, the `MATCH`, `FROM`, and `WHERE` clauses all contain filtering conditions, but they serve different purposes. The `MATCH` clause is an operator representing the tables to be queried. A single `MATCH` pattern can exist within a `SELECT` statement; these patterns cannot be stacked. In this embodiment, the `MATCH` pattern specifies the query range and order for each vertex in the graph database to complete the traversal operation. The `FROM` clause represents a Cartesian set, indicating the set of tables to be queried. In the method provided in this embodiment, the tables in the `MATCH` clause and the tables in the `FROM` clause have different meanings. The `MATCH` clause does not need to participate in the table set in the `FROM` clause, so the tables in the `MATCH` clause and the tables in the `FROM` clause need to be specified separately. The `MATCH` result is a result set. After joining the `MATCH` result set and the `FROM` result set to obtain all the tables to be queried, further querying (selection) operations are performed on each table based on the filtering conditions of the `WHERE` clause. In step 102, the conditions in the WHERE clause are decomposed into the traversal process and aggregated into each corresponding traversal step. This allows for filtering and selection of the traversal results while each traversal step is executed.

[0060] By decomposing and reassembling traversal steps and filtering conditions, the query process expressed in standard SQL can be converted into graph database query instructions. The graph database traversal steps and the sub-conditions decomposed into each traversal step are then pushed down to the graph database storage engine for execution. In practice, the traversal step array can include: sub-conditions decomposed into the traversal steps, predicate normal forms, step projections, and reserved parameters required for actual use. In practice, the existing storage engine mechanism can be used to complete the query for each schema object, or the pushdown optimization method provided later can be used.

[0061] After steps 101-103 provided in this embodiment, the SQL query statement can be associated with the topology of the graph database. The query process is optimized by decomposing the traversal steps and splitting the filtering conditions, so that the data in the graph database can be queried using the SQL language.

[0062] In step 101, there are three types of schema objects established based on the SQL language extension: graph, vertex table, and edge table.

[0063] (1) When the pattern object is a graph, each graph corresponds to a graph database instance. The graph contains the vertex table and edge table of the graph database, and stores the association and adjacency relationship of all vertices and edges in the graph database through the graph data index.

[0064] A graph represents a graph object, which is an extension of a database object. A graph database can create vertex and edge tables, and create a graph data index in the database to store the associations and adjacency relationships between all vertices and edges in the graph database.

[0065] (2) When the pattern object is a vertex table, each item in the vertex table corresponds to a vertex in the graph database, and each vertex table stores data of a specified type of vertex in the graph database.

[0066] A vertex represents a vertex table, which is an extension of a regular table in a relational database, storing data on vertices of a specific type. In a vertex table, the primary key of each vertex table itself can be used as the ID of that type of vertex, or a default auto-incrementing integer column can be used as the vertex ID.

[0067] (3) When the pattern object is an edge table, each item in the edge table corresponds to an edge in the graph database. Each edge table stores data of a set of edges in the graph database with the same starting point type and the same ending point type, and specifies the vertex table of the starting point and the vertex table of the ending point.

[0068] The edge table, or edge table, is an extension of a regular table in a relational database, storing data on edges of a specific type. Edges of the same type have the same start and end points. The edge table uses a default auto-incrementing integer column as the edge ID and requires specifying the vertex tables for the start and end points of the edges.

[0069] Through the above extensions, the topological relationships between vertices and edges in a graph database can be stored using the ordinary table structure of a relational database. This allows users to write query statements using SQL syntax, achieving the effect of querying the graph database using SQL.

[0070] In steps 102 and 103, to improve query efficiency in the distributed storage engine, the SQL Extended Graph Database Query Language in this invention incorporates Match Step Pushdown (MSPD). Unlike traditional predicate pushdown, the method provided in this embodiment decomposes the complete query plan provided by the `match` clause in the SQL query statement into independent traversal steps, and manages these traversal steps as an array. During a query, the entire Match Step array is pushed down to the distributed cluster storing the graph database, and is responsible for distributing, filtering, secondary distribution, merging, and matching Match Step result sets, continuously driving the data flow using a multi-threaded asynchronous approach. Compared to traditional predicate pushdown, MSPD reduces unnecessary intermediate data and unnecessary projection data during graph data traversal, lowers network transmission costs, and improves query efficiency.

[0071] To decompose the corresponding sub-conditions for each traversal step in step 102, the WHERE clause in the query statement can be parsed into an Abstract Syntax Tree (AST) at the lexical-syntactic analysis layer. The hierarchical structure of the AST corresponds to the disjunctive normal form of the query statement. Specifically, the conditional expressions in the WHERE clause are sorted according to the order of the traversal steps, and an ordered conditional expression tree is generated according to the logic of the conditional expressions. The expression branches in the ordered conditional expression tree are decomposed into sub-expressions from left to right. Each sub-expression represents a sub-condition. Except for the root node, each sub-expression consists of an edge and a node in the conditional expression tree. The specific process can be combined with the following... Figures 7-10 And related textual descriptions.

[0072] After decomposition, the logical plan layer creates a query plan using the AST information. The `match` clause of the query statement is created as a `match` pushdown plan. Creating the query `match` pushdown plan involves decomposing the AST traversal plan and optimizing the conditional expressions. Specifically, the ordered conditional expression tree is traversed, and each decomposed sub-expression is assigned to a corresponding traversal step. The traversal steps are then assembled according to the logic of the ordered conditional expression tree and the execution order of the traversal steps, generating a traversal step array. This array includes projection information, expression information, traversal direction, and at least one of the following: reserved variables from the previous step or multiple steps.

[0073] After decomposition and assembly, the sub-conditions corresponding to each traversal step can be integrated into the corresponding traversal step, and a Match Step array of all traversal steps can be obtained. When traversing according to the Match Step array, after the executor finishes executing each traversal step, the current query results can be filtered according to the corresponding sub-conditions, and only the filtered data is returned, thereby pruning intermediate results, reducing the candidate result set, and thus improving the efficiency of traversal queries.

[0074] The query execution engine and the MSPD pushdown engine coordinate and schedule each other. After the query engine generates the Match Step array, the pushdown engine pushes the entire Match Step array down to the storage engine. The execution layer is responsible for scheduling the step handles generated by the MSPD pushdown engine, executing single-step Match Steps, backtracking multi-step result sets, integrating and pushing the complete result set chain. The pushdown engine is responsible for data distribution, filtering intermediate data, and merging the final data, including the projected result set, during the execution of each single-step Match Step. The MSPD execution steps are as follows: Figure 2 As shown. Specifically: The entire traversal step array is pushed down to the distributed storage engine, a unique step handle is generated for the traversal step array, the execution layer schedules the push-down engine, generates a globally unique Match Step ID, and returns a globally unique Match Step handle. This handle is then used to schedule and execute single steps. Starting from the head node of the traversal step array, the traversal steps in the traversal step data group are scheduled sequentially through the step handles, completing the traversal query of each node in the graph database according to the sub-conditions corresponding to each traversal step.

[0075] After completing one step, it is still necessary to proceed as follows: Figure 3 Follow the steps shown to complete the query for the next step.

[0076] Step 201: Obtain the result set found in the current traversal step as the first batch of data, and generate a first batch result chain with the same number of data as this batch.

[0077] The execution layer schedules the pushdown engine based on the Match Step array in the current execution plan, executes the current pushdown step, obtains a batch of results from the current Match Step execution, and generates or merges the batch of data into a result chain.

[0078] Step 202: Use the first batch result chain as the starting information for the next traversal step to complete the query for the next traversal step, and continue to backtrack and execute each subsequent traversal step in the traversal step array, integrating all the batch data obtained into the complete result chain of the current traversal step.

[0079] The execution engine uses a batch of data from the first batch of result chains in step 201 as the starting information for the next Match Step, and continues to backtrack to execute the next Match Step. When the last batch of data is executed, the execution engine integrates the last batch of data into the complete Result result chain.

[0080] Step 203: Take the next traversal step as the new current traversal step, and continue to backtrack and execute each traversal step in the traversal step array until the last traversal step is reached.

[0081] In step 202, if the current Match Step is the last traversal step, the complete Result chain of the current batch is pushed to the result set data stream in a multi-threaded asynchronous manner.

[0082] After steps 201-203, the query of all traversal steps in the traversal step array can be completed by backtracking, and the complete query result set can be obtained.

[0083] In actual implementation, the process of generating the first batch result chain with the same quantity as the first batch of data in step 201 can be completed by merging data flow channels. The result set is returned to the pushdown engine, which merges the data flow channels and passes them up to the query engine. The data flow channels include the projection column data of each sub-condition query result in the result set, as well as the Key information corresponding to the query result. Specifically, the storage engine will search for data according to the conditions in MatchStep[0] and return it to the pushdown engine. The pushdown engine will merge the data flow channels, which include the current Match Step. The query layer obtains the result set and generates the first batch result chain with the same quantity as the first batch of data based on the first batch of data in the current traversal step result set. Specifically, the query layer will obtain the result set of MatchStep[0] and generate an incomplete Result result chain with the same quantity as the first batch of data based on the first batch of data in the current result set.

[0084] After obtaining the first batch of result chains, the first batch of result chains also need to be used as the starting information for the next traversal step to complete the query for the next traversal step. The pushdown engine distributes the execution command for the next traversal step to the storage engine cluster. The pushdown engine obtains the filtered and unfiltered results of each cluster node in the first batch of result chains. It uses an asynchronous thread to transmit the filtered data to the query engine in a streaming manner. At the same time, it sends the unfiltered data and intermediate information to the storage engine corresponding to the cluster node where the data is located, and continuously pushes the filtered data to the filtered data stream. Specifically, based on the first batch of Result result chains in the previous step, MatchStep[1] continues to be executed iteratively. Since there are no unknown variables in MatchStep[1] in the previous step, it is not necessary to reference the known results of the MatchStep[0] result set. The pushdown engine directly distributes the execution command of MatchStep[1] to the storage engine cluster. The query layer retrieves the filtered data from the data stream of the next traversal step and merges the filtered data as a batch of data into the result chain of the current traversal step. The pushdown engine obtains the filtered and unfiltered results of each cluster node. At this time, the pushdown engine uses an asynchronous thread to stream the filtered data to the query engine, while sending the unfiltered data and intermediate information to the cluster node where the data is located, and continuously pushes the filtered data into the filtered data stream.

[0085] Similarly, it is necessary to continuously backtrack and execute each subsequent traversal step in the traversal step array to complete the final traversal query. When executing each subsequent traversal step, the latest batch of results in the result chain of the previous traversal step is used as the starting information of the subsequent traversal step, and the required parameters are obtained from the latest result chain. Specifically, the query layer obtains the Step1 filtered data from the MatchSteps[1] data stream, merges the results into the Result result chain generated by the previous traversal step, and continues to execute MatchStep[2] according to a batch of results in the latest result chain, carrying the required parameters, which are obtained from the current Result result chain. The pushdown engine will distribute the execution command of the corresponding traversal step, and carry the required parameters of the traversal step to the distributed cluster node. The storage node performs data filtering based on the known data to complete the query of the traversal step. Specifically, the pushdown engine will distribute the MatchStep[2] execution command, and carry the required parameters of Match to the distributed cluster node, and its storage node performs data filtering based on the known data. The process involves backtracking through each step until the last item in the array of steps. The final result is the collection of filtered data obtained.

[0086] The method based on the SQL Extended Graph Database Query Language provided in this embodiment is based on the standard SQL Extended Graph Database Query Language. It optimizes the Match Step plan calculation for distributed graph database storage scenarios and pushes the optimized Match Step down to the storage cluster. It supports both standard SQL relational databases, possessing the powerful computational capabilities of SQL, and complex relationship processing of graph data. This allows users familiar with SQL syntax to quickly learn and master the graph database query language pattern, reducing the overall learning cost and improving the efficiency of graph database queries.

[0087] Example 2:

[0088] Based on the method of SQL-based extended graph database query language provided in Embodiment 1, this embodiment provides some examples of SQL language extended syntax. The following examples all conform to the syntax of existing standard SQL language and can be directly used on various platforms that use existing SQL language. In actual implementation, the following examples can be used to complete the writing of relevant query statements, or other extensions can be made according to the method of Embodiment 1 and actual usage needs.

[0089] This embodiment provides two types of SQL-based extended syntax: DDL and DML. The following provides specific examples of creating and managing schema objects in step 101, and specific examples of querying and specifying filter conditions in step 102.

[0090] 1) Create a graph:

[0091] grammar:

[0092] CreateDatabaseStmt::=

[0093] 'CREATE" DATABASE'IfNotExists DBName DatabaseOptionListOpt'AS'GRAPH'

[0094] Example: Use a graph database named GraphDemo as a graph.

[0095] CREATE DATABASE GraphDemo AS GRAPH

[0096] 2) Delete a graph:

[0097] grammar:

[0098] DropDatabaseStmt::=

[0099] 'DROP"DATABASE'IfExists DBName

[0100] Example: Delete the graph named GraphDemo.

[0101] DROP DATABASE GraphDemo

[0102] 3) Create a vertex table:

[0103] grammar:

[0104] CreateVertexTableStmt::=

[0105] 'CREATE'OptTemporary'TABLE'IfNotExists TableName(TableElementListOptCreateTableOptionListOpt PartitionOpt DuplicateOpt AsOpt CreateTableSelectOpt|LikeTableWithOrWithoutParen)'AS''VERTEX'['USE''PRIMARY KEY']

[0106] Example: Create a vertex table containing 100 vertices, where each vertex contains a Person table with ID as the primary key.

[0107] CREATE TABLE Vertex1(

[0108] p1 VARCHAR(100)

[0109] AS VERTEX

[0110] CREATE TABLE Person(

[0111] ID INTEGER PRIMARY KEY,

[0112] name VARCHAR(100)

[0113] AS VERTEX USE PRIMARY KEY

[0114] Note: When creating a vertex table, if the "use primary key" option is not used, the default auto-incrementing integer column is used as the vertex ID, and a "$vid" column is added to the actual vertex table for storage. If the "use primary key" option is used, the primary key or composite primary key of each vertex in the table is used as the vertex ID, and the "$vid" column is not added.

[0115] 4) Delete the vertex table:

[0116] grammar:

[0117] DropTableStmt::=

[0118] 'DROP'OptTemporary TableOrTables IfExists TableNameListRestrictOrCascadeOpt

[0119] Example: Delete the Person table

[0120] DROP TABLE Person

[0121] Note: You can use RestrictOrCascadeOpt to specify whether cascading deletion of reference tables is required.

[0122] 5) Create the edge table:

[0123] grammar:

[0124] CreateEdgeTableStmt::=

[0125] 'CREATE'OptTemporary'TABLE'IfNotExists TableName(TableElementListOptCreateTableOptionListOpt PartitionOpt DuplicateOpt AsOpt CreateTableSelectOpt|LikeTableWithOrWithoutParen)'AS''EDGE'['USE''PRIMARY KEY']'START'TableName'END'TableName

[0126] Example: Create a friendOf edge table where the vertex table for both the start and end points is Person.

[0127] CREATE TABLE friendOf(

[0128] atDate date

[0129] )AS EDGE START Person END Person

[0130] Explanation: In the edge table, a $eid column is added first, using the default auto-incrementing integer column as the edge ID. 'START'TableName specifies the vertex table name of the starting point; 'END'TableName specifies the vertex table name of the ending point. If the vertex table uses the 'use primary key' option, the edge table uses the value of the primary key column of the vertex table as the edge-to-vertex reference, adding columns such as $start$c1, $start$c2, or $end$c1, $end$c2, where c1 and c2 are the primary key column names of the vertex table; otherwise, the edge table uses the value of the $vid column of the vertex table as the edge-to-vertex reference, adding columns such as $start$vid or $end$vid.

[0131] 6) Delete the edge table:

[0132] grammar:

[0133] DropTableStmt::=

[0134] 'DROP'OptTemporary TableOrTables IfExists TableNameListRestrictOrCascadeOpt

[0135] Example: Deleting the friendOf table

[0136] DROP TABLE friendOf

[0137] 7) Add vertex data to the vertex table:

[0138] grammar:

[0139] InsertIntoStmt::=

[0140] 'INSERT'TableOptimizeHints PriorityOpt IgnoreOptional IntoOptTableName PartitionNameListOpt InsertValues ​​OnDuplicateKeyUpdate

[0141] Example: Add two vertex data (1, 'John') and (2, 'Mary') to the Person table.

[0142] INSERT INTO Person(Id,name)VALUES(1,'John'),(2,'Mary')

[0143] Note: The statement for adding vertices is syntactically identical to the standard insert statement used to add data.

[0144] 8) Delete vertex data:

[0145] grammar:

[0146] DeleteFromStmt::=

[0147] 'DELETE'TableOptimizerHints PriorityOpt QuickOptional IgnoreOptional('FROM'(TableName TableAsNameOpt IndexHintListOpt WhereClauseOptionalOrderByOptional LimitClause|TableAliasRefList'USING'TableRefsWhereClauseOptional)|TableAliasRefList'FROM'TableRefs WhereClauseOptional)

[0148] Example: Delete the vertex with id 1.

[0149] DELETE FROM Person WHERE ID=1

[0150] 9) Add edge data:

[0151] grammar:

[0152] InsertIntoStmt:=

[0153] 'INSERT'TableOptimizerHints PriorityOpt IgnoreOptional IntoOptTableName PartitionNameListOpt InsertValeus OnDuplicateKeyUpdate

[0154] Example: Add an edge between the vertex with id 1 and the vertex with id 2, and set the attribute value to '1990-10-8'.

[0155] INSERT INTO friendOf($start$Id,$end$id,atDate)

[0156] VALUES(1,2,'1990-10-8')

[0157] Note: The statement for adding edges is syntactically identical to the standard insert statement used to add data.

[0158] 10) Delete edge data:

[0159] grammar:

[0160] DeleteFromStmt::=

[0161] 'DELETE'TableOptimizerHints PriorityOpt QuickOptional IgnoreOptional('FROM'(TableName TableAsNameOpt IndexHintListOpt WhereClauseOptionalOrderByOptional LimitClause|TableAliasRefList'USING'TableRefsWhereClauseOptional)|TableAliasRefList'FROM'TableRefs WhereClauseOptional)

[0162] Example: Delete the edge with id 1 at the starting point.

[0163] DELETE FROM friendOf WHERE$START$VID=1

[0164] 11) Graph data query (match):

[0165] grammar:

[0166] SelectStmtFromTable::=

[0167] SelectStmtBasic FromClause MatchClauseOptionsal WhereClauseOptionalSelectStmtGroup HavingClause WindowClauseOptional

[0168] FromClause:=

[0169] “FROM”TableRefsClause

[0170] MatchClauseOptional:=

[0171] nil|

[0172] MATCH (Match Pattern)

[0173] MatchPattern:=

[0174] VertexTableName{AjacentPattern[AjacentPattern…,n]}

[0175] AjacentPattern:=EdgePattern VertexTableName

[0176] EdgePattern:=

[0177] '-('EdgeTableName')->'

[0178] |'<-('EdgeTableName')-'

[0179] |'-('EdgeTableName')-'

[0180] Example: Query data that matches the filtering conditions in the WHERE clause, based on the query steps specified in the MATCH clause.

[0181]

[0182] The following is a query example in a real-world scenario to illustrate the use of the above syntax extensions in graph database queries.

[0183] The storage cluster and graph data model for this scenario are as follows: Figure 4 As shown, we need to query a graph data path that meets the conditions "PersonKnows Person" and "Person Created Software", and output the name fields of labels p1 and p2, the weight field of the relation Created, and the name field of the label Software on that path. The graph data involved in the query statement carries the labels Person and Software, the Knows relation, and the Created relation. The disjunction normal form structure of the graph data labels and relations in the WHERE clause is as follows: Figure 5 As shown.

[0184] The specific query statement used is as follows:

[0185] select p2.name,p1.name,c.weight,s.name match(software s,created c,person p1,knows k,person p2|s<-(c)-p1-(k)->p2)where s.name='java'ANDc.weight<0.5AND p2.age>25AND p1.age=p2.age

[0186] The traversal process in the Match clause can be broken down into the following three steps, and its MatchStep structure is as follows: Figure 6 As shown.

[0187] step 0: s; VertexFilter: s.name = 'java'

[0188] step 1:<-(c)-p1; EdgeFilter:c.weight<0.5

[0189] step 2:-(k)->p2; VertexFilter:p1.age>25and p2.age>p1.age

[0190] To facilitate the explanation of the three steps involved in the planning layer, the specific data in the above query statement is abstracted into a data model (hereinafter referred to as the Match model). The Match model represents the process of traversing and querying graph data. The traversal process in the match clause used for pattern matching is abstracted as "(v1)-[e2]->(v2)-[e3]->(v3)-[e4]->(v4)-[e5]->(v5)-[e6]->(v6)". The where clause used for conditional filtering is abstracted as "(v1.count>1OR v2.count>2)AND(((v3.count>3)AND(v6.count>6))OR(NOT((v4.count>4)OR(v5.count>5))))". Figure 7 It is a syntax tree for WHERE conditional expressions; Figure 8 It is the decomposition of the left subtree in the WHERE clause; Figure 9 This refers to the right subtree decomposition in the WHERE clause. In the diagram, T1-T9 represent the subtrees split off during the decomposition process. Figure 10 The ordered condition sets for subtrees T10-T12 are T2-T4, respectively. The ordered condition sets for the remaining subtrees can be referenced from [the previous examples]. Figure 10The model is organized in the form of corresponding elements. In this model, v1, v2, v3, v4, v5, and v6 all represent vertices, and "count" is an integer attribute of a vertex. The "count" attribute is used as an example to illustrate how conditional expressions are used as filtering conditions.

[0191] According to step 102, the planning layer decomposes the traversal process in the AST and generates a MatchStep array for pushdown.

[0192] The decomposition rule is as follows: the MatchStep in the AST is divided sequentially from left to right. Except for the first MatchStep, which has no edges and only vertices, each MatchStep consists of one edge and one vertex. For example, the match clause in the Match model will be decomposed into 6 sequentially executed steps in this step: step1: v1, step2: -[e2]->(v2), step3: -[e3]->(v3), step4: -[e4]->(v4), step5: -[e5]->(v5), step6: -[e6]->(v6).

[0193] Corresponding to the actual traversal steps, the three decomposed steps are as follows:

[0194] step0: s;

[0195] step1: <-(c)-p1;

[0196] step2: -(k)->p2.

[0197] After breaking down the steps, the filtering conditions in the WHERE clause still need to be sorted, optimized, and allocated. Specifically, the following algorithm can be used to perform the sorting and allocation:

[0198] Input: Conditional table expression syntax tree exprTree

[0199] Output: sorted subcondition groups orderedExprTrees

[0200]

[0201] The function OrderDestributeLaw applies the distributive law to two sorting subconditions connected by OR, in the order of MatchStep, to generate a new sorting subcondition. The function OrderDestributeLaw is described as follows:

[0202] Input: Two sorting sub-conditions left and right

[0203] Output: The sorting subconditions after applying the distributive law in step order.

[0204]

[0205]

[0206] Among them, order1 and order2 recursively call the OrderDistributeLaw function.

[0207] In the scenario of this embodiment, Figure 11 , Figure 12 and Figure 13 This describes the sorting process of the WHERE expression in the orderedExprTrees function within the Match model. Figure 14 , Figure 15 , Figure 16 and Figure 17 This describes the allocation process of the sorted syntax tree in the OrderDistributeLaw function.

[0208] After the above decomposition and allocation, the traversal steps will be updated as follows:

[0209] step0:s;VertexFilter:s.name='java';

[0210] step1:<-(c)-p1;EdgeFilter:c.weight<0.5,

[0211] step2:-(k)->p2; VertexFilter: p2.age>25and p2.age>p1.age.

[0212] As can be seen from the above SQL statements and execution process examples, by using the method based on the SQL extended graph database query language provided in Example 1, the standard SQL language can be associated with the topological structure of the graph database, thereby achieving the purpose of querying the graph database using the standard SQL language.

[0213] Example 3:

[0214] Based on the methods of SQL Extended Graph Database Query Language provided in Embodiments 1 and 2, this embodiment provides a specific example of using SQL statements to complete graph database queries in a real-world scenario with a distributed storage engine, including optimizations to the pushdown query process in step 103. In specific implementations, corresponding settings or adjustments can be made according to the actual scenario requirements as described below.

[0215] In this scenario, the storage cluster and graph data model are as follows: Figure 4 As shown, the specific query statement used is the same as in Example 2, as follows:

[0216] select p2.name,p1.name,c.weight,s.name match(software s,created c,person p1,knows k,person p2|s<-(c)-p1-(k)->p2)where s.name='java'ANDc.weight<0.5AND p2.age>25AND p1.age=p2.age

[0217] This query aims to find a graph data path that meets the conditions "Person Knows Person" and "Person CreatedSoftware" and also meets the filtering conditions in the WHERE clause. It then outputs the name fields of labels p1 and p2, the weight field of the relation Created, and the name field of the label Software on that path.

[0218] Step 301: The pushdown engine receives the Match Step array (hereinafter referred to as MatchSteps) generated in step 102. The array is defined as MatchStep[], and the Match Steps is converted into a pushdown binary stream object.

[0219] Step 302: The pushdown engine uses multi-threading to push down the Math Steps binary stream object to the storage engine and generates a unique operation handle corresponding to the Match Step. The handle is then used to operate on each Match Step in the array.

[0220] Step 303: The query engine executes MatchStep[0], and its pushdown engine distributes the execution operations in MatchStep[0] to each distributed storage engine.

[0221] Step 304: The storage engine will perform data lookup based on the conditions in MatchStep[0] and return the lookup results to the pushdown engine. The pushdown engine will merge the data stream channels of the lookup results, and the data stream channels include MatchStep.

[0222] Step 305: The query layer will obtain the result set of MatchStep[0] and generate an incomplete Result chain with the same number of data as the first batch of the result set based on the first batch of data in the current result set.

[0223] Step 306: Based on the first batch of Result chain from the previous step, continue to iterate and execute MatchStep[1]. Since there are no unknown variables in MatchStep[1] from the previous step, there is no need to reference the known results of the MatchStep[0] result set. The pushdown engine directly distributes the MatchStep[1] execution command to the storage engine cluster.

[0224] Step 307: The pushdown engine obtains the filtered and unfiltered results for each cluster node. At this point, the pushdown engine uses an asynchronous thread approach to stream the filtered data to the query engine, while simultaneously sending the unfiltered data and intermediate information to the cluster node where the data resides. It also continuously pushes filtered data into the filtered data stream. The format of the filtered and unfiltered data is as follows: Figure 18 As shown.

[0225] Step 308: The query layer obtains the Step 1 filtered data from the MatchSteps[1] data stream and merges the results into the Result chain generated in Step 305. It then continues to execute Match Step[2] based on a batch of results in the latest result chain, carrying the required parameter KeyParams, which includes p1.Key and p1.age. The required parameters are obtained from the current Result chain.

[0226] Step 309: The pushdown engine will distribute the MatchStep[2] execution command, carrying the parameters required for Match to the distributed cluster nodes. Its storage nodes will filter the data based on the known data, similar to step 307. The filtered and unfiltered data in this step are as follows: Figure 19 As shown.

[0227] Through steps 301-309, MSPD pushes down the Match Steps decomposed from the planning layer as a whole. Instead of pushing down one or a few predicate segments individually, it pushes down multiple pieces of information involved in traversal operations, such as projection, conditions, direction, and reserved fields, to the storage cluster. This works closely with the execution layer to achieve efficient querying of large amounts of data, reduce unnecessary intermediate results and network transmission of data that does not meet the conditions, and achieve efficient querying of graph databases.

[0228] Example 4:

[0229] Based on the methods based on the SQL extended graph database query language provided in Embodiments 1 to 3 above, the present invention also provides an apparatus based on the SQL extended graph database query language that can be used to implement the above methods, such as... Figure 20The diagram shown is a schematic representation of the device architecture according to an embodiment of the present invention. The device based on the SQL Extended Graph Database Query Language in this embodiment includes one or more processors 11 and a memory 12. Figure 20 Take a processor 11 as an example.

[0230] Processor 11 and memory 12 can be connected via a data interface, which can be a data bus or other means. Figure 20 Taking the example of a connection between China and Israel via a bus.

[0231] The memory 12, as a non-volatile computer-readable storage medium based on the SQL Extended Graph Database Query Language method, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the SQL Extended Graph Database Query Language method in Embodiments 1 to 3. The processor 11 executes various functional applications and data processing of the device based on the SQL Extended Graph Database Query Language by running the non-volatile software programs, instructions, and modules stored in the memory 12, thereby implementing the SQL Extended Graph Database Query Language method of Embodiments 1 to 3.

[0232] Memory 12 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, memory 12 may optionally include memory remotely located relative to processor 11, which can be connected to processor 11 via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0233] The program instructions / modules are stored in memory 12. When executed by one or more processors 11, they perform the methods based on the SQL extended graph database query language described in Embodiments 1 to 3 above, for example, performing the methods described above. Figure 1 , Figure 2 and Figure 3 The steps shown.

[0234] Those skilled in the art will understand that all or part of the steps in the various methods of the embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0235] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for extending a graph database query language based on SQL, characterized in that, Specifically comprising: According to the association and adjacency relationship of all vertices and edges in the graph database, a corresponding schema object is established using the SQL language, wherein the schema object comprises a graph, an edge table and a vertex table; The match clause in the query statement is split into independent traversal steps, the filter conditions in the where clause are split into corresponding sub-conditions for each traversal step, and the traversal steps and corresponding sub-conditions are assembled into a traversal step array; The traversal step array is pushed down to the storage engine of the graph database, the query of each schema object in the graph database is completed according to the traversal steps, and a filtered and merged query result set chain is returned, comprising: obtaining the result set found by the current traversal step as the first batch of data, generating a first batch of result chains equal in number to the first batch of data; the generation of the first batch of result chains equal in number to the first batch of data comprises: returning the result set found by the current traversal step to the pushdown engine, the pushdown engine merging the data stream channel, and passing the data stream channel upwards to the query engine, the query layer obtaining the result set, and generating a first batch of result chains equal in number to the first batch of data according to the first batch of data in the current traversal step result set; The first batch of result chains are used as the starting information of the next traversal step to complete the query of the next traversal step, and each subsequent traversal step in the traversal step array is executed in succession, and all batch data obtained is integrated into the complete result chain of the current traversal step; The next traversal step is taken as the new current traversal step, and each traversal step in the traversal step array is executed in succession, and the iteration is executed to the last traversal step.

2. The method of querying a graph database based on an extended SQL language according to claim 1, wherein, The use of the SQL language to establish the corresponding schema object specifically comprises: When the schema object is a graph, each graph corresponds to a graph database instance, the graph contains the vertex table and the edge table of the graph database, and the association and adjacency relationship of all vertices and edges in the graph database are stored through the graph data index; When the schema object is a vertex table, each item in the vertex table corresponds to a vertex in the graph database, and each vertex table stores the data of a specified type of vertex in the graph database; When the schema object is an edge table, each item in the edge table corresponds to an edge in the graph database, each edge table stores the data of a group of edges with the same start point type and the same end point type in the graph database, and the vertex table of the start point and the vertex table of the end point are specified.

3. The method of SQL extension graph database query language based according to claim 1, characterized in that, The filter conditions in the where clause are split into corresponding sub-conditions for each traversal step, specifically comprising: The condition expressions in the where clause are sorted according to the traversal step order, and an ordered condition expression tree is generated according to the logic of the condition expressions; The branches of the expression in the ordered condition expression tree are sequentially split into sub-expressions from left to right, and each sub-expression represents a sub-condition, wherein, except for the root node, the remaining sub-expressions are composed of an edge and a node in the condition expression tree.

4. The method of querying a graph database based on an extended SQL language according to claim 3, wherein, The traversal steps and corresponding sub-conditions are assembled into a traversal step array, specifically comprising: Each sub-expression split out is assigned to the corresponding traversal step by traversing the ordered condition expression tree; Assembled according to the logic of the ordered conditional expression tree and the execution order of the traversal steps, a traversal step array is generated, including projection information, expression information, traversal direction and reserved variables, wherein the reserved variables are reserved variables of the previous step or multiple previous steps.

5. The method of SQL extension graph database query language based according to claim 1, characterized in that, The query of each schema object in the graph database is completed according to the traversal steps, and specifically includes: The entire traversal step array is pushed down to the distributed storage engine, and a unique step handle is generated for the traversal step array; Starting from the head node of the traversal step array, the traversal steps in the traversal step data group are sequentially dispatched through the step handle, and the traversal query of each schema object in the graph database is completed according to the corresponding sub-condition of each traversal step.

6. The method of SQL extension graph database query language based according to claim 1, characterized in that, The projection column data of each sub-condition query result in the result set is included in the data flow channel, and the Key information corresponding to the query result is included.

7. The method of SQL extension graph database query language based according to claim 1, characterized in that, The first batch of result chains are used as the starting information of the next traversal step to complete the query of the next traversal step, and specifically includes: The push-down engine distributes the execution command of the next traversal step to the storage engine cluster, and the push-down engine obtains the filtered and unfiltered results of each cluster node in the first batch of result chains, and uses a thread asynchronous mode to deliver the filtered data to the query engine in a streaming manner, and simultaneously delivers the unfiltered data and intermediate information to the storage engine corresponding to the cluster node where the data is located, and continuously pushes the filtered data into the filtered data stream; The query layer obtains the filtered data from the data stream of the next traversal step, and merges the filtered data into the result chain of the current traversal step as a batch of data.

8. The method of SQL extension graph database query language based according to claim 1, characterized in that, The subsequent each traversal step in the traversal step array is continuously traced back and executed, and specifically includes: When each subsequent traversal step is executed, the latest batch of results in the previous traversal step result chain is used as the starting information of the subsequent traversal step, and the required parameters are obtained from the latest result chain; The push-down engine distributes the execution command of the corresponding traversal step, and carries the required parameters of the traversal step to the distributed cluster nodes, and the storage nodes filter the data according to the known data to complete the query of the traversal step.

9. An apparatus based on a SQL extended graph database query language, characterized in that: comprising at least one processor and a memory, the at least one processor and the memory are connected through a data interface, the memory stores instructions executable by the at least one processor, and the instructions are used to complete the method of any one of claims 1-8 based on the SQL extended graph database query language after being executed by the processor.

Images