a NEUral STANchion

abramova

These years there’s been a lot of growing attention around the so-called ‘No SQL’ databases.

This name distinguishes a generation of db with alternative premises compared with usual ER db’s: these principles can be graph db, document db or key-value db.

Originally they had a strong anti SQL-centric viewpoint; this inflexibility was one of the reasons of their interest, but also their limit: the world was still using largely SQL and an environment excluding SQL was a cost rather than an investment.

The ones which evolved and decided to adopt SQL and other points of convergence with the world outside are still alive and fighting with us. A side effect is that the term ‘No SQL’ does not fit anymore, and ‘NoT Only SQL’ seems more appropriate.

Old school ER db’s had to face quite a rigid architecture of data: basically entities with attributes connected with other entities. Using a specific term, it was a world easy to normalize.

Modern days db’s live in a jungle: unstructured (for instance: documents to be semantically parsed) and large amount of data (often in a swiftly changing environment, a.k.a. ‘high costs for join operations‘) that requires a high fluidity in their represantation. It’s no more about to normalize data; we need something polymorphic, something that, rather than descending from canonical db’s structures, belongs to the Object-Oriented modelling.

Since we are still talking about db’s architecture, we need also something that may preserve the ACID integrity of data – or, at least, most of it.

One of these ‘Not Only SQL‘ db is Orient DB, an italian project, totally written in Java and implementing interesting ‘No SQL’ features, especially for document oriented project’s environments.

It’s self-sufficient: it has got a Apache 2.0 License (no fees or royalties required) and no dependices from other software

Unfortunately, it’s not all bed of roses.

Even though Orient DB’s peculiar data structure (called MVRB-Tree, a specialization of classical red-black trees) claims to be quite efficient in terms of ‘read’ operation, it shows computational limits when performing ‘update’ operations, or worst, a long succession of ‘update‘ operations, something not exactly negligible talking about a database.

In the final summarizing chart – excluding Redis, which is an in-memory key-value db which totally load data into volatile memory, and for this reason plays in a different pitch – our friend Orient DB pays a heavy penalty for all its versatility: it turns out to demonstrate the worst performance.

Using their words:

“[Orient DB] requires more system capacities compared with the capacities provided by the environment used in the evaluation. Therefore, their performances were limited by the memory management, the operating system and the use of virtual machine environment”

So, as it was easily predictable, every rose has its thorns.

For a more complete and pleasant (which is never a despised factor) series of articles about Orient DB and life side by side with it, I recommend this blog: