OrientDB - Voxxed Days Berlin 2016

@ldellaquila#VoxxedBerlin #OrientDB
Platinum Sponsor
- the 2nd generation
of
(Multi-Model) NoSQL
And why GraphDB are the starting point
of this revolution

Luigi Dell’Aquila
Director of Consulting
OrientDB LTD
Twitter: @ldellaquila
http://www.orientdb.com

“90% of the data  
in the world today  
has been created  
in the last two years alone.”
- IBM

Order #134
(Order) John
(Provider)
Commodore
Amiga 1200
(Product)
Frank
(Customer)
Monitor 40”
(Product)
Mouse
(Product)
Bruno
(Provider)

Order #134
(Order) John
(Provider)
Commodore
Amiga 1200
(Product)
Frank
(Customer)
Monitor 40”
(Product)
Mouse
(Product)
Bruno
(Provider)
Data by itself has little value, it’s the
relationship
between data that gives it
incredible value

Order #134
(Order) John
(Provider)
Commodore
Amiga 1200
(Product)
(Sells)
Frank
(Customer)
(Has)
(Makes)
Monitor 40”
(Product)
(Sells)
(Has)
Mouse
(Product)
Bruno
(Provider)
(Sells)
(Has)

Key/Value Databases
Document Databases
Graph Databases
Column Databases

Key/Value Databases
Document Databases Graph Databases
Column Databases

Why do most NoSQL products
avoid
managing relationships?

ID Name
10 John
11 John
24 Mike
28 Mike
ID Address
10 24
10 33
32 44
ID Location
24 Milan
33 London
18 Paris
18 Madrid
44 Moscow
Customer CustomerAddress Address
Is this
familiar?

What’s wrong
with JOIN?

A-Z
A-L M-Z
Imagine an
Address Book
where we want to find
Luigi’s phone number
Index Lookup: how does it work?

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

A-Z
A-L M-Z
A-L
A-D E-L
M-Z
M-R S-Z
A-D
A-B C-D
E-L
E-G H-L

A-Z
A-L M-Z
A-L
A-D E-L
M-Z
M-R S-Z
A-D
A-B C-D
E-L
E-G H-L
E-G
E-F G
H-L
H-J K-L

A-Z
A-L M-Z
A-L
A-D E-L
M-Z
M-R S-Z
A-D
A-B C-D
E-L
E-G H-L
E-G
E-F G
H-L
H-J K-L
Luigi
Found!
This lookup took 5 steps.
With millions of indexed
records, the tree depth
could be 1000’s of levels!

ID Name
10 John
11 John
24 Mike
28 Mike
ID Address
10 24
10 33
32 44
ID Location
24 Milan
33 London
18 Paris
18 Madrid
44 Moscow
Customer CustomerAddress Address
Joins are executed every time
you cross relationships
Querying million of records
joining 3-4 tables could
generate billions of
combinations

This is why the database
query performance
suffers as the database
increases in size
O(Log N)

PERFORMANCE
DATABASE SIZE
RDBMS performance on traversal

Solution: Graph Database!

“A graph database is any
storage system
that provides
index-free adjacency”
- Marko Rodriguez
(author of TinkerPop Blueprints)

Back to school:
Graph Theory crash course

Basic Graph
Luigi Berlin
Visited

Vertices and Edges can
have properties
Vertices are directed
* https://github.com/tinkerpop/blueprints/wiki/Property-Graph-Model
Property Graph Model*
Berlin
country: Germany
Luigi
company: OrientDB
have properties
have properties
Visited
year: 2016

Luigi Berlin
Visited
year: 2016
An Edge connects only 2 vertices
Use multiple edges to represent 1-N and
N-M relationships
Worked
year: 2016
1-N and N-M Relationships

Congrats! This is your diploma in
«Graph Theory»

How does a true*
Graph Database
manage relationships?
*a “Graph” layer on top of a DBMS doesn’t qualify as a true GraphDB

Luigi Berlin
Visited
year: 2015
#13:55
#15:99
Each element in the
Graph has own immutable
Record ID
#22:11
(Edge)
(Vertex)
(Vertex)
Each element in the
Record ID
Each element in the
Record ID

Connections use
persistent pointers
Luigi Antwerp
Visited
on: 2015
#13:55
#15:99out = #22:11
in = #22:11
#22:11
(Edge)
(Vertex)
(Vertex)
out = #13:55
in = #15:99

Luigi Antwerp
Visited
on: 2015
#13:55
#15:99out = #22:11
in = #22:11
#22:11
(Edge)
(Vertex)
(Vertex)
out = #13:55
in = #15:99

A Graph Database creates the
relationship just once
(when the edge is created)
VS
RDBMS computes the
relationship every time
you query a database

When you move from a RDBMS
to a Graph Database you jump
from a O(log N) speed to a near O(1)
With a Graph Database, the
traversing time is
not affected by database size!
This is huge in the BigData age

No costs to traverse relationships:
• Recommendation engines
• Social Applications
• Spatial Apps
• Master Data Management
• Information Clustering
John
Thriller
Comedy
Pulp
Fiction
Mr Bean
Theater
B
Theater
A
Theater C
NYC
San Josè
Lives in
Likes

So the Graph Model
Is the only solution to efficiently
manage relationships
But what about data complexity?
And data consistency?
And scaling?

RelationshipsComplexity>
Data Complexity >
Relational
Key Value
Column
Graph
Document
First generation NoSQL

Oracle
(RDBMS)
Redis or
Memcache
(Key/Value)
MongoDB
(DocDB)
Neo4j
(GraphDB)
Application
ETL
Primary
DB

Oracle
(RDBMS)
Redis or
Memcache
(Key/Value)
MongoDB
(DocDB)
Neo4j
(GraphDB)
Application
ETL
- No standard between NoSQL
products
- Multiple vendors = multiple skills
- ETL + synchronization code
is costly to write and maintain
- Performance and Reliability is
hard to predict

2nd Generation NoSQL
is
Multi-Model
2nd Generation NoSQL
is
Multi-model

GraphDocument
Object
Key/Value
Multi Model represents the
intersection
of multiple models in just one
product
What’s Multi-Model DBMS?

GraphDocument
Object
Key/Value
Multi Model represents the
intersection
of multiple models in just one
product
What’s Multi-Model DBMS?
- Just one product to learn and maintain
- Just one vendor relationship to manage
- No ETL, no synchronization required
- Performance and Reliability is easy to test from the beginning

`
{
”@rid": “12:382”,
”@class": ”Customer",
“name”: “Frank”,
“surname” : “Raggio”,
“phone” : “+39 33123212”,
“details”: {
“city”:”London",
“tags”:”millennial”
}
}
Frank
Order
M
akes
General purpose solution:
• JSON
• Schema-less
• Schema-full
• Schema-hybrid
• Nested documents
• Rich indexing and querying
• Developer friendly

RelationshipsComplexity>
Data Complexity >
Relational
Key Value
Column
Graph Multi-Model
Document
Second Generation NoSQL

With a true Graph, Document,
Key/Value and Object Oriented engine

FEATURES ORIENTDB)) MONGODB NEO4J
MYSQL)
(RDBMS)
Operational Database X X X
Graph Database X X
Document Database X X
Object-Oriented Concepts X
Schema-full, Schema-less, Schema mix X
User and Role & Record Level Security X
Record Level Locking X X X
SQL X X
ACID Transaction X X X
Relationships (Linked Documents) X X X
Custom Data Types X X X
Embedded Documents X X
Multi-Master Zero Configuration Replication X
Sharding X X
Server Side Functions X X X
Native HTTP Rest/ JSON X X
Embeddable with No Restrictions X
X
X

• Support for TinkerPop standard for
Graph DB: Gremlin language and
Blueprints API
• SQL + extensions for graphs
• JDBC driver to connect any BI tool
• HTTP/JSON support
• Drivers in Java, Node.js, Python,
PHP, .NET, Perl, C/C++ and more
API & Standards

Master Node Master Node
C
C C C
CC
C
Multi-master
Replication
Atomic, Consistent, Isolated and Durable (ACID) multi-statement transactions

Master Node Master Node
C
C C C
CC
C
Auto-
Discovered
Node

DEMO

50,000
Downloads per
Month from 200+
countries.
70+
Committers
contributing to
the product
1000s
Users from SMBs
to Fortune 10
Companies.
17+
Years of Research
have been put in
the product

Graph DBMS increased their popularity by 500% within the last 2 years
Document DBMS are the 3rd fastest growing category

Udemy Getting Started Training is
and Free
http://www.orientechnologies.com/getting-started
OrientDB Enterprise is Free for
Development
OrientDB Community is FREE for any
purpose (APACHE 2 license)

Thank you!
Luigi Dell’Aquila
@ldellaquila
http://www.orientdb.com
Q/A

OrientDB - Voxxed Days Berlin 2016

More Related Content

What's hot (12)

Viewers also liked (10)

Similar to OrientDB - Voxxed Days Berlin 2016 (20)

More from Luigi Dell'Aquila (9)

Recently uploaded (20)

OrientDB - Voxxed Days Berlin 2016