OrientDB - the 2nd generation of (Multi-Model) NoSQL - Devoxx Belgium 2015

@ldellaquila#Devoxx #OrientDB
Luigi Dell’Aquila
Director of Consulting
Orient Technologies LTD
Twitter: @ldellaquila
http://www.orientdb.com
OrientDB - the 2nd generation
of
(Multi-Model) NoSQL
And why GraphDB are the starting point of this revolution

“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
Index
algorithms
are
all

similar
and
based
on

balanced
trees

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 Antwerp
Visited

Vertices
and
Edges
can

have
properties
Vertices
are
directed
*
https://github.com/tinkerpop/blueprints/wiki/Property-‐Graph-‐Model
Property Graph Model*
Antwerp

country:
Belgium
Luigi

company:

OrientTechnologies
Vertices
and
Edges
can

have
properties
Vertices
and
Edges
can

have
properties
Visited

on:
2015

Luigi Antwerp
Visited

on:
2015
An
Edge
connects
only
2
vertices

Use
multiple
edges
to
represent
1-‐N
and

N-‐M
relationships
Worked

on:
2015
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 Antwerp
Visited

on:
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

Luigi Antwerp
Visited

on:
2015
#13:55
#15:99
Connections use
persistent pointers
out = #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

Luigi Lyon
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

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

• 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
Multi-Master Replication, Sharding and Auto-Discovery to Simplify Ops
+200k Tps on Commodity Hardware

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 - the 2nd generation of (Multi-Model) NoSQL - Devoxx Belgium 2015

More Related Content

What's hot

Similar to OrientDB - the 2nd generation of (Multi-Model) NoSQL - Devoxx Belgium 2015

More from Luigi Dell'Aquila

Recently uploaded

OrientDB - the 2nd generation of (Multi-Model) NoSQL - Devoxx Belgium 2015