OrientDB Codemotion 2014

ROME 11-12 april 2014ROME 11-12 april 2014

OrientDB: a Document-Graph Database ready for the Cloud

OrientDB CommitterOrientDB Academy Coordinator at Orient Technologies LTDProject Manager at AssetData S.r.l.

Email: l.dellaquila – at – orientechnologies.comTwitter: @ldellaquila

Luigi Dell’Aquila

ROME 11-12 april 2014 - Luigi Dell’Aquila

Relational Databases:

Everybody knows what a TABLE is

Everybody knows SQL


These are tables,Data ARE Tables!






But this is not


But this is not


But this is not


But this is not


But this is not


These are

GRAPHS!


And sometimesRepresenting them in tables

Can be difficultAnd

Inefficient


Think about it…


When you write your codeYou have to deal with

Links, References, Pointers



Collections and Maps(and dynamic data structures!)



Nested and complex objects



Class hierarchies,Inheritance, Polymorphism


Would You LikeA Storage Layer

That Supports ALLThese Conceps Out Of The Box?

ROME 11-12 april 2014

This is why

Was born

- Luigi Dell’Aquila


Two data models:

Graphand

Document


Classes, not Tables

create class Person

create class Student extends Person

select from Person

Polymorphic query: returns both instances of Person and Student


Dynamic schema

create class Person

insert into Person (name, surname) values (“Luigi”, “Dell’Aquila”)

No need to fully specify the class structure, you can work in schemaless mode


Complex attributes

Update person set address = {

“street”: “5th Ave”, “city”: “NY”

}, tags = [“developer”, “artist”, “geek”]

Collections and embedded properties


Physical links(no Join!)

Update person set address.city = (select from city where name = ‘Rome’)

where name = ‘Luigi’

Select address.city.country.name from Person where name = ‘Luigi’

Dot notation instead of JoinNo need for foreign keys O(1) computational cost – compared to O(log N) in relational Join


The Graph API(TinkerPop Blueprints)

Traverse out(“Friend”) from (select from Person where name =

‘Luigi’)while address.city = ‘Rome’

Find my friends network in my city (friends, firends of frineds, friends of friends of friends…)

Deep traversal, no need to know in advance HOW deep


Every record has unique IDSelect from Person

{"result": [{

"@rid": "#13:0","@class": “Person","name": "Luigi","surname": "Dell'Aquila","friendOf": "#13:1"

}]}



{"result": [{


}]}



{"result": [{


}]}


Record ID (RID)

=

Physical position


Traversing relationships

=

Following a physical path


It means:

• Accessing linked data is very efficient• No calculation *• Independent from cluster size **• Deep traversal is allowed and encouraged ***

* In RDMS, a Join is calculated EVERY TIME you execute a query ** RDBS use index-based optimization to speed up joins, but index access is O(log N), so it depends on data size – what about Big Data??? *** in RDMS multiple joins are inefficient (would you dare to write a query with 1000 joins?)


But OrientDBGives you more!


Javascript In the Storage

Extend the query languageWith you own functions


Javascript functions

As REST services


But of course you can use it from


90’s are gone

Today you need


Scalability


High availability


Fault tolerance


Today everybody(with a little luck)

Can write a killer appAnd reach billions of users


provides:

Replication (Multi Master)and

Sharding

Also on cloud infrastructures


HAZELCAST HAZELCAST

HAZELCAST

Multi Master


Example


HAZELCAST HAZELCAST

HAZELCAST

Amazon

Elastic Load

Balancing+

Auto Scaling


HOWTO 1/3

Key pair


HOWTO 2/3

Security group


HOWTO 3/3


http://www.orientechnologies.com

http://www.orientechnologies.com/training

https://github.com/orientechnologies/orientdb/

Job opportunities: [email protected]

References

http://www.orientechnologies.com/







http://www.orientechnologies.com/event/orientdb-planet-first-conference-orientdb-rome-italy/

OrientDB Planet



Software

OrientDB Codemotion 2014