Parallel and efficient techniques for building and maintaining graph indexes based on main memory CSRs in RDBMS

Abstract

This paper describes a technique for concurrently populating entries in compressed sparse row (CSR) encodings of heterogeneous graph edge types. In an embodiment, the computer obtains a mapping from a relational schema to a graph data model. The relational schema defines a vertex table corresponding to vertex types in the graph data model, and an edge table corresponding to edge types in the graph data model. Each edge type is associated with a source vertex type and a destination vertex type. For each vertex type, a persistent identifier sequence of vertices is obtained. Based on the mapping, for each edge type's CSR representation, a source array is populated, sorted for vertices identical to the persistent identifier sequence of the source vertex type, based on the edge counts originating from the edge type of the source vertex type. For the CSR, the computer populates a destination array in parallel based on the mapping, the destination array containing canonical offsets as sequence positions within the persistent identifier sequence of vertices.

Description

Technical Field

[0001] This invention relates to loading heterogeneous graphs from tables in a relational database into memory. This paper describes a technique for concurrently constructing main-memory representations of property graphs (such as one or more compressed sparse row (CSR) encodings of the graph's vertices and edges). Background Technology

[0002] The demand for graph analysis of data residing in relational database management systems (RDBMS) is growing. Known solutions require constructing graphs outside the RDBMS storing the data of interest. One solution requires constructing the graph within a dedicated graph analysis engine. Another solution requires migrating the data to a graph database. These solutions are undesirable because they significantly increase the complexity of data management within an enterprise and result in substantial loading / data transfer costs to external engines.

[0003] Using existing RDBMS technologies, direct graph analysis of relational tables (such as graph pattern matching queries or graph algorithm execution, or a combination of both) performs significantly worse than the performance offered by dedicated graph engines, especially for algorithms of interest such as PageRank. Typically, RDBMS implements graph algorithms as a series of table joins, which are slow and require tedious materialization of transient intermediate results.

[0004] Compared to relational queries (such as standard query language (SQL)), some queries (such as pathfinding queries) are better expressed as graph queries. For example, topology queries can be better expressed as regular expressions or context-free expressions that are not easily expressed as SQL. RDBMSs that only expect SQL and / or tabular queries typically lack data structures dedicated to graph analysis. In these respects, existing RDBMSs may be too slow for graph analysis. Attached Figure Description

[0005] In the picture:

[0006] Figure 1 It is a block diagram depicting an example computer that uses parallelism to accelerate the filling of compressed sparse line (CSR) codes for logic graphs;

[0007] Figure 2It is a flowchart depicting an example process of using parallelism to accelerate the filling of CSR codes for a logic graph;

[0008] Figure 3 This is a flowchart depicting an example process of filling the destination array of CSR entries in parallel;

[0009] Figure 4 It is a flowchart describing an example multithreaded process that populates a lookup table in parallel batches for vertex persistent identifiers;

[0010] Figure 5 This is a flowchart describing an example multithreaded process that populates a lookup table in parallel batches for edge persistent identifiers;

[0011] Figure 6 This is a block diagram illustrating an embodiment of a computer system on which the present invention can be implemented;

[0012] Figure 7 This is a block diagram illustrating the basic software system that can be used to control the operation of a computing system. Detailed Implementation

[0013] In the following description, numerous specific details are set forth for purposes of explanation in order to provide a thorough understanding of the invention. However, it will be clear that the invention can be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form to avoid unnecessarily obscuring the invention.

[0014] Overview

[0015] This paper presents a technique for concurrently populating entries in a memory aggregation of edges of logical graphs (such as Compressed Sparse Row (CSR) encoding). Graph analytics support may require efficient in-memory graph indices to provide competitive performance compared to dedicated main-memory graph analytics engines. CSR encoding is a graph topology index that makes navigation through graph elements fast, accelerating workloads (such as graph pattern matching queries) and computationally or navigationally intensive graph algorithms (such as PageRank). This paper presents methods for efficiently constructing in-memory indexes for graphs defined on existing relational tables, which can be seamlessly integrated with the in-memory storage features provided by relational database management systems (RDBMS).

[0016] This article explains how to efficiently construct a main-memory representation of a graph index that utilizes CSR representation and seamlessly integrates with the in-memory columnar representation of relational database tables that contribute to the graph content. The solution presented in this article addresses the main challenges:

[0017] • Supports CSRs with different corresponding graph element types. This feature provides users with maximum expressive power based on the types and normalization of legacy data that are familiar to them.

[0018] • Heterogeneous extended topology support. This feature allows users to define graphs of any shape and any mixture of graph element types.

[0019] • Performance. CSRs can be the most efficient data structure for navigating relationships within a graph. The challenge of graph analysis performance is twofold: efficiently constructing CSRs from relational / tabular data, and quickly accessing the graph topology through CSRs.

[0020] • RDBMS Integration. CSR population (and graph model) can be seamlessly integrated with legacy, standard, and / or optimized features of modern RDBMS. This article identifies suitable features that can be utilized, including how to perform CSR creation, maintenance, and use within an RDBMS.

[0021] This paper presents maintenance methods, including how to efficiently maintain a catalog of heterogeneous graph representations based on main memory CSRs in an RDBMS, and how to use it on demand to represent one or more user-defined attribute graphs. A generalized approach to heterogeneous graph data modeling is presented to enrich graphs in terms of type, context, and aggregation, making them comparable to graphs in relational databases. The graph data model in this paper is defined on many relation tables (not just two) that act as containers for graph vertices or edges. This addresses both the challenges of heterogeneity and extended topology.

[0022] No changes to the legacy database schema are required. The techniques described in this article allow users to define graphs and achieve in-memory speed without altering their schema or table content. Supplementary tables are not needed. The legacy schema functions as is.

[0023] The techniques presented in this paper provide direct and seamless access to the RDBMS main memory through some or all of the memory management provided by the RDBMS. The memory interface presented in this paper integrates seamlessly with existing and well-optimized mechanisms provided by modern RDBMS. This paper presents a novel relational table pseudocolumn to provide queryable, non-physical vertex / edge identifiers that help the RDBMS efficiently construct CSRs with negligible memory footprint for the table's main memory representation.

[0024] This paper presents graph index sharing. For example, the system described in this paper can maintain a dictionary that catalogs some or all instances of a CSR. CSRs can be shared transparently and automatically across multiple (fully or partially) overlapping graphs defined in a database. This paper also presents a memory storage format that can reduce both memory footprint and the time required to construct a main memory representation of a graph, such as when multiple graphs overlap in terms of the edge and vertex tables they use.

[0025] It presents both coarse-grained and fine-grained parallel filling of memory aggregation and indexing. Parallel construction of CSRs can be accelerated through chunking. This feature can be seamlessly integrated with any existing engine for main memory columnar representation.

[0026] This paper describes an in-memory graph index that integrates the CSR representation of a graph with the main memory columnar representation of a database. In some embodiments, the construction of the main memory representation for a specific graph may be an optional feature. Database administrators and advanced users can control which graphs can consume main memory resources for graph processing acceleration.

[0027] The construction of the main-memory representation of a graph can be performed concurrently with user requests, especially requests to execute graph algorithms or graph pattern matching queries. User requests are not blocked by graph index building operations. This solution allows the system to further address performance challenges by allowing users to trade memory for performance improvements without service interruption. While some embodiments are applicable to main-memory columnar databases, some embodiments support more complex scenarios such as dual-storage systems that combine persistent row storage with optional columnar in-memory storage (such as with Oracle RDBMS).

[0028] In this embodiment, the computer obtains a mapping from a relational schema to a graph data model. The relational schema is defined as: a) a vertex table corresponding to a corresponding vertex type in the graph data model, and b) an edge table corresponding to a corresponding edge type in the graph data model. Each edge type is associated with a corresponding source vertex type and a corresponding destination vertex type.

[0029] For each vertex type, a sequence of persistent identifiers for vertices of that vertex type is obtained. Based on the mapping, and for the corresponding CSR representation for each edge type, the computer populates a source array, sorted for vertices that are the same as the persistent identifier sequence of the source vertex type for the edge type, based on the edge count of the edge type originating from the vertices of that source vertex type. For the CSR representation of each edge type, the computer populates a destination array in parallel based on the mapping, containing canonical offsets of the sequence positions within the persistent identifier sequence of vertices of the target vertex type.

[0030] 1.0 Sample Computer

[0031] Figure 1 This is a block diagram depicting an example computer 100 in an embodiment. Computer 100 uses parallelism to accelerate the filling of Compressed Sparse Line (CSR) encoding 110 in logic diagram 105. Computer 100 may be at least one rack server, such as a blade, personal computer, mainframe, virtual computer, or other computing device. When computer 100 includes multiple computers, these computers are interconnected via a communication network.

[0032] Figure 105 is a directed graph containing vertices AD and directed edges UZ connecting vertices AD, as shown. Figure 105 is an example of graph data model 130, which contains vertex types 141-142 and edge types 151-152, as shown in the element type column of graph data model 130. The display column of graph data model 130 is an illustrative legend of the graph instance (such as 105). For example, and according to the display column, edge Y is shown as a dashed line, indicating that edge Y is an instance of edge type 152.

[0033] Graph data model 130 can define the types and attributes (not shown) of vertices and edges. For example, vertex type 141 can have age and color attributes, some, none, or all of these attributes can also be attributes of vertex type 142. According to graph data model 130, each edge type has a corresponding source vertex type and a target vertex type, one, none, or both of these types may be the same as other edge types. For example, edge types 151-152 both have the same source vertex type 141 but have different corresponding target vertex types 141-142.

[0034] For edge type 151, the source vertex type is also the destination vertex type, which facilitates self-directed edges, such as X, that originate from and terminate at the same vertex. A first vertex can be redundantly connected to the same second vertex via multiple edges of the same or different edge types along the same or opposite directions. For example, edges U and X redundantly connect vertex A to itself.

[0035] In operation, Figure 105 is loaded as individual columnar vectors into volatile or non-volatile memory for analysis. The contents of the vectors are isomorphic with respect to the element data type, although different vectors may have different content data types. For example, a vector can store the values ​​of the same attributes for vertices or edges of the same type. A vector can store system attributes of graph elements, such as the identifier of a vertex of type 141. A vector can store application attributes of graph elements, such as the shipping status of a vertex of type 141.

[0036] While elements of the same vector are stored contiguously in memory, multiple vectors of different corresponding attributes of the same graph element type do not need to be adjacent in memory. Multiple vectors of different corresponding attributes of the same graph element type should have the same number of elements, and the contents of these vectors should be ordered in the same way. For example, for vertex type 141, the color or age of vertex A should appear at the same offset in every vector of the corresponding color and age attribute vectors. This offset can be operated as a canonical offset to access all attributes of the same vertex or edge. The canonical offset may also be referred to herein as an internal identifier, a volatile identifier, or an in-memory graph topology identifier (IMGTID).

[0037] As used herein, depending on the context, an in-memory array for a graph element type can be a single attribute vector or a logical aggregation of multiple distinct attribute vectors that accept the canonical offset of that graph element type as their offset. Each graph element type has its own sequence of zero-based, incrementing canonical offset values. Computers should be careful not to confuse canonical offset values ​​of different graph element types, even if such offsets are syntactically interchangeable. Canonical offsets are not semantically interchangeable.

[0038] A canonical offset uniquely identifies a vertex or edge within a vertex or edge type. Canonical offsets are not globally unique. Vertices and / or edges of different types may unintentionally share the same canonical offset. For example, zero might be the same canonical offset for both vertices A and D, which have different vertex types.

[0039] In this embodiment, the uniqueness of the canonical offset is guaranteed to apply only to the same graph instance. If the graph data model 130 describes multiple graph instances residing simultaneously in memory, each graph instance has its own set of vertex and edge arrays. For example, regardless of whether two graph instances share the same graph data model 130, if these two graph instances share vertex type 141, then for the same vertex type 141, there are two separate vertex arrays with separate attribute vectors. Therefore, the canonical offsets of vertices of the same vertex type 141 in two graph instances should not be confused.

[0040] In this embodiment, graph instances may partially overlap to share one or more vertices and / or one or more edges. Even for graph instances that do not share metadata 120, 130, and / or 160, graph instances may share some CSRs, vectors, or arrays when one or more vertex types and / or one or more edge types are shared. For example, such aggregation and / or indexing structures may store unions of two graph instances for one, some, or all graph element types. In this embodiment, only metadata 120, 130, and / or 160 may be shared, but the graph instance content may not be shared.

[0041] Loading any or every graph element type into memory creates at least one attribute vector for each graph element type. Therefore, each vertex type and edge type has a non-empty set of logical attribute vectors. For vertex types, this set of logical vectors is referred to herein as the vertex array, which is logically tabular. For edge types, this set of logical vectors is referred to herein as the edge array, which is logically tabular.

[0042] Therefore, vertex types 141-142 and edge types 151-152 each have a corresponding vertex array or edge array with attribute vectors. In this document, all internal identifiers of graph elements in memory are canonical offsets to the vertex array or edge array of the corresponding graph element type. Each graph element type has its own zero-based, dense, ascending, and continuous sequence of non-negative integer values, which is valid when graph 105 is loaded into memory and until graph 105 is evicted from and / or reloaded into memory, as explained later herein.

[0043] Some attribute vectors (one or more) in an array of graph element types can store canonical offsets of another graph element type for cross-referencing. For example, an edge array can have attribute vectors that store the canonical offsets of vertices of the target vertex type for that edge type. Thus, the various graph element arrays can be associated with each other, which is sufficient to encode the entire topology of Figure 105.

[0044] Figure 105 is loaded from a relational database having a relational schema 160 (which defines vertex tables 171-172 and edge tables 181-182). Relational schema 160 defines the persistent format of the data in Figure 105, and graph data model 130 defines the analysis format suitable for graph analysis in memory. For example, each row of vertex table 171 can be a persistent representation of the corresponding vertex of vertex type 141. For example, vertex A can be stored as a row in vertex table 171, and vertex D can be stored in vertex table 172.

[0045] Mapping 120 is more or less a data binding between graph data model 130 and relation schema 160. Mapping 120 can be bidirectional to facilitate data reformatting during loading or persistence. In an embodiment, rows of mapping 120 are stored as rows in a mapping table (such as relation schema 160 or different schemas and / or databases). In an embodiment, mapping 120 is alternatively persisted to a separate data file or interactively entered during operation.

[0046] Although not shown, mapping 120 can contain bindings that are finer or coarser than a one-to-one mapping from table to vertex type. For example, mapping 120 can contain query predicates that can selectively bind rows of a vertex table to different corresponding vertex types based on the contents of the vertex table rows. Similarly, mapping 120 can contain query unions or query joins that can bind vertex types to multiple vertex tables.

[0047] The semantics of mappings (such as 120) provide flexibility to facilitate various scenarios. For example, multiple database instances can share the same relation schema 160 but each database instance has different content in the relation tables, and the same graph data model 130 and mapping 120 can be used to generate separate graph instances for each database instance. Different mappings (such as 120) can each map the same relation schema 160 to different corresponding graph data models. Different mappings (such as 120) can each map different corresponding relation schemas to the same graph data model.

[0048] Mapping 120 provides flexibility for various structural normalization, renormalization, or denormalization scenarios. For example, each vertex table row can be mapped to a vertex, and each edge table row can be mapped to an edge. The edge table may have foreign keys from the vertex table, and vice versa. These and the following mapping details (such as which table columns are primary or foreign keys and how these keys are used and how they are associated with graph element types) are specified in Mapping 120.

[0049] The polarity of table relationships can vary. For example, an edge table connecting two vertex tables might have a foreign key in one vertex table, while the other vertex table might have a foreign key in the edge table. An edge table can be an associative table, having two foreign keys corresponding to the two connected vertex tables. An edge table might have no foreign keys, such as when both connected tables have a foreign key in the edge table. An edge type doesn't need to have any edge tables, such as when one vertex table has a foreign key in another vertex table.

[0050] There may be some overloading of table rows, such that mapping 120 can map the same row of the same vertex table to multiple vertex types. For example, the same row may have two columns with different correspondence foreign keys for different correspondence relations that map to different correspondence edge types with different correspondence source vertex types and / or different correspondence destination vertex types.

[0051] Various embodiments of mapping 120 may contain various kinds of binding tuples, such as any of the following:

[0052] • (Relationship table, graph element type)

[0053] • (Source vertex type, edge type, target vertex type)

[0054] • (Source vertex table, edge table, target vertex table)

[0055] • (Source primary key, source foreign key, target primary key, target foreign key)

[0056] Implementations can be modified to partially or completely combine these types of tuples to implement other types of tuples.

[0057] Among the many approaches presented above, there is ample flexibility to allow mapping 120 to be reused relative to different database instances (such as the January sales database and the February sales database), and different mappings can: a) adapt different corresponding relation schemas to the same graph data model, and / or b) adapt different corresponding graph data models to the same relation schema. For example, two different mappings can alternatively map the same edge table to different corresponding edge types, which differ only in direction in different corresponding graph data models. For example, two edge types can connect the same two vertex types, such that one edge type uses a vertex type as the source vertex type, and the other edge type alternatively uses the same vertex type as the target vertex type. Therefore, foreign key polarity and edge type direction can be related or unrelated.

[0058] This adaptability facilitates integration with legacy databases without interfering with their legacy schemas, thereby enabling future validation of legacy schemas and content. Consequently, it promotes the reuse and / or recycling of mappings, relational schemas, graph data models, and / or database content.

[0059] Mapping 120 is metadata that does not require providing the actual content of any specific graph instance (such as 105) for analysis. The analytical representation of Figure 105 is based on Compressed Sparse Row (CSR) aggregation (such as 110) for topological encoding in memory such as volatile dynamic random access memory (DRAM). As shown, CSR 110 only encodes edges of edge type 151. Other edge types may each have their own separate CSR.

[0060] CSR 110 contains arrays 190 and 195, which, although presented in tabular form, are integer vectors of corresponding individual columns, the actual contents of which are shown in bold. Columns in CSR 110 that are not shown in bold are implicit columns, which may be descriptive and are not actually stored.

[0061] The vertices and edges of Figure 105 are topologically encoded as CSRs, such as 110 for edge type 151, as shown below. Each edge type has its own CSR, which has its own source array, such as source array 190. Each row of source array 190 represents a different vertex of vertex type 141 (which is the source vertex type of edge type 151). Each edge type has its own edge array, such as destination array 195 for edge type 151. Each row of destination array 195 represents a different edge of edge type 151.

[0062] Each edge type has its own CSR, such as CSR 110 for edge type 151. Although multiple edge types 151-152 share the same source vertex type 141, the corresponding CSRs for edge types 151-152 have their own corresponding source arrays.

[0063] Source array 190 contains an edge position vector that contains the offsets of rows in destination array 195. The values ​​in the edge position vector of source array 190 are monotonically increasing to indicate the starting position of a subsequence of rows in destination array 195 representing edges of edge type 151 (which originate from vertices of a given row in source array 190). For example, in source array 190, vertex A generates edges of edge type 151, which are represented as consecutive corresponding rows starting from row 0 of destination array 195. Each value in the edge position vector of source array 190 can be calculated by adding the count of edges of edge type 151 originating from the previous vertex in the previous row of source array 190 to the previous value.

[0064] For example, vertex A generates four edges UX of edge type 151, which are represented by rows 0-3 of the destination array 195. Therefore, for vertex B, 0+4=4 is the value in the edge position vector of the source array 190. Similarly, vertex B does not generate edges, so for vertex C, 4+0=4 is the value in the edge position vector of the source array 190. In this embodiment, the last entry in the edge position vector of the source array 190 contains the count of edges of edge type 151, which is also the count of rows in the destination array 195.

[0065] Each edge row of the destination array 195 indicates an offset of a row in the vertex position vector within the vertex array of the target vertex type 141, in which case the vertex array of the target vertex type 141 may be the source array 190 or include the source array 190, as described below. For example, the vertex position vector of the destination array 195 indicates that edge V terminates at a vertex (vertex B) in row 1 of the source array 190.

[0066] By using only the edge position vectors of the source array 190, the computer 100 can detect that vertex A generates four edges of edge type 151 by subtracting adjacent values. By using the destination array 195 after using the source array 190, the computer 100 can also detect that these four edges terminate at vertex AC. With a separate CSR for each edge type, the entire topology of Figure 105 can be densely encoded and traversed quickly.

[0067] Arrays 190 and 195 are both represented as columns or vectors with vertex and edge positions. All these columns / vectors contain canonical offsets for the graph elements, which are specific to a given graph element type for a given column or vector. In source array 190, the vertex position column contains canonical offsets for vertex type 141, and the edge position vector contains canonical offsets for edge type 151.

[0068] In destination array 195, the edge position column contains the canonical offset for edge type 151, and the vertex position vector contains the canonical offset for vertex type 141. The edge position vectors and columns of the corresponding arrays 190 and 195 in the same CSR 110 should be for the same edge type. The vertex position columns and vectors of the corresponding arrays 190 and 195 in the same CSR 110 may or may not be for the same vertex type, depending on whether the source vertex type and the destination vertex type of edge type 151 are the same.

[0069] Although arrays 190 and 195 are shown as contents of CSR 110, in some embodiments, these arrays may logically also be vertical slices of the graph element arrays. For example, in an embodiment, source array 190 may be a column subset of the vertex array of vertex type 141. In any case, source array 190 and the vertex array of vertex type 141 have the same number and order of vertices.

[0070] Edge types 151-152 have separate CSRs, and these separate CSRs have separate source arrays with separate edge position vectors (even if both edge types 151-152 have the same source vertex type 141). In an embodiment, these separate edge position vectors may also be separate columns in the same vertex array used for vertex type 141.

[0071] In one embodiment, destination array 195 may be a subset of the columns of the edge array for edge type 151, in which case destination array 195 and the edge array for edge type 151 have the same sorted edges. In another embodiment, destination array 195 and the edge array for edge type 151 may have different sorted edges, provided that a mapping exists between these sorts, as explained later herein. In any case, destination array 195 and the edge array for edge type 151 have the same number of edges.

[0072] This paper presents techniques for parallel populating entries of the same CSR for acceleration in shared memory, such as through symmetric multiprocessing (SMP), which utilizes multi-core processors. For example, Figure 105 can be enormous, such as having a diameter with billions of vertices, trillions of edges, and / or tens or hundreds of thousands of vertices. For example, time feasibility may depend on horizontally scaled populating of the same CSR according to the synchronization and coordination techniques described herein.

[0073] In this embodiment, memory structures such as CSRs and vertex tables are optional. The following data definition language (DDL) statements can specify my_graph 105 as suitable for loading into memory, where the owner is a user or a schema.

[0074] ALTER PROPERTY GRAPH[owner.]my_graph TNMEMORY

[0075] Similar DDL statements can indicate that Figure 105 is no longer suitable for memory loading. In embodiments and as discussed later herein, computer 100 exposes Figure 105 to clients in the same manner, regardless of whether Figure 105 resides in memory. For example, if Figure 105 does not reside in memory, computer 100 applies Data Manipulation Language (DML) statements (such as Standard Query Language (SQL)) to a database containing relational schema 160 and its tables to perform filtering, joins, and projections on demand, thereby retrieving a result set of all instances representing Figure 105 or a particular graph data element or a particular graph data element type.

[0076] As will be described later herein, loading some or all of Figure 105 into memory can occur asynchronously in a background process, such that: a) client requests are more or less entirely delegated to a database management system (DBMS) hosted by computer 100 or a different computer for query processing; b) but alternatively, repetitions of the same request during the same graph analysis session are applied only to Figure 105 in memory. Various embodiments may incorporate some or all of the graph processing capabilities of computer 100 into the DBMS itself. For example, the DBMS on computer 100 may operate as both a relational database engine and a graph database engine.

[0077] As will be described later in this document, Figure 105 can be loaded into and / or unloaded from memory in a segmented manner, synchronously or asynchronously (e.g., in the background) with respect to client requests. For example, CSRs and / or vertex tables are individually loaded into memory on demand and evicted from memory driven by memory scarcity. In another example described later in this document: a) horizontal and / or vertical slices of vertex and / or edge tables store their data in memory blocks; b) each block can be individually loaded or evicted; and c) multiple blocks can be loaded in parallel from the same or different(one or more) relational tables. Therefore, the implementation of client requests may require a hybrid approach to database tables and memory.

[0078] 2.0 CSR Initialization Process

[0079] Figure 2 This is a flowchart depicting an example process that computer 100 can execute to construct a CSR for Figure 105, including populating entries in the destination array 195 in parallel. (Reference) Figure 1 Let's discuss Figure 2 The parallel padding of some portions of the source array 190 will be presented later in this article.

[0080] As presented earlier in this document, step 202 yields a mapping 120 that binds relation schema 160 to graph data model 130. For example, mapping 120 may include a lookup table where the key is the relation table name and the value is the vertex type name. Mapping 120 may specify a source vertex type and a destination vertex type for each edge type. Mapping 120 may be constructed manually or automatically derived, such as by analyzing graph data model 130 and relation schema 160.

[0081] For each vertex type, step 204 obtains a sequence of persistent identifiers for vertices in the vertex table of that vertex type. As shown in the source vertex column of source array 190, the sequence of persistent identifiers for vertex type 141 is A, B, C, which may or may not be retrieved from one or more identifier columns in vertex table 171. For example, such identifier columns in vertex table 171 may be a primary key, secondary keys (such as natural keys), pseudo-columns (such as row identifiers (ROWID)), and / or composite keys from multiple columns in vertex table 171. Semantics need not be imposed on the identifier columns except for the identifier columns themselves or as part of a composite key; duplicate values ​​are not allowed, as duplicate values ​​would prevent the identification of a specific row in vertex table 171.

[0082] Regardless of whether they are based on one or more identity columns, persistent identifiers should facilitate random access to specific vertex rows or edge rows in a database table. For a graph element type, the sequence of persistent identifiers can be unsorted and sparse with gaps. For example, persistent identifiers may have domain semantics, such as postal addresses. Although they may be unsorted, the sequence of persistent identifiers is ordered, whether intentionally or not.

[0083] For example, once loaded into memory, vertex A is always sorted before vertex B, regardless of whether this sorting is due to vertex table 171 itself. However, if vertex AC is later reloaded into memory, this sorting may change, regardless of whether the order of rows in vertex table 171 changes. For example, the physical order of rows in vertex table 171 may be somewhat unstable, such as due to table compaction. Similarly, the apparent row ordering may be affected by disk blocks or database caches of table rows. Therefore, whenever Figure 105 is reloaded into memory, the CSR can be implemented as volatile and regenerated, including repeating step 204.

[0084] Based on the mapping, for the corresponding CSR for each edge type, step 206 populates the source array of that CSR, as discussed earlier or later herein. The vertices are sorted in the source array (such as 190) according to the (e.g., unsorted) order of their persistent identifiers determined in step 204. For example, steps 204 and 206 may preserve the order of vertices retrieved from vertex table 171. In embodiments and as discussed later herein, populating the edge position vectors of source array 190 requires a group-by-join query to obtain the count of outgoing edges for each source vertex.

[0085] Mappings (such as lookup tables) can be generated to bind canonical offsets of vertex type 141 to persistent identifiers of vertex type 141. For example, the vertex position column and the source vertex column of source array 190 can be stored together as a lookup table. In an embodiment, the lookup table only has the source vertex column as a stored attribute vector, and the vertex position column is implicit. Parallel padding of portions of source array 190 will be presented later in this document.

[0086] In this embodiment, lookup tables can be avoided by using one or more other native mechanisms of the DBMS instead. These other native mechanisms are, for example, columnar caches with blocks (such as in-memory compaction units (IMCUs)) that have the same columns as lookup tables would have. Block caching as a native DBMS mechanism will be discussed later in this document.

[0087] For each edge type of CSR, step 208 populates the entries of the destination array of the CSR in parallel based on mapping 120. For example, destination array 195 can be an edge array and loaded from the corresponding edge table. However, the ordering of edges within destination array 195 should require grouping edges by source vertex, regardless of the ordering of edge rows in edge table 181. Within a group of edges with the same source vertex, these edges can be arbitrarily ordered. Maps (such as lookup tables) can be generated to bind array offsets of destination array 195 to persistent edge identifiers. For example, the edge position column and edge column of destination array 195 can be stored together as a lookup table. As mentioned above, DBMS implementations can have one or more native mechanisms, such as block caching, which makes separate lookup tables unnecessary.

[0088] The parallel filling of destination array 195 can occur in any temporal order. For example, in time, the bottom row of destination array 195 can be written before the top row is written, and vice versa. As will be presented later in this document, the racing implementation of step 208 does not depend on the order in which the edge rows are retrieved from edge table 181, nor on the order in which the edges are processed in step 208. For example, in various multithreaded embodiments, some or all of the following may be irrelevant:

[0089] • Are each of the adjacent entries in destination array 195 processed by the same or a separate thread, or

[0090] • Are the entries processed by the same thread adjacent in the destination array 195?

[0091] • Are edges with the same source vertex processed by the same thread?

[0092] • Whether the same thread processes edges from vertices with different sources.

[0093] Due to such lenient restrictions on filling the destination array 195, racing is encouraged and centralized coordination by the main thread is not required. Therefore, techniques presented elsewhere in this paper achieve maximum throughput, such as using contention-mitigating atomic instructions. After step 208, one or more CSRs are ready for use. In this embodiment, the CSR is set to read-only after step 208.

[0094] 3.0 Example of parallel filling of the destination array

[0095] Figure 3 This is a flowchart depicting an example process that computer 100 can execute to populate entries in the destination array 195 in parallel. (Reference) Figure 1 and Figure 2 discuss Figure 3 ,and Figure 3 Can provide Figure 2 The implementation scheme of step 208. Therefore, in various embodiments, some or all of the limitations and / or features presented in the above description of step 208 also apply. Figure 3 Some or all of the steps. For example, step 206 can be a prerequisite for step 208, and therefore also... Figure 3 This is a prerequisite for the process. The parallel filling of a portion of the source array 190 will be presented later in this article.

[0096] Figure 3 The process described herein allows for multi-threaded population of the destination array 195, thereby facilitating concurrent loading of many edges of the same edge type. For example, edge loading can be delegated individually or in batches to multiple threads. In the embodiments, the order of edges retrieved from edge table 181 and the temporal order of edge population into destination array 195 are irrelevant. For example, it is not expected that edges in edge table 181 are grouped by source vertices. However, an embodiment of grouping edges by source vertices when retrieving edge rows from edge table 181 is described later herein.

[0097] Step 302 associates the corresponding edge counter, containing an integer value, with each source vertex of the CSR of the edge type. For example, the counter vector may have as many counters as there are vertices in the source array 190. In one embodiment, each counter starts at zero and counts up to 1. In another embodiment, each counter counts down to 1 and is initialized with the count of edges of the same edge type originating from the same corresponding source vertex.

[0098] Step 304 performs the following two actions atomically together: a) obtaining a copy of the integer value of the edge counter and b) adjusting the integer value of the edge counter by 1. Depending on the implementation, different counters in the same counter vector may be accessed more or less concurrently without regard to thread safety.

[0099] However, since individual counters can be corrupted or misread due to contested use by multiple threads, counter access should be protected. In this embodiment, the counter is protected by atomic instructions such as fetch-and-add. In other words, the underlying hardware of the instruction set architecture (ISA) and its dedicated atomic instructions provide thread safety and simultaneous reading and adjustment of the counter by the same thread, even in the presence of competing threads reading and adjusting the same counter atomically.

[0100] Instead of atomic instructions, implementations can use memory synchronization instructions, such as barrier instructions in an ISA, or fence instructions that flush (i.e., write back) some or all shared data to global memory and / or reload it to the local memory of each thread or processing core. The advantage of atomic instructions such as fetch-and-add is that synchronization is non-blocking for higher throughput. Blocking synchronization can be used instead, such as using mutexes or semaphores, or critical sections.

[0101] Although two edge types may have the same source vertex type, they have separate CSRs, separate source arrays of the same length, and therefore separate counter vectors of the same length. The use of the counter vectors is independent of how the edges are distributed among the threads. Each thread iterates through the edges it has been assigned, or takes the next edge or the next batch of edges from the backlog of unprocessed edges of the same edge type. In either case, each thread processes one edge at a time, as shown below.

[0102] Step 304 detects which vertex is the source vertex of the currently processed edge and what its offset is in the source array 190. This same offset is used to access a specific counter in the counter vector. This specific counter is read and incremented atomically.

[0103] Step 306 reuses the same offset to read the value from the edge position vector in the source array 190. This edge position value is a base offset, and for edges of edge type 151 originating from a specific source vertex of the current edge, the subsequence of rows begins at this base offset in the destination array 195. The base offset is arithmetically added to the read counter value to derive the canonical offset in the destination array 195 where the current edge can be stored. Therefore, each thread can autonomously calculate where to store any edge in the destination array 195. After step 306, the destination array 195 is ready for use, and the counter vector can be discarded. In one embodiment, the destination array 195 is made read-only after step 306.

[0104] 4.0 Example Parallel Mapping of Vertex Persistent Identifiers

[0105] Figure 4 This is a flowchart depicting an example procedure that one or more computing threads of computer 100 can execute to populate a lookup table in parallel batches for vertex persistent identifiers. Reference Figure 1-2 discuss Figure 4 ,and Figure 4 It could be a partial implementation of steps 204 and 206.

[0106] As presented earlier in this document, attribute vectors can store all values ​​of attributes of a graph element type contiguously in memory. However, in memory, implementations can store any array (such as attribute vectors(s) or lookup tables) in segments referred to herein as blocks, which do not need to be contiguous. In embodiments, blocks can be filled or used later as units of work assigned to threads.

[0107] Each block will contain, or has already contained, a horizontal slice, which is a contiguous portion of a vector or array. If the block comes from a table array, then the block may also be a vertical slice having some or all of the columns of that array. That is, a slice can contain one or more vectors accessed according to the same canonical offsets of the same vertices or edges.

[0108] While each vector is contiguous within itself, multiple vectors within the same block do not necessarily have to be contiguous. Although the following process populates multiple blocks in parallel, individual blocks can be processed sequentially internally. The following process populates a block lookup table that maps canonical offsets to persistent identifiers of a vertex type. A somewhat similar process for edge types is described later in this paper.

[0109] Step 401 is preparatory and is executed by a controller such as the main thread. Step 402 and its sub-steps are executed by each of the many threads.

[0110] Step 401 associates the corresponding vertex counter with the vertex type, the vertex counter containing a non-negative integer value that is initially zero and increments by a fixed or varying amount. Somewhat similar to the counter thread safety presented earlier in this paper, atomic instructions can be used for counter integrity protection, as described below.

[0111] Step 402 has sub-steps 403-406. In step 402, each of the many threads concurrently processes a corresponding subset of rows from a vertex table in the relational database. Simultaneously, different threads can execute different corresponding sub-steps. If there is a backlog of unprocessed blocks due to fewer threads than blocks, a thread that has completed a block may take over and process another block until all blocks have been processed.

[0112] Step 403 atomically performs the following operations: a) obtaining a copy of the integer value of a vertex counter of type vertex, and b) adjusting the row count in the row subset of the vertex table with the integer value of the vertex counter. In this embodiment, an atomic fetch-and-add instruction is used, where the value of the addend operand of this instruction is the row count in the row subset. The copy of the vertex counter value returned by this instruction becomes the canonical offset of the first vertex in the block.

[0113] Each subsequent vertex in the block has a canonical offset that is 1 greater than the previous vertex in the block. The block may have metadata in which a copy of the vertex counter integer value can be stored as the canonical offset of the first vertex in the block. The canonical offsets of other vertices in the block are implicit rather than stored in the block and can be calculated as per step 405 below.

[0114] Step 404 executes a database query to read a pseudo-column of the vertex table, which indicates the canonical offset corresponding to a subset of rows in the vertex table. The pseudo-column may be more or less unstable, such that reloading Figure 105 may cause the pseudo-column to return different canonical values ​​for the same vertex than the canonical values ​​returned before the reload.

[0115] The implementation does not require the use of pseudo-columns to discover the canonical offset of rows. For example, the implementation may introduce database operators (such as built-in functions or other query operators) capable of returning the canonical offset based on the row identifier or primary key. In the implementation, the database operator may accept the row identifier or primary key as a parameter. In the implementation, the row identifier or primary key is implicit. For example, the database operator implementation may automatically obtain the row identifier or primary key.

[0116] Step 405 sums the following: a) a copy of the integer value of the block's vertex counter and b) the corresponding block position (which is the relative offset of the specific vertex within the block representing a subset of rows in the vertex table). For example, if the block has ten vertices, then each vertex has a relative offset from 0 to 9. For example, if the first vertex in the block has a canonical offset of 8000 (as recorded in the block's metadata), then the sum of the canonical offsets of the last vertex in the block is 8000 + 9 = 8009.

[0117] Step 406 stores the corresponding persistent identifier for the vertex of the vertex type in a block representing a subset of rows in the vertex table. Steps 404-406 work together and can be combined more or less such that: a) step 404 informs the database management system (DBMS) hosted on computer 100 or another computer that canonical offsets and persistent identifiers are needed; b) step 405 explains how these canonical offsets are calculated (e.g., by the DBMS); and c) step 406 stores the persistent identifiers as vectors in blocks for vertices, ordered in the same way as the canonical offsets of the vertices.

[0118] After step 406, the block can become read-only and / or be used as a lookup table to obtain persistent identifiers of vertices in the block based on vertex offsets, which can be: a) canonical offsets, or b) relative offsets in the block's persistent identifier vector. For example, for a given block, computer 100 can bidirectionally convert between canonical and relative offsets as needed based on context.

[0119] Example parallel mapping of edge persistent identifiers in version 5.0

[0120] Figure 5 This is a flowchart depicting an example process that one or more computing threads of computer 100 can execute to populate a lookup table in parallel batches for edge persistent identifiers. Reference Figure 1-4 discuss Figure 5 .

[0121] Figure 5 Some characteristics of the process are similar to Figure 4 Those in it. Figure 4 Parallel filling of blocks for vertices. Figure 5 Parallel filling is used for the blocks used for the edges.

[0122] Steps 502 and 504, and their sub-steps, are executed by each of the many computational threads. Step 502 is preparatory. In step 502, each thread executes a database query that retrieves data only for the corresponding subset of rows in the same edge table for that thread. This can be based on a thread-safe edge counter, which is correlated with... Figure 4A similar approach is used to that of a thread-safe vertex counter. Edge tables may have pseudo-columns for canonicalizing edge identifiers and may operate more or less as discussed earlier in this document with respect to vertex tables. As explained earlier, embodiments may have database operators that are semantically more or less equivalent to such pseudo-columns and used in place of them.

[0123] Depending on the embodiment and / or scenario, two or only one of sub-steps 504a-b may occur. Step 504a populates the corresponding memory block, the lifetime of which is managed by a DBMS that may or may not be hosted on computer 100. Empty or unused blocks are polymorphic unless they are populated with content, allowing them to be later populated with various data vectors depending on the scenario. In embodiments, regardless of whether it is for a graph, the block may be populated by the DBMS using data from one or more columns of any relational table (such as a vertex table, edge table, or a table that is neither a vertex table nor an edge table).

[0124] Various embodiments may have different corresponding mechanisms and strategies for managing the lifecycle of blocks. In one embodiment, the DBMS maintains a pool of unused blocks, which may or may not be allocated to the graph and to the same clients, and is populated when needed and returned to the pool for eventual reuse when no longer needed. In another embodiment, the cache may contain a fixed or elastic number of blocks that can be reused according to a caching strategy such as Least Recently Used (LRU).

[0125] For example, eviction of a block might require keeping the block in the cache and immediately reusing it to store different content than before. Database administrators (DBAs) and / or the DBMS can manually and / or autonomously statically preset and / or dynamically adjust the following items: b) which relational table and / or graph element types can be cached and / or chunked, how many bytes or blocks each relational table or graph element type can use, and / or c) the total number of bytes or blocks, such as the size of the cache.

[0126] In another embodiment, blocks are created and destroyed without being reclaimed. In any case, blocks may have different or the same number of the following items: bytes, multibyte values, and / or rows (such as graph elements).

[0127] In step 504b, the same or different threads fill the first and second corresponding memory blocks (which correspond to the row subsets of the first side table and the second side table, respectively) at the same or different times, and the two blocks store the same fixed amount of data bytes even if the first and second row subsets may have different numbers of rows.

[0128] After step 504, the block can become read-only and / or be used as a lookup table to obtain persistent identifiers of edges in the block based on the block's offset, which can be: a) a canonical offset or b) a relative offset in the block's persistent identifier vector. For example, for a given block, computer 100 can bidirectionally convert between canonical and relative offsets as needed based on context.

[0129] 6.0 Example Implementation

[0130] This is an exemplary embodiment based on a modern relational DBMS (RDBMS) such as Oracle. This embodiment refines the previous example, which can further explain this embodiment. Therefore, the following description of this embodiment is omitted to emphasize the improvements. The limitations of this embodiment, which are to be interpreted as requirements, are not necessarily the requirements of the previous examples.

[0131] 6.1 CSR Filling

[0132] CSR population is performed in three main steps:

[0133] 1. The source and destination tables are populated in main memory, and at the same time, the mapping between vertex primary keys (PK) and identifiers (ID) used in the CSR is created.

[0134] 2. Initialize the CSR data structure.

[0135] 3. Fill in the CSR with content

[0136] Steps 1 and 3 above utilize parallelism, achieved by breaking down each operation in CSR filling into memory blocks. Data from table rows will not span multiple blocks. Blocks have a fixed number of bytes. Each block can hold a varying number of rows of data, depending on various factors (e.g., the compression level implemented for the row data, etc.).

[0137] This embodiment makes no assumptions about how data is stored within blocks (dictionary encoding, other forms of compression, etc.). It only requires that the data be organized in some columnar representation, allowing all column values ​​of a particular row to be associated with the same index, which is unique within the block and assigned from a dense range of integer values ​​(starting from 0 to the row number in the block).

[0138] The DBMS provides a physical identifier for rows that can be queried using pseudo-columns (such as the ROWID pseudo-column in Oracle or IBM Db2), and range predicates on ROWID values ​​are possible (e.g., ROWID >= x AND ROWID <= y).

[0139] Each block has a metadata header associated with it, which contains useful information about the block itself, such as the number of rows stored in the block, and information that allows identification of the ROWID range of the rows stored in the block.

[0140] Loading rows into the memory repository in columnar format is done in parallel, so that each block can be filled independently of other blocks when the optional filling of the vertex (or edge) table is performed in step 1 (or step 3 if it is an edge) of the CSR filling.

[0141] The construction of the CSR for the edge table is done in parallel: during CSR construction, each block of the edge table is processed independently of other blocks, and only non-blocking synchronization is used to allocate entries in the CSR destination array (step 2).

[0142] Depending on the database system, parallelism can be achieved using processes, lightweight threads, or a combination of both. For example, in Oracle databases, the parallelism in steps 1 and 3 is performed using background processes, which are coordinated with the CSR master process, which is also a background process. The CSR master process ensures synchronization between these steps and distributes blocks to different population processes.

[0143] If the RDBMS already presents a block-based main memory parallel loading mechanism (as is the case with Oracle's memory columnar option), this embodiment can be seamlessly integrated with that mechanism to add CSR-specific operations and leverage the existing parallel loading framework.

[0144] 6.2 Vertex Row and ID Mapping

[0145] This embodiment also aims to support graphs on top of a pre-existing database (e.g., a legacy database at an existing client). This embodiment does not expect tables to already have, i.e., each row of a column has a unique integer value from a dense range that can already be used as an index.

[0146] Conversely, this embodiment utilizes an aspect of in-memory columnar databases, where table data is organized into main memory arrays of column values, one array for each column of the table. The columns of a given row of the table reside in the same position within each array storing the column values. This position can act as a unique row identifier in the columnar representation. In a dual-storage system (where rows are primarily stored on disk in row format, and in-memory columnar storage is selectively used to cache some columns of the table), this position is defined only for tables that have a copy in the in-memory repository. When the in-memory repository is organized in blocks, this position can be relative to the beginning of a block. Furthermore, the in-memory repository maintains a mapping between the physical address of the row on disk (e.g., ROWID in Oracle) and the position assigned to that row within the block of the in-memory columnar repository (which stores the column values ​​for that row).

[0147] This embodiment utilizes the relative position to provide unique identifiers for the vertex and edge elements of the graph in memory. These unique identifiers can serve as indexes to the arrays used in the CSR and can be used in queries that construct the CSR as follows.

[0148] A new pseudo-column called IMGTID (In-Memory Graph Topology ID) is defined by the DBMS. This pseudo-column behaves like a table column, but it is not actually stored in the table. Users cannot insert, update, or delete its values. The IMGTID pseudo-column is defined only for in-memory tables. Any attempt to use IMGTID on a table that is not in memory will result in an error. IMGTID is the canonical offset as presented earlier in this article.

[0149] Step 1 of CSR population calculates the IMGTID of the first row of each block and stores it in the metadata associated with that block. Step 1 may face two different scenarios: the table is not yet in memory (or not all columns that make up the vertex PK are yet in memory), or the table is in memory (all PK columns are in memory). IMGTID metadata creation can be applied to the vertex table in both of these different scenarios.

[0150] In the first case, the IMGTID is created simultaneously when the vertex is loaded into memory via a background process running asynchronously. The counter is shared by all these processes, and atomic increment operations are used to preserve a continuous range of IMGTID values.

[0151] With the vertex table already in memory and all PK columns loaded, the task is assigned to the foreground process that iterates through all blocks and simply sets the minimum vertex ID for each block.

[0152] Following step 1 of CSR population, queries against the vertex table can utilize the IMGTID pseudo-column. This will be leveraged in subsequent steps of CSR population, as detailed below.

[0153] 6.3 CSR Data Structure Initialization

[0154] Step 2 is executed by the CSR main process itself. It allocates the CSR data structures to be populated in Step 3, as well as all auxiliary data structures to be utilized by the background processes used in Step 3. Step 2 first retrieves the following information: the number of source vertices, the number of edges, and the number of destination vertices. This can be accomplished using the following three queries:

[0155] ·select count(*)from source_vertex_table;

[0156] ·select count(*)from edge_table;

[0157] ·select count(*)from destination_vertex_table;

[0158] The source vertex table size and edge table size facilitate the allocation of the CSR data structure, where the source array size is the same as the vertex table size + 1 (to have extra slots to store the total number of edges in the CSR) and the destination array size is the same as the edge table size. Information about unique identifiers for the source, edge, and destination tables from the RDBMS is also stored in the CSR metadata for quick retrieval upon request (e.g., for graph queries or graph algorithms). The CSR source array is then initialized by performing the following query:

[0159] select IMGTID, count(ET.source_fk1)

[0160] from(select IMGTID, source_pk1, source_pk2,....,

[0161] source_pkN from schema.source_vertex_table)ST

[0162] left outer join schema.edge_table ET on

[0163] ST.source_pk1=ET.src_fk1 AND

[0164] ST.source_pk2=ET.src_fk2 AND

[0165] ....AND

[0166] ST.scurce_pkN = ET.src_fkN

[0167] GROUP BY IMGTID

[0168] ORDER BY TMGTID

[0169] The above query is generated using the metadata of the descriptive graph and the tables that make up the graph. This in particular allows for customized queries on specific primary / foreign keys (FKs) between the source vertex and edge tables, where the key may be composite.

[0170] The above query retrieves the value of the IMGTID pseudo-column (which can be used as the canonical offset to the CSR source array) and the count of the neighbors (edges) emanating from that vertex for each vertex. This count can be used to calculate the offset stored in the source array for each vertex by summing the retrieved neighbor counts with the previous count stored at position (IMGTID-1) in the source array.

[0171] Step 2 is accomplished by assigning unassigned neighbor positions (unp) to a temporary array, which can be an earlier example of this paper. Figure 3 The implementation scheme for the counter vector is presented. `unp` is a temporary structure that provides thread safety during the filling of the CSR destination array; `unp` can be discarded after the CSR destination array is filled. The size of this array is equal to the size of the CSR source array (i.e., the number of elements in the source vertex table).

[0172] The entries in the `unp` array should allow storing integer values ​​in a manner consistent with non-blocking atomic instructions (e.g., atomic compared-and-swap). Each entry in the array stores the value of the next unassigned position in the list of the source vertex's neighbors. That is, assuming a vertex has IMGTID `i`, then `unp[i]` stores a value between 0 and the number of edges originating from vertex `i`. The `unp` array is initially zero-padded and will be used in step 3 to construct the destination array for the CSR.

[0173] 6.4 CSR Construction

[0174] Step 3 is performed by several background processes. These processes also create the IMGTID pseudo-column for the edge table, and they process the data in the same block-based manner described in the previous section. These processes introduce a neighborhood initialization step, which requires populating the CSR destination array, thus ultimately determining its construction.

[0175] This step mainly involves executing the following queries and utilizing their return values:

[0176]

[0177] The query above returns three values:

[0178] ·ET.IMGTID (the edge's IMGTID),

[0179] • SRC_VID (the IMGTID of the source vertex of this edge), and

[0180] ·DST_VID (IMGTID of the destination vertex of this edge).

[0181] The above query only returns results for edges that are part of the block allocated to this process. This is possible because the last condition restricts the query to performing a JOIN only on rows within a range of distinct identifiers. The boundaries of this range can be retrieved by reading the RDBMS metadata information of the edge table block.

[0182] The SRC_VID (source IMGTID) is used to retrieve the offset of the current source vertex, which is the index at the beginning of the vertex neighbor list in the CSR destination array. The same IMGTID can then be used to perform an atomic "fetch-and-add" operation on the element stored in the previously allocated unp array. Summing the retrieved offset with the acquired value allows for precise detection of which slot in the CSR destination array is available to store the destination IMGTID retrieved by the query.

[0183] This CSR implementation also includes a third array, referred to herein as the CSR edge array, which contains the edge IMGTID for each edge type used in the CSR. This speeds up edge retrieval for queries and algorithms. The CSR edge array is where the edge IMGTIDs are stored. The location where the IMGTID of the current edge is stored is exactly the location previously calculated, because there is a one-to-one mapping between the CSR destination array and the CSR edge array.

[0184] Once all background processes for this step are complete, a CSR exists in memory that is fully filled, thus presenting all the properties and benefits described earlier in this article.

[0185] 6.5 CSR Main Behavior

[0186] The CSR master process is responsible for ensuring synchronization and scheduling all background processes for intermediate steps. Step 1 publishes background processes for the source and vertex tables. The transformation to Step 2 can only occur after these background processes have completed the population and IMGTID creation. The necessary data structures are then allocated and initialized. Afterward, one or more background processes (one or more) for the edge table are published. Once the edge population is complete, the outgoing CSR is also complete.

[0187] 7.0 Database Overview

[0188] Embodiments of the present invention are used in the context of a database management system (DBMS). Therefore, a description of an example DBMS is provided.

[0189] Typically, a server (such as a database server) is a combination of integrated software components and computing resources (such as memory, nodes, and processes on those nodes for executing the integrated software components), where the combination of software and computing resources is dedicated to providing a specific type of functionality on behalf of clients. A database server manages and facilitates access to a specific database, thereby handling client requests to access the database.

[0190] Users interact with the DBMS database server by submitting commands to the database server that cause the database server to perform operations on the data stored in the database. A user can be one or more applications running on a client computer that interact with the database server. Multiple users may also be collectively referred to as users in this document.

[0191] A database consists of data stored on a persistent storage mechanism (such as a set of hard disks) and a database dictionary. A database is defined by its own separate database dictionary. The database dictionary contains metadata that defines the database objects contained in the database. In fact, the database dictionary defines most of the database. Database objects include tables, table columns, and tablespaces. A tablespace is a set of one or more files used to store data for various types of database objects (such as tables). If a database object's data is stored in a tablespace, the database dictionary maps the database object to one or more tablespaces where that database object's data is stored.

[0192] The database dictionary is referenced by the DBMS to determine how to execute database commands submitted to the DBMS. Database commands can access database objects defined by the dictionary.

[0193] Database commands can take the form of database statements. For a database server to process a database statement, the statement must conform to a database language supported by the database server. A non-limiting example of a database language supported by many database servers is SQL, including proprietary SQL forms supported by database servers such as Oracle (e.g., Oracle Database 11g). SQL Data Definition Language (“DDL”) instructions are issued to the database server to create or configure database objects, such as tables, views, or complex types. Data Manipulation Language (“DML”) instructions are issued to the DBMS to manage data stored within database structures. For example, SELECT, INSERT, UPDATE, and DELETE are common examples of DML instructions found in some SQL implementations. SQL / XML is a common extension of SQL used when manipulating XML data in object-relational databases.

[0194] A multi-node database management system consists of interconnected nodes that share access to the same database. Typically, these nodes are interconnected via a network and share access to a shared repository to varying degrees, such as shared access to a set of disk drives and the blocks of data stored thereon. Nodes in a multi-node database system can take the form of a group of computers (such as workstations and / or personal computers) interconnected via a network. Alternatively, nodes can be nodes in a mesh, which consists of nodes in the form of server blades interconnected with other server blades on a rack.

[0195] In a multi-node database system, each node hosts a database server. A server (such as a database server) is a combination of integrated software components and computing resources (such as memory, nodes, and processes on the nodes used to execute the integrated software components) allocated to perform a specific function on behalf of one or more clients.

[0196] In a multi-node database system, resources from multiple nodes can be allocated to software running a specific database server. Each combination of software and resource allocation from the nodes is a server referred to herein as a "server instance" or "instance". A database server may include multiple database instances, some or all of which may run on separate computers, including separate server blades.

[0197] 7.1 Query Processing

[0198] A query is an expression, command, or set of commands that, when executed, causes a server to perform one or more operations on a set of data. A query can specify source data objects (one or more), such as tables (one or more), columns (one or more), views (one or more), or snapshots (one or more) from which a result set (one or more) is to be determined. For example, source data objects (one or more) might appear in the FROM clause of a Structured Query Language (“SQL”) query. SQL is a well-known example language for querying database objects. As used herein, the term “query” is used to refer to any form of query, including queries in the form of database statements and any data structure used for inner query representation. The term “table” refers to any source object referenced or defined by a query and representing a set of rows, such as a database table, view, or inline query block, such as an inline view or subquery.

[0199] Queries can perform operations on data from one or more source data objects row by row as the source data objects are loaded, or on the entire source data objects after the objects have been loaded. Result sets generated by some operations can be used for other operations, and in this way, result sets can be filtered or narrowed based on some criteria, and / or combined or combined with other result sets and / or other source data objects.

[0200] A subquery is a part or component of a query that is distinct from the other parts or components of the query and can be evaluated independently (i.e., as a separate query). The other parts or components of the query can form an outer query, which may or may not include other subqueries. When evaluating the results for the outer query, subqueries nested within it can be evaluated individually once or multiple times.

[0201] Typically, a query parser receives a query statement and generates an internal query representation of that statement. This internal query representation is usually a set of interconnected data structures that represent the various components and structure of the query statement.

[0202] The internal query representation can take the form of a node graph, where each interconnected data structure corresponds to a node and a component of the query statement it represents. The internal representation is typically generated in memory for evaluation, manipulation, and transformation.

[0203] Hardware Overview

[0204] According to one embodiment, the technology described herein is implemented by one or more dedicated computing devices. The dedicated computing device may be hardwired to execute the technology, or may include one or more application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs) that are permanently programmed to execute the technology, or may include one or more general-purpose hardware processors programmed to execute the technology according to program instructions in firmware, memory, other storage devices, or combinations thereof. These dedicated computing devices may also combine custom hardwired logic, ASICs, or FPGAs with custom programming to implement the technology. The dedicated computing device may be a desktop computer system, a portable computer system, a handheld device, a networking device, or any other device that combines hardwired and / or program logic to implement the technology.

[0205] For example, Figure 6This is a block diagram illustrating a computer system 600 on which embodiments of the present invention may be implemented. The computer system 600 includes a bus 602 or other communication mechanism for transmitting information, and a hardware processor 604 coupled to the bus 602 for processing information. The hardware processor 604 may be, for example, a general-purpose microprocessor.

[0206] Computer system 600 also includes main memory 606, such as random access memory (RAM) or other dynamic storage devices, coupled to bus 602 for storing information and instructions to be executed by processor 604. Main memory 606 can also be used to store temporary variables or other intermediate information during the execution of instructions to be executed by processor 604. When these instructions are stored in non-transitory storage media accessible to processor 604, they make computer system 600 a dedicated machine customized to perform the operations specified in the instructions.

[0207] Computer system 600 also includes a read-only memory (ROM) 608 or other static storage device coupled to bus 602 for storing static information and instructions for processor 604. Storage device 610, such as a disk, optical disk, or solid-state drive, is provided and coupled to bus 602 for storing information and instructions.

[0208] Computer system 600 can be coupled to display 612, such as a cathode ray tube (CRT), via bus 602 for displaying information to the computer user. Input device 614 (which includes alphanumeric and other keys) is coupled to bus 602 for transmitting information and command selections to processor 604. Another type of user input device is cursor control 616, such as a mouse, trackball, or arrow keys, for transmitting directional information and command selections to processor 604 and for controlling cursor movement on display 612. Such input devices typically have two degrees of freedom in two axes (a first axis (e.g., x) and a second axis (e.g., y)), which allows the device to specify a position in a plane.

[0209] Computer system 600 may implement the techniques described herein using custom hard-wired logic, one or more ASICs or FPGAs, firmware, and / or program logic. This custom hard-wired logic, one or more ASICs or FPGAs, firmware, and / or program logic, combined with the computer system, enable or program the computer system 600 to be a special-purpose machine. According to one embodiment, the techniques described herein are executed by computer system 600 in response to processor 604 executing one or more sequences of one or more instructions contained in main memory 606. These instructions may be read into main memory 606 from another storage medium, such as storage device 610. Execution of the sequence of instructions contained in main memory 606 causes processor 604 to perform the processing steps described herein. In alternative embodiments, hard-wired circuitry may be used instead of or in combination with software instructions.

[0210] As used herein, the term "storage medium" refers to any non-transient medium that stores data and / or instructions that enable a machine to operate in a particular manner. Such storage media can include non-volatile media and / or volatile media. Non-volatile media include, for example, optical discs, magnetic disks, or solid-state drives, such as storage device 610. Volatile media include dynamic memory, such as main memory 606. Common forms of storage media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tape or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a perforated pattern, RAM, PROMs and EPROMs, FLASH-EPROMs, NVRAMs, any other memory chips or cassettes.

[0211] Storage media differ from transmission media but can be used in conjunction with them. Transmission media participate in the transfer of information between storage media. For example, transmission media include coaxial cables, copper wires, and optical fibers, including wires containing bus 602. Transmission media can also take the form of sound waves or light waves, such as those generated during radio wave and infrared data communication.

[0212] Various forms of media can involve carrying one or more sequences of instructions to processor 604 for execution. For example, instructions may initially be carried on a disk or solid-state drive of a remote computer. The remote computer may load the instructions into its dynamic memory and transmit them via a telephone line using a modem. A modem local to computer system 600 may receive data over the telephone line and convert the data into an infrared signal using an infrared transmitter. An infrared detector may receive the data carried in the infrared signal, and appropriate circuitry may place the data on bus 602. Bus 602 carries the data to main memory 606, from which processor 604 retrieves and executes the instructions. Instructions received from main memory 606 may optionally be stored on storage device 610 before or after execution by processor 604.

[0213] Computer system 600 also includes a communication interface 618 coupled to bus 602. Communication interface 618 provides bidirectional data communication coupled to network link 620, which is connected to local network 622. For example, communication interface 618 may be an Integrated Services Digital Network (ISDN) card, a cable modem, a satellite modem, or a modem providing data communication connectivity to a corresponding type of telephone line. As another example, communication interface 618 may be a LAN card providing data communication connectivity to a compatible local area network (LAN). A wireless link may also be implemented. In any such implementation, communication interface 618 transmits and receives electrical, electromagnetic, or optical signals carrying streams of digital data representing various types of information.

[0214] Network link 620 typically provides data communication to other data devices via one or more networks. For example, network link 620 may provide a connection to host computer 624 or to data devices operated by Internet Service Provider (ISP) 626 via local network 622. ISP 626, in turn, provides data communication services through a worldwide packet data communication network now commonly referred to as the "Internet" 628. Both local network 622 and Internet 628 use electrical, electromagnetic, or optical signals carrying digital data streams. Signals through various networks, as well as signals on network link 620 and through communication interface 618, are example forms of transmission media in which information carries digital data to or from computer system 600.

[0215] Computer system 600 can send messages and receive data, including program code, through one or more networks, network links 620, and communication interfaces 618. In the Internet example, server 630 can transmit request codes to the application through the Internet 628, ISP 626, local network 622, and communication interface 618.

[0216] The received code can be executed by processor 604 when it is received, and / or stored in storage device 610 or other non-volatile memory for later execution.

[0217] Software Overview

[0218] Figure 7 This is a block diagram of a basic software system 700 that can be used to control the operation of computing system 600. Software system 700 and its components, including their connections, relationships, and functions, are intended to be exemplary only and are not intended to limit the implementation of the example embodiments (one or more). Other software systems suitable for implementing the example embodiments (one or more) may have different components, including components with different connections, relationships, and functions.

[0219] Software system 700 is provided to guide the operation of computing system 600. Software system 700, which may be stored in system memory (RAM) 606 and on fixed storage devices (e.g., hard disk or flash memory) 610, includes a kernel or operating system (OS) 710.

[0220] OS 710 manages the low-level aspects of computer operations, including managing process execution, memory allocation, file input and output (I / O), and device I / O. One or more applications, designated 702A, 702B, 702C…702N, can be “loaded” (e.g., transferred from fixed storage device 610 to memory 606) for execution by system 700. Applications or other software intended for use on computer system 600 can also be stored as a set of downloadable computer-executable instructions, for example, for downloading and installing from an internet location (e.g., a web server, app store, or other online service).

[0221] Software system 700 includes a graphical user interface (GUI) 715 for receiving user commands and data graphically (e.g., "clicks" or "touch gestures"). System 700 can then act on these inputs according to instructions from operating system 710 and / or application(s) 702. GUI 715 is also used to display the results of operations from OS 710 and application(s) 702, whereby the user can provide additional input or terminate the session (e.g., log off).

[0222] OS 710 can execute directly on the bare hardware 720 of computer system 600 (e.g., processor(s) 604). Alternatively, a hypervisor or virtual machine monitor (VMM) 730 can be inserted between the bare hardware 720 and OS 710. In this configuration, VMM 730 acts as a software “buffer” or virtualization layer between OS 710 and the bare hardware 720 of computer system 600.

[0223] VMM 730 instantiates and runs one or more virtual machine instances (“guest machines”). Each guest machine includes a “guest” operating system, such as OS 710, and one or more applications designed to run on the guest operating system, such as application(s)702. VMM 730 presents a virtual operating platform for the guest operating system and manages the execution of the guest operating system.

[0224] In some cases, VMM 730 can allow a guest operating system to run as if it were running directly on the bare hardware 720 of computer system 700. In these cases, the same version of the guest operating system configured to run directly on the bare hardware 720 can also run on VMM 730 without modification or reconfiguration. In other words, in some situations, VMM 730 can provide complete hardware and CPU virtualization for a guest operating system.

[0225] In other cases, the guest operating system can be specifically designed or configured to run on the VMM730 for improved efficiency. In these cases, the guest operating system "knows" that it is running on the virtual machine monitor. In other words, in some situations, the VMM730 can provide paravirtualization for the guest operating system.

[0226] Computer system processes include hardware processor time allocation and memory (physical and / or virtual) allocation. Memory allocation is used to store instructions executed by the hardware processor, to store data generated by the execution of instructions by the hardware processor, and / or to store hardware processor state (e.g., register contents) between hardware processor time allocations when the computer system process is not running. Computer system processes run under the control of the operating system and can also run under the control of other programs executing on the computer system.

[0227] cloud computing

[0228] The term “cloud computing” is generally used in this article to describe a computing model that enables on-demand access to a shared pool of computing resources, such as computer networks, servers, software applications, and services, and allows for the rapid provisioning and release of resources with minimal management effort or service provider interaction.

[0229] Cloud computing environments (sometimes referred to as cloud environments or the cloud itself) can be implemented in a variety of different ways to best meet diverse needs. For example, in a public cloud environment, the underlying computing infrastructure is owned by the organization that makes its cloud services available to other organizations or the public. In contrast, private cloud environments are typically designed for use by a single organization or within a single organization. Community clouds are designed to be shared by several organizations within a community; while hybrid clouds include two or more types of clouds (e.g., private, community, or public) that are bound together by data and application portability.

[0230] Typically, cloud computing models enable some of the responsibilities that might have previously been provided by an organization's own IT departments to be delivered as service layers within a cloud environment for consumers (whether internal or external, depending on the public / private nature of the cloud). Depending on the specific implementation, the precise definition of the components or features provided or internal to each cloud service layer can vary, but common examples include: Software as a Service (SaaS), where consumers use software applications running on cloud infrastructure, while the SaaS provider manages or controls the underlying cloud infrastructure and applications; Platform as a Service (PaaS), where consumers can use software programming languages ​​and development tools supported by the PaaS provider to develop, deploy, and otherwise control their own applications, while the PaaS provider manages or controls other aspects of the cloud environment (i.e., everything in the runtime execution environment); and Infrastructure as a Service (IaaS), where consumers can deploy and run arbitrary software applications and / or provide processing, storage, networking, and other basic computing resources, while the IaaS provider manages or controls the underlying physical cloud infrastructure (i.e., everything below the operating system layer). Database as a Service (DBaaS) is a service where consumers use database servers or database management systems that run on cloud infrastructure, while the DBaaS provider manages or controls the underlying cloud infrastructure and applications.

[0231] The basic computer hardware and software, as well as the cloud computing environment described above, are presented for the purpose of illustrating the basic underlying computer components that can be used to implement the example embodiments (one or more). However, the example embodiments (one or more) are not necessarily limited to any particular computing environment or computing device configuration. Rather, the example embodiments (one or more) can be implemented in any type of system architecture or processing environment that a person skilled in the art will understand from this disclosure as capable of supporting the features and functionality of the example embodiments (one or more) presented herein.

[0232] In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may change with implementation. Therefore, the specification and drawings are to be considered illustrative rather than restrictive. The unique and exclusive references to the scope of the invention, and what the applicant intends to be within the scope of the invention, are the literal and equivalent scope of the set of claims published in this application, in the specific form of such claims, including any subsequent corrections.

Claims

1. A computer-implemented method, comprising: Obtain the mapping from relational schemas to graph data models, where: The relation schema defines multiple vertex tables corresponding to multiple corresponding vertex types in the graph data model and multiple edge tables corresponding to multiple corresponding edge types in the graph data model, and Each of the plurality of edge types is associated with a corresponding source vertex type and a corresponding target vertex type among the plurality of vertex types; For each of the plurality of vertex types, obtain a sequence of persistent identifiers of the vertices of that vertex type; For the corresponding compressed sparse line (CSR) representation of each of the plurality of edge types, the source array is populated based on the mapping, sorted for vertices that are the same as the sequence of persistent identifiers of the source vertex type of the edge type, the source array being based on the count of edges of the edge type originating from vertices of that source vertex type; For the CSR representation of each of the plurality of edge types, a destination array is populated in parallel based on the mapping, the destination array containing canonical offsets as sequence positions within a sequence of persistent identifiers of vertices of the target vertex type of the edge type; The first and second graphs are based on the same graph data model, and For the first graph and the second graph, for the CSR representation of each of the plurality of edge types, the source array and the destination array are filled based on the same mapping from the relation schema to the graph data model.

2. The computer-implemented method as described in claim 1, wherein, For the CSR representation of the edge type, filling the destination array includes performing the following operations for each edge of the edge type: Associate the corresponding edge counter containing an integer value with each vertex of the source vertex type of the edge type represented by the CSR; Perform the following operations atomically: obtain a copy of the integer value of the edge counter, and adjust the integer value of the edge counter by 1; The canonical offset of the target vertex type of the edge type is stored at an array position in the destination array, the array position being based on the copy of the integer value.

3. The computer-implemented method as described in claim 2, wherein, The acquisition and adjustment are performed atomically, including non-blocking synchronization.

4. The computer-implemented method as described in claim 1, wherein, For the CSR representation of the edge type, populating the destination array includes: each of a plurality of computation threads concurrently processing a corresponding subset of rows of the edge table of the edge type to compute the canonical offset of the target vertex type of the edge type.

5. The computer-implemented method as described in claim 4, wherein: The plurality of edge tables includes a first edge table and a second edge table, wherein the first edge table and the second edge table are either different tables or the same table; The row subset of the first edge table contains more rows than the row subset of the second edge table; Processing the row subset of the first side table and processing the row subset of the second side table includes: filling a first corresponding memory block and a second corresponding memory block with the same fixed amount of data bytes, the first corresponding memory block and the second corresponding memory block respectively corresponding to the row subset of the first side table and the row subset of the second side table.

6. The computer-implemented method as described in claim 4, wherein, Processing the row subset of the edge table includes filling the corresponding memory block that the database management system (DBMS) can fill with data from one or more columns of any relational table.

7. The computer-implemented method as described in claim 4, wherein, The computation thread processes the row subset of the edge table by performing a database query that retrieves only the data of the row subset of the edge table.

8. The computer-implemented method as described in claim 1, wherein, The sequence for obtaining the persistent identifier of the vertex type includes: Associate the corresponding vertex counter containing an integer value with the vertex type; Each of the multiple computation threads concurrently processes a corresponding subset of rows from the vertex table of the vertex type by: Perform the following operations atomically: obtain a copy of the integer value of the vertex counter, and adjust the count of rows in the row subset of the vertex table by the integer value of the vertex counter; The following items are stored in the corresponding memory block representing the row subset of the vertex table: the copy of the integer value and the corresponding subsequence of the persistent identifier of the vertex type.

9. The computer-implemented method as described in claim 8, wherein, The vertex table includes pseudo-columns that, for a specific row of the vertex table, indicate the canonical offset of the vertex corresponding to that specific row.

10. The computer-implemented method as described in claim 9, wherein, Storing the corresponding subsequence of the persistent identifier into the memory block includes reading the pseudo-column that indicates the canonical offset corresponding to the specific row.

11. The computer-implemented method as described in claim 10, wherein, Reading the pseudo-column that indicates the canonical offset corresponding to the specific row includes summing the following: The copy of the integer value of the vertex counter, and The corresponding block position within the memory block representing the row subset of the vertex table, the corresponding block position corresponding to the specific row.

12. The computer-implemented method as described in claim 10, wherein, The computation thread performs a database query to read the pseudo-column, which indicates the canonical offset corresponding to the subset of rows in the vertex table.

13. The computer-implemented method as described in claim 8, wherein, The memory block representing the row subset of the vertex table includes: The primary key value of the row subset of the vertex table, and / or The storage row identifier of the row subset of the vertex table.

14. The computer-implemented method as described in claim 1, wherein, The persistent identifier of a vertex of a vertex type includes: the primary key value of the row of the vertex table of the vertex type, and / or the storage row identifier of the row of the vertex table.

15. The computer-implemented method as described in claim 1, wherein: The plurality of edge tables includes a first edge table and a second edge table, wherein the first edge table and the second edge table are either different edge tables or the same edge table; The plurality of edge tables corresponding to the plurality of corresponding edge types include: the first edge table corresponding to a first edge type and the second edge table corresponding to a second edge type that is not the first edge type; The edges of the first edge type include the first edges represented by the rows of the first edge table; The second edge type contains a second edge represented by the following: a row in the second edge table, or the same row in the first edge table.

16. The computer-implemented method of claim 6, wherein the relation table includes a vertex table, an edge table, or a table that is neither a vertex table nor an edge table.

17. One or more non-transitory computer-readable media storing one or more sequences of instructions, which, when executed by one or more processors, cause the execution of the method as claimed in any one of claims 1-16.

18. An electronic device comprising: One or more processors; as well as A memory, coupled to the one or more processors and including instructions stored thereon, which, when executed by the one or more processors, cause the execution of the method as claimed in any one of claims 1-16.

Images