Network Graphs

Kinetica provides support for graph creation and management in SQL. Graphs represent topological relationships (both geospatial and non-geospatial) via nodes that are connected by edges.

Graph features accessible via SQL include:


CREATE GRAPH

Creates a new graph. The nodes and edges of a graph are optionally weighted and/or restricted to aid in calculating various ways to traverse the graph. Graphs comprise a maximum of four components that each have unique specifications and ways they can be combined to define the graph. Review Components and Identifiers and Identifier Combinations for more information.

CREATE GRAPH Syntax
1
2
3
4
5
6
7
8
CREATE [OR REPLACE] [DIRECTED] GRAPH [<schema name>.]<graph name>
(
    EDGES => <INPUT_TABLE(<select statement>) | INPUT_TABLES((<select statement>)[,...])>,
    [NODES => <INPUT_TABLE(<select statement>) | INPUT_TABLES((<select statement>)[,...])>,]
    [WEIGHTS => <INPUT_TABLE(<select statement>) | INPUT_TABLES((<select statement>)[,...])>,]
    [RESTRICTIONS => <INPUT_TABLE(<select statement>) | INPUT_TABLES((<select statement>)[,...])>,]
    [OPTIONS => <KV_PAIRS>('<option key>' = '<option value>'[,...])]
)
ParameterDescription
OR REPLACEAny existing graph with the same name will be dropped before creating this one
DIRECTEDOptional keyword used to create the graph as directed
<schema name>Name of the schema that will contain the created graph; if no schema is specified, the graph will be created in the calling user's default schema
<graph name>Name of the graph, which can be referenced in subsequent commands
EDGESGraph component, provided as table column names, expressions, or constants using the SQL INPUT_TABLE or INPUT_TABLES function, to use for identifying the edges of the graph; review Components and Identifiers and Identifier Combinations for more information
NODESOptional graph component, provided as column names, expressions, or constants using the SQL INPUT_TABLE or INPUT_TABLES function, to use for identifying the nodes of the graph; review Components and Identifiers and Identifier Combinations for more information
WEIGHTSOptional graph component, provided as column names, expressions, or constants using the SQL INPUT_TABLE or INPUT_TABLES function, to use for identifying the weights of the graph; review Components and Identifiers and Identifier Combinations for more information
RESTRICTIONSOptional graph component, provided as column names, expressions, or constants using the SQL INPUT_TABLE or INPUT_TABLES function, to use for identifying the restrictions of the graph; review Components and Identifiers and Identifier Combinations for more information
OPTIONS

Optional indicator that a list of connection option/value assignments will follow, passed as a comma-delimited list of key/value pairs to the KV_PAIRS function

OptionDescription
add_table_monitorAdds a table monitor to every table used in the creation of the graph; this table monitor will trigger the graph to update dynamically upon inserts to the source table(s). Note that upon database restart, if save_persist is also set to true, the graph will be fully reconstructed and the table monitors will be reattached. For more details on table monitors, see Table Monitors. The default value is false.
add_turnsAdds dummy "pillowed" edges around intersection nodes where there are more than three edges so that additional weight penalties can be imposed by the solve endpoints (increases the total number of edges). The default value is false.
allow_multiple_edgesEnables multigraph capability--pairs of nodes can be connected by more than one edge. Without this option, undirected graphs can only have one edge between each pair of nodes, and directed graphs can have one edge in each direction between each pair of nodes--"duplicate" edges are discarded.
cluster_graph_schemaIf export_graph_schema is true, outputs the graph's schema into a table named <graph_name>_clusters
export_graph_schema

Exports a graph's schema in Graphviz DOT format.

The schema is a conversion of the graph into a label-based ontology, done by grouping the nodes using the Louvain clustering algorithm.

This schema is made available in two ways:

  • visually, by clicking View Schema in the result of an CREATE GRAPH command in a SQL Block within Workbench
  • as text, under the info and then dot keys of the response to a native API call to /execute/sql
graph_tableIf specified, the created graph is also created as a table with the given name, in [schema_name.]table_name format, using standard name resolution rules and meeting table naming criteria. The table will have the following identifier columns: EDGE_ID, EDGE_NODE1_ID, EDGE_NODE2_ID. If left blank, no table is created. The default value is blank.
is_partitionedIf set to true, the graph will be partitioned across the servers specified in server_id; if false, the graph will be replicated across those servers. The default value is false.
label_delimiterIf specified, the delimiter to use when parsing edge labels. All labels separated by this delimiter will be applied to the corresponding edge.
merge_toleranceIf node geospatial positions are input (e.g., POINT(X Y)), determines the minimum separation allowed between unique nodes. If nodes are within the tolerance of each other, they will be merged as a single node. The default value is 1.0E-5.
recreateIf set to true and the graph already exists, the graph is deleted and recreated. The default value is false.
save_persistIf set to true, the graph will be saved in the persist directory (see the config reference for more information). If set to false, the graph will be removed when the graph server is shutdown. The default value is false.
schema_edge_labelkeysIf export_graph_schema is true, generates the label-based schema by collapsing edges based on the their label keys; otherwise, schema edges are created from the edge labels.
schema_node_labelkeysIf export_graph_schema is true, generates the label-based schema by collapsing nodes based on the their label keys; otherwise, schema nodes are created from the node labels.
server_idIndicates on which graph server(s) to create the graph. Default is to create on the server with the most available memory. Can be a single server ID, a comma-separated list of IDs, or all for all servers.
simplifySimplifies the graph topology at 2-valence by collapsing edge.
use_rtreeUse a range tree structure to accelerate and improve the accuracy of snapping, especially to edges.

CREATE GRAPH Examples

Edges & Weights Example
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
CREATE GRAPH sample_graph
(
    EDGES => INPUT_TABLE
    (
        SELECT
            id AS ID,
            wktline AS WKTLINE
        FROM sample_map
    ),
    WEIGHTS => INPUT_TABLE
    (
        SELECT
            id AS EDGE_ID,
            cost AS VALUESPECIFIED
        FROM sample_map
    ),
    OPTIONS => KV_PAIRS(recreate = 'true', graph_table = 'sample_graph_table')
)
Nodes/Edges & Weights Example
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
CREATE GRAPH big_cities_graph
(
    NODES => INPUT_TABLE
    (
        SELECT
            city_location AS WKTPOINT
        FROM big_cities
    ),
    EDGES => INPUT_TABLE
    (
        SELECT
            city1_location AS NODE1_WKTPOINT,
            city2_location AS NODE2_WKTPOINT
        FROM big_cities_map
    ),
    WEIGHTS => INPUT_TABLE
    (
        SELECT
            (REMOVE_NULLABLE(ST_MAKELINE(city1_location, city2_location))) AS EDGE_WKTLINE,
            trip_time AS VALUESPECIFIED
        FROM big_cities_map
    ),
    OPTIONS => KV_PAIRS(recreate = 'true', graph_table = 'big_cities_graph_table')
)
Label & Label Key from Constants Example
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
CREATE OR REPLACE GRAPH people
(
    NODES => INPUT_TABLES
    (
        (SELECT 'Gender' AS LABEL_KEY, 'MALE:FEMALE' AS LABEL),
        (SELECT 'Interest' AS LABEL_KEY, 'golf:business:dance:chess' AS LABEL),

        (SELECT 'Jane' AS NAME, 'FEMALE:business' AS LABEL),
        (SELECT 'Bill' AS NAME, 'MALE:golf' AS LABEL),
        (SELECT 'Susan' AS NAME, 'FEMALE:dance' AS LABEL),
        (SELECT 'Alex' AS NAME, 'MALE:chess' AS LABEL),
        (SELECT 'Tom' AS NAME, 'MALE:chess' AS LABEL)
    ),
    EDGES => INPUT_TABLES
    (
        (SELECT 'Relation' AS LABEL_KEY, 'Friend:Family' AS LABEL),
        
        (SELECT 'Jane' AS NODE1_NAME, 'Bill' AS NODE2_NAME, 'Friend' AS LABEL),
        (SELECT 'Bill' AS NODE1_NAME, 'Alex' AS NODE2_NAME, 'Family' AS LABEL),
        (SELECT 'Bill' AS NODE1_NAME, 'Susan' AS NODE2_NAME, 'Friend' AS LABEL),
        (SELECT 'Susan' AS NODE1_NAME, 'Alex' AS NODE2_NAME, 'Friend' AS LABEL),
        (SELECT 'Alex' AS NODE1_NAME, 'Tom' AS NODE2_NAME, 'Friend' AS LABEL)    
    ),
    OPTIONS => KV_PAIRS(label_delimiter = ':', graph_table = 'people_graph_table')
)
Label & Label Key from Tables Example
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
CREATE DIRECTED GRAPH imdb
(
    NODES => INPUT_TABLES
    (
        -- Implicit labeling of movie nodes with the LABEL_KEY 'movie', as all movies have an associated genre
        (SELECT DISTINCT genre AS LABEL, 'movie' AS LABEL_KEY FROM movie),
        -- Implicit labeling of person nodes with the LABEL_KEY 'person', as all persons have an associated profession
        (SELECT DISTINCT profession AS LABEL, 'person' AS LABEL_KEY FROM person),

        -- Give each movie node a genre label; the LABEL_KEY 'movie' will also be associated with each
        (SELECT title AS NAME, genre AS LABEL FROM movie),
        -- Give each person node a profession label; the LABEL_KEY 'person' will also be associated with each
        (SELECT name AS NAME, profession AS LABEL FROM person),

        (SELECT DISTINCT CHAR64(YEAR(DOB)) AS NAME, CHAR64('year') AS LABEL FROM person),
        (SELECT DISTINCT CHAR64(released) AS NAME, CHAR64('year') AS LABEL FROM movie)
    ),
    EDGES => INPUT_TABLES
    (
        (SELECT DISTINCT participation AS LABEL, 'participation' AS LABEL_KEY FROM imdb),

        (SELECT person AS NODE1_NAME, film AS NODE2_NAME, participation AS LABEL FROM imdb),
        (SELECT title AS NODE1_NAME, CHAR64(released) AS NODE2_NAME, CHAR64('released') AS LABEL FROM movie),
        (SELECT name AS NODE1_NAME, CHAR64(YEAR(dob)) AS NODE2_NAME, CHAR64('born') AS LABEL FROM person)
    ),
    OPTIONS => KV_PAIRS(label_delimiter = ':', graph_table = 'imdb_graph_table')
)

SOLVE_GRAPH

Solves an existing graph using one of the supported solver types. The SOLVE GRAPH function can be called either within a SELECT statement as a table function or within an EXECUTE FUNCTION call.

Table Function Syntax
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
SELECT * FROM TABLE
(
    SOLVE_GRAPH
    (
        GRAPH => '[<schema name>.]<graph name>',
        SOLVER_TYPE => '<solver type>',
        SOURCE_NODES => <INPUT_TABLE(<select statement>) | INPUT_TABLES((<select statement>)[,...])>,
        [DESTINATION_NODES => <INPUT_TABLE(<select statement>) | INPUT_TABLES((<select statement>)[,...])>,]
        [WEIGHTS_ON_EDGES => <INPUT_TABLE(<select statement>) | INPUT_TABLES((<select statement>)[,...])>,]
        [RESTRICTIONS => <INPUT_TABLE(<select statement>) | INPUT_TABLES((<select statement>)[,...])>,]
        [OPTIONS => <KV_PAIRS>('<option name>' = '<option value>'[,...])]
    )
)
EXECUTE FUNCTION Syntax
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
EXECUTE FUNCTION SOLVE_GRAPH
(
    GRAPH => '[<schema name>.]<graph name>',
    SOLVER_TYPE => '<solver type>',
    SOURCE_NODES => <INPUT_TABLE(<select statement>) | INPUT_TABLES((<select statement>)[,...])>,
    SOLUTION_TABLE => '[<schema name>.]<table name>',
    [DESTINATION_NODES => <INPUT_TABLE(<select statement>) | INPUT_TABLES((<select statement>)[,...])>,]
    [WEIGHTS_ON_EDGES => <INPUT_TABLE(<select statement>) | INPUT_TABLES((<select statement>)[,...])>,]
    [RESTRICTIONS => <INPUT_TABLE(<select statement>) | INPUT_TABLES((<select statement>)[,...])>,]
    [OPTIONS => <KV_PAIRS>('<option name>' = '<option value>'[,...])
)
ParameterDescription
GRAPHName of the graph to solve
SOLVER_TYPE

The type of solver to use for the operation.

SolverDescriptionCPU Parallel
ALLPATHSDetermines all reasonable paths between a source and destination pair.X
BACKHAUL_ROUTINGDetermines the optimal routes between remote asset nodes and fixed asset nodes.X
CENTRALITYCalculates the degree of a node to depict how many pairs of individuals that would have to go through the node to reach one another in the minimum number of hops. Also known as betweenness.X
CLOSENESSCalculates the centrality closeness score per node as the sum of the inverse shortest path costs to all nodes in the graph.X
INVERSE_SHORTEST_PATHDetermines the shortest path downstream using multiple technician routing.X
MULTIPLE_ROUTINGCalculates the shortest possible route between the nodes and returns to the origin node -- also known as the traveling salesman.X
PAGE_RANKCalculates how connected the nodes are and determines which nodes are the most important. Weights are not required.X
PROBABILITY_RANKCalculates the probability of a node being connected to another node using hidden Markov chains.X
SHORTEST_PATHDetermines the shortest path upstream between given source(s) and destination(s).X
STATS_ALLCalculates graph statistics such as graph diameter, longest pairs, vertex valences, topology numbers, average and max cluster sizes, etc.X

SOURCE_NODESThe node(s) used as the origin point(s) for the solution specified using the SQL INPUT_TABLE or INPUT_TABLES function
SOLUTION_TABLEOnly applicable when using EXECUTE FUNCTION syntax. Name of the table to store the solution in [schema_name.]table_name format, using standard name resolution rules and meeting table naming criteria
DESTINATION_NODESThe node(s) used as the destination point(s) for the solution specified using the SQL INPUT_TABLE or INPUT_TABLES function
WEIGHTS_ON_EDGESAdditional weights to apply to the edges of an existing graph specified using the SQL INPUT_TABLE or INPUT_TABLES function; review Components and Identifiers and Identifier Combinations for more information
RESTRICTIONSAdditional restrictions to apply to the nodes/edges of an existing graph specified using the SQL INPUT_TABLE or INPUT_TABLES function; review Components and Identifiers and Identifier Combinations for more information
OPTIONS

Optional indicator that a comma-delimited list of connection option/value assignments will follow.

OptionDescription
astar_radiusFor SHORTEST_PATH, INVERSE_SHORTEST_PATH, ALLPATHS, and MULTIPLE_ROUTING solvers, when solve_heuristic is astar. The shortest path traversal front includes nodes only within this radius (kilometers) as it moves towards the target location. Default is 70.
convergence_limitFor PAGE_RANK solver only; maximum percent relative threshold on the pagerank scores of each node between consecutive iterations to satisfy convergence. Default value is 1%.
intersection_penaltyThis will add an additional weight over the edges labeled as intersection if the add_turn option was invoked during graph creation. The default value is 0.0.
left_turn_penaltyThis will add an additional weight over the edges labeled as left_turn if the add_turn option was invoked during graph creation. The default value is 0.0.
max_iterationsFor PAGE_RANK solver only; maximum number of pagerank iterations for satisfying convergence. Default value is 100.
max_num_combinationsFor MULTIPLE_ROUTING solver only. Sets the cap on the combinatorial sequence generated. If the default value (2000000) is overridden, it potentially speeds up the solver.
max_runsFor CENTRALITY solver only. Sets the maximum number of shortest path runs--maximum possible value is the number of nodes in the graph. Default of 0 enables this value to be auto-computed by the solver.
max_solution_radiusFor SHORTEST_PATH, INVERSE_SHORTEST_PATH, & ALLPATHS solvers only. Sets the maximum solution cost radius, which ignores the DESTINATION_NODES list and instead outputs the nodes within the radius sorted by ascending cost. If set to 0.0 (the default), the setting is ignored.
max_solution_targetsFor SHORTEST_PATH, INVERSE_SHORTEST_PATH, & ALLPATHS solvers only. Sets the maximum number of solution targets, which ignores the DESTINATION_NODES list and instead outputs no more than n number of nodes sorted by ascending cost where n is equal to the setting value. If set to 0 (the default), the setting is ignored.
min_solution_radiusFor SHORTEST_PATH, INVERSE_SHORTEST_PATH, & ALLPATHS solvers only. Applicable when max_solution_radius is set. Sets the minimum solution cost radius, which ignores the DESTINATION_NODES list and instead outputs the nodes within the radius sorted by ascending cost. If set to 0.0 (the default), the setting is ignored.
num_best_pathsFor MULTIPLE_ROUTING solver only. Sets the number of shortest paths computed from each node. This is the heuristic criterion. If set to 0 (the default), the number will be determined automatically by the solver. Users may want to override this parameter to speed up the solver.
output_clustersFor STATS_ALL solver only; the cluster index for each node will be inserted as an additional column in the output.
output_edge_pathIf set to true, concatenated edge IDs will be added as an EDGE_PATH column to the solution table for each source and target pair in the SHORTEST_PATH solves. The default value is false
output_wkt_pathIf set to true, WKT line segments will be added as a WKTROUTE column to the solution table for each source and target pair in SHORTEST_PATH solves. The default value is false.
right_turn_penaltyThis will add an additional weight over the edges labeled as right_turn if the add_turn option was invoked during graph creation. The default value is 0.0.
server_idIndicates which graph server(s) to send the request to. Default is to send to the server, amongst those containing the corresponding graph, that has the most computational bandwidth. For SHORTEST_PATH solver, the input is split among the server containing the corresponding graph.
sharp_turn_penaltyThis will add an additional weight over the edges labeled as sharp_turn or u_turn if the add_turn option was invoked during graph creation. The default value is 0.0.
solve_heuristicThe heuristic search criterion to use, only for geo graphs and SHORTEST_PATH solves towards a single target. Specify astar to use an A-STAR heuristic. The default value is none.
uniform_weightsWhen specified, assigns the given value to all the edges in the graph. Note that weights provided using weights_on_edges will override this value.

SOLVE_GRAPH Examples

Using the EXECUTE FUNCTION syntax necessitates the SOLUTION_TABLE parameter to store the solve results, where using the table function syntax will return the results directly.

Table Function Example
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
SELECT * FROM TABLE
(
    SOLVE_GRAPH
    (
        GRAPH => 'sample_graph',
        SOLVER_TYPE => 'SHORTEST_PATH',
        SOURCE_NODES => INPUT_TABLE(SELECT ST_GEOMFROMTEXT('POINT(0 0)') AS WKTPOINT),
        DESTINATION_NODES => INPUT_TABLE(SELECT ST_GEOMFROMTEXT('POINT(-5 -5)') AS WKTPOINT),
        OPTIONS => KV_PAIRS(output_edge_path = 'true')
    )
)
EXECUTE FUNCTION Example
1
2
3
4
5
6
7
8
9
EXECUTE FUNCTION SOLVE_GRAPH
(
    GRAPH => 'sample_graph',
    SOLVER_TYPE => 'SHORTEST_PATH',
    SOURCE_NODES => INPUT_TABLE(SELECT ST_GEOMFROMTEXT('POINT(0 0)') AS WKTPOINT),
    DESTINATION_NODES => INPUT_TABLE(SELECT ST_GEOMFROMTEXT('POINT(-5 -5)') AS WKTPOINT),
    SOLUTION_TABLE => 'sample_graph_solved_shortest_path',
    OPTIONS => KV_PAIRS(output_edge_path = 'true')
)

QUERY_GRAPH

Queries an existing graph using unique query identifiers and combinations. The QUERY_GRAPH function can be called either within a SELECT statement as a table function or within an EXECUTE FUNCTION call.

Table Function Syntax
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
SELECT * FROM TABLE
(
    QUERY_GRAPH
    (
        GRAPH => '[<schema name>.]<graph name>',
        QUERIES => <INPUT_TABLE(<select statement>) | INPUT_TABLES((<select statement>)[,...])>,
        RINGS => <integer>,
        [RESTRICTIONS => <INPUT_TABLE(<select statement>) | INPUT_TABLES((<select statement>)[,...])>,]
        [OPTIONS => <KV_PAIRS>('<option name>' = '<option value>'[,...])]
    )
)
EXECUTE FUNCTION Syntax
1
2
3
4
5
6
7
8
9
EXECUTE FUNCTION QUERY_GRAPH
(
    GRAPH => '[<graph schema name>.]<graph name>',
    QUERIES => <INPUT_TABLE(<select statement>) | INPUT_TABLES((<select statement>)[,...])>,
    ADJACENCY_TABLE => '[<table schema name>.]<table name>',
    RINGS => <integer>,
    [RESTRICTIONS => <INPUT_TABLE(<select statement>) | INPUT_TABLES((<select statement>)[,...])>,]
    [OPTIONS => <KV_PAIRS>('<option name>' = '<option value>'[,...])]
)
ParameterDescription
GRAPHName of the graph to query
QUERIESNodes or edges to be queried specified using the SQL INPUT_TABLE or INPUT_TABLES function; review Query Identifiers and Query Identifier Combinations for more information
ADJACENCY_TABLE

Name of the table to store the resulting adjacent edges in [schema_name.]table_name format, using standard name resolution rules and meeting table naming criteria; a table storing the resulting matching nodes will also be created, named <ADJACENCY_TABLE>_nodes

Important

Only applicable when using the EXECUTE FUNCTION syntax

RINGS

Sets the number of rings around (hops from) the queried node(s) to return matching edges & nodes

Important

Only applicable when querying on nodes; e.g., giving NODE_NAME or NODE_LABEL

RESTRICTIONS

Additional restrictions to apply to the nodes/edges of an existing graph specified using the SQL INPUT_TABLE or INPUT_TABLES function; review Components and Identifiers and Identifier Combinations for more information

Important

Only applicable when querying on nodes; e.g., giving NODE_NAME or NODE_LABEL

OPTIONS

Optional indicator that a comma-delimited list of connection option/value assignments will follow.

OptionDescription
and_labelsIf true, the result of the query has entities that satisfy all the target labels instead of any of the labels. The default is false.
find_common_labelsIf true, adds a LABELS column to the output tables specified by ADJACENCY_TABLE. When RINGS is 0, all labels of queried nodes & edges will be listed in this column; otherwise, (for many-to-many queries and multi-level traversals), all common labels between the source & target nodes, as well as common edge labels in each path will be listed. The default is false.
force_undirected

If true, all inbound & outbound edges relative to the node will be returned. If set to false, only outbound edges relative to the node will be returned. The default is false. Consult Directed Graphs for more details.

Important

Only applicable when querying on nodes on a directed graph

limitWhen specified, limits the number of query results. The size of the corresponding node table will also be limited by this value.
output_charn_lengthWhen specified, limits the size of string columns in the output tables. The default is 64. Valid values are between 1 & 256.
output_wkt_pathIf true, adds a QUERY_EDGE_WKTLINE column to the specified ADJACENCY_TABLE so the solution can be viewed via WMS; for social and non-geospatial solutions, the QUERY_EDGE_WKTLINE column will be populated with spatial coordinates derived from a flattening layout algorithm so the solution can still be viewed. The default is false.
result_table_index

Indicates which result table to return results from:

  • 1 - Return edge results (default)
  • 2 - Return node results

Important

Only applicable when using the table function syntax

server_idIndicates which graph server(s) to send the request to. Default is to send to the server, amongst those containing the corresponding graph, that has the most computational bandwidth.

QUERY_GRAPH Examples

Using the EXECUTE FUNCTION syntax necessitates the ADJACENCY_TABLE parameter to store the query results, where using the table function syntax will return the results directly.

Table Function (Nodes) Example
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
SELECT * FROM TABLE
(
    QUERY_GRAPH
    (
        GRAPH => 'sample_graph',
        QUERIES => INPUT_TABLE(SELECT ST_GEOMFROMTEXT('POINT(0 0)') AS NODE_WKTPOINT),
        RINGS => 1,
        OPTIONS => KV_PAIRS(output_wkt_path = 'true', result_table_index = '2')
    )
)
Table Function (Edges) Example
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
SELECT * FROM TABLE
(
    QUERY_GRAPH
    (
        GRAPH => 'sample_graph',
        QUERIES => INPUT_TABLE(SELECT ST_GEOMFROMTEXT('POINT(0 0)') AS NODE_WKTPOINT),
        RINGS => 1,
        OPTIONS => KV_PAIRS(output_wkt_path = 'true')
    )
)
EXECUTE FUNCTION Example
1
2
3
4
5
6
7
8
EXECUTE FUNCTION QUERY_GRAPH
(
    GRAPH => 'sample_graph',
    QUERIES => INPUT_TABLE(SELECT ST_GEOMFROMTEXT('POINT(5 5)') AS NODE_WKTPOINT),
    RINGS => 2,
    ADJACENCY_TABLE => 'sample_graph_node_query',
    OPTIONS => KV_PAIRS(output_wkt_path = 'true')
)

Querying by Hops

Queries can make use of a HOP_ID identifier to match nodes & edges at a given distance from the source node or edge.

A graph of movies and their actors & directors can be queried, for instance, to return the titles & directors of movies in which James Spader has acted. Here, the query starts with the James Spader actor node and uses HOP_ID filters to:

  • move across acted edges in the 1st hop to all the nodes in which James Spader has acted
  • find the director nodes connected to those movies in the 2nd hop; note the -2 for the HOP_ID allows one-way edges to be traversed in reverse--the directed edge connecting directors to the movies they directed is one-way, from director to movie, but the query needs to move from movie to director of that movie, thus the -2 designation for the 2nd hop to follow those edges in reverse

Since hop-based queries return all edges along the path, the query ends by filtering the James Spader node out of the result set.

Query by Hop ID Example
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
SELECT
    QUERY_NODE2_NAME AS Movie,
    QUERY_NODE1_NAME AS Director
FROM TABLE
(
    QUERY_GRAPH
    (
        GRAPH => 'example_graph_label.imdb',
        QUERIES => INPUT_TABLES
        (
            (SELECT 'James Spader'           AS NODE_NAME),
            (SELECT  1 AS HOP_ID, 'acted'    AS EDGE_LABEL),
            (SELECT -2 AS HOP_ID, 'directed' AS EDGE_LABEL)
        ),
        RINGS => 2
    )
)
WHERE QUERY_NODE1_NAME != 'James Spader'

Querying for Commonalities

Queries can make use of the find_common_labels option to list labels shared by both source & target node, as well as labels shared by edges in the result paths.

A graph of movies and their actors & directors can be queried, for instance, to return the common occupations within filmmaking between Al Pacino and those who have directed movies in which he has acted. Here, the query starts with the Al Pacino actor node, looks within two hops for directors (Al Pacino->movie->directed by), and returns those directors along with occupations shared by Al Pacino and each one:

Query for Common Labels Example
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
EXECUTE FUNCTION QUERY_GRAPH
(
    GRAPH => 'example_graph_label.imdb',
    QUERIES => INPUT_TABLES
    (
        (SELECT 'Al Pacino' AS NODE_NAME),
        (SELECT 'director' AS TARGET_NODE_LABEL)
    ),
    RINGS => 2,
    ADJACENCY_TABLE => 'example_graph_label.imdb_fcl',
    OPTIONS => KV_PAIRS
    (
        force_undirected = 'true',
        find_common_labels = 'true'
    )
)

Supplementing Queried Graph Data

As graph queries ultimately produce standard SQL result sets, they can be used in larger SQL queries as joins or sub-selects to add data to result sets or to filter data out of them.

A graph of movies and their actors & directors can be queried, for instance, to return the actors in Jean Reno movies, and that result can be joined with a table of actor biographical data to also return the ages of those actors. Here, the query starts with the Jean Reno actor node, looks within two hops for actors (Jean Reno->movie->acted in), and returns those actors along with their respective current ages by subtracting their corresponding date of birth (dob column) in the biographical table (person) from the current date:

Supplementing Graph Query Example
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
SELECT
    QUERY_NODE_NAME_TARGET AS Actor,
    DATEDIFF(YEAR, p.dob, CURRENT_DATE()) AS Age
FROM TABLE
(
    QUERY_GRAPH
    (
        GRAPH => 'example_graph_label.imdb',
        QUERIES => INPUT_TABLES
        (
            (SELECT 'Jean Reno' AS NODE_NAME),
            (SELECT 'actor' AS TARGET_NODE_LABEL)
        ),
        RINGS => 2,
        OPTIONS => KV_PAIRS
        (
            force_undirected = 'true',
            result_table_index = '2'
        )
    )
)
JOIN person p ON QUERY_NODE_NAME_TARGET = name

MATCH_GRAPH

Matches an existing graph to a dataset using one of the supported solver types and sample points which are defined using unique match identifiers and combinations. The MATCH_GRAPH function can be called either within a SELECT statement as a table function or within an EXECUTE FUNCTION call.

Table Function Syntax
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
SELECT * FROM TABLE
(
    MATCH_GRAPH
    (
        GRAPH => '[<schema name>.]<graph name>',
        SAMPLE_POINTS => <INPUT_TABLE(<select statement>) | INPUT_TABLES((<select statement>)[,...])>,
        SOLVE_METHOD => '<solver type>',
        [OPTIONS => <KV_PAIRS>('<option name>' = '<option value>'[,...])]
    )
)
EXECUTE FUNCTION Syntax
1
2
3
4
5
6
7
8
EXECUTE FUNCTION MATCH_GRAPH
(
    GRAPH => '[<graph schema name>.]<graph name>',
    SAMPLE_POINTS => <INPUT_TABLE(<select statement>) | INPUT_TABLES((<select statement>)[,...])>,
    SOLVE_METHOD => '<solver type>',
    SOLUTION_TABLE => '[<table schema name>.]<table name>',
    [OPTIONS => <KV_PAIRS>('<option name>' = '<option value>'[,...])]
)
ParameterDescription
GRAPHName of the graph to match
SAMPLE_POINTSSample points used to match an underlying geospatial graph specified using the SQL INPUT_TABLE or INPUT_TABLES function. Sample points are specified as identifiers, which are grouped into combinations.
SOLVE_METHOD

The type of solve method to use for the operation; review Match Identifier Combinations for more information.

SolverDescriptionCPU Parallel
MARKOV_CHAINMatches sample points to the graph using the Hidden Markov Model (HMM)-based method, which conducts a range-tree closest-edge search to find the best combinations of possible road segments for each sample point to create the best route. The route is secured one point at a time, so the prediction is corrected after each point. This solution type is the most accurate, but also the most computationally intensive.X
MATCH_BATCH_SOLVESMatches each provided sample source and destination pair using the shortest path between the points.X
MATCH_CHARGING_STATIONSMatches a given sample source and destination pair to the optimal recharging stations along the route (for EVs).X
MATCH_CLUSTERS

Matches the graph nodes with a cluster index using the Louvain clustering algorithm.

Note

Parallel running of this solver is experimental and can be invoked with the parallel_clustering option.

X*
MATCH_LOOPSMatches closed loops (Eulerian paths) originating and ending at each graph node between min and max hops (levels).X
MATCH_OD_PAIRSMatches sample points to find the most probable path between origin and destination (OD) pairs with given cost constraints.X
MATCH_SIMILARITYComputes the Jaccard similarity between vertex pairs and N-level intersections within M hops.X
MATCH_SUPPLY_DEMANDMatches sample generic supply depots to generic demand points using abstract transportation (referred to as trucks). Each route is determined by a truck's ability (size) to service demand at each demand point.X

SOLUTION_TABLEOnly applicable when using EXECUTE FUNCTION syntax. Name of the table to store the solution in [schema_name.]table_name format, using standard name resolution rules and meeting table naming criteria
OPTIONS

Optional indicator that a comma-delimited list of connection option/value assignments will follow.

OptionDescription
aggregated_outputFor the MATCH_SUPPLY_DEMAND solver only. When set to true (default), each record in the output table shows a particular supplier's scheduled cumulative round-trip path (MULTILINESTRING) and the corresponding aggregated cost. Otherwise, each record shows a single scheduled supplier route (LINESTRING) towards a particular demand site with its corresponding cost.
batch_tsm_modeFor the MATCH_SUPPLY_DEMAND solver only. If set to true (non-default), each supplier is limited to drop off 1 unit of supply at each demand site visited per trip, in order to model the traveling salesman problem.
chain_widthFor the MARKOV_CHAIN solver only. Length of the sample points lookahead window within the Markov kernel; the larger the number, the more accurate the solution. The default value is 9.
charging_candidatesFor the MATCH_CHARGING_STATIONS solver only. Solver searches for this many stations closest to each base charging location found by capacity. The default value is 10.
charging_capacityFor the MATCH_CHARGING_STATIONS solver only. The maximum charging capacity of an EV (distance in meters or time in seconds, depending on the unit of the graph weights). The default value is 300000.
charging_penaltyFor the MATCH_CHARGING_STATIONS solver only. The penalty for fully charging. The default value is 30000.
cluster_quality_metricFor the MATCH_CLUSTERS solver only. The quality metric for Louvain modularity optimization solver.
destinationOptional WKT ending point from SAMPLE_POINTS for the solver. The default behavior for the endpoint is to use time to determine the destination point. The default value is POINT NULL.
enable_reuseFor the MATCH_SUPPLY_DEMAND solver only. If set to true (non-default), all suppliers can be scheduled for additional rounds of supply drop-off from their originating depots.
filter_folding_pathsFor the MARKOV_CHAIN solver only. When set to true (non-default), the paths per sequence combination is checked for folding over patterns and can significantly increase the execution time depending on the chain width and the number of GPS samples.
gps_noiseGPS noise value (in meters) to remove redundant sample points. Use -1 to disable noise reduction. The default value (5.0) accounts for 95% of point variation (±5 meters)
intersection_penaltyThis will add an additional weight over the edges labeled as intersection if the add_turn option was invoked during graph creation. The default value is 0.0.
inverse_solveFor the MATCH_BATCH_SOLVES solver only. Solves source-destination pairs using inverse shortest path solver.
left_turn_penaltyThis will add an additional weight over the edges labeled as left_turn if the add_turn option was invoked during graph creation. The default value is 0.0.
max_combinationsFor the MATCH_SUPPLY_DEMAND solver only. This is the cutoff for the number of generated combinations for sequencing the demand locations. The maximum number of combinations is 2000000. The default value is 10000.
max_hopsFor the MATCH_SIMILARITY solver only. Solver searches within this many hops for source and target node pairs to compute the Jaccard scores. The default value is 3.
max_loop_levelFor the MATCH_LOOPS solver only. Finds closed loops around each node deducible not more than this maximal hop (level) deep.
max_num_clustersFor the MATCH_CLUSTERS solver only. If set, processing terminates when the number of clusters after a cycle is at or below this number; thus, the solution will have at most this many clusters in it.
max_num_threadsFor the MARKOV_CHAIN solver only. If specified value is greater than 0 (default), the maximum number of threads will not be greater than the specified value. It can be lower due to the memory and number of cores available. The default value allows the algorithm to set the optimal number of threads within these constraints.
max_stopsFor the MATCH_SUPPLY_DEMAND solver only. If specified (greater than zero), a supplier can at most have this many stops (demand sites) in one round trip; otherwise, it is unlimited. If enable_reuse is on, this condition will be applied separately at each round-trip use of the same supplier.
max_supply_combinationsFor the MATCH_SUPPLY_DEMAND solver only. This is the cutoff for the number of generated combinations for sequencing the supply locations, when permute_supplies is true. The default value is 10000.
max_trip_costFor the MATCH_SUPPLY_DEMAND solver only. If this constraint is greater than 0 (default), then the suppliers will skip traveling from one demand site to another if the cost between them is greater than this number (distance or time). The default value means no check is performed.
min_loop_levelFor the MATCH_LOOPS solver only. Finds closed loops around each node deducible not less than this minimal hop (level) deep.
num_cyclesFor the MATCH_CLUSTERS solver only. If this is greater than 0 (default), then at most this many 2-step clustering exchange cycles will be performed; otherwise, processing will continue until quality does not improve across iterations.
num_loops_per_cycleFor the MATCH_CLUSTERS solver only. If this is greater than 0 (default), then at most this many best-fit calculations for all nodes will be attempted in the first step of each cycle; otherwise, processing will continue until the overall best-fit quality does not improve beyond a pre-defined epsilon threshold value.
num_output_clustersFor the MATCH_CLUSTERS solver only. If this is greater than 0 (default), then at most this many of the top clusters will be output after sorting them from most dense to least dense; otherwise, all clusters will be output.
num_segmentsMaximum number of potentially matching road segments for each sample point. The default is 3.
output_batch_sizeFor the MATCH_LOOPS solver only. Uses this value as the batch size of the number of loops in flushing (inserting) to the output table.
output_tracksFor the MATCH_SUPPLY_DEMAND solver only. When it is true (non-default), the output will be in tracks format for all the round trips of each supplier in which the timestamps are populated directly from the edge weights starting from their originating depots.
paired_similarityFor the MATCH_SIMILARITY solver only. When set to true (default), the Jaccard score will be computed between each pair; otherwise, the Jaccard score will be computed from the intersection set between the source and target nodes.
partial_loadingFor the MATCH_SUPPLY_DEMAND solver only. When false (non-default), suppliers do not off-load at the demand site side if the remainder is less than the site's demand.
permute_supplies

For the MATCH_SUPPLY_DEMAND solver only. When true (default), suppliers are permuted for the demand site combinations during the optimization phase.

Note

This option increases optimization time significantly--use of max_combinations in tandem is recommended to prevent prohibitively long runs.

restricted_type

For the MATCH_SUPPLY_DEMAND solver only. If specified, this supplier type will be restricted from routes traversing edges with the MSDO_ODDEVEN_RESTRICTED label. This models restrictions that exist, for example, in Jakarta, Indonesia.

Possible values:

  • none - Do not apply any restrictions.
  • odd - Apply odd/even rule restrictions to odd ID suppliers
  • even - Apply odd/even rule restrictions to even ID suppliers
right_turn_penaltyThis will add an additional weight over the edges labeled as right_turn if the add_turn option was invoked during graph creation. The default value is 0.0.
round_tripFor the MATCH_SUPPLY_DEMAND solver only. When set to true (default), each supplier will have to return to the origination site; otherwise, the route is considered terminated at the final demand site.
search_limitFor the MATCH_LOOPS solver only. Searches within this limit of nodes per vertex to detect loops. The value zero means there is no limit.
search_radiusMaximum search radius used when snapping sample points onto potentially matching surrounding segments. The default value (0.001) corresponds to approximately 100 meters.
server_idIndicates which graph server(s) to send the request to. Default is to send to the server, among those containing the corresponding graph, that has the most computational bandwidth.
service_limitFor the MATCH_SUPPLY_DEMAND solver only. If specified, any supplier's total service cost (distance or time) will be limited by the specified value including multiple rounds of drop-off (if set). The default value is 0.0.
service_radiusFor the MATCH_SUPPLY_DEMAND solver only. If specified, it filters the demands outside this radius, centered around the supplier's originating location (distance or time). The default value is 0.0.
sharp_turn_penaltyThis will add an additional weight over the edges labeled as sharp_turn or u_turn if the add_turn option was invoked during graph creation. The default value is 0.0.
sourceOptional WKT starting point from SAMPLE_POINTS for the solver. The default behavior for the endpoint is to use time to determine the starting point. The default value is POINT NULL.
traversal_node_limitFor the MATCH_SIMILARITY solver only. Limits the traversal depth if it reaches this many nodes. The default value is 1000.
unit_unloading_costFor the MATCH_SUPPLY_DEMAND solver only. The unit cost per load amount to be delivered. If this value is greater than 0 (default) then the additional cost of this unit load multiplied by the total dropped load will be added over to the trip cost to the demand location.

MATCH_GRAPH Examples

Using the EXECUTE FUNCTION syntax necessitates the SOLUTION_TABLE parameter to store the match results, where using the table function syntax will return the results directly.

Table Function Example
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
SELECT * FROM TABLE
(
    MATCH_GRAPH
    (
        GRAPH => 'big_cities_graph',
        SAMPLE_POINTS => INPUT_TABLE
        (
            SELECT
                city1_location AS ORIGIN_WKTPOINT,
                city2_location AS DESTINATION_WKTPOINT,
                trip_time AS OD_TIME
            FROM big_cities_map
        ),
        SOLVE_METHOD => 'match_od_pairs'
    )
)
EXECUTE FUNCTION Example
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
EXECUTE FUNCTION MATCH_GRAPH
(
    GRAPH => 'big_cities_graph',
    SAMPLE_POINTS => INPUT_TABLE
    (
        SELECT
            city1_location AS ORIGIN_WKTPOINT,
            city2_location AS DESTINATION_WKTPOINT,
            trip_time AS OD_TIME
        FROM big_cities_map
    ),
    SOLVE_METHOD => 'match_od_pairs',
    SOLUTION_TABLE => 'big_cities_graph_matched'
)

ALTER GRAPH

Alters an existing graph.

ALTER GRAPH Syntax
1
2
3
4
5
6
7
8
ALTER GRAPH [<schema name>.]<graph name> MODIFY
(
    [EDGES => <INPUT_TABLE(<select statement>) | INPUT_TABLES((<select statement>)[,...])>,]
    [NODES => <INPUT_TABLE(<select statement>) | INPUT_TABLES((<select statement>)[,...])>,]
    [WEIGHTS => <INPUT_TABLE(<select statement>) | INPUT_TABLES((<select statement>)[,...])>,]
    [RESTRICTIONS => <INPUT_TABLE(<select statement>) | INPUT_TABLES((<select statement>)[,...])>,]
    [OPTIONS => <KV_PAIRS>('<option key>' = '<option value>'[,...])]
)
ParameterDescription
<schema name>Name of the schema containing the graph to alter
<graph name>Name of the graph to alter
EDGESGraph component, provided as column names, expressions, or constants using the SQL INPUT_TABLE or INPUT_TABLES function, to use for identifying the edges of the graph; review Components and Identifiers and Identifier Combinations for more information
NODESGraph component, provided as column names, expressions, or constants using the SQL INPUT_TABLE or INPUT_TABLES function, to use for identifying the nodes of the graph; review Components and Identifiers and Identifier Combinations for more information
WEIGHTSGraph component, provided as column names, expressions, or constants using the SQL INPUT_TABLE or INPUT_TABLES function, to use for identifying the weights of the graph; review Components and Identifiers and Identifier Combinations for more information
RESTRICTIONSGraph component, provided as column names, expressions, or constants using the SQL INPUT_TABLE or INPUT_TABLES function, to use for identifying the restrictions of the graph; review Components and Identifiers and Identifier Combinations for more information
OPTIONS

Indicator that a list of connection option/value assignments will follow, passed as a comma-delimited list of key/value pairs to the KV_PAIRS function

OptionDescription
add_table_monitorAdds a table monitor to every table used in the creation of the graph; this table monitor will trigger the graph to update dynamically upon inserts to the source table(s). Note that upon database restart, if save_persist is also set to true, the graph will be fully reconstructed and the table monitors will be reattached. For more details on table monitors, see Table Monitors. The default value is false.
add_turnsAdds dummy "pillowed" edges around intersection nodes where there are more than three edges so that additional weight penalties can be imposed by the solve endpoints (increases the total number of edges). The default value is false.
allow_multiple_edgesEnables multigraph capability--pairs of nodes can be connected by more than one edge. Without this option, undirected graphs can only have one edge between each pair of nodes, and directed graphs can have one edge in each direction between each pair of nodes--"duplicate" edges are discarded. The default value is true.
cluster_graph_schemaIf export_graph_schema is true, groups nodes based on the Louvain clustering algorithm, converting the graph into a label-based schema.
export_graph_schema

Exports a graph's schema in Graphviz DOT format; this is made available in two ways:

  • visually, by clicking View Schema in the result of an ALTER GRAPH command in a SQL Block within Workbench
  • as text, under the info and then dot keys of the response to a native API call to /execute/sql
graph_tableThe graph is created as a table with the given name, in [schema_name.]table_name format, using standard name resolution rules and meeting table naming criteria. The table will have the following identifier columns: EDGE_ID, EDGE_NODE1_ID, EDGE_NODE2_ID.
label_delimiterIf specified, the delimiter to use when parsing edge labels. All labels separated by this delimiter will be applied to the corresponding edge.
save_persistIf set to true, the graph will be saved in the persist directory (see the config reference for more information). If set to false, the graph will be removed when the graph server is shutdown. The default value is false.
schema_edge_labelkeysIf export_graph_schema is true, generates the label-based schema by collapsing edges based on the their label keys; otherwise, schema edges are created from the edge labels.
schema_node_labelkeysIf export_graph_schema is true, generates the label-based schema by collapsing nodes based on the their label keys; otherwise, schema nodes are created from the node labels.
simplifySimplifies the graph topology at 2-valence by collapsing edge.
use_rtreeUse a range tree structure to accelerate and improve the accuracy of snapping, especially to edges.

To alter the weights of a graph and allow it to survive a database restart:

ALTER GRAPH Example
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
ALTER GRAPH big_cities_graph MODIFY
(
    WEIGHTS => INPUT_TABLE
    (
        SELECT
            REMOVE_NULLABLE(ST_MAKELINE(city1_location, city2_location)) AS EDGE_WKTLINE,
            REMOVE_NULLABLE(ST_DISTANCE(city1_location, city2_location)) AS VALUESPECIFIED
        FROM big_cities_map
    ),
    OPTIONS => KV_PAIRS('save_persist' = 'true')
)

DROP GRAPH

Removes an existing graph.

DROP GRAPH Syntax
1
DROP GRAPH [<schema name>.]<graph name>
ParameterDescription
<schema name>Name of the schema containing the graph to remove
<graph name>Name of the existing graph to drop.

To drop a graph, big_cities_graph:

DROP GRAPH Example
1
DROP GRAPH big_cities_graph

SHOW GRAPH

Outputs the request used to create one or more existing graphs.

SHOW GRAPH Syntax
1
SHOW GRAPH [<schema name>.]<graph name>
SHOW GRAPH (All within Schema) Syntax
1
SHOW GRAPH <schema name>.*
SHOW GRAPH (All) Syntax
1
SHOW GRAPH *
ParameterDescription
<schema name>Name of the schema containing the graph(s) to show
<graph name>Name of the existing graph for which the creation request will be output

Note

The response to SHOW GRAPH is a single-column result set with the creation request in the DDL column. The request shown will depend on the way in which the graph was created (SQL vs. API/REST):

  • SQL - output will be the SQL DDL statement used to create the graph
  • API/REST - output will be the JSON request, wrapped by the API or sent directly via REST, used to create the graph

For example, to output the creation request for a graph, big_cities_graph:

SHOW GRAPH Example
1
SHOW GRAPH big_cities_graph

DESCRIBE GRAPH

Outputs the configuration of one or more existing graphs.

DESCRIBE GRAPH Syntax
1
DESC[RIBE] GRAPH [<schema name>.]<graph name>
DESCRIBE GRAPH (All within Schema) Syntax
1
DESC[RIBE] GRAPH <schema name>.*
DESCRIBE GRAPH (All) Syntax
1
DESC[RIBE] GRAPH *
ParameterDescription
<schema name>Name of the schema containing the graph(s) to describe
<graph name>Name of the existing graph for which the configuration will be output

The response to DESCRIBE GRAPH is a multi-column result set.

Output ColumnDescription
GRAPH_NAMEName of the graph
GRAPH_SERVER_IDID of the server on which the graph is hosted
DIRECTEDWhether the edges of the graph have directionality or are bidirectional
NUM_NODESNumber of nodes in the graph
NUM_EDGESNumber of edges in the graph
NUM_BYTESBytes of memory used by the graph
IS_PERSISTEDWhether the graph will survive a database restart or not
IS_SYNC_DBWhether the graph is recreated from its source tables upon database startup
GRAPH_OWNER_USER_NAMEName of user who created the graph
GRAPH_OWNER_RESOURCE_GROUPResource group for the graph; the effective resource group of the graph creator at the time it was created
RESOURCE_CAPACITYAllocated memory limit for this graph
IS_PARTITIONEDWhether the graph is distributed across the available graph servers
HAS_INSERT_TABLE_MONITORWhether the graph has an associated insert table monitor or not
ORIGINAL_REQUESTRequest used to create the graph, similar to what is returned by SHOW GRAPH

To show the configuration for a graph, big_cities_graph:

DESCRIBE GRAPH Example
1
DESCRIBE GRAPH big_cities_graph