Query optimization method, system, device and storage medium for graph database

Abstract

The application relates to a query optimization method, system, device and storage medium for a graph database. In the application, a query engine acquires a graph data query statement, analyzes the graph data query statement, and identifies a Join operator. A preset pushdown condition is acquired, and it is judged whether the Join operator meets the pushdown condition. If the judgment result is yes, the Join operator is pushed to a storage engine. The storage engine queries a point edge scanning operator upstream of the Join operator to obtain first point edge data, and the first point edge data is transmitted to the Join operator. The storage engine performs a Join operation on the first point edge data according to the Join operator to obtain first connection data, and the first connection data is returned to the query engine. In the application, the Join operator is pushed to the storage engine, unnecessary intermediate data in the transmission of a final result is reduced, and the query speed is improved. Moreover, the storage layer computing capacity is fully utilized through the pushdown of the Join operator.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of graph database, and in particular to a query optimization method, system, device and storage medium for a graph database. BACKGROUND

[0002] A graph database is a non-relational database specifically designed to handle highly interconnected data, which uses graph structures (nodes, edges, and properties) to represent and store data. Compared with traditional relational databases, graph databases have significant advantages in handling multi-hop queries, complex relationship network analysis, and other scenarios. This data model is very suitable for handling highly interconnected data. Currently, graph databases (such as NebulaGraph) generally adopt a compute-storage separation architecture, in which the query engine layer is responsible for query parsing, optimization, and execution coordination, and the storage engine layer is responsible for data persistence and local computation. The current common query mode is two-stage query processing: first, perform a basic scan operation in the storage engine layer, and then perform data connection, filtering, and aggregation in the query engine layer.

[0003] However, as the scale of graph data expands, the existing graph database query method needs to transmit a large amount of raw data to the query engine layer, point-edge data needs to be serialized / deserialized multiple times, intermediate data that is not needed for the final result is transmitted, and the connection efficiency is low. The traditional Join algorithm is not suitable for the characteristics of graph data, the query engine needs to cache a large amount of intermediate results, and the computing power of the storage layer is not fully utilized. Therefore, the existing graph data query method has problems such as large memory pressure, low CPU utilization, and slow query speed. SUMMARY

[0004] Embodiments of the present application provide a query optimization method, system, device and storage medium for a graph database to at least solve the problem of slow query speed and underutilized computing power of the storage layer in the existing graph data query method in related technologies.

[0005] In a first aspect, embodiments of the present application provide a query optimization method for a graph database, applied in a graph database query system with a query engine and a storage engine, the method comprising:

[0006] obtaining a graph data query statement through the query engine, and performing disassembly analysis on the graph data query statement to identify a Join operator;

[0007] obtaining a preset pushdown condition, determining whether the Join operator meets the pushdown condition, and if the determination result is yes, pushing the Join operator to the storage engine;

[0008] query, by the storage engine, a point-edge scan operator upstream of the Join operator to obtain first point-edge data, and pass the first point-edge data to the Join operator;

[0009] perform, by the storage engine, a Join operation on the first point-edge data according to the Join operator to obtain first connection data, and return the first connection data to the query engine.

[0010] In an embodiment, the method further comprises:

[0011] when the Join operator does not satisfy the pushdown condition, query, by the storage engine, a point-edge scan operator upstream of the Join operator to obtain second point-edge data;

[0012] return the second point-edge data to the query engine and pass the second point-edge data to the Join operator;

[0013] perform, by the storage engine, a Join operation on the first point-edge data according to the Join operator to obtain first connection data, and return the first connection data to the query engine.

[0014] In an embodiment, when the first connection data is returned to the query engine, the method further comprises:

[0015] if there is no query operator downstream of the Join operator, feed back the first connection data to a user;

[0016] if there is a query operator downstream of the Join operator, obtain other data upstream of the query operator, and perform, by the query engine, corresponding query processing on the first connection data and the other data according to the query operator;

[0017] if the storage engine returns multiple first connection data to the query engine, perform, by the query engine, merging processing on multiple second connection data.

[0018] In an embodiment, the storage format of point data is: graph identifier + point type identifier + point identifier; and the storage format of edge data is: graph identifier + edge type identifier + edge start point identifier + edge end point identifier.

[0019] The storage engine comprises multiple storage partitions, and the pushdown condition is:

[0020] The point data and the edge data scanned upstream of the Join operator are saved in the same storage partition, and the execution logic of the Join operator is that the start point identifier of the edge data is equivalent to the identifier of the point data.

[0021] In an embodiment, the parsing of the graph data query statement comprises:

[0022] parsing the graph data query statement into an abstract syntax tree;

[0023] and converting the abstract syntax tree into a logical execution plan to obtain query operators, the query operators comprising point scan operators, edge scan operators and Join operators.

[0024] In an embodiment, the storage engine queries the point edge scan operators upstream of the Join operator comprises:

[0025] querying the point identifier through a primary key index in the storage partition, and obtaining the corresponding point data according to the point identifier;

[0026] scanning in the same storage partition according to the point identifier to obtain edge data starting from the point identifier.

[0027] In an embodiment, the storage engine comprises a plurality of storage partitions, wherein,

[0028] the plurality of storage partitions can execute the Join operators meeting the push-down condition in parallel, and in the process of executing the Join operators, each storage partition performs a Join operation on the point edge data held by itself.

[0029] In a second aspect, the embodiments of the present application provide a graph database query system, the system comprising a query engine and a storage engine, the system realizing the query optimization method for a graph database as described in any of the above embodiments when running; wherein,

[0030] the query engine is configured to receive a graph data query statement, read graph data from the storage engine and execute corresponding query operators, and feed back the final query result to the user; wherein, the query engine can execute all query operators except point edge scan operators and write operators;

[0031] the storage engine is configured to store graph data, and execute point edge scan operators, write operators and Join operators meeting the push-down condition.

[0032] In a third aspect, the embodiments of the present application provide a computer device, comprising a memory, a processor and a computer program stored in the memory and executable on the processor, the processor realizing the query optimization method for a graph database as described in the first aspect above when executing the computer program.

[0033] In a fourth aspect, the embodiments of the present application provide a computer readable storage medium, having a computer program stored thereon, the program being executable by a processor to realize the query optimization method for a graph database as described in the first aspect above.

[0034] The query optimization method, system, device and storage medium for the graph database provided by the embodiments of the present application have at least the following technical effects:

[0035] The query engine obtains a graph data query statement, analyzes the graph data query statement, and identifies a Join operator. A preset pushdown condition is obtained, and it is determined whether the Join operator meets the pushdown condition. If the determination result is yes, the Join operator is pushed to a storage engine. The storage engine queries a point edge scanning operator upstream of the Join operator to obtain first point edge data, and transmits the first point edge data to the Join operator. The storage engine performs a Join operation on the first point edge data according to the Join operator to obtain first connection data, and returns the first connection data to the query engine. The Join operator that meets the condition is pushed to the storage engine to be executed, so that a large amount of original data does not need to be transmitted to the query engine layer, intermediate data that is not needed for transmission of a final result is reduced, and the query speed is improved. In addition, the Join operator is pushed, so that the computing capability of the storage layer is fully utilized, and computing resource waste is reduced.

[0036] Details of one or more embodiments of the present application are presented in the following drawings and description to make other features, objects and advantages of the present application more apparent. BRIEF DESCRIPTION OF DRAWINGS

[0037] The accompanying drawings illustrated herein are used to provide further understanding of the present application, constitute a part of the present application, and the illustrative embodiments of the present application and their descriptions are used to explain the present application, and do not constitute an improper limitation on the present application. In the drawings:

[0038] Figure 1 is a flowchart of a query optimization method for a graph database in an embodiment of the present application;

[0039] Figure 2 is a logical execution and data flow diagram of a graph data query statement in an embodiment of the present application;

[0040] Figure 3 is a structural block diagram of an electronic device in an embodiment of the present application. DETAILED DESCRIPTION

[0041] In order to make the objects, technical solutions and advantages of the present application clearer, the present application will be described and illustrated below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and should not be used to limit the present application. Based on the embodiments provided by the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort belong to the scope of the present application.

[0042] Obviously, the accompanying drawings in the following description are only some examples or embodiments of the present application, and for those of ordinary skill in the art, the present application can also be applied to other similar scenarios without creative effort based on the accompanying drawings. In addition, it can be understood that although the efforts made in the development process can be complex and lengthy, for those of ordinary skill in the art related to the content disclosed in the present application, some design, manufacture or production changes based on the technical content disclosed in the present application are only routine technical means, and should not be understood as insufficient disclosure of the content disclosed in the present application.

[0043] In the present application, "embodiment" means that the specific features, structures or characteristics described in conjunction with the embodiment can be included in at least one embodiment of the present application. The phrase appears at various places in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment to other embodiments. It is explicitly and implicitly understood by those of ordinary skill in the art that the embodiments described in the present application can be combined with other embodiments without conflict.

[0044] Unless otherwise defined, technical terms and scientific terms used in the present application shall have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. The terms "a", "an", "one", "this", and similar referents in the context of describing the application are to be construed to be inclusive, not exclusive. For example, the use of the term "a" or "one" or "the" to refer to an item does not exclude the presence of two or more such items, unless the context clearly indicates otherwise. As used herein, the term "or" as used herein, without additional context, shall not be construed to mean "exclusive or" unless otherwise stated. As used herein, the term "comprises" and its variants are intended to cover both the singular and plural forms of the terms described, such that a process, method, article, or apparatus that comprises a list of elements is not limited to only those elements but can include other elements not expressly listed or inherent to such process, method, article, or apparatus. As used herein, the terms "connected," "coupled," and "pathway" are not limited to direct connections, but can also include indirect connections or pathways, unless otherwise stated. As used herein, the term "plurality" means two or more. As used herein, the term "and / or" describes the association between associated objects, which means that there are three relationships, for example, "A and / or B" can mean that A exists alone, A and B exist together, and B exists alone. The character " / " generally represents an "or" relationship between the associated objects. As used herein, the terms "first", "second", "third", and the like merely distinguish similar objects, and do not represent a specific order.

[0045] Graph database: A database management system specially designed to store and query graph-structured data, which consists of points and edges.

[0046] Point: In a graph database, a point represents an entity, such as Zhang San, a person, and a point is used to store an entity in the graph database. Each point has a unique identifier (a globally unique integer) in the graph database.

[0047] Edge: In a graph database, an edge represents the relationship between entities, such as the relationship between Zhang San and Li Si, and the relationship between entities is stored in the form of an edge in the graph database. The actual content stored in each edge includes the identifiers of the starting point and the ending point.

[0048] In addition, in a graph database, the Join operation is significantly different from the Join in a traditional relational database. The Join in a graph database is a process of matching and connecting vertices with edges or other vertices based on a specific relationship. This connection is not based on value matching, but on the topological relationship of the graph structure itself.

[0049] Currently, Join is mainly implemented in the following ways: for memory Join, point-edge data is pulled to the graphd memory to perform connection; for distributed Join, data is shuffled across nodes and then connected; for index nested loops, point-edge association is achieved through index lookup. How to push down the Join operator to the new optimization scheme of the storage engine to fully utilize the locality characteristics of graph data and the computing power of modern storage engines is a technical direction to be solved at present.

[0050] Based on the above reasons, by pushing down the Pre-defined Join (a Join that meets the pre-defined push-down conditions under the graph database modeling) to the storaged for execution, the application can perform these Joins in parallel while reducing the data volume of each Join, thereby greatly improving the performance of graph database queries. The application can be widely applied to various graph database query optimization scenarios, including social network analysis, recommendation systems, etc.

[0051] Based on the above situation, in a first aspect, embodiments of the application provide a graph database management system, in which there are mainly two components: a query engine (graphd) and a storage engine (storaged). The query engine is used to receive a graph data query statement, read graph data from the storage engine and execute corresponding query operators, and feed back the final query result to the user; for example, the query engine executes all query operators except point-edge scan operators and write operators. The storage engine is used to store graph data (i.e., point-edge data) and execute point-edge scan operators, write operators, and Join operators that meet the push-down conditions. Specifically, the storaged is only responsible for executing point scan operators (NodeScan), edge scan operators (EdgeScan), and write operators (write operators refer to data modification operations such as data insertion, update, deletion, etc.), while all operators other than scan operators (Scan) and write operators are executed in the graphd.

[0052] In embodiments of the application, point data (referred to as points) and edge data (referred to as edges) in graph data are stored in the storaged based on key-value, and the relevant key format is as follows:

[0053] Point: GraphID (unique identifier of the graph) + NodeType (unique identifier of the point type) + NodeID (unique identifier of the point);

[0054] Edge: GraphID (unique identifier of the graph) + EdgeType (unique identifier of the edge type) + SrcID (unique identifier of the start point of the edge) + DstID (unique identifier of the end point of the edge).

[0055] Based on the storage format described above, the embodiment storaged can complete the following query operations:

[0056] 1. In a certain graph, to obtain a point of a given type NodeType and identifier X, only need to specify GraphID+NodeType+X for reading, that is, the identifier X of a point can be read;

[0057] 2. In a certain graph, to obtain all edges of a given edge type EdgeType, only need to specify GraphID+EdgeType for prefix scan, that is, a plurality of edges can be read;

[0058] 3. In a certain graph, to obtain all edges of a given edge type EdgeType and starting point identifier X, only need to specify GraphID+EdgeType+X for prefix scan, that is, a plurality of edges (because there can be multiple edges with X as the starting point) can be read.

[0059] In addition to the above points and edges, for each point, the storaged will additionally save the primary key index, that is, the mapping of the primary key attribute to the point identifier, which is also saved in the form of key-value. For example, assuming that there is a point type Person, and the primary key attribute of the Person is name, then for each point of the Person type, a key-value is saved, the key is the name attribute of the point, and the value is the identifier of the corresponding point.

[0060] In a second aspect, the embodiment of the present application provides a query optimization method for a graph database, which can run in the graph database management system described above, as shown in the following. Figure 1 The query optimization method of the present application is implemented by the following contents.

[0061] Step S1, obtain a graph data query statement through the query engine, and analyze the graph data query statement to identify the Join operator. Specifically, parse the graph data query statement into an abstract syntax tree; then convert the abstract syntax tree into a logical execution plan to obtain a query operator, the query operator including a point scan operator, an edge scan operator and a Join operator.

[0062] In a specific embodiment, the embodiment gives a commonly used graph database query statement of a graph database, and the query statement is used to describe the query optimization method of the present application in detail, and the query statement is:

[0063] MATCH (p1:Person{name:"Alice"})-[e1:KNOWS]->(p2:Person) RETURN p2

[0064] The query is parsed into an abstract syntax tree (AST) and the key components in the query are identified: point patterns (e.g. (p1:Person{name:"Alice"})), edge patterns (e.g. [e1:KNOWS]), relationship patterns (e.g. (p1)-[e1]->(p2)), and return results (e.g. RETURN p2). The query in this embodiment looks for all data in the graph that satisfies the following conditions: a point named p1 with type Person and name attribute Alice; a point named p2 with type Person; an edge between p1 and p2 with type KNOWS named e1; and the query returns p2, i.e. all people that Alice knows.

[0065] The query is translated into the following logical and physical execution plans in the graph database, as described in Figure 2 , where arrows represent data flow, and in the logical plan:

[0066] NodeScan(p1): the function is to find p1, i.e. all points with type Person and name Alice;

[0067] EdgeScan(e1): the function is to find e1, i.e. all edges with type KNOWS;

[0068] Join1: the condition is left_node_id(e1) = element_id(p1), i.e. find all data that satisfies the start point identifier of the e1 edge is equal to the point identifier of p1;

[0069] NodeScan(p2): the function is to find p2, i.e. all points with label Person;

[0070] Join2: the condition is element_id(p2) = right_node_id(e1), i.e. find all data that satisfies the end point identifier of the e1 edge is equal to the point identifier of p2.

[0071] In step S2, the preset pushdown condition is obtained, and it is determined whether the Join operator meets the pushdown condition. If the determination result is yes, the Join operator is pushed to the storage engine. In this embodiment, the storage format of point data is: graph identifier + point type identifier + point identifier; and the storage format of edge data is: graph identifier + edge type identifier + edge start point identifier + edge end point identifier.

[0072] In this embodiment, the storage engine includes multiple storage partitions, and NebulaGraph adopts a hash sharding strategy. First, for a point, each point has a corresponding primary key attribute, and the hash value of the primary key attribute of each point is obtained to obtain an integer X, and then the number of partitions is taken as a modulus, that is, the partition ID is obtained. That is, partition ID = Hash (primary key attribute) % number of partitions. In addition, the unique identifier of each point also contains information of the partition ID. Secondly, for an edge, which partition each edge is saved in is determined by the unique identifier of the starting point of the edge. That is, the edge is saved in the partition where the starting point is located. Through the above operations, it is ensured that "a point and all edges with the point as the starting point are only saved in a given storage partition".

[0073] In the graph database of the embodiment of the present application, there are multiple instances (that is, storage partitions), and each instance is responsible for saving a part of data in the graph. For a point, assuming that the identifier of the point is X, then the point with the identifier X and all edges with the point X as the starting point are saved in the same storaged in the graph database. Therefore, as long as any identifier X is known, the point p with the identifier X and all edges e with the point X as the starting point can be queried in the same storaged, and the Join operator with the Join condition of left_node_id (e) = element_id (p) can also be executed in the storaged. Such a Join is also called a Pre-defined Join.

[0074] Based on the storage sharding strategy of the embodiment, the pushdown condition of the present application is that the point data and edge data obtained by scanning upstream of the Join operator are saved in the same storage partition, and the execution logic of the Join operator is that the starting point identifier of the edge data is equivalent to the identifier of the point data. That is, the point and edge data upstream of the Join, that is, the data read by the NodeScan and the data of the EdgeScan are saved in the same storaged, and the Join condition is that the starting point identifier of the edge = the identifier of the point.

[0075] In Figure 2 , Join1 meets the two conditions, so it is a Pre-defined Join, and Join2 is not a Pre-defined Join because the Join condition does not match.

[0076] Step S3, querying the point edge scanning operator upstream of the Join operator by the storage engine to obtain first point edge data, and passing the first point edge data to the Join operator. Specifically, in the point edge scanning process, the point identifier is queried by the primary key index in the storage partition, and the corresponding point data is obtained according to the point identifier; the point identifier is scanned in the same storage partition to obtain edge data starting from the point identifier.

[0077] Taking the above query statement as an example, when executing NodeScan(p1), storaged queries the primary key index to find the corresponding point identifier through Alice, which is assumed to be X. Then the point is read through GraphID + NodeType + X, that is, p1, which is the point of type Person and name Alice. Note that unlike the original scheme, storaged passes the identifier of each point in p1 to EdgeScan(e1), and finally passes the corresponding data to the downstream Join1, without returning to graphd.

[0078] When executing EdgeScan(e1), storaged performs prefix scanning on each point identifier received from NodeScan(p1) through GraphID + EdgeType + point identifier, and passes the corresponding data to the downstream Join1, without returning to graphd.

[0079] Step S4, performing Join operation on the first point edge data by the storage engine according to the Join operator to obtain first connection data, and returning the first connection data to the query engine. For details, refer to Figure 2 After receiving the data of NodeScan(p1) and EdgeScan(e1), storaged Join1 can perform Join according to the condition left_node_id(e1) = element_id(p1), and then return the corresponding data to graphd.

[0080] In a preferred embodiment, if the storage engine returns multiple first connection data to the query engine, the query engine performs merging processing on multiple second connection data. Multiple storage partitions can execute the Join operator that meets the pushdown condition in parallel, and in the process of executing the Join operator, each storage partition performs Join operation on the point edge data it holds. graphd merges the results of Join1 of each storaged and passes them to the downstream operator.

[0081] In an embodiment of the present application, when the first connection data is returned to the query engine, if there is no query operator downstream of the Join operator, the first connection data is fed back to the user; if there is a query operator downstream of the Join operator, such as Join2 in Figure 2 , the query engine acquires the scan result of other data upstream of the query operator, such as the scan result of NodeScan(p1) in Figure 2 , and then performs corresponding query processing on the first connection data and the other data according to the query operator, such as performing a Join2 operation.

[0082] In an excellent embodiment of the present application, when the Join operator does not meet the pushdown condition, the query engine queries the point-edge scan operator upstream of the Join operator through the storage engine to obtain second point-edge data; after the second point-edge data is returned to the query engine, the second point-edge data is transmitted to the Join operator; the query engine performs a Join operation on the second point-edge data according to the Join operator to obtain second connection data, and transmits the second connection data to a downstream operator.

[0083] Specifically, taking the above query statement as an example, and referring to Figure 2 , if Join1 does not meet the pushdown condition, the query is performed according to the following manner in the query process:

[0084] When NodeScan(p1) is executed, storaged queries the primary key index, finds the corresponding point identifier through Alice, which is assumed to be X, and then reads the point through GraphID + NodeType + X, that is, p1, which is all points of the Person type and with the name Alice, and finally returns the read data to graphd;

[0085] When EdgeScan(e1) is executed, storaged performs prefix scan through GraphID + EdgeType, that is, e1, which is all edges of the KNOWS type, and finally returns the read data to graphd;

[0086] After graphd receives the data of NodeScan(p1) and EdgeScan(e1), it can perform Join1, that is, Join according to the condition of left_node_id(e1) = element_id(p1), and then outputs the corresponding data to the downstream. The remaining process is similar to the process of pushing down to the storage engine described above, and is not described in detail.

[0087] In summary, the query optimization method for the graph database provided by the embodiments of the present application can realize that the Pre-defined Join can be completed in parallel in multiple storages (each storage performs the Join on the part of data it holds, and finally combines the data results) by pushing the Pre-defined Join meeting the pushdown condition provided by the present application to the storage engine, which can greatly improve the execution efficiency. Moreover, the data volume of the Join is greatly reduced during the execution of the Pre-defined Join in the storage, and the frequent data transmission between the storage engine and the query engine (such as returning a large number of point-edge data to the query engine) is avoided, which improves the query speed and the query efficiency. In addition, the present application can make full use of the computing memory of the storage engine by pushing part of the Join to the storage engine, and the waste of computing resources is avoided.

[0088] In a third aspect, the embodiments of the present application provide an electronic device, Figure 3 FIG. 1 is a block diagram of an electronic device according to an exemplary embodiment. As shown in FIG. 1, the electronic device can include a processor 11 and a memory 12 storing computer program instructions. Figure 3

[0089] Specifically, the processor 11 can include a central processing unit (CPU), or an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application.

[0090] ​The memory 12 can include a mass storage for data or instructions. By way of example and not limitation, the memory 12 can include a Hard Disk Drive (HDD), floppy disk drive, a Solid State Drive (SSD), flash memory, a Compact Disc Read Only Memory (CDROM), a Digital Versatile Disk (DVD), a magnetic tape, or a Universal Serial Bus (USB) drive, or a combination of two or more of these. The memory 12 can be removable and / or non-removable (or fixed) as appropriate. The memory 12 can be internal or external as appropriate. In particular embodiments, the memory 12 is a Non-Volatile memory. In particular embodiments, the memory 12 includes a Read-Only Memory (ROM) and a Random-Access Memory (RAM). The ROM can be a mask-programmed ROM, a Programmable ROM (PROM), an Erasable PROM (EPROM), an Electrically EPROM (EEPROM), an Electrically Alterable ROM (EAROM), or a FLASH, or a combination of two or more of these, as appropriate. The RAM can be a Static Random-Access Memory (SRAM) or a Dynamic Random-Access Memory (DRAM), which can be a Fast Page Mode Dynamic Random-Access Memory (FPMDRAM), an Extended Data Out Dynamic Random-Access Memory (EDODRAM), a Synchronous Dynamic Random-Access Memory (SDRAM), or the like, as appropriate.

[0091] The memory 12 can be used to store or buffer various data files required for processing and / or communication, and possible computer program instructions executed by the processor 11.

[0092] The processor 11 realizes the query optimization method for the graph database in any of the above embodiments by reading and executing the computer program instructions stored in the memory 12.

[0093] In an embodiment, the electronic device can further include a communication interface 13 and a bus 10. As shown in the figure, the processor 11, the memory 12, and the communication interface 13 are connected through the bus 10 and complete communication with each other. Figure 3

[0094] The communication interface 13 is used to realize the communication between various modules, devices, units and / or equipment in the embodiments of the present application. The communication interface 13 can also realize data communication with other components, such as external devices, image / data acquisition devices, databases, external storage, and image / data processing workstations, etc.

[0095] ​Bus 10 includes hardware, software, or both, to couple components of electronic device to each other. Bus 10 includes, but is not limited to, at least one of a data bus, an address bus, a control bus, an expansion bus, a local bus, and the like. By way of example and not limitation, bus 10 can include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an InfiniBand (IB) interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or the like, or a combination of two or more of these. Where appropriate, bus 10 can include one or more buses. Although the present application is described and illustrated with a particular bus, it is contemplated that any appropriate bus or interconnect can be used.

[0096] In a fourth aspect, an embodiment of the present application provides a computer readable storage medium, having stored thereon a program, wherein the program is executed by a processor to implement the method for query optimization for a graph database according to the first aspect.

[0097] More specifically, the computer readable storage medium can include, but is not limited to, a portable disc, a hard disk, a random access memory, a read-only memory, an erasable programmable read-only memory, an optical storage device, a magnetic storage device, or any appropriate combination of the above.

[0098] In possible implementation manners, the present application can also be implemented in the form of a program product, which comprises program codes for causing a terminal device to perform the steps of the query optimization method for a graph database provided by the first aspect when the program product is run on the terminal device.

[0099] Wherein, the program codes for executing the present application can be written in any combination of one or more programming languages, which can be executed entirely on the user device, partially on the user device, as a separate software package, partially on the user device and partially on a remote device, or entirely on a remote device.

[0100] The technical features of the above-mentioned embodiments can be combined in any manner. In order to make the description concise, all possible combinations of the technical features in the above-mentioned embodiments are not described, however, as long as the combinations of the technical features do not exist contradictions, they should be considered as the scope of the present application.

[0101] The above-mentioned embodiments only express several implementation manners of the present application, and the description is more specific and detailed, but it should not be understood as a limitation on the scope of the patent. It should be pointed out that for those skilled in the art, without departing from the concept of the present application, a number of modifications and improvements can be made, which are all within the scope of the present application. Therefore, the scope of the patent of the present application should be subject to the appended claims.

Claims

1. A method for query optimization for a graph database, characterized in that, The application is applied to a graph database query system with a query engine and a storage engine, and the method comprises the following steps: Obtaining a graph data query statement through the query engine, and analyzing and resolving the graph data query statement to identify a Join operator; Obtaining a preset pushdown condition, and pushing the Join operator meeting the pushdown condition to the storage engine; Obtaining first point-edge data by querying point-edge scanning operators upstream of the Join operator through the storage engine, and delivering the first point-edge data to the Join operator; Obtaining first connection data by performing a Join operation on the first point-edge data according to the Join operator through the storage engine, and returning the first connection data to the query engine; The storage engine comprises a plurality of storage partitions, and the pushdown condition is that: Point data and edge data scanned upstream of the Join operator are saved in the same storage partition, and the execution logic of the Join operator is that a start point identifier of the edge data is equivalent to an identifier of the point data.

2. The query optimization method of claim 1, wherein, The method further comprises the following steps: When the Join operator does not meet the pushdown condition, obtaining second point-edge data by querying point-edge scanning operators upstream of the Join operator through the storage engine; After returning the second point-edge data to the query engine, delivering the second point-edge data to the Join operator; Obtaining second connection data by performing a Join operation on the second point-edge data according to the Join operator through the query engine, and delivering the second connection data to downstream operators.

3. The query optimization method of claim 1, wherein, After returning the first connection data to the query engine, the method further comprises the following steps: If there is no query operator downstream of the Join operator, feeding back the first connection data to a user; If there is a query operator downstream of the Join operator, obtaining other data upstream of the query operator, and performing corresponding query processing on the first connection data and the other data according to the query operator through the query engine; If the storage engine returns a plurality of first connection data to the query engine, performing merging processing on a plurality of second connection data through the query engine.

4. The query optimization method according to claim 1, wherein: The storage format of point data is graph identifier+point type identifier+point identifier, and the storage format of edge data is graph identifier+edge type identifier+edge start point identifier+edge end point identifier.

5. The query optimization method of claim 1, wherein, The analysis and resolution of the graph data query statement comprises the following steps: Parsing the graph data query statement into an abstract syntax tree; Converting the abstract syntax tree into a logical execution plan to obtain query operators, wherein the query operators comprise point scanning operators, edge scanning operators and Join operators.

6. The query optimization method of claim 4, wherein, The querying of point-edge scanning operators upstream of the Join operator by the storage engine comprises the following steps: Querying a point identifier through a primary key index in the storage partition, and obtaining corresponding point data according to the point identifier; Scanning edge data with the point identifier as a start point in the same storage partition.

7. The query optimization method of claim 1, wherein, The storage engine comprises a plurality of storage partitions, wherein The multiple storage partitions can perform the Join operator meeting the push-down condition in parallel, and in the process of executing the Join operator, each storage partition performs a Join operation on the point-edge data held by itself.

8. A graph database query system, characterized in that, The system comprises a query engine and a storage engine, and the system implements the query optimization method for a graph database as claimed in any one of claims 1 to 7 when running; wherein, The query engine is configured to receive a graph data query statement, read graph data from the storage engine, execute corresponding query operators, and feed back the final query result to the user; wherein, the query engine executes all query operators except the point-edge scanning operator and the write operator; The storage engine is configured to store graph data and execute the point-edge scanning operator, the write operator, and the Join operator meeting the push-down condition.

9. An electronic device, comprising: A computer program product comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor implements the query optimization method for a graph database as claimed in any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the query optimization method for a graph database as claimed in any one of claims 1 to 7.

Images