Why Multi-Model is becoming mainstream and Graph databases are the starting point of this revolution

1. - the 2nd generation
of
(Multi-Model) NoSQL
And why GraphDB are the
starting point of this revolution
And why GraphDB are the
starting point of this revolution

2. #OrientDB - @ldellaquila
Luigi Dell’Aquila
Core Developer and Director of Consulting
OrientDB LTD
Twitter: @ldellaquila
http://www.orientdb.com

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

4. #OrientDB - @ldellaquila
Order #134
(Order) John
(Provider)
Commodore
Amiga 1200
(Product)
Frank
(Customer)
Monitor 40”
(Product)
Mouse
(Product)
Bruno
(Provider)

5. #OrientDB - @ldellaquila
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

6. #OrientDB - @ldellaquila
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)

7. #OrientDB - @ldellaquila
Key/Value Databases
Document Databases
Graph Databases
Column Databases

8. #OrientDB - @ldellaquila
Key/Value Databases
Document Databases Graph Databases
Column Databases

9. #OrientDB - @ldellaquila
Why do most NoSQL products
avoid
managing relationships?

10. #OrientDB - @ldellaquila
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?

11. #OrientDB - @ldellaquila
What’s wrong
with JOIN?

12. #OrientDB - @ldellaquila
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 millions of records
joining 3-4 tables could
generate billions of
combinations

13. #OrientDB - @ldellaquila
This is why the database
query performance
suffers as the database
increases in size
O(Log N)

14. #OrientDB - @ldellaquila
PERFORMANCE
DATABASE SIZE
RDBMS performance on traversal

15. #OrientDB - @ldellaquila
Solution: Graph Database!

16. #OrientDB - @ldellaquila
Back to school:
Graph Theory crash course

17. #OrientDB - @ldellaquila
Basic Graph
Luigi Rome
Visited

18. #OrientDB - @ldellaquila
Vertices and Edges can
have properties
Vertices are directed
* https://github.com/tinkerpop/blueprints/wiki/Property-Graph-Model
Property Graph Model*
Rome
country: Italy
Luigi
company: OrientDB
Vertices and Edges can
have properties
Vertices and Edges can
have properties
Visited
year: 2016

19. #OrientDB - @ldellaquila
Luigi Rome
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

20. #OrientDB - @ldellaquila
Congrats! This is your diploma in
«Graph Theory»

21. #OrientDB - @ldellaquila
How does a true*
Graph Database
manage relationships?
*a “Graph” layer on top of a DBMS doesn’t qualify as a true GraphDB

22. #OrientDB - @ldellaquila
Luigi Rome
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
Graph has own immutable
Record ID
Each element in the
Graph has own immutable
Record ID

23. #OrientDB - @ldellaquila
Connections use
persistent pointers
Luigi Rome
Visited
on: 2015
#13:55
#15:99out = #22:11
in = #22:11
#22:11
(Edge)
(Vertex)
(Vertex)
out = #13:55
in = #15:99

24. #OrientDB - @ldellaquila
Luigi Rome
Visited
on: 2015
#13:55
#15:99out = #22:11
in = #22:11
#22:11
(Edge)
(Vertex)
(Vertex)
out = #13:55
in = #15:99

25. #OrientDB - @ldellaquila
Luigi Rome
Visited
on: 2015
#13:55
#15:99out = #22:11
in = #22:11
#22:11
(Edge)
(Vertex)
(Vertex)
out = #13:55
in = #15:99

26. #OrientDB - @ldellaquila
A Graph Database creates the
relationship just once
(when the edge is created)
VS
RDBMS computes the
relationship every time
you query a database

27. #OrientDB - @ldellaquila
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

28. #OrientDB - @ldellaquila
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

29. #OrientDB - @ldellaquila
So the Graph Model
Is the only solution to efficiently
manage relationships
But what about data complexity?
And data consistency?
And scaling?

30. #OrientDB - @ldellaquila
RelationshipsComplexity>
Data Complexity >
Relational
Key Value
Column
Graph
Document
First Generation NoSQL

31. #OrientDB - @ldellaquila
RDBMS
Key/Value
Store
Document
Database
Graph
Database
Application
ETL
Primary
DB

32. #OrientDB - @ldellaquila
RDBMS
Key/Value
Store
Document
Database
Graph
Database
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

33. #OrientDB - @ldellaquila
2nd Generation NoSQL
is
Multi-Model
2nd Generation NoSQL
is
Multi-model

34. #OrientDB - @ldellaquila
GraphDocument
Object
Key/Value
Multi Model represents the
intersection
of multiple models in just one
product
What’s Multi-Model DBMS?

35. #OrientDB - @ldellaquila
GraphDocument
Object
Key/Value
Multi Model represents the
intersection
of multiple models in just one
product
- 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
What’s Multi-Model DBMS?

36. #OrientDB - @ldellaquila
`
{
”@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

37. #OrientDB - @ldellaquila
Second Generation NoSQL
RelationshipComplexity>
Data Complexity >
Relational
Key Value
Column
Graph
Document
Multi-Model

38. #OrientDB - @ldellaquila
With a true Graph, Document,
Key/Value and Object Oriented engine

39. #OrientDB - @ldellaquila
•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

40. #OrientDB - @ldellaquila
• Basic HTTP authentication (+HTTPS/SSL)
• User/Role authentication system. One User can have multiple
Roles
• Privileges are managed in Roles
• Roles can inherit from other Roles
• Record-level security: every record can contain the user/
role can create/read/update/delete the record
• Auditing available in Enterprise Edition
Security

41. #OrientDB - @ldellaquila
• HTTPS/SSL
• Starting from OrientDB v2.2:
• Support for Kerberos
• Encryption at REST using AES and DES of the entire
database or portions
• PBKDF2 HASH algorithm with a 24-bit length Salt per
user for a configurable number of iterations.
Encryption

42. #OrientDB - @ldellaquila
• Full Backup and Restore
• Delta Backup (v2.2) Enterprise Edition and Restore is
available
• Studio web tool
• Command line Console
Administration

43. #OrientDB - @ldellaquila
• Import/Export in JSON
• Import from SQL script
• OrientDB ETL tool (http://orientdb.com/docs/last/ETL-Introduction.html)
• Teleporter (v2.2)
Data Extraction and Loading

44. #OrientDB - @ldellaquila
• Multi-Master architecture
• Tunable consistency through the usage of a quorum, per
database or single class (table)
• Synchronous and Asynchronous replication
• Zero config: if multicast is enabled the server is attached to
the cluster
Scale out and HA

45. #OrientDB - @ldellaquila
Master Node Master Node
C
C C C
CC
C
Multi-master
Replication
Atomic, Consistent, Isolated and Durable (ACID) multi-statement transactions

46. #OrientDB - @ldellaquila
Master Node Master Node
C
C C C
CC
C
Auto-
Discovered
Node

47. #OrientDB - @ldellaquila
Architectures
• Single, stand-alone node
• Embedded (in-process) DB
• Multi-Master Replica
• Mixed
DB
Application
Application DB
Application
DBApplication
Application
DBDB
(replica N)
DBApplication
Application
DB
DB
ApplicationDB
(replica N)

48. #OrientDB - @ldellaquila
FEATURES ORIENTDB)) MONGODB NEO4J
MYSQ
(RDBM
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

49. #OrientDB - @ldellaquila
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)

50. #OrientDB - @ldellaquila
DEMO

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