NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



Correction: OrientDB is a Document and Graph Store

Luca Garulli, ☞ OrientDB project lead, contacted me a couple of days ago offering some clarifications about OrientDB.

Luca Garulli: OrientDB is a document-graph dbms with schema-less, schema-full or mixed modes. Why also graph? Because the relationships are all direct links between documents. No “JOIN” is used. This allow to load entire graph of interconnected documents in few ms!

The Graph interface is documented ☞ here and starting from v. 0.9.22 OrientDB is compliant with Tinkerpop stack of Graph tools such as the Gremlin language. ☞ This is the link that shows the OrientDB usage from Gremlin.

Alex: Couple of questions:

  1. what is the format in which data is stored?
  2. how do you query data?

Luca: The document is stored in a compressed JSON-like format. Documents are contained in clusters. Clusters can be physical, logical or in-memory. A cluster is something close to the Collection of MongoDB and its aim is to group documents all together. The first use of a cluster is to group documents of the same type, as a sort of TABLE in the Relational world. But you can create a cluster “UrgentInvoices” and put all the urgent invoices close to be expired.

A cluster can be browsed and queried using Native queries and SQL queries. The SQL support is good enough and has extension to handle the schema-free features such as add/remove items in collections and maps. This example add the String ‘Luca’ to the collection “names”.

update Account add names = 'Luca'

And special operators to treat Trees and Graphs. This cross all the relationships avoiding costly JOINs:

select from Profile where = 'Rome'

This one is much more powerful and complex:

select from Profile where any() traverse( 0,3 ) ( 
    any().toUpperCase().indexOf( 'NAVONA' ) > -1 )

any() means any fields because each documents can have different fields (is schema-less). the traverse operator goes recursively from the current document (0) to maximum the 3rd level of nesting (3) checking the condition on the right.

Then you have native queries:

new ONativeAsynchQuery<ODocument, OQueryContextNativeSchema<ODocument>>(
        new OQueryContextNativeSchema<ODocument>(), this) {

      public boolean filter(OQueryContextNativeSchema<ODocument> iRecord) {
        return iRecord.column("id").toInt().minor(10).go();

Alex: Thanks a lot!

Update: It looks like OrientDB is also seeing some speed improvements these days. You can read about it ☞ here.

Original title and link: Correction: OrientDB is a Document and Graph Store (NoSQL databases © myNoSQL)