OrientDB & Hazelcast: In-Memory Distributed Graph Database

Copyright (c) - Orient Technologies LTD 1

+

AgendaWhat is OrientDB

Master-Slave replication

New Distributed Architecture goals

Why we choose Hazelcast

Multi-Master replication features

Future roadmap


What is ?


Graph Document

Best of both worlds

FlexibilityPerformance


Complex Domains

Person

Customer Provider

name surname phone email

type delivery

discount

True Polymorphism


ACID Transactionsdb.begin();

try {

…

db.commit();

} catch( Exception e ) {

db.rollback();

}

Eventually consistency is cool, but many times you need full ACID transactions

distributed across servers

SQL + extensions

Everybody knows SQL

We’ve just added a few new operators and functions to support

Tree and Graphs concepts


OrientDB Server

(C)lient

{ “@class”: “VIP”, “name”: “Jay”, “surname”: “Miner”, “invented”: “Amiga” }

HTTP + JSON

HTTP + JSON native support


Commercial Friendly Apache license

FREE for any usage !

We like to keep it simple for users: no (A)GPL


Is OrientDB a Distributed

DBMS ?


Short history !

In 2012, we had a Master/Slave replication !

While it scaled up well on reads, users complained of a single Master node bottleneck

It’s quite easy to scale up reads, the hard part is to scale up both reads and writes

Copyright (c) - Orient Technologies LTD

How Master/Slave works

12

Master Node

CC C

Slave Node

Slave Node

Writes

Master node is the bottleneck


Master/Slave !

PROS: - Relatively easy to develop !

CONS: - The master is the bottleneck for writes - No matter how many servers you have, the

throughput is limited by the Master node


What happened to OrientDB's M/S architecture?

This is the old MASTER/SLAVE replication


2012: new architectural goals

Multi-Master: all the nodes must accept writes

Sharding: split data in multiple partitions

Better Fail-Over

Simplified configuration with Auto-Discovery


How to achieve this?

We evaluated different approaches such as:

Akka (actor model)

JBoss Infinispan

Queue Engines: ActiveMQ, RabbitMQ, ZeroMQ

and Hazelcast, the winner!

16


Why ? !

- It has everything you need to build distributed software: - Auto-discovery - RPC - Synchronization - Queues and Topics

- Embeddable - Easy API, good documentation - Stable in terms of:

- Run-time - API changes

- Mature product with many users in production - Same license as OrientDB: Apache2


Master Node

Auto-Discovery

I’m the only one!

C


Auto-Discovery

Master Node

Master Node

Connected!

C


Master Node

Master Node

C

updated distributed configuration is broadcasted to

all the connected clients

Clients see the distributed configuration


Master Node

Master Node

CC

Master Node

Auto-reconnect in case of failure

In case of failure, the clients auto-reconnect to

the available nodes


Master Node

Master Node

C

DB are automatically deployed

to the new joining nodes

DB DB

Auto-deploy of databases

CC

C


DEMO


Customer

customer

Classes rely on Cluster to store records

By default 1 class -> 1 cluster Class

Cluster


Classes can be split into more clusters

25

Customer

customer_usa

customer_europe

customer_china

Class

Cluster

ClusterCluster

Define multiple clusters

and assign them to each node


Assign 1 cluster per Node

2626

customer_usa customer_europe customer_china

Master Node

Master Node

Master Node

Customer

Copyright (c) - Orient Technologies LTD

What about sharing + replication?

!

We used a solution similar to RAID for HardDrives

27


RAID for databases

282828


Master Node

Master Node

Master Node

Customer

customer_europecustomer_usacustomer_china

Replica factor = 2


RAID for databases

29292929


Master Node

Master Node

Master Node

Replica factor = 3

customer_usa customer_europecustomer_china

customer_usacustomer_europe customer_china

Each node owns all customers


Replication: under the hood Client sends an INSERT request

3030303030

Master Node

Master Node

Master Node

HZ Queue

HZ Queue

HZ Queue

C

INSERT

Requests


Master Node

Master Node

Master Node

HZ Queue

HZ Queue

HZ Queue

C

HZ Queue

HZ Queue

HZ Queue

Replication: under the hood Response handling

WriteQuorum = 2

Sends OK

OK

Requests

Responses


Replication: under the hood Fix the unaligned node

32323232323232

Master Node

Master Node

Master Node

HZ Queue

HZ Queue

HZ Queue

HZ Queue

HZ Queue

HZ Queue

Requests

Responses

Fix


DEMO


Master Node

Master Node

CC

C

CC

C Master Node

CC

C

Master Node

CC

C

Master Node

CC

C

Master Node

CC

C

Master Node

C

C

Linear and Elastic scalability on both read & writes!


Hazelcast’s role

Auto-Discovering (Multicast/TCP-IP/Amazon)

Queues for requests and responses

Store metadata in distributed Maps

Distributed Locks

3535


OrientDB 2.0 (Sept 2014) has even better performance: +300% improvement on all the distributed operations

Pluggable conflict resolution strategy

Auto-discovery also by Clients

OrientDB’s Future Roadmap



Thanks!

Luca Garulli CEO Orient Technologies LTD @lgarulli

Any Questions?

Software

OrientDB & Hazelcast: In-Memory Distributed Graph Database