Graph databases

Abstract

The present invention relates to a computer implemented method of natively storing a set of nodes and / or edges in a graph database, comprising generating a bitset representing a set of graph nodes or graph edges, and setting the value of a bit in the bitset in dependence on whether a corresponding node and / or edge is part of the set. The present invention also relates to a computer implemented method of querying data in a graph database, the graph database comprising graph nodes connected by graph edges, the method comprising: receiving a query, the query comprising a first query node, a first query edge, and a second query node arranged in a pattern; for the first query node, identifying a first set of graph nodes or graph edges associated with the graph nodes which satisfy criteria of the first query node; for the first query edge, identifying a second set of graph nodes or graph edges associated with the graph edges which satisfy criteria of the first query edge; for the second query node, identifying a third set of graph nodes or graph edges associated with the graph nodes which satisfy criteria of the second query node; and computing the intersection of the first, second and third sets of graph nodes or graph edges to obtain one or more first output sets of graph nodes or graph edges.

Description

[0001] Graph Databases

[0002] Field of Invention

[0003] The present invention relates to the field of graph databases. More specifically, the invention relates to computer implemented methods of natively storing a set of nodes and / or edges in a graph database, and querying data in a graph database.

[0004] Background

[0005] Graph databases store connected data in graph structures formed of nodes, edges and properties. Nodes (also known as vertices) represent individual entities or instances in the database. Edges (also known as relationships) connect the nodes together in the graph and represent the relationships between the nodes. In some cases, edges may have a direction; a unidirectional edge represents a one-way relationship between two nodes, and a bidirectional edge represents a two-way relationship between two nodes. The nodes and edges may have properties representing data associated with the nodes or edges.

[0006] Graph databases are typically used to store very large datasets of connected data. Exemplary uses of graph databases include social networks and large knowledge bases to serve internet search engines or large language models. For a graph database representing a social network, for example, the nodes in the graph may represent the individual users of the social network (where the properties of the nodes represent the data associated with the users) and the edges in the graph may represent the relationships between the users (where the properties of the edges may represent, for example, the type of relationship between the users).

[0007] The current state of the art algorithms for graph querying must always traverse the graph and walk all matching paths in order to satisfy the query, and that coordination overhead makes this hard to parallelise efficiently.

[0008] The present disclosure seeks to address the non-linear performance characteristics when querying a graph.

[0009] Summary of the Invention

[0010] Aspects and embodiments of the present invention are set out in the appended claims. These and other aspects and embodiments of the present disclosure are also described herein. According to at least one aspect described herein, there is provided a computer implemented method of natively storing a set of nodes and / or edges in a graph database, comprising generating a bitset representing a set of graph nodes or graph edges, and setting the value of a bit in the bitset in dependence on whether a corresponding node and / or edge is part of the set.

[0011] As used in this disclosure, the term "graph storage” and related terms are used to refer to the underlying structure of connected data persisted in either memory or on disk. When the storage is built specifically for graph data, it is known as “native” graph storage. Native graph storage is optimised for storing and querying highly connected data and is designed to handle complex relationships between data points efficiently. Accordingly, as used in this disclosure, the term “native graph storage”, or related terms such as “natively storing”, are used to refer to the underlying data structures optimised specifically for storing connected graph data, persisted in either memory or on disk.

[0012] Preferably, the nodes and / or edges in the graph database each have an associated unique identifier.

[0013] Preferably, the method comprises setting the value of a bit in the bitset in dependence on whether a node and / or edge having a unique identifier corresponding to that bit is part of the set.

[0014] Preferably, the method comprises setting the value of a bit in the bitset in dependence on whether a node and / or edge having a unique identifier corresponding to the position of that bit in the bitset is part of the set.

[0015] Preferably, wherein the unique identifiers for the nodes and / or edges in the graph database are integers, preferably monotonically increasing integers.

[0016] Preferably, the method comprises, for a node in the graph database, generating a bitset representing the set of edges which point at that node as a target.

[0017] Preferably, the method comprises, for a node in the graph database, generating a bitset representing the set of edges which point from that node as a source.

[0018] Preferably, the method comprises, for an edge in the graph database, generating a bitset representing the source node(s) for that edge.

[0019] Preferably, the method comprises, for an edge in the graph database, generating a bitset representing the target node(s) for that edge. Preferably, wherein the bitsets are formed of words having a length that is selected to suit hardware used to perform operations on the bitsets, preferably 64-bit or 128-bit words.

[0020] The hardware used to perform any of the bitset operations described in the present disclosure maybe be one or more central processing units (CPUs), one or more graphics processing units (GPUs) or one or more neural processing units (NPUs) or any combination therefore arranged to perform bitset operations in parallel.

[0021] According to another aspect described herein, there is provided a computer implemented method of querying data in a graph database, the graph database comprising graph nodes connected by graph edges, the method comprising: receiving a query, the query comprising a first query node, a first query edge, and a second query node arranged in a pattern; for the first query node, identifying a first set of graph nodes or graph edges associated with the graph nodes which satisfy criteria of the first query node; for the first query edge, identifying a second set of graph nodes or graph edges associated with the graph edges which satisfy criteria of the first query edge; for the second query node, identifying a third set of graph nodes or graph edges associated with the graph nodes which satisfy criteria of the second query node; and computing the intersection of the first, second and third sets of graph nodes or graph edges to obtain one or more first output sets of graph nodes or graph edges.

[0022] Preferably, the query comprises a second query edge, and the method further comprises: for the second query edge, identifying a fourth set of graph nodes or graph edges associated with the graph edges which satisfy criteria of the second query edge; and computing the intersection of a set associated with the first output set and the fourth set of graph nodes or graph edges to obtain a second output set of graph nodes and / or graph edges.

[0023] Preferably, the query comprises a third query node, and the method further comprises: for the third query node, identifying a fifth set of graph nodes or graph edges associated with the graph nodes which satisfy criteria of the third query node; and computing the intersection of the set associated with the first output set the fourth and fifth sets of graph nodes or graph edges to obtain the second output set of graph nodes and / or graph edges.

[0024] Preferably, the method comprises removing at least one graph node or graph edge from the first output set of graph nodes or graph edges based on the second output set of graph nodes or graph edges.

[0025] Preferably, the first query node and / or the first query edge are selected from among multiple query nodes and / or multiple query edges in the query based on statistics associated with the query nodes and / or query edges. Preferably, the first and / or third set of graph nodes or graph edges comprises a set of graph edges which point to graph nodes which satisfy the criteria of the first and / or second query nodes respectively, and / or a set of graph edges which point from graph nodes which satisfy the criteria of the first and / or second query node respectively.

[0026] Preferably, the second set of graph nodes or graph edges comprises a set of graph nodes which are sources for graph edges which satisfy the criteria of the first query edge and / or a set of graph nodes which are targets for graph edges which satisfy the criteria of the first query edge.

[0027] Preferably, the method comprises traversing the query pattern from a first query segment to a last query segment, each segment comprising at least one query node and at least one query edge; for each segment, identifying sets of graph nodes or graph edges associated with the graph nodes or graph edges which satisfy the criteria of the query nodes or query edges in the segment; and computing the intersection of the sets to obtain an output set for the segment.

[0028] Preferably, the method comprises traversing the query pattern from the last query segment to the first query segment; and based on the output set obtained from one segment, removing at least one graph node or graph edge from the output sets for obtained from at least one other segment.

[0029] Preferably, the method comprises obtaining, from the output set(s) and node-edge maps, at least one output sub-graph of the graph database.

[0030] Preferably, the sets of graph nodes or graph edges are represented by bitsets wherein the value of a bit in the bitset depends on whether a corresponding graph node and / or graph edge is part of the set.

[0031] Preferably, computing the intersection comprises parallelising the intersection computation across multiple processors, preferably across multiple graphics processing units (GPUs).

[0032] According to another aspect described herein, there is provided a computer implemented method of querying data in a graph database, the graph database comprising nodes and / or edges stored according to any of the aforementioned methods, the method of querying data comprising: retrieving a bitset representing a set of graph nodes or graph edges; and retrieving, from the graph database, data associated with the graph nodes or graph edges represented in the bitset. Accordingly to another aspect described herein, there is provided a computer program product comprising software code adapted, when executed on one or more processors, to carry out any of the aforementioned methods.

[0033] According to another aspect described herein, there is provided a graph database comprising nodes and / or edges stored according to any of the aforementioned methods.

[0034] In contrast to the background art, the present disclosure does not traverse the graph or walk the paths, is easy to parallelise, and produces an intermediate graph data representation that allows some queries to be satisfied without needing a walk of the paths during projection.

[0035] The novel native graph storage data structure of the present disclosure enables; the ability to query the data without doing any graph walking, keeping the query linear in the size and order of the graph; the ability to do highly uncoordinated parallel processing of the query; and the ability to do this on hardware that natively supports bitset operations (e.g., GPUs) for even faster processing of the query.

[0036] As used herein, the term “bitsets” refers to an array of binary bits. The “position” of a bit in the bitset refers to where the bit appears in sequence in the array; it does not refer to the significance of the bit in the array.

[0037] Any apparatus feature described herein may also be provided as a method feature, and vice versa. As used herein, means plus function features may be expressed alternatively in terms of their corresponding structure.

[0038] Any feature in one aspect of the disclosure may be applied to other aspects of the disclosure, in any appropriate combination. In particular, method aspects may be applied to apparatus aspects, and vice versa.

[0039] Furthermore, any, some and / or all features in one aspect can be applied to any, some and / or all features in any other aspect, in any appropriate combination. It should also be appreciated that particular combinations of the various features described and defined in any aspects of the present disclosure can be implemented and / or supplied and / or used independently. As used herein, means plus function features may be expressed alternatively in terms of their corresponding structure, such as a suitably programmed processor and associated memory.

[0040] The disclosure also provides a computer program or a computer program product for carrying out any of the methods described herein, and / or for embodying any of the apparatus features described herein. The disclosure also provides a non-transitory computer readable medium having stored thereon a program for carrying out any of the methods described herein and / or for embodying any of the apparatus features described herein.

[0041] The disclosure also provides a signal embodying a computer program or a computer program product for carrying out any of the methods described herein, and / or for embodying any of the apparatus features described herein, a method of transmitting such a signal, and a computer product having an operating system which supports a computer program for carrying out the methods described herein and / or for embodying any of the apparatus features described herein.

[0042] Furthermore, features implanted in hardware may generally be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly.

[0043] One or more aspects will now be described, by way of example only and with reference to the accompanying drawings having I ike- reference numerals, in which:

[0044] Figure 1 is a diagram showing an exemplary simplified graph database structure;

[0045] Figure 2 is a diagram showing another exemplary simplified graph database structure;

[0046] Figure 3a is a flowchart showing the method for querying data stored in the graph database;

[0047] Figure 3b is a flowchart showing the method for querying, with a multi-segment query, data stored in the graph database; and

[0048] Figure 4 is a process flow diagram showing the method for querying data stored in the graph database.

[0049] Detailed

[0050] The present disclosure provides a method for natively storing data in a graph database and a method for querying data in a graph database. A simplified exemplary graph database is described below with reference to Figures 1 and 2, and this exemplary graph database is used throughout this disclosure to illustrate the methods of storing and querying data in the database. The method for querying data in the database is described below with reference to Figure 3a and 3b, and an overall process flow is described below with reference to Figure 4.

[0051] Graph databases

[0052] Figure 1 is a diagram showing an exemplary simplified graph database structure. The graph database in this example may be (part of) a knowledge graph and is used to store information about films. This exemplary graph database comprises three types of nodes (Person, Film, and Country) connected by three types of edges (starredln, directed, and producedin) representing the relationships between the nodes. A “starredln” edge may connect a person node to a film node to indicate that the person starred in that film. A “directed” edge may also connect a person node to a film node to indicate that the person directed that film. A “producedin” edge may connect a film node to a country node to indicate that the film was produced in that country.

[0053] In this example each of the edges is unidirectional because the three types of relationships represented by the edges are one-way relationships. It should also be noted that the directions of the edges have been chosen to fit the semantic definitions of the edges. For example, the “directed” edges point in this example from a person node to a film node to fit the semantic definition “Person X directed Film Y”. It would be equally possible to reverse the direction of this edge and change the semantic definition of the edge to “directedBy” to fit a different semantic definition such as “Film Y was directed by Person X”.

[0054] Figure 2 is a diagram showing another exemplary simplified graph database structure, which is a more specific example of the general graph database shown in Figure 1. In the graph database shown in Figure 2 the person, film, and country nodes have been specified along with their respective node identification (ID) numbers in brackets. The node ID numbers are the unique identifiers associated with each node and are used to store the nodes. In this example, the node ID numbers are simply monotonically increasing integers assigned to each node.

[0055] In Figure 2, the graph database includes five person nodes:

[0056] • Tom Hanks (node ID: 1)

[0057] • Matt Damon (node ID: 2)

[0058] • Steven Spielberg (node ID: 3)

[0059] • Robert Zemeckis (node ID: 4)

[0060] • Doug Liman (node ID: 5)

[0061] The graph database also includes three film nodes:

[0062] • Saving Private Ryan (node ID: 6)

[0063] • Forest Gump (node ID: 7)

[0064] • The Bourne Identity (node ID: 8)

[0065] Finally, the graph database includes one country node: United States of America (node ID: 9)

[0066] The edges of the graph database can also be assigned unique edge identification numbers to identify the edges. In this example the edge ID numbers are also monotonically increasing integers assigned to each edge in brackets in Figure 2. Each edge may additionally or alternatively be identified by the nodes it connects; for example, the edge can be identified by the node ID for its source (i.e., the node from which the edge originates) and the node ID for its target (i.e., the node at which the edge terminates).

[0067] In Figure 2, the graph database includes three “starredln” edges:

[0068] • Tom Hanks - starredln - Saving Private Ryan (edge ID: 1 ; source 1 , target 6)

[0069] • Tom Hanks - starredln - Forrest Gump (edge ID: 2; source 1 , target 7)

[0070] • Matt Damon - starredln - Bourne Identity (edge ID: 3; source 2, target 8)

[0071] The graph database also includes three “directed” edges:

[0072] • Saving Private Ryan <- directed - Steven Spielberg (edge ID: 4; source 3, target 6)

[0073] • Forrest Gump <- directed - Robert Zemeckis (edge ID: 5; source 4, target 7)

[0074] • Bourne Identity <- directed - Doug Liman (edge ID: 6; source 5, target 8)

[0075] Finally, the graph database includes three “producedin” edges:

[0076] • Saving Private Ryan - producedin - United States of America (edge ID: 7; source 6, target 9)

[0077] • Forrest Gump - producedin - United States of America (edge ID: 8; source 7, target 9)

[0078] • Bourne Identity - producedin - United States of America (edge ID: 9; source 8, target 9)

[0079] A simple query of a graph database may involve a user asking for a set of nodes that match some constraints. For example, a database query written in the Cypher / GQL language reading “MATCH (a:Person) RETURN a;” would return all nodes in the database of type “Person”. In the exemplary graph database shown in Figure 2, this query would return nodes 1 to 5.

[0080] A slightly more complex query may involve a user asking for the sets of nodes and edges which fulfil certain relationship criteria. In this case, the query would span an edge and the user might input criteria for the edge as well as the nodes on either side of that edge. For example, in the exemplary graph database shown in Figure 2, the query: “MATCH p=(a:Person)-[e:starredln]->(b:Film) RETURN p;” would return all sets of nodes and edges which represent a person who starred in a film, that is:

[0081] • Tom Hanks - starredln Saving Private Ryan

[0082] • Tom Hanks - starredln - Forest Gump

[0083] • Matt Damon - starredln - The Bourne Identity.

[0084] A similar query could be used for a graph database representing a social network. For example, the query “MATCH p=(a:Person)-[e:knows]->(b:Person {name:"Joe Bloggs"}) RETURN p;” would return all person nodes in the social network who know Joe Bloggs. It is important to note that in this example the first node in the query “(a:Person)” is not limited to any particular person, it is just limited to any node of the type “Person”. In contrast, the second node in the query “(b:Person {name:"Joe Bloggs"})” is limited to a particular person, Joe Bloggs, rather than all nodes of the type “Person”.

[0085] A yet more complex query can span multiple edges or search for branched relationships. An exemplary query spanning multiple edges may be “p=(a:Person)-[e1 :knows]->(b:Person)- [e2:bornln]->(c:Country) RETURN p;” which will return results where a first person knows a second person who was born in a certain country. An exemplary query for branched relationships may be “MATCH p=(a:Person)-[e1 :knows]->(b:Person)-[e2:bornln]- >(c:Country), (b)-[e3:hasPet]->(d:Animal)” which will return results where a first person knows a second person who was born in a certain country, and where the second person has a pet which is a certain animal; in this example, there are two relationships branching from the second person node “(b:Person)”.

[0086] An important aspect of querying a graph database is that the results of the query are essentially pathways through the graph database. These pathways represent sub-sections or ‘sub-graphs’ of the graph database which fulfil the criteria of the query. It should also be noted that the query itself resembles a pathway through the graph database in that it specifies nodes connected by edges. For queries spanning multiple edges, the query can be broken down into segments, with each segment of the query containing one edge. For example, the query “p=(a:Person)-[e1 :knows]->(b:Person)-[e2:bornln]->(c:Country) RETURN p;” can be broken down into the following two segments: “(a:Person)-[e1 :knows]->(b:Person)” and “(b:Person)- [e2:bornln]->(c:Country)” where the central node in the query “(b:Person)” is common to both segments.

[0087] The exemplary graph databases shown in Figures 1 and 2 are highly simplified for the purposes of clarity and brevity. In practice, graph databases are very large, typically containing potentially millions if not billions of nodes and edges. Bitsets as native graph data storage

[0088] In the present disclosure, node adjacency lists in the graph database are natively stored using bitsets.

[0089] Bitsets (also known by other terms including bit arrays, bitmaps, and bit vectors) are an efficient and compact data structure for storing information in strings of binary bits (“0” or “1”). Modern computers typically process bitsets in the form of 32-bit or 64-bit words (i.e., strings of 32 or 64 bits). Various bitwise operations can be performed on bitsets, such as bitmask, intersection, and union operations, and such operations can be performed extremely quickly. Bitset compression algorithms, such as Roaring Bitmaps, can be used to compress bitsets for efficient storage; such compression algorithms are particularly effective for dense bitsets (i.e., containing primarily “1” bits) or sparse bitsets (i.e., containing primarily “0” bits).

[0090] In the present disclosure, bitsets are used to represent sets of nodes in the graph database. This is achieved by generating bitsets wherein the value of a bit in the bitset depends on whether a corresponding node is part of the set. For example, the value of bits in the bitset is set to “1” or “0” in dependence on whether a given node is or is not contained in a set. One way to achieve this is to assign unique identifiers to each node in the graph database, such as monotonically increasing integer numbers, and setting the value of a bit in a given position in the bitset to “1” or “0” depending on whether the node with the unique identifier corresponding to that position is or is not contained in the set.

[0091] The following description of this data structure refers to some examples using 8-bit words (i.e., bytes). This is for simplicity and brevity; in practice it is preferred to construct bitsets of (arrays of) a size that suits the native hardware word size to optimise for processing (specifically, to optimise for hardware that natively supports bitset operations such as graphics processing unit (GPU) Textures).

[0092] Suppose a graph database contains 8 nodes, each of which is assigned a monotonically increasing integer as its unique identifier. The 8 nodes would be represented by the following set of unique identifiers: 1 , 2, 3, 4, 5, 6, 7, 8. The set of the 8 nodes can then be represented by an 8-bit bitset where each bit in the bitset represents one of the unique identifiers: the first bit represents the node with identifier “1”, the second bit represents the node with identifier “2”, and so on. Therefore, to generate a bitset to identify a particular node, or a particular set of nodes, the value of the bit in the position corresponding to the particular node is set to “1” while the other bits remain “0”. For example, to generate a bitset containing the nodes with identifiers 3 and 6, the third and sixth bits in the bitset would be set to “1”, as follows: Bitset: 0 0 1 0 0 1 0 0

[0093] Identifiers: 1 2 3 4 5 6 7 8

[0094] In other examples, the unique integer identifiers may start from “0” rather than “1”, in which case the first bit in the bitset represents the node with identifier “0”, the second bit represents the node with identifier “1”, and so on.

[0095] Given two bitsets, it is possible to carry out bitwise operations such as intersection (“D”) and union (“u") operations. An intersection of first and second bitsets returns a third bitset containing only the elements that are part of both the first and second bitsets. For example:

[0096] Bitset 1 : 0 0 0 1 0 0 1 0

[0097] Bitset 2: 0 1 0 1 0 0 0 0

[0098] Intersection: 0 0 0 1 0 0 0 0

[0099] A union of first and second bitsets returns a third bitset containing all elements that are part of either the first or second bitset. For example:

[0100] Bitset 1 : 0 0 0 1 0 0 1 0

[0101] Bitset 2: 0 1 0 1 0 0 0 0

[0102] Union: 0 1 0 1 0 0 1 0

[0103] This data structure can be extended beyond 8-bit bytes to much larger numbers by stacking bytes in an array. For example, 8 bytes stacked into a 64-bit array can be used to represent integers 1 to 64 inclusive. The intersection and union operations can be calculated by iterating over the bytes of the arrays (i.e., for an intersection operation, the first byte of a first array is intersected with the first byte of the second array, the second bye of the first array is intersected with the second byte of the second array, and so on). For example, the intersection (“D”) of a first 64-bit bitset identifying the numbers 6, 33, and 57 and a second 64-bit bitset identifying the numbers 3, 6, 9, 19, 24, 37, 40, 41 , 42, 43, 49, 50, 57, 59, 63 can be represented in binary form as follows: 00000 100, 0 0100 100, 000 00100,

[0104] 0000000 0, 1 00000 00, 0000000 0,

[0105] 0000000 0, 0 01000 01, 0000000 0, oooooooo, n 0000000 0, 0000000 0,

[0106] 10000000, 0 00010 01, 0000000 0, oooooooo, 1 11000 00, 0000000 0, oooooooo, 1 10000 00, 0000000 0,

[0107] 10000000, 1 01000 10, 100 00000,

[0108] The bitset resulting from this intersection identifies only the numbers 6 and 57 which are the only numbers identified by both the first and second bitsets. Union operations can also be computed over such bitsets.

[0109] Extending this concept further, rather than using 8-bit words, as set out in the example above, 64-bit words can be used. If using 64-bit words, the above intersection can be computed with a single intersection operation rather than in 8 separate iterated intersection operations. Very large bitsets can be formed of stacked 64-bit words.

[0110] Storage of nodes - example

[0111] Applying this native graph storage method to the exemplary graph database shown in Figure 2, which contains 9 nodes, an empty bitset (using, for the sake of example, two 8-bit words) representing the 9 node identifiers would be:

[0112] Bitset: 0000000000000000

[0113] Identifiers: 123456789 -

[0114] For the graph database shown in Figure 2, the nodes of the type “Person” have unique identifiers 1 to 5, the nodes of type “Film” have unique identifiers 6 to 8, and the node of the type “Country” has the unique identifier 9. Therefore, bitsets for all Person, Film and Country nodes can be represented respectively as follows:

[0115] Person node bitset: 1111100000000000

[0116] Film node bitset: 0000011100000000

[0117] Country node bitset: 0000000010000000 Identifiers: 1 2 3 4 5 6 7 8 9

[0118] These bitsets can be maintained and updated whenever new nodes are added to the graph database. For example, if a new Film node was added to the graph database, with a unique identifier 10, the value of the 10thbit in the Film bitset would be changed from “0” to “1”, and the value of the 10thbit in the Person and Country node bitsets would remain “0”.

[0119] Native graph storage of edges

[0120] Similar bitset representations can be used to natively store sets of edges of the graph database. In the present disclosure, bitsets are used to represent sets of edges in the graph database. This is achieved by generating bitsets wherein the value of a bit in the bitset depends on whether a corresponding edge is part of the set. For example, the value of bits in the bitset is set to “1” or “0” in dependence on whether a given edge is contained in a set. One way to achieve this is to assign unique identifiers to each edge in the graph database, such as monotonically increasing integer numbers, and setting the value of a bit in a given position in the bitset to “1” or “0” depending on whether the edge with the unique identifier corresponding to that position is or is not contained in the set.

[0121] In particular, the node adjacency lists are stored as follows::

[0122] • For each node, the set of "in" edges which point at that node as a target. This set of graph edges can be represented as a bitset as described above.

[0123] • For each node, the set of "out" edges which point from that node as a source. This set of graph edges can also be represented as a bitset as described above.

[0124] In addition, the graph database may include a collection of key-value pairs to map the graph edges to their source and target nodes. In particular, the graph database may include the following maps:

[0125] • For each edge, a map identifying its source node (that is, the node from which the edge starts)

[0126] • For each edge, a map identifying its target node (that is, the node at which the edge ends)

[0127] Using these bitsets and maps, it is possible to convert between a bitset representing a set of nodes to a corresponding bitset representing a set of associated edges . For example, these bitsets and maps can be used to obtain, from a bitset representing a set of nodes, a bitset representing the set of edges which point out from that set out nodes. The bitset of "in" edges for each node identifies the set of edges which point at that node as a target. For example, if a node is the target of edges with the unique identification numbers “1 ” and “2”, the bitset representing the “in” edges forthat node will have the first and second bits set to “1” and all other bits set to “0”.

[0128] The bitset of "out" edges for each node identifies the set of edges which point from that node as a source. For example, if a node is the source of edges with the unique identification numbers “3” and “4”, the bitset representing the “out” edges for that node will have the third and fourth bits set to “1” and all other bits set to “0”.

[0129] Native storage of edges - example

[0130] With reference to the exemplary graph database in Figure 2, the bitsets representing the “in” edges for each node are computed as:

[0131] Nodel: 000000000 / / No edges point to node 1

[0132] Node 2: 000000000 / / No edges point to node 2

[0133] Node 3: 000000000 / / No edges point to node 3

[0134] Node 4: 000000000 / / No edges point to node 4

[0135] Node 5: 000000000 / / No edges point to node 5

[0136] Node 6: 100100000 / / Edges 1 and 4 point to node 6

[0137] Node 7: 010010000 / / Edges 2 and 5 point to node 7

[0138] Node 8: 001001000 / / Edges 3 and 6 point to node 8

[0139] Node 9: 0 00000 111 / / Edges 7, 8 and 9 point to node 9

[0140] The bitsets representing the "out" edges for each node are:

[0141] Nodel: 1 10000000 / / Edges 1 and 2 point from node 1

[0142] Node 2: 001000000 / / Edge 3 points from node 2

[0143] Node 3: 000100000 / / Edge 4 points from node 3

[0144] Node 4: 000010000 / / Edge 5 points from node 4

[0145] Node 5: 000001000 / / Edge 6 points from node 5

[0146] Node 6: 000000100 / / Edge 7 points from node 6 Node 7: 000000010 / / Edge 8 points from node 7

[0147] Node 8: 000000001 / / Edge 9 points from node 8

[0148] Node 9: 000000000 / / No edges point from node 9

[0149] The maps identifying the source node for each edge are, as key-value pairs:

[0150] / / Node 1 is the source of edge 1

[0151] / / Node 1 is the source of edge 2

[0152] / / Node 2 is the source of edge 3

[0153] / / Node 3 is the source of edge 4

[0154] / / Node 4 is the source of edge 5

[0155] / / Node 5 is the source of edge 6

[0156] / / Node 6 is the source of edge 7

[0157] / / Node 7 is the source of edge 8

[0158] / / Node 8 is the source of edge 9

[0159] The maps identifying the target node for each edge are, as key-value pairs:

[0160] / / Node 6 is the target of edge 1

[0161] / / Node 7 is the target of edge 2

[0162] / / Node 8 is the target of edge 3

[0163] / / Node 6 is the target of edge 4

[0164] / / Node 7 is the target of edge 5

[0165] / / Node 8 is the target of edge 6

[0166] / / Node 9 is the target of edge 7

[0167] / / Node 9 is the target of edge 8

[0168] / / Node 9 is the target of edge 9

[0169] These bitsets and maps can be used during the process for querying data stored in the graph database as described in more detail below. Querying data

[0170] When querying data from a graph database, the structure of the query (typically written using the Cypher or GQL languages) takes the form of a pattern of nodes and edges. Therefore, the result of the query will itself be a pattern of graph nodes and graph edges which represent sub-graphs of the graph database matching the query pattern. The query may include certain criteria associated with any of the nodes or edges in the query which limit the query to graph nodes and edges satisfying those criteria. For example, the query may specify nodes / edges of a certain type or nodes / edges having a certain property. The output of a graph database query is one or more sub-graphs of the graph database representing each and every set of nodes and edges which matches the structure of the query and satisfies the criteria of the query.

[0171] Figure 3 shows a flowchart representing a method 300 for querying a graph database according to the present disclosure. The method 300 will be described with reference to the exemplary query pattern “p=(a:Person)-[e1 :knows]->(b:Person)-[e2:bornln]->(c:Country) RETURN p” discussed in the graph databases section above. Throughout the description of the querying method, references to “query nodes” and “query edges” are used to mean the nodes and edges specified in the query pattern - for example, “(a:Person)” is a query node of the query pattern above, and “[e1 :knows]” is a query edge of the pattern above. These query nodes and query edges are distinct from the “graph nodes” and “graph edges” which refer to the actual nodes and edges in the graph database.

[0172] In the first step 302, the query is received. The query may be received from a user input. Typically, the query may be written by a user in the Cypher / GQL language. Alternatively, the user may interact with a user interface having fields in which the user can enter node and / or edge criteria, and a query in Cypher / GQL can then be automatically generated based on the information entered by a user via the user interface.

[0173] In the second step 304, the query is segmented. Each segment of the query includes a first query node and a query second node connected by a query edge between the first and second query nodes. Therefore, the exemplary query set out above can be broken down into two segments:

[0174] • “(a:Person)-[e1 :knows]->(b:Person)” and

[0175] • “(b:Person)-[e2:bornln]->(c:Country)”.

[0176] The first segment comprises a first query node “(a:Person)”, a second query node “(b:Person)”, and a first query edge “[e1 :knows]” between the first and second query nodes. For the first segment each of the following bitsets is computed (or retrieved, if it has already been computed and stored):

[0177] 1 . A bitset representing graph nodes satisfying the criteria for the first query node (for the query set out above, in which the first query node is “(a:Person)” that would be a bitset representing all nodes of the type “Person”)

[0178] 2. A bitset representing graph edges satisfying the criteria for the query edge (for the query set out above, in which the first query node is “[e1 :knows]” that would be a bitset representing all edges of the type “knows”)

[0179] 3. A bitset representing graph nodes satisfying the criteria for the second query node (for the query set out above, in which the second query node is “(b:Person)” that would be a bitset representing all nodes of the type “Person”, which would be the same bitset as was computed or retrieved in point 1 above)

[0180] These three bitset computations or retrievals are labelled steps 306, 308 and 310 respectively in Figure 3, however in practice these computations / retrieval may be carried out in a different sequence or in parallel, rather than in the sequence shown in Figure 3.

[0181] In order to then execute bitwise operations between these three bitsets, it is necessary to convert the bitsets into like quantities (i.e., to convert the bitsets into sets which represent only edges, or only nodes). This is achieved by converting graph node bitsets to corresponding graph edge bitsets (step 312). This conversion is carried out using the bitsets of "in" and “out” edges for each node and / or the maps of “source” and “target” nodes for each edge as described above under the heading “Native graph storage of edges”. As used in this disclosure, references to “converting” a set of graph nodes to a set of graph edges are intended to mean determining a set of edges that are associated with a set of nodes (for example, obtaining the set of edges which point out from, or which point to, the set of nodes).

[0182] To convert a graph node bitset to a corresponding graph edge bitset, the adjacency lists for each node identified in the graph node bitset are retrieved. Then, the union of the computed / retrieved “in” and / or ’’out” graph edge bitsets is computed. The resultant bitset identifies the set of edges pointing into or out of, as the case may be, the nodes identified in the graph node bitset. In the example query set out above, the graph node bitset for “(a:Person)” may be converted to a bitset of edges pointing out from any Person nodes, because “(a:Person)” is the source query node in the query, and the graph node bitset for “(b:Person)” may be converted to a bitset of edges pointing into any Person nodes, because “(b:Person)” is the target query node in the query. Finally, once the bitsets for the query nodes and edges have been computed and, where necessary, converted into like quantities, the intersection of the bitsets is taken (step 314). The resultant bitset identifies the full set of edges that satisfy the criteria of the segment of the query.

[0183] When the graph node bitsets are converted into graph edge bitsets, three bitsets will be obtained as follows:

[0184] 1 . A bitset of all graph edges which point out from graph nodes that fulfil the criteria of the first query node (in the example above, this will be a bitset of all graph edges which point out from graph nodes of the type “Person”) - for reference, bitset “Ei”

[0185] 2. A bitset of all graph edges which fulfil the criteria of the query edge (in the example above, this will be a bitset of all graph edges of type “knows”) - for reference, bitset »l— 11 t2

[0186] 3. A bitset of all graph edges which point into graph nodes that fulfil the criteria of the second query node (in the example above, this will be a bitset of all graph edges which point into nodes of the type “Person”) - for reference, bitset “E3”

[0187] To find the set of edges satisfying all criteria of the first segment of the query, the intersection of each of these three bitsets is computed (that is, Ei D E3IT E3) to obtain an output bitset (E4) for the first segment of the query.

[0188] For a query consisting of only a single segment, the bitset (E4) resulting from step 314 is sufficient to determine the final results of the query by finding, using the node-edge maps, the set of nodes which are sources for the edges in E4and the set of nodes which are targets for the edges in E4; this then gives the sub-graphs (i.e., sets of graph nodes and edges) which match the criteria of the query segment.

[0189] For a query comprising multiple segments, it is necessary to proceed further by repeating the steps 306 to 314 in Figure 3 for each additional segment of the query. The onward procedure for a multi-segment query is set out in Figure 4.

[0190] Given that the second query node of the first segment becomes the first query node of the second segment (and so on), the search space can be reduced by carrying the bitset of graph nodes satisfying the criteria of the second query node of the first segment (as found when processing the first segment of the query) and using it as the graph node bitset for the first query node of the second segment (i.e., step 306 of processing the second segment). In this way, any graph nodes that were eliminated as candidates for the query node due to the constraints of the first segment will already be eliminated from consideration while processing the second segment, thereby reducing the search space. Otherwise, the steps 306 to 314 are repeated as described above for the second and subsequent segments of the query.

[0191] Accordingly, repeating the steps 306 to 314 for each segment of the query involves traversing the query pattern from a starting query node along adjacent query edges and query nodes in the pattern to a final query node in the pattern. Each time a segment of query nodes and / or query edges in the query pattern is visited during the traversal, the sets of graph nodes or graph edges associated with the graph nodes or graph edges which satisfy the criteria of the query nodes or query edges in the segment are identified, and the intersection of the sets is computed to obtain an output set for the segment.

[0192] It is possible that some of the nodes identified as satisfying the criteria of the first segment of the query do not satisfy the criteria of the second (or subsequent) segments of the query. For example, continuing with the exemplary query set out above (“p=(a:Person)-[e1 :knows]- >(b:Person)-[e2:bornln]->(c:Country) RETURN p;”), a graph node may satisfy the second query node of the first segment (“(b:Person)”) because it is a node of type “Person” and has an ”in” edge of type “knows” from another node of type “Person”. Therefore, that node will be identified in the bitset obtained while processing the first segment of the query. However, that node may not satisfy the criteria of the second segment of the query (for example, because it does not have an “out” edge of type “bornln”). To filter out such nodes or edges from the query results, once the query pattern has been fully traversed, descending from the starting query node to the final query node, the query pattern is then traversed again , but this time ascending from the final query node to the starting query node. When ascending the graph query, the output bitset resulting from processing the last segment of the query is propagated in step 320 back through the output bitsets obtained from processing earlier segments of the query to prune (i.e., remove) in step 322 any nodes and edges from the respective output bitsets which do not satisfy the criteria of subsequent segments of the query.

[0193] Referring again to the exemplary query above, this recursive traversal of the query pattern would result in the bitset representing graph nodes satisfying the query node “(b:Person)” being pruned to remove any nodes which do not satisfy criteria of the second segment of the query. Then, the bitset for the candidate graph edges for the query element “[e1 :knows]” is pruned to remove any edges which point only to nodes that were pruned from the “(b:Person)” bitset. Finally, the bitset for the candidate graph nodes for the query element “(a:Person)” is pruned to remove any nodes which had only “out” edges that were pruned from the “[e1 :knows]” bitset. As used here, the term “pruning” it intended to mean removing graph edges or graph nodes from a set by setting to “0” the bits which correspond to those graph edges or graph nodes. In the above example, the query pattern is traversed starting from the first segment appearing in the query (i.e., at the beginning of the query) and moving onwards to the last segment (i.e., at the end of the query). However, as an alternative, the querying method may instead begin by determining an optimal starting point for the query pattern traversal and the query pattern traversal may begin at that point. In one example, statistics about the graph database may be used to determine the optimal node at which to begin the query traversal. The optimal node may be the node that reduces the search space the most for the least (computational) cost. For example, for a query pattern which includes a query node which specifies a node with a particular property (such as a person with a specific name), it is likely that the number of graph nodes satisfying the criteria of that query node will be very small. Accordingly, it is most efficient to begin the query pattern traversal at this node and carry the reduced node / edge bitsets into subsequent segments of the query pattern. The statistics of the graph database may provide information of how many nodes / edges matching the criteria of a given element of a query pattern; for example, for query containing query nodes such as “(b:Person)” and “(c:Country)”, the statistics for the number of “Person” nodes compared to the number of “Country” nodes in the graph database may be used to determine which node would be a preferable starting point in the query pattern.

[0194] To avoid duplicating computations when recursively traversing the query pattern, the method may involve checking, when descending or ascending along the query pattern, whether a query edge has already been visited in that descent or ascent. If the query edge has not been visited already in the traversal, the relevant bitsets and bitset operations are computed forthat segment. If the query edge has already been visited in the query pattern traversal, the segment is skipped and the traversal moves to the next segment in the query pattern until all query nodes / edges in the query pattern have been visited. In this way, each query edge is only visited once during the descent of the query pattern, and once again during the ascent of the query pattern.

[0195] Querying data - example

[0196] Applying this querying method to the exemplary graph database shown in Figure 2, a user may wish to find, for example, all films starring Tom Hanks and directed by Steven Spielberg. A corresponding Cypher query would reading “MATCH p=(actor:Person {name:"Tom Hanks"})-[s:starredln]->(f:Film)<-[d:directed]-(director:Person {name:"Steven Spielberg"}) RETURN p;” would be received (step 302).

[0197] This query can be segmented (step 304) into two segments as follows:

[0198] 1. (actor:Person {name:"Tom Hanks"})-[s:starredln]->(f:Film) 2. (f:Film)<-[d:directed]-(director:Person {name:"Steven Spielberg"})

[0199] Starting from the first segment, the query pattern is traversed, descending from the first query node (actor:Person {name:"Tom Hanks"}) to the last query node (directorperson {name:"Steven Spielberg"}). the bitset representing graph nodes satisfying the criteria for the first query node of the first segment is obtained (step 306). In the exemplary graph database in Figure 2, the only graph node of type “Person” with the name property “Tom Hanks” is node 1. Accordingly, the bitset for the first query node of the first segment will have its first bit set to “1” with all other bits set to “0”. This bitset can be represented in shorthand as <1>.

[0200] Next, the bitset for edge nodes satisfying the criteria for the query edge of the first segment is obtained (step 308). In the exemplary graph database in Figure 2, the graph edges of type “starredln” are nodes 1 , 2, and 3. Accordingly, the bitset forthe query edge of the first segment will can be represented in shorthand as <1 , 2, 3> (i.e., a bitset with “1”s in the first, second, and third bits, with “0”s elsewhere).

[0201] Next, the bitset for graph nodes satisfying the criteria for the second query node of the first segment is obtained (step 310). In the exemplary graph database in Figure 2, the graph edges of type “Film” are nodes 6, 7, and 8. Accordingly, the bitset for the query edge of the first segment will can be represented in shorthand as <6, 7, 8> (i.e., a bitset with “1”s in the sixth, seventh, and eighth bits, with “0”s elsewhere).

[0202] The graph node bitsets must be converted to graph edge bitsets (step 312). In this example, the graph node bitsets (computed in steps 306 and 310) will be converted to graph edge bitsets; the graph edge bitset computed in step 308 does not need to be converted as it already represents a set of edges.

[0203] Taking the bitset computed at step 306, the node with identifier 1 acts as the source node for edges with identifiers 1 and 2. Therefore, the corresponding graph edge bitset will be <1 , 2>. Taking the bitset computed at step 310, the nodes with identifiers 6, 7 and 8 act as target nodes for edges 1 , 2, 3, 4, 5 and 6. Therefore, the corresponding graph edge bitset will be <1 , 2, 3, 4, 5, 6>.

[0204] To summarise, the three edge bitsets for the first query segment are as follows:

[0205] Ei = <1 , 2>

[0206] E2= <1 , 2, 3> E3= <1 , 2, 3, 4, 5, 6>

[0207] Taking the intersection (step 314) of these gives a first output bitset of <1 , 2> for the first query segment.

[0208] Accordingly, there are two edges (with identifiers 1 and 2) which satisfy the criteria of the first segment of the graph. Using the node-edge maps, we see that node 1 is the source of edges 1 and 2, and nodes 6 and 7 are the targets. Accordingly, after processing the first segment of the query, there are two sub-graphs which satisfy the criteria of the first segment of the query, and are candidates for satisfying the criteria of the whole query pattern:

[0209] • Tom Hanks - starredln - Saving Private Ryan

[0210] • Tom Hanks - starredln - Forrest Gump

[0211] As this is a multi-segment query, these steps are repeated by traversing the query onwards to the second segment. The graph node bitset for the second query node in the first segment (that is, <6, 7, 8>) is carried forward and used as the bitset for the first query node of the second segment (step 306).

[0212] Next, the bitset for edge nodes satisfying the criteria for the query edge of the second segment is obtained (step 308). In the exemplary graph database in Figure 2, the graph edges of type “directed” are nodes 4, 5, and 6. Accordingly, the bitset for the query edge of the first segment will can be represented in shorthand as <4, 5, 6>.

[0213] Finally, the bitset for graph nodes satisfying the criteria for the second query node of the second segment is obtained (step 310). In the exemplary graph database in Figure 2, the only graph node of type “Person” with the name property “Steven Spielberg” is graph node 3. Accordingly, the bitset for the second query node of the second segment will be <3>.

[0214] Again, the graph node bitsets are converted to graph edge bitsets (step 312). Taking the first graph node bitset of the second segment, as set out above (E3for the first segment) is <1 , 2, 3, 4, 5, 6>. Taking the second graph node bitset of the second segment, the node 3 acts as a source node for edge 4 only. Therefore, the graph edge bitset will be <4>. To summarise, the three edge bitsets for the second segment are as follows:

[0215] Ei = <1 , 2, 3, 4, 5, 6>

[0216] E2= <4, 5, 6>

[0217] E3= <4> Taking the intersection (step 316) of these gives a second output bitset <4> for the second query segment.

[0218] Accordingly, there is only a single edge (with identifier 4) which satisfies the criteria of the second segment of the graph. Using the node-edge maps, we see that node 3 is the source and node 6 is the target for edge 4. Accordingly, after processing the first segment of the query, there is only one sub-graph which satisfies the criteria of the second segment of the query:

[0219] • Saving Private Ryan <- directed - Steven Spielberg

[0220] Lastly, the result of processing the second segment of the query must be propagated back through the query pattern to prune the output from processing the first segment of the query. This is achieved by traversing the query again, this time ascending from the last query segment to the first query segment. In this case, as the query node “(f:Film)” is common to both the first and second segments of the query, the bitset of candidate nodes obtained for the “(f: Film)” query node in the first segment can be pruned to remove any graph nodes which are not targets of edge node 4, which is the only edge satisfying the criteria of the second segment of the query. This results in removing node 7 and edge 2 from the query results for the first segment. This leaves just one sub-graph which satisfies the global criteria of the query:

[0221] • Tom Hanks - starredln - Saving Private Ryan <- directed - Steven Spielberg This single sub-graph is provided to the user as the result of the query.

[0222] Process flow

[0223] Figure 5 is a diagram showing the overall process flow of the native graph data storage and querying methods set out in the present disclosure.

[0224] In the data storage phase, bitsets representing nodes and edges in a graph database are generated. These data structures may represent sets of nodes or edges of a particular type or sets of nodes or edges with a particular property. Generating these data structures in advance, and maintaining the data structures when new nodes and edges are added to the database, speeds up subsequent querying of the data because the relevant bitsets can simply be retrieved from memory rather than generated when required.

[0225] Querying data in the graph database involves a reduction phase and a projection phase. In the reduction phase the query pattern is recursively traversed (as set out in steps 306 to 322 above) and graph node and graph edge bitsets, which match the criteria of each element of the query, are generated or retrieved. Where necessary, the bitsets are converted into like quantities. In this example, the bitsets are converted to graph edge bitsets. The bitset intersection operations required to find the reduced bitsets which satisfy all elements of a query segment are carried out by a processor or multiple processors. Preferably, the processors are graphics processing units (GPUs) as these processors are optimised for handling bitset operations as the bitsets can be implemented as GPU Textures. However, even on standard central processing unit (CPU) the computational operations involved in the query method of the present disclosure are extremely fast.

[0226] The bitset operations required during the reduction phase are “embarrassingly parallel”, meaning that little or no effort or coordination is needed to split the operations into a number of parallel tasks which can be executed by parallel processors. For example, a large intersection operation could be broken down into a series of smaller intersection operations that could be parallelised (e.g., by representing the smaller bitsets as bitmap textures and processing the intersection operations using parallel GPUs). Alternatively or additionally, each bitset intersection operation in the reduction phase could be computed on a different processor independently from one another.

[0227] If necessary, the results of the reduction phase for the final segment in the query pattern are propagated back through the query pattern to prune the results of the reduction phase for preceding segments in the query pattern (to remove any nodes or edges which do not meet the global criteria of the query).

[0228] Finally, in the projection phase, the full set of query results is obtained from reduced bitsets (in Figure 5, a reduced set of edges), using the node-edge maps to fine the source and target nodes of each edge, thereby obtaining the final sub-graphs which satisfy the criteria of the query, and these sub-graphs are output.

[0229] It is important to note that although the above description refers to using binary bitsets to represent the sets of graph nodes and graph edges, and using bitwise intersection operations, this is just a particularly advantageous way of representing the sets of graph nodes and graph edges. The querying method of this disclosure could be implemented with the sets of graph nodes and graph edges represented in a different way, and with different intersection operations.

[0230] Each feature disclosed in the description, and (where appropriate) the claims and drawings may be provided independently or in any appropriate combination. Reference numerals appearing in the claims are by way of illustration only and shall have no limiting effect on the scope of the claims.

Claims

- 25 -Claims1 . A computer implemented method of natively storing a set of nodes and / or edges in a graph database, comprising generating a bitset representing a set of graph nodes or graph edges, and setting the value of a bit in the bitset in dependence on whether a corresponding node and / or edge is part of the set.

2. A method according to Claim 1 , wherein the nodes and / or edges in the graph database each have an associated unique identifier.

3. A method according to Claim 2, comprising setting the value of a bit in the bitset in dependence on whether a node and / or edge having a unique identifier corresponding to that bit is part of the set.

4. A method according to Claim 2 or 3, comprising setting the value of a bit in the bitset in dependence on whether a node and / or edge having a unique identifier corresponding to the position of that bit in the bitset is part of the set.

5. A method according to any of Claims 2 to 4, wherein the unique identifiers for the nodes and / or edges in the graph database are integers, preferably monotonically increasing integers.

6. A method according to any preceding claim, comprising, for a node in the graph database, generating a bitset representing the set of edges which point at that node as a target.

7. A method according to any preceding claim, comprising, for a node in the graph database, generating a bitset representing the set of edges which point from that node as a source.

8. A method according to any preceding claim, comprising, for an edge in the graph database, generating a bitset representing the source node(s) for that edge.

9. A method according to any preceding claim, comprising, for an edge in the graph database, generating a bitset representing the target node(s) for that edge.

10. A method according to any preceding claim, wherein the bitsets are formed of words having a length that is selected to suit hardware used to perform operations on the bitsets, preferably 64-bit or 128-bit words.

11. A computer implemented method of querying data in a graph database, the graph database comprising graph nodes connected by graph edges, the method comprising: receiving a query, the query comprising a first query node, a first query edge, and a second query node arranged in a pattern; for the first query node, identifying a first set of graph nodes or graph edges associated with the graph nodes which satisfy criteria of the first query node; for the first query edge, identifying a second set of graph nodes or graph edges associated with the graph edges which satisfy criteria of the first query edge; for the second query node, identifying a third set of graph nodes or graph edges associated with the graph nodes which satisfy criteria of the second query node; and computing the intersection of the first, second and third sets of graph nodes or graph edges to obtain one or more first output sets of graph nodes or graph edges.

12. A method according to Claim 11 , wherein the query comprises a second query edge, and the method further comprises: for the second query edge, identifying a fourth set of graph nodes or graph edges associated with the graph edges which satisfy criteria of the second query edge; and computing the intersection of a set associated with the first output set and the fourth set of graph nodes or graph edges to obtain a second output set of graph nodes and / or graph edges.

13. A method according to Claim 12, wherein the query comprises a third query node, and the method further comprises: for the third query node, identifying a fifth set of graph nodes or graph edges associated with the graph nodes which satisfy criteria of the third query node; and computing the intersection of the set associated with the first output set the fourth and fifth sets of graph nodes or graph edges to obtain the second output set of graph nodes and / or graph edges.

14. A method according to Claim 12 or 13, comprising removing at least one graph node or graph edge from the first output set of graph nodes or graph edges based on the second output set of graph nodes or graph edges.

15. A method according to any of Claims 11 to 14, wherein the first query node and / or the first query edge are selected from among multiple query nodes and / or multiple query edges in the query based on statistics associated with the query nodes and / or query edges.

16. A method according to any of Claims 11 to 15, wherein the first and / or third set of graph nodes or graph edges comprises a set of graph edges which point to graph nodes which satisfy the criteria of the first and / or second query nodes respectively, and / or a set of graph edges which point from graph nodes which satisfy the criteria of the first and / or second query node respectively.

17. A method according to any of Claims 11 to 16, wherein the second set of graph nodes or graph edges comprises a set of graph nodes which are sources for graph edges which satisfy the criteria of the first query edge and / or a set of graph nodes which are targets for graph edges which satisfy the criteria of the first query edge.

18. A method according to any of Claims 11 to 17, comprising: traversing the query pattern from a first query segment to a last query segment, each segment comprising at least one query node and at least one query edge; for each segment, identifying sets of graph nodes or graph edges associated with the graph nodes or graph edges which satisfy the criteria of the query nodes or query edges in the segment; and computing the intersection of the sets to obtain an output set for the segment.

19. A method according to Claim 18, comprising: traversing the query pattern from the last query segment to the first query segment; and based on the output set obtained from one segment, removing at least one graph node or graph edge from the output sets for obtained from at least one other segment.

20. A method according to any of Claims 11 to 19, comprising obtaining, from the output set(s) and node-edge maps, at least one output sub-graph of the graph database.

21. A method according to any of Claims 11 to 20, wherein the sets of graph nodes or graph edges are represented by bitsets wherein the value of a bit in the bitset depends on whether a corresponding graph node and / or graph edge is part of the set.

22. A method according to any of Claims 11 to 21 , wherein computing the intersection comprises parallelising the intersection computation across multiple processors, preferably across multiple graphics processing units (GPUs).

23. A computer implemented method of querying data in a graph database, the graph database comprising nodes and / or edges natively stored according to the method of any of Claims 1 to 10, the method of querying data comprising: retrieving a bitset representing a set of graph nodes or graph edges; and retrieving, from the graph database, data associated with the graph nodes or graph edges represented in the bitset.

24. A computer program product comprising software code adapted, when executed on one or more processors, to carry out the method of any preceding claim.

25. A graph database comprising nodes and / or edges natively stored according to the method of any of Claims 1 to 10.

Images