Monday, November 03, 2014

GraphDB Communities comparison

This post is an update to my last post related to GraphDB marketshare (posted more than 2 years ago.) After 2 years, how have the GraphDB Communities changed? Twitter followers, reviews, etc can be bought/falsified.

But with an Open Source project, with open communities, I found a metric that is very hard to cheat: participation in groups. Then I discovered that Google Groups already provides this metric.

Below find the Neo4j and OrientDB charts.



It's very cool to see that not only is the OrientDB community very active on Groups, noting that OrientDB also has other channels (Chat, StackOverflow, etc.), but OrientDB is actually more active than Neo4j. In the past month, October 2014, OrientDB had 472 posts compared to 351 posts on Neo4j.

Monday, September 23, 2013

New Neo4J marketing campaign

This morning I've read a tweet by Emil Eifrem, CEO of Neo Technology (the company behind Neo4J product).

Do they really had to spend the $ 10.6 Million of dollars received in funding in this marketing operation?

If Open Source OrientDB wasn't SUPERIOR (faster, smarter and more complete) to the OVERPRICED Neo4j, Neo4j wouldn't be so obsessed with campaigning against it.

To remain in the telco field  is like : leader for a while but didn't innovate. And then came ...

Friday, August 02, 2013

The popularity of OrientDB grows up so fast!

Sometimes I check the site with the ranking of DBMS products in popularity (this is the method they use). I'm not surprised to see OrientDB at the second position in Graph Database market right after Neo4JNeo4J has a score of 9.73 against OrientDB with "only" 0.92.

But the most interesting thing is the grow up factor: OrientDB is at +22,8% while Neo4J is at "only" +8,3. So can OrientDB surpass Neo4J in terms of popularity? What are the pros and cons of OrientDB against Neo4J? Any comments is welcome, also in private.

Thursday, November 01, 2012

OrientDB: huge improvement in performance (+9,000%) in many use cases. Thanks RaspberryPi !

Hi all,
today I've a good story to tell you. A couple of days ago Fabrizio Fortino sent to me an email with some metrics and screenshots about the profiling of an in-production instance of OrientDB. Well, a lot of time was spent on open/close of database. 

That was the issue 1145 ( but I assigned to it a low priority because it was an improvement, not a real bug...

Well today I'm hacking with a Raspberry PI cheap HW and OrientDB to see if it could be used in production for some limited use cases. Well on this kind of HW everything is much-much slower! "Yeah, it's normal: I have a $35 HW, Java is not so optimized yet on this ARM platform, etc.". This were my firsts thoughts about the initial results.

But after some profiling I was arrived at the same conclusion of Fabrizio, so I decided to spend 2 hours of my life to investigate in deep.

Well, I've just committed a small patch (r7134) that avoids to open a database every time a database is re-used from the pool. In facts this is a quite costly operation, specially if you do many small atomic operation where most of the cost is in open/close that in the operation itself!

This fix improved a lot these scenarios:
  • Usage via HTTP/Rest, because a new connection is acquired every time from the pool at every operation
  • Java Web Applications where at the server side you used the database pool
  • you wrote a Java App that every time creates a new instance of a database. if this is your case I strongly encourage using the database pool that at this time is much faster
  1. in case metadata changes (schema, security, functions) you would need to invoke a reload() to get the changes
The improvement will be minor in the cases:
All these are PROS, what about CONS?
This is a simple load of a tiny document against a database on my pc:

$ ab -n1000 -A admin:admin -k -c10 http://localhost:2480/document/demo/71:1
Requests per second:    52.56 [#/sec] (mean)

$ ab -n1000 -A admin:admin -k -c10 http://localhost:2480/document/demo/71:1
Requests per second:    4694.57 [#/sec] (mean)

This is 90x faster, namely 9,000%, namely a huge improvement!

Now it's funny that OrientDB on the Raspberry PI, with the new patch, runs at a speed quite close to my PC I used everyday to work before this patch!

Saturday, May 05, 2012

GraphDB market share

Last week a market analysis agency contacted me to ask some questions about OrientDB saying that OrientDB, following its research, has the second position in the worldwide GraphDB market right after Neo4J. Awesome!

But who are the main players of the GraphDB market?
Since each vendor claims, more or less, to be the market leader, what is the real user base? Seems quite hard to gather real data about users and customers directly from vendors.

So I though that one of the best way is to look into the public groups and forums because users, before or after, will subscribe on it because it's the first hand source of information, help and tricks. They can't lie! This document contains some metrics extracted from public sources. Click on the source to see with your eyes about the source I used.

By reading this data Neo4J is, without any doubts, the GraphDB market leader, followed by OrientDB in rapid grow and after a long distance InfiniteGraph and  DEX. By reading the web site  InfiniteGraph seems to have some real customers, but seems all related to the previous product ObjectivityDB (an ODBMS born more than a decade ago).

Below the metrics:

Updated on
created on
April 2011
April 2010
September 2011
May 2011
threads since the beginning
posts since the beginning
posts in the last month (April 2012)
posts 2 months ago (March 2012)
but 100% announcements

Monday, February 20, 2012

Why I hate Maven

Yes, I admin that Maven has improved the development of Java programmers because the tons of dependencies each project brings.

So why I hate it so much? Well, because the thousands (really thousands!) of network calls to the remote server to:

  • check versions
  • check md5
  • download pom.xml files
  • download jars

But why Maven has been realized in the way we know? All the logic is at client side. This means that each Maven user pays the absurd latency cost for each network calls! The solution? Git teaches.

Why don't build a tree of requested JARs, send it to the Maven server and download the resulting zipped archive containing all the stuff to install in one shot?

In this way updates daily updates would take ms or just some seconds depending by the updates and the network bandwidth, not any more by the network latency.

Thursday, April 28, 2011

GraphDB benchmark part II

After some months since my last post about OrientDB (sorry but I prefer micro-blogging than blogging...) I'm back to write some news about the OrientDB engine.

The hard work has been the optimization at many levels:
  • minimize the wasted space created by set/delete operations (HOLES)
  • minimize marshalling/unmarshalling operations, specially on LinkSet type responsible of relationships between vertices and edges
  • fine tuning of Transactions
The main difficulty has been reduce the Disk I/O when you update a record. In facts when you execute an update, rarely the serialized content size will be the same of the original size. In this case you've a new HOLE, namely a free space marked to being reused.

The problems I found with the HOLES were that small spaces aren't reused at all and huge defragmentation was present. This caused a global slowness and the growth of the database on disk (in some cases many times the original size). After 2 weeks of work I've published in the SVN and maven the new version of the OrientDB storage with:
  • In-line defrag: something like some File Systems already do by joining small holes all together. In-line defrag works while the database is online and in use
  • Improved the management of small changes to records
  • 2 configurable strategies of how to find the best hole to join during defrag process
  • configurable hole distance to decide when to join multiple holes all together
The gain of overall speed has been perceived by a lot of users. Since there are not benchmarks against GraphDB yet I've re-run the TinkerPop Blueprints Test Cases (see my previous post about this).

This test suite is part of TinkerPop Blueprints project and is NOT a BENCHMARK, but just a lot of tests against GraphDB implementations to test the compliance level of them. So please don't flame about this. It's not an official benchmark, just a way to test how OrientDB performs in comparison with other GraphDBs and with the previous releases of the same OrientDB. More how OrientDB performs on different platforms. The comparison in this case is only with Neo4J (the market leader?) since DEX supports only few Test Cases and it wouldn't be fair. Note that both GraphDBs run with default settings.

These are the results on a cheap Linux server (Linux CentOS, Intel Atom Dual Core 330 1,6Ghz, 1GB Ram DDR2, HD U-ATA 7200rpm):

Test name Times in ms. Less is better = faster
OrientDB 1.0rc1 snapshot Neo4J 1.3 + faster, - slower
VertexTestSuite 11,190.80 48,354.85 +432,1%
EdgeTestSuite 6,421.55 24,361.78 +379,4%
GraphTestSuite 12,642.21 36,932.11 +292,1%
IndexableGraphTestSuite 1,173.55 2,618.00 +223,1%
IndexTestSuite 462.70 1,052.32 +227,4%
AutomaticIndexTestSuite 1,719.91 4,912.81 +285,6%
TransactionGraphTestSuite 1,603.59 4,237.17 +264,2%
GraphMLReaderTestSuite 1,291.93 2,365.85 +183,1%
Total 36,506.24 124,834.89 +342,0%

OrientDB completes all the tests in less than a third of the time of Neo4J: +342% faster than Neo4J!

The difference is lower running the same test against a MacBook Pro (OS X 10.6.7 64bit, 4GB Ram, CPU Intel core 2 duo 2.4ghz, HD 5400rpm):

Test name Times in ms. Less is better = faster
OrientDB 1.0rc1 snapshot Neo4J 1.3 + faster, - slower
VertexTestSuite 13,380.67 23,647.54 +176,7%
EdgeTestSuite 7,508.78 14,139.71 +188,3%
GraphTestSuite 9,514.58 18,664.99 +196,2%
IndexableGraphTestSuite 523.92 969.06 +185,0%
IndexTestSuite 263.58 640.80 +243,1%
AutomaticIndexTestSuite 1,672.92 2,943.86 +176,0%
TransactionGraphTestSuite 1,378.59 3,047.77 +221,1%
GraphMLReaderTestSuite 1,418.21 1,805.27 +127,3%
Total 35,661.25 65,859.00 +184,7%

In this case OrientDB completes all the tests in about half time: +184,7% faster than Neo4J. I was not able to complete all the tests on Windows 7 machine (Intel i7 720q, 4GB Ram, HD 7200rpm) since Neo4J gives errors and break the test suite:

Test name Times in ms. Less is better = faster
OrientDB 1.0rc1 snapshot Neo4J 1.3 + faster, - slower
VertexTestSuite 7,762.61 51,474.76 +663,1%
EdgeTestSuite 6,737.59 71,479.28 +1.060,9%
GraphTestSuite 7,280.43 75,695.77 +1.039,7%
IndexableGraphTestSuite 2,766.07 Error n.a.
IndexTestSuite 1,064.49 Error n.a.
AutomaticIndexTestSuite 2,796.08 Error n.a.
TransactionGraphTestSuite 3,471.80 Error n.a.
GraphMLReaderTestSuite 3,067.81 Error n.a.
Total 34,946.88 198,649.81 +921,2%

However by looking at the 3 available tests OrientDB outperforms Neo4J also on Windows machines of +921,2%!

Another interesting point is about the platforms. Linux CentOS performs very well even if the underlying HW is cheaper & older than the other 2 machines.

I'm pretty satisfied of these results in relation to the previous ones where Neo4J performed better in some circumstances. Thank you to all the OrientDB contributors and users that have made this possible!

It's not time to rest or sleep, because the work is not yet ended: all the efforts now are for the 1.0 release.

How to execute these test on my PC?

To re-execute the same test on your machine just install Java 6, Git and Apache Maven. Then execute these command in a shell (or command prompt if you've MS Windows):

> git clone git://
> cd blueprints
> mvn install

Now wait that all the software is compiled and all the tests start. Now you've your results. Please share them to the OrientDB Group attaching your HW/SW configuration!

Tuesday, November 23, 2010

Codemotion 2011, the most important Italian conference about programming

Save this date: March 5th 2011! In Rome, Italy there will be the most important conference about programming. The event is totally FREE. About 1,500 attendees. Sessions in English and Italian languages.

For information:

Tuesday, October 19, 2010

When someone is criticizing something you care...

When someone is criticizing something you care, don't defend it till death, but ask him what's his idea to improve it! Both will growth. Lvc@

Thursday, October 14, 2010

A standard for GraphDB

Yesterday GraphDBs have covered a niche market. In the last period things are changed and they are becoming much more popular than ever. This is due to:
  • The always growing need to have data strongly interconnected. What better than a GraphDB for it?
  • Applications are much more "social" than before. And social means relationships among subjects that perfectly bound to the Graph model
  • Performance on large datasets. You can live without a pure GraphDB, and therefore continue to use a Relational DBMS, until you need a real fast access to your data
  • The NoSQL movement has contributed a lot to change the mind of developers to focus to DBMS different (and sometime very different) from the Relational model.

The GraphDB has few but strong concepts. Graphs are composed by:
  • Vertex or Node, the linked entity. Vertexes can have properties.
  • Edge or Arc, as the link between the Vertexes. Edges can have properties and can be unidirectional or bidirectional
  • Property, is a value to assign to Vertexes and Edges. A property has a name and a value
Each GraphDB product is based upon the above concepts, but features can be very different among them. Furthermore there isn't a standard for them and an application can't migrate from one to another one at zero or low cost.

This is the reason why I want to introduce the Tinkerpop Blueprints. This Open Source project aims to have a shared set of basic interfaces to abstract the concepts of Graph, Vertex, Edge and Property. In this way applications can easily migrate to another available implementation of the specification.

Furthermore Tinkerpop has created a complete stack of tools and framework to work with Graphs. Below the main ones:
  • Gremlin is a Turing-complete, graph-based programming language designed for key/value-pair multi-relational graphs. Gremlin makes use of an XPath-like syntax to support complex graph traversals. This language has application in the areas of graph query, analysis, and manipulation.
  • Rexster is a RESTful graph shell that exposes any Blueprints graph as a standalone server. Extensions support standard traversal goals such as search, score, rank, and, in concert, recommendation. Rexster makes extensive use of Blueprints, Pipes, and Gremlin. In this way its possible to run Rexster over various graph systems.
  • Pipes is a graph-based data flow framework for Java 1.6+. A process graph is composed of a set of process vertices connected to one another by a set of communication edges. Pipes supports the splitting, merging, and transformation of data from input to output.

(1) What do you think about this effort to standardize GraphDB?

(2) What is missed today in Tinkerpop Blueprints API?

(3) Does a .NET porting make sense?