Switching from the Relational to the Graph model

Switching from the
Relational to the
Graph model

Luca Garulli –
Founder and CEO @NuvolaBase Ltd
Author of OrientDB Doc/Graph DB
Oct 6th 2012 in Barcelona
(c) Luca Garulli Licensed under a Creative Commons Attribution-NoDerivs 3.0 Unported License Page 1
www.orientechnologies.com

One of the main resistences of
RDBMS users to pass to a NoSQL product
are related to the
complexity of the model:

Ok, NoSQL products are super for
BigData and BigScale
but...

...but what about the model?


What is the NoSQL answer
about managing complex domains?

Key-Value stores
Column-Based
Document database
Graph database

CAUTION!
This presentation will not use a
social like domain with
the classic paradigm of
friend-of-friendN
where the graph databases
are already widely used...

...But rather we will explore how
to think «graphically» with one of the
most common domains in the
enterprise world:

The old-classic CRM* domain

* today in 99% of the cases a RDBMS is used


Every developer knows
the Relational Model,
but who knows the
Graph one?

Back to school:
Graph Theory crash course


Basic Graph

NoSQL
Likes
Luca Matters
conference


Property Graph Model*
Vertices are directed

NoSQL
Luca Matters
Likes
name: Luca
surname: Garulli since: 2012
conference
company: NuvolaBase
editions: [Cologne, Barcelona]

Vertices and Edges
can have properties

* https://github.com/tinkerpop/blueprints/wiki/Property-Graph-Model

Property Graph Model

NoSQL
Luca Matters
conference

An Edge connects 2 vertices:
use multiple vertices to
represents 1-N and N-M
relationships

Property Graph Model
Pere

Luca
Likes Joins

FriendOf
NoSQL
Matters
Katja conference


Compliments, this is your diploma in
«Graph Theory»


Now go back
to our domain:
the CRM

Domain: minimal CRM

Customer Address

Registry system
Order system

Order Stock


Domain: minimal CRM

Customer Address

How does
Relational DBMS
Registry system
manage relationships?
Order system

Order Stock


Relational World: 1-1 Relationships

Customer Address
Id Name Address Id Location
10 Luca 34 34 Rome, London
11 Katja 44 44 Cologne
34 Sylvia 54 54 Rome
56 Mark 66 66 New Mexico
88 Steve 68 68 Palo Alto

JOIN Customer.Address -> Address.Id


Relational World: 1-N Relationships

Customer Address
Id Name Id Customer Location
10 Luca 24 10 Rome
11 Katja 33 10 London
34 Sylvia 44 34 Rome
56 Mark 66 11 Cologne
88 Steve 68 88 Palo Alto

Inverse JOIN Address.Customer -> Customer.Id


Relational World: N-M Relationships

Customer CustomerAddress Address
Id Name Id Address Id Location
10 Luca 10 24 24 Rome
11 Katja 10 33 33 London
34 Sylvia 34 24 44 Rome
56 Mark 66 Cologne
88 Steve 68 Palo Alto

Additional table with 2 JOINs
(1) CustomerAddress.Id -> Customer.Id and
(2) CustomerAddress.Address -> Address.Id

Relational World: N-M Relationships

10 Luca 10 24 24 Rome
56 Mark 66 Cologne

Additional table with 2 JOINs
(1) CustomerAddress.Id -> Customer.Id and
(2) CustomerAddress.Address -> Address.Id

What‟s wrong with the
Relational Model?


The JOIN is the evil!
10 Luca 10 24 24 Rome
56 Mark 66 Cologne

These are all JOINs executed
everytime you traverse a
relationship!
relationship

A JOIN means searching for a key in
another table

The first rule to improve performance
is indexing all the keys

Index speeds up searches but slows down
insert, updates and deletes

So in the best case a JOIN is a lookup
into in an index

This is done per single join!

If you traverse hundreds of relationships
you‟re executing hundreds of JOINs


Index Lookup
it is really that fast?


Index Lookup: how does it works?
A-Z

A-L M-Z

Think to an
Address Book
where we have to find
the Luca’s phone number


A-Z

A-L M-Z

A-L M-Z

A-D E-L M-R S-Z

Index algorithms are all
similar and based on
balanced trees


A-Z

A-L M-Z

A-L M-Z

A-D E-L M-R S-Z

A-D E-L

A-B C-D E-G H-L


A-Z

A-L M-Z

A-L M-Z

A-D E-L M-R S-Z

A-D E-L

A-B C-D E-G H-L

E-G H-L

E-F G H-J K-L


A-Z

A-L M-Z

A-L M-Z
Found!
A-D E-L M-R S-Z
Each lookup takes
A-D E-L
X steps, where X
A-B C-D E-G H-L
grows with the
E-G H-L index size!
E-F G H-J K-L

Luca


An index lookup is executed
for each JOIN

Querying more tables can easily
produce millions of JOINs/Lookups!

Here the rule: more entries
= more lookup steps = slower JOIN

Is there a better way to
manage relationships?


“A graph database is any
storage system
that provides
index-free adjacency”
- Marko Rodriguez


How does GraphDB manage
index-free relationships?


an Open Source (Apache 2)
document-graph NoSQL dbms
supports: transactions, extended-SQL,
Multi-Master replication, etc

OrientDB: traverse a relationship
The Record ID (RID)
is a Physical position

RID = #13:35 RID = #13:100

RID = #14:54

Lives
Luca Rome
out: [#13:35]
in: [#13:100]
out : [#14:54] Label : ‘Lives’ in: [#14:54]
label : ‘Customer’ label = ‘Address’
name : ‘Luca’ name = ‘Rome’


GraphDB handles relationships as a
physical LINK to the record
assigned when the edge is created

on the other side

RDBMS computes the
relationship every time you query a database

Is not that crazy?!

This means jumping from a
O(log N) algorithm to a near O(1)

traversing cost is not more affected
by database size!

This is huge in the BigData age


OrientDB in the Blueprints micro-benchmark,
on common hw, with a hot cache,
traverses 29,6 Millions
of records in less than 5 seconds

about 6 Millions of nodes traversed per sec!
Do not this at home with a
RDBMS*!

*unless you live in the Google‟s server farm

Create the graph in SQL
$luca> cd bin
$luca> ./console.sh
OrientDB console v.1.2.0-SNAPSHOT (www.orientdb.org)
Type 'help' to display all the commands supported.

orientdb> create vertex V set name = „Luca‟, label = „Customer‟
Created vertex #13:35 in 0.03 secs

orientdb> create vertex V set name = „Rome‟, label = „Address‟
Created vertex #13:100 in 0.02 secs

orientdb> create edge E from #13:35 to #13:100 set label = „Lives‟
Created edge #14:54 in 0.02 secs

Create the graph in Java
OGraphDatabase graph = new OGraphDatabase("local:/tmp/db/graph”);

ODocument luca = graph.createVertex();
luca.field(“name", “Luca");
luca.field(“label", “Customer");

ODocument rome = graph.createVertex();
rome.field(“name", “Rome”);
rome.field(“label", “Address”);

ODocument edge = graph.createEdge(luca, rome).field(“label”, “Lives”);
edge.save();

graph.close();


Query the graph in SQL
orientdb> select in[label=„Lives‟].out from V where label = „Address‟
and name = „Rome‟
---+--------+--------------------+--------------------+--------------------+
#| REC ID |label |out |in |
---+--------+--------------------+--------------------+--------------------+
0| 13:35|Luca |[#14:54] | |
---+--------+--------------------+--------------------+--------------------+
1 item(s) found. Query executed in 0.007 sec(s).

orientdb> select * from V where label = „Address‟ AND
in[label=„Lives‟].size() > 0
---+--------+--------------------+--------------------+--------------------+
#| REC ID |label |out |in |
---+--------+--------------------+--------------------+--------------------+
0| 13:100| Rome | |[#14:54] |
---+--------+--------------------+--------------------+--------------------+
1 item(s) found. Query executed in 0.007 sec(s).


Query the graph in Java
OGraphDatabase graph = new OGraphDatabase("local:/tmp/db/graph”);

// GET ALL THE THE CUSTOMER FROM ROME, ITALY
List<ODocument> result = graph.command( new OCommandSQL (
“select in[label=„Lives‟].out from V where label = „Address‟
and name = ?”)
).execute( “Rome”);

for( ODocument v : result ) {
System.out.println(“Result: “ + v.field(“label”) );
}

---------------------------------------------------------------------------------------
Result: Luca

Query vs traversal

Once you‟ve a well connected database
in the form of a Super Graph you can
cross records instead of query them!

All you need is some root vertices
where to start to traverse

Query vs traversal
Special
Customers Stocks
Customers

Luca John Sylvia
White
This is a Soap
root vertex Order Order
2332 8834


Query the graph in SQL
Customers Supposing that the root node #30:0 links all the
#30:0 Customer vertices

Get all the customers:

orientdb> select out.in from #30:0

Get all the customers who bought at least one „White Soap‟ product:

orientdb> select * from (
select out.in from #30:0
) where out.in.out[label=„Bought‟].in.name = „White Soap‟


Demo time!


NuvolaBase.com
The first
Graph Database
on the Cloud
always available
few seconds to setup it
use it from app & mobile

«Graphs change the way of modelling data»

Luca Garulli
Author of CEO at

Document-Graph NoSQL
Open Source project Ltd, London UK

www.twitter.com/lgarulli

Switching from the Relational to the Graph model

More Related Content

Similar to Switching from the Relational to the Graph model (15)

More from Luca Garulli (12)

Recently uploaded (20)

Switching from the Relational to the Graph model