OrientDB, the document or graph store, has announced a new release, 0.9.24, featuring amongst a few SQL support improvements, synchronous and asynchronous replication.

The complete list of changes can be found ☞ here. The ☞ official announcement is listing the following new features:

• Support for Clustering with synchronous and asynchronous replication
• New SQL RANGE keyword: SELECT FROM ... WHERE ... RANGE <from> [,<to>]
• New SQL LIMIT keyword: SELECT FROM ... WHERE ... LIMIT 20
• Improved CREATE INDEX command
• New REMOVE INDEX command
• New console command INFO CLASS
• New console command TRUNCATE CLASS and TRUNCATE CLUSTER
• MRB+Tree now is faster and stable
• Improved import/export commands
• Improved JSON compliance
• Improved TRAVERSE operator with the optional field list to traverse

I’ve contacted Luca Garulli, OrientDB main developer, for more details about the OrientDB replication.

Original title and link: OrientDB New Release Featuring Sync and Async Replication (NoSQL databases © myNoSQL)

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 address.city.country.name = '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>>(
        database, 
        "Profile",
        new OQueryContextNativeSchema<ODocument>(), this) {

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

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)

OrientDB, the mixed document/graph database with SQL flavor, ☞ has announced a new release featuring:

• New run-time Fetch Plans
• New database properties (Issue #54)
• POJO callback on serialization/deserialization (Issue #56)
• New annotation to use RAW binding (Issue #57)

You can read more about OrientDB fetch strategies ☞ here. OrientDB 0.9.20 can be downloaded from ☞ here.

Considering I’ve started to look at OrientDB quite recently and except this presentation I couldn’t find many more details, I’m wondering if there are people using OrientDB in their projects and what are some of its use cases.

Not long ago, I’ve written about a couple of new projects in the NoSQL space, listing OrientDB among those.

The slides below are offering a quick overview of OrientDB:

• what is OrientDB
• database structure
• API
• clustering and partitioning

Lately I’ve been hearing about a couple of newcomers in the NoSQL space so here is your chance to find out about them and why not provide other readers with some additional feedback about each of them:

kumofs ☞

Kumofs is a distributed key-value store built on top of Tokyo Cabinet and using the memcached protocol.

According to the ☞ project homepage:

• Data is partitioned and replicated over multiple servers.
• Extreme single node performance; comparable with memcached.
• Both read and write performance got improved as servers added.
• Servers can be added without stopping the system.
• Servers can be added without modifying any configuration files.
• The system does not stop even if one or two servers crashed.
• The system does not stop to recover crashed servers.
• Automatic rebalancing support with a consistency control algorithm.
• Safe CAS operation support.
• memcached protocol support.

There already seems to be ☞ success story of kumofs, but you’ll have to take that with a grain of salt as the same company was announcing a success story with Redis for the same problem.

Raven DB ☞

Raven DB is a dual licensed document database for the .NET platform with a RESTful API.

According to the ☞ project homepage:

• Scalable infrastructure: Raven builds on top of existing, proven and scalable infrastructure
• Simple Windows configuration: Raven is simple to setup and run on windows as either a service or IIS7 website
• Transactional: Raven support System.Transaction with ACID transactions. If you put data in it, that data is going to stay there
• Map/Reduce: Easily define map/reduce indexes with Linq queries
• .NET Client API: Raven comes with a fully functional .NET client API which implements Unit of Work and much more
• RESTful: Raven is built around a RESTful API

Orient ☞

Orient comes in two flavors: OrientDB: a document database and OrientKV a key-value store, both running on the Java platform.

According to the ☞ project homepage, OrientDB is a

scalable Document based DBMS that uses the features of the Graph Databases to handle links. It’s the basic engine of all the Orient products. It can work in schema-less mode, schema-full or a mix of both. Supports advanced features, such as indexing, fluent and SQL-like queries. It handles natively JSON and XML documents.

The OrientKV is a:

Key/Value Server based on the Document Database technology and accessible as embedded repository via Java APIs or via HTTP using a RESTful API. Orient K/V uses a new algorithm called RB+Tree, derived from the Red-Black Tree and from the B+Tree. Orient Key/Value server can run in high availability mode using a cluster of multiple nodes partitioned.

Have you tried any of these?

Pincaster ☞

According to the GitHub page, Pincaster is a persistent NoSQL database to store geographic data and key/value pairs, with a HTTP/JSON interface. Unfortunately there’s almost no documentation about the project so I don’t think there’s anything else I could add for now.

Update: hint received from @fs111