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

@ldellaquila#Devoxx #OrientDB

Luigi Dell’AquilaDirector of ConsultingOrient Technologies LTDTwitter: @ldellaquila

http://www.orientdb.com

OrientDB - the 2nd generation of

(Multi-Model) NoSQLAnd 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)



(Provider)


(Product)

Frank (Customer)


Mouse (Product)

Bruno (Provider)

Data by itself has little value, it’s the relationship

between data that gives it incredible value



(Provider)


(Product)

(Sells)

Frank (Customer)

(Has)(Makes)


(Sells)(Has)

Mouse (Product)

Bruno (Provider)

(Sells)

(Has)


Key/Value DatabasesDocument Databases

Graph DatabasesColumn 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 AddressJoins 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 AntwerpVisited


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



Visited on: 2015

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


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)


Record ID


Record ID


Luigi Antwerp

Visited on: 2015

#13:55#15:99

Connections use persistent pointers

out = #22:11in = #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


Rel

atio

nshi

ps C

ompl

exity

>

Data Complexity >

Relational

Key Value

Column

Graph

Document

First generation NoSQL



Oracle(RDBMS)

Redis orMemcache(Key/Value)

MongoDB(DocDB)

Neo4j(GraphDB)

Application

ETL

Primary DB


Oracle(RDBMS)

Redis orMemcache(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

Makes

General purpose solution: • JSON • Schema-less • Schema-full • Schema-hybrid • Nested documents • Rich indexing and querying • Developer friendly


Rel

atio

nshi

ps C

ompl

exity

>

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

CC C C

CC

C

Multi-master Replication

Atomic, Consistent, Isolated and Durable (ACID) multi-statement transactions


Master Node Master Node

CC 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 Freehttp://www.orientechnologies.com/getting-started

OrientDB Enterprise is Free for Development

OrientDB Community is FREE for any purpose (APACHE 2 license)

http://www.orientechnologies.com/getting-started


Thank you!Luigi Dell’Aquila@ldellaquilahttp://www.orientdb.com

Q/A


Software

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