OrientDB introduction - NoSQL

“A NoSQL Database for the Internet age”

www.OrienTechnologies.com

Author of OrientDB and Roma
Luca Garulli
Luca Garulli Framework Open Source projects,
CTO@AssetData.it
CTO@AssetData.it CTO at Asset Data company,
http://zion-city.blogspot.com
http://zion-city.blogspot.com Technical Manager at Romulus
http://twitter.com/lgarulli
http://twitter.com/lgarulli consortium

NoSQL movement
“In recent years, a number of new systems, sometimes called
“NoSQL” systems, have been introduced to provide indexed data
storage that is much higher performance than existing relational
database products like MySQL, Oracle, DB2, and SQL Server.
These data storage systems have a number of features in common:

● A simple call level interface or protocol (in contrast to a SQL
binding)
● Ability to horizontally scale throughput over many servers,

● Efficient use of distributed indexes and RAM for data storage, and

● The ability to dynamically define new attributes or data schema“

from “High Performance Scalable Data Stores” by Rick Cattell
For more information visit: http://www.orientechnologies.com

Products
There are two main products released with commercial friendly
Open Source Apache 2 license

Deeply scalable Document based DBMS that uses the The Key/Value Server based on the
features of the Graph Databases to handle links. It's the Document Database technology and
basic engine of all the Orient products. It can work in accessible as embedded repository
schema-less mode, schema-full or a mix of both. via Java APIs or via HTTP using a
RESTful API. Orient K/V uses a new
Supports advanced features, such as indexing, fluent and algorithm called RB+Tree, derived
SQL-like queries. It handles natively JSON and XML from the Red-Black Tree and from the
documents. Developers can use Java native and HTTP B+Tree.
RESTful APIs
Orient Key/Value server can run in
Graphs of hundreads of linked objects can be retrieved all high availability mode using a
in memory in less than 1ms without executing costly JOINs cluster of multiple nodes partitioned.
such as the Relational DBMSs do.

Cluster concept
Class “Profile“ has
records distributed on
multiple clusters. Class “Profile“
Class “Profile“
Cluster “FamousProfile“
Cluster “FamousProfile“
All the other Type = physical
Type = physical
profiles will be
stored into the
Jay Miner Bill Gates
“OtherProfile“
cluster of type
“logical“ The “FamousProfile“ cluster
contains all the profile of the most
famous people and it's supposed
to being accessed frequently. This Cluster “Twit“
Cluster “OtherProfile“ is the reason why we selected Cluster “Twit“
Cluster “OtherProfile“ Type = physical
Type = logical “physical“ as type. Type = physical
Type = logical


APIs
OrientDB is written 100% in Java® and can run on any
platform that supports the Java® Technology version 5 or
more.

OrientDB supports native Java client API to work with
embedded or remote databases using the fast binary
protocol

OrientDB Server comes with a HTTP RESTful interface to
being used from any language, even from the Internet
Browser. Uses JSON to represents records

Java example with records
// OPEN THE DATABASE
ODatabaseDocumentTx db = new ODatabaseDocumentTx("remote:localhost/demo").open("admin", "admin");

// CREATE A NEW DOCUMENT AND FILL IT
ODocument doc = new ODocument(db, "Person");
This is a
doc.field( "name", "Luke" ); relationship
doc.field( "surname", "Skywalker" ); Many-to-One
doc.field( "city", new ODocument("City" ).field("name","Rome").field("country", "Italy") );

// SAVE THE DOCUMENT
doc.save();

// QUERY THE DOCUMENT Query using the
List<ODocument> result = database.query( SQL syntax with
new OSQLSynchQuery("select * from person where city.name = 'Rome'")).execute(); extensions to
traverse links
// PRINT THE RESULT SET
for( ODocument d : result ){ without costly
System.out.println("Person: " + d.field( "name" ) + d.field( "surname" )); JOINs
}

db.close();


Object Database interface
Even if OrientDB is not an ODBMS (but is a Document DBMS), it
offers the ODatabaseObject interface to works with POJOs in
transparent way removing the Impedence Mismatch problem

Fields not present in the real Java class will be not mapped but
saved with the original record

Queries convert automatically records to POJOs

References between POJO can be stored as links (aka
relationships) or by including the referenced object as
embedded.

Java example with POJOs
// OPEN THE DATABASE
ODatabaseObjectTx db = new ODatabaseObjectTx("remote:localhost/demo").open("admin", "admin");

// CREATE A NEW OBJECT AND FILL IT
Person person = new Person(); Automatic
person.setName( "Luke" ); binding from
person.setSurname( "Skywalker" );
person.setCity( new City( "Rome", "Italy") ); POJO to record

// SAVE THE OBJECT
db.save( person ); Query returns directly List
of POJO. Queries use the
// QUERY THE OBJECT cache before to load the
List<Person> result = database.query( records from the storage
new OSQLSynchQuery("select from person where city.name = 'Rome'"));

// PRINT THE RESULT SET
for( Person p : result ){
System.out.println("Person: " + p.getName() + “ “ + p.getSurname() ); The POJOs
} are usable as
usually
db.close();


HTTP RESTful API
select from Profile where project = 'Amiga'

HTTP RESTful protocol
(JSON) OrientDB
OrientDB
{ result :
{ _rec: 3:4,
Server
Server
_ver: 2,
name: “Jay”,
surname: “Miner”
}, Fast
{ _rec: 4:343,
_ver: 0, binary protocol
name: “Tim”,
surname: “King”
}
}
Java
Java
application
application

Security
Encrypted
password using “Reader“ Role
SHA-256 algorithm Mode = Deny all but

Rules:
2 modes: “allow database = Read
all but” and “deny database.cluster.* = Read
database.cluster.metadata = None
all but” database.class.* = Read

Each user has one
or more roles
“Publisher“ Role
Default roles are:
reader, writer and Mode = Deny all but
admin “Admin“ Role Rules:
Database.Cluster.cars = All
Mode = Allow all but


OrientDB Studio


Orient Key/Value – Partitions in the Ring

Backup=1 in
configuration means
that each node backup
Keys range: S .. Z data synchronously on
the next one.

Back
Node #1 up Keys range: 0 .. F
Each node is owner
of part of keys (Node

up
ck
#1 the range S-Z) and
Ba

Ba
ck
is responsable to p u
Node #2
synchronize them to
the disk
The last node in
the Ring is the last
Node #3 one started
Keys range: G .. R


Orient Key/Value – Update an entry

The client (application or
web-browser) connects to
upd the owner node of the
a te b Keys range: S .. Z entry to update
and
:Co
ld p
lay
Back
Node #1 up Keys range: 0 .. F
to disk
e
sav

p
ku
Ba

c
Ba
ck
p u
Node #2

Node #1 is the owner of the
updated entry: propagates
changes to the local disk and to Node #3
backup node synchronously Keys range: G .. R


Orient Key/Value – Fail Over Management

The Backup of Node #1
is the Node #2. The
Node #2 becames the
Keys range: S .. Z owner and assures to
write all the entries to
the Disk

Back
Node #1 up Keys range: S .. F

up
ck
Ba

Ba
ck
save to d
isk
p u
Other Nodes envolved Node #2
change the backup
policies themselves. In
this case Node #3
backups on Node #2
and viceversa Node #3
Keys range: G .. R


OrientDB introduction - NoSQL

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to OrientDB introduction - NoSQL (20)

More from Luca Garulli (14)

Recently uploaded (20)

OrientDB introduction - NoSQL