Graph Gurus Episode 31: GSQL Writing Best Practices Part 1

Graph Gurus 31
GSQL Writing Best Practices
Part 1 - Thinking in GSQL
1

© 2020 TigerGraph. All Rights Reserved
Today's Host
2
David Ronald
Director of Product Marketing
● BSc in Applied Physics from Strathclyde University, MSc
in Optoelectronic & Laser Devices from St Andrews
● Prior work in artificial intelligence, natural linguistic
programming and telecommunications technology
● 18+ years in tech industry

Today's Presenter
3
Xinyu Chang
Director of Customer Solutions
● Co-authored GSQL, TigerGraph’s query language,
and expertise in graph solutions and algorithms
● Developed solutions for many Fortune 50
companies
● Over 5 years with TigerGraph

Some Housekeeping Items
● Although your phone is muted we do want to answer your questions -
submit your questions at any time using the Q&A tab in the menu
● The webinar is being recorded and will uploaded to our website shortly
(https://www.tigergraph.com/webinars/) and the URL will be emailed
you
● If you have issues with Zoom please contact the panelists via chat
4

Thinking in GSQL - Agenda
5
1. Review the Basics
2. The Thinking Steps
3. Example 1
4. Example 2
5. Example 3

The Basics
Data Declare Session
Query Logic Session
7

The Basics
8
GSQL traverses the graph from one set of vertices, through selected edges originated from the
starting set, to another set of vertices:
cardiology
cardiac
electrophysiology,
echocardiog
raphy
Cardiology

The Basics
The query always starts with a seed
vertex set - that is where your traversal
logic originates from
Start from a single vertex:
CREATE QUERY example(VERTEX input_ver) FOR GRAPH g {
start_set = {input_ver};
….
}
● Here start_set is the variable
name of vertex set variable
● A vertex set variable is where
a SELECT statement starts from
● A vertex set variable is also the
outcome of a SELECT
statement
● In this case the vertex set
start_set only contains one
single vertex that is the input
parameter
● This is the recommended way
to start your traversal logic
9

The Basics
Start from a set of vertex:
CREATE QUERY example(SET<VERTEX> input_set) FOR
GRAPH g {
start_set = input_set;
….
}
Start from a type of vertex, and all vertices:
CREATE QUERY example() FOR GRAPH g {
start_set = {Claim.*};
start_set2 = {ANY};
….
}
10

The Basics
Find all the claims of a patient
11
CREATE QUERY GetClaims(vertex<User> input_patient) FOR GRAPH Social {
Start = {input_patient};
Claims = SELECT t FROM Start:s-(reverse_Associated:e)-Claim:t;
PRINT Claims;
}
Input
Patient
ClaimA
ClaimB
ClaiC
Start Claimsreverse_Associated
s
s
s
t
t
t
e
e
e
● Start is a vertex set initialized by the input
vertex input_patient
● FROM clause finds edges which match the
pattern: source vertex is in Start, edge type
is reverse_Associated, and target vertex
is restricted to User type.
● For each edge satisfies the conditions in
the FROM clauses, s, e and t are aliases
of source vertex, edge and target vertex.
● s, e and t are not keywords, you can
rename them.
● Claims is a new vertex set equal to t.
11

The Basics
resultSet = SELECT vSet
FROM ( edgeSet | vertexSet )
[whereClause] [accumClause]
[postAccumClause] [havingClause]
[orderClause] [limitClause] ;
• FROM: select active vertices & edges.
• WHERE: conditionally filter the active sets
• ACCUM: iterate on edge set; compute with accumulators
• POST-ACCUM: iterate on vertex sets; compute with accumulators
• HAVING: conditionally filter the result set
• ORDER BY: sort
• LIMIT: max number of items
• SELECT: result from source or target set
12
ACCUM
POST-ACCUM
WHERE
FROM
LIMIT
SELECT
ORDER BY
HAVING

© 2020 TigerGraph. All Rights Reserved 13
Accumulators
A
E
B
D
C
Accumulator
2
1
1
Accumulators are special type of variables that accumulate information about the graph during the traversal
Accumulating phase 1: receiving messages, the messages received will be temporarily put to a bucket that
belongs to the accumulator
Accumulating phase 2: The accumulator will aggregate the messages it received based on its accumulator
type - the aggregated value will become the accumulator’s value, and its value can be accessed
Graph
2,1,1
Value: 0Value: 4

Accumulators
14
For example:
The teacher collects test papers from all
students and calculates an average score.
Teacher: accumulator
Student: vertex/edge
Test paper: message sent to accumulator
Average Score: final value of accumulator
Phase 1: teacher collects all the test paper
Phase 2: teacher grades it and calculate
the average score.

Local Accumulators:
• Each selected vertex has its own
accumulator
• Local means per vertex - each vertex does
its own processing and considers what it
can see/read/write
15
Global Accumulators:
• Stored in stored globally, visible
to all
• All vertices and edges have
access
e.x. SumAccum @A;
4
@@B
2,1,1
15
@A
1,4,10
10
4
1
2
1
1
e.x. SumAccum @@B;
@A
@A
@A
@A
Accumulators

Accumulators
The GSQL language provides many different accumulators, which follow the
same rules for receiving and accessing data - each of them, however, has its
unique way of aggregating values
16
Old Value:
2
New Value:
11
1, 3, 5
1
3 5
SumAccum<int>
Old Value:
2
New Value:
5
1, 3, 5
1 3
MaxAccum<int>
Old Value:
2
New Value:
1
1, 3, 5
1 3
MinAccum<int>
Old Value:
2
New Value:
2.75
1, 3, 5
1 3
AvgAccum
5 5 5
Computes and stores the
cumulative sum of numeric
values or the cumulative
concatenation of text values.
The MaxAccum types
calculate and store the
cumulative maximum of
a series of values.
Calculates and stores
the cumulative mean of
a series of numeric
values.
The MinAccum types
calculate and store the
cumulative minimum of
a series of values.

The GSQL language provides many different accumulators, which follow the
same rules for receiving and accessing data - each of them, however, has its
unique way of aggregating values.
17
Old Value:
[2]
New Value:
[2,1,3,5]
1, 3, 3, 5
1 3 5
SetAccum<int>
Old Value:
[2]
New Value:
[2,1,5,3,3]
1, 5, 3, 3
1 3
ListAccum<int>
Old Value:
[1->1]
New Value:
1->6
5->2
1->2
1->3
5->2
1->2 1->3
MapAccum<int,SumAccum<int>>
Old Value:
[userD,150]
New Value:
[userC,300,
UserD,150,
userA,100]
userC,300
userA,100
(“userA”, 100)
HeapAccum<Tuple>
5 5->23 3 (“userC”, 300)
Maintains a collection of
unique elements.
Maintains a sequential
collection of elements.
Maintains a collection of
(key -> value) pairs.
Maintains a sorted collection of
tuples and enforces a
maximum number of tuples in
the collection
Accumulators

The Thinking Steps
1. Design a traversal plan
Where to start from? What are the steps? What edge to use for
each step?
2. Choose and define the accumulators
What needs to be in the result? Where is the info needed? What
accumulator to use?
3. Populate the accumulators
How do we gather the info to the right place?
4. Print the result
19

Example 1
20
Order the specialties in descending order
by the number of Claims

The Thinking Steps
Where to start from? Specialty? Claim?
What are the steps?
What edge to use for each step?
21
Claim -> Prescriber -> SubSpecialty -> Specialty
submit, subspecialty_prescriber,
specialty_sub_specilaty

The Thinking Steps
What is the final result?
Where is the info needed for the final result?
What accumulator to use?
22
Specialties order by number of the claims
Number of claims is a integer summed value. So
we are using SumAccum<INT>
We need to count the number of claims, so the info
is on Claim vertexes

The Thinking Steps
23
Pass the number of claims from claims vertexes to
specialty vertexes

Example 2
24
Given a prescriber, who are the top k other
prescribers sharing the most patient?

The Thinking Steps
Where to start from?
What are the steps?
25
Input Prescriber -> Claims -> Patients
-> Claims -> Prescribers
Submit, associate, submit, associate
Input Prescriber

The Thinking Steps
26
Top k prescribers with most common patients
SumAccum? SetAccum?
Patient vertexes

The Thinking Steps
27
Pass patient IDs to the prescribers

Example 3
28
Given a prescriber, who are the other
prescribers being referred?
Refer: a patient has a second claims that are no
longer than a given period of time after the first
claim. The prescriber of the first claim referred
the prescriber of the second claim.

The Thinking Steps
Where to start from?
What are the steps?
29
Input Prescriber -> Claims -> Patients
-> Claims -> Prescribers
Submit, associate, submit, associate
Input Prescriber

The Thinking Steps
30
The referral edges between input prescribers and
referred prescribers
ListAccum of dates
Claims of the input prescriber, patient
Other Claims of the patient

The Thinking Steps
31
Pass the dates of claims of the input prescriber to
the patient vertex

Q&A
Please submit your questions via the Q&A tab in Zoom

More Questions?
Join our Developer Forum
https://groups.google.com/a/opengsql.org/forum/#!forum/gsql-users
Sign up for our Developer Ofﬁce Hours (every Thursday at 11 AM PDT)
https://info.tigergraph.com/officehours
33

Additional Resources
Start Free at TigerGraph Cloud Today!
https://www.tigergraph.com/cloud/
Test Drive Online Demo
https://www.tigergraph.com/demo
Download the Developer Edition
https://www.tigergraph.com/download/
Guru Scripts
https://github.com/tigergraph/ecosys/tree/master/guru_scripts
34

Upcoming Online Events
Roundtable on Fraud Detection with Graph and
Machine Learning
Tuesday, March 24, at 11am PDT
https://www.experoinc.com/get/fraud-with-tigergraph
35
Roundtable on Fraud
Detection with Graph and
Machine Learning

Graph Gurus Episode 31: GSQL Writing Best Practices Part 1

More Related Content

Similar to Graph Gurus Episode 31: GSQL Writing Best Practices Part 1 (20)

More from TigerGraph (20)

Recently uploaded (20)

Graph Gurus Episode 31: GSQL Writing Best Practices Part 1