NoSQL Zone is brought to you in partnership with:

Pere Urbón is a Software Engineer at DAMA-UPC, currently working on graph databases applications, mostly an application developer using web technologies. With nearly teen years of experience in software development but without losing an important interest on free software, reading, sports and the entire live pleasures!. Pere has posted 2 posts at DZone. View Full User Profile

NoSQL Graph Database Comparison

05.12.2010
| 30166 views |
  • submit to reddit

A few days ago I published a short overview of the most trendy graph databases. Today I'm bringing you a review of the most important features of them. As you can see the current ecosystem is quite bit, without general uniformity, although this is normal when analyzing an ongoing technology movement.

 

As you can see in the previous table,  there are substantial differences that can help our projects. Next we are going to analyze these main differences.

License

There are flos licenses, commercial and mixed licenses. A diverse ecosystem, providing you with the right to choose the best one according your needs. You must take into account the importance of flos licenses, if they are backed with an active and diverse community, they could provide the product with a high standard of quality.

Distribution

Confronting us with a high demand needs, either of computing, storage or both, brings us to distributed computing. Any database product with the aspiration to succeed must take this into account. In our review the only one truly distributed solution is HyperGraphDB , however they must improve a lot of things. The other communities are pushing hard, accomplishing great steps forward, and I'm sure they will present interesting solutions soon.

Indexing

Every data structure designed to store high quantity of data and allows efficient retrieving of data, needs to provide indexing. An index is nothing more than a direct pointer between a key and a certain value, like a dictionary. The solutions we analyzed facilitate indexing of attributes in nodes and edges, however there are some differences. Specifically Neo4J , which uses Lucene to index node attributes. An interesting thing happens with InfoGrid , where only uuids are indexed. An important peculiarity of Neo4J is that they are not indexing as a default behavior. There are many different indexing techniques, with different properties and performance, but this would give us for a complete set of posts.

Storage system

The analyzed database products show different storage solutions: a custom storage system, a generic one or the possibility to choose your own storage solution. Personally this is an important decision, a non specialized storage system tends to perform better than an specialized one. If we are confronted with a generic storage system, it's different to be using a low level, like storage api of mysql, or a high level solution, using the sql interface of mysql for example.. We found cases such as HyperGraphDB where the use of Berkeley DB database facilitates rapid development, but also penalizes performance. However other solutions like VertexDB and DEX have their own storage, or a low level generic storage, giving better performance. In an upcoming post we'll see an indepth performance benchmark. Collaborations and ideas are welcome.

Programming APIs

Basically we want to develop, using our favorite programming language, with the best database. Our review shows us several solutions to this problem. There is Neo4J which provides web API's and for a variety of programming languages, however the majority only provide an API for Java. However there is a generic solution, web services API, also found in many of the existing databases. As a conclusion there are enough resources to use this databases using the most common programming languages. But after the review of their common characteristics, here is a list of missing things that we believe are important.
  • A standard, and independent, benchmark will provide customers with comparison data that is useful while trying to make a decision.
  • Transaction and indexing facilities are not present in all the solutions analyzed. In our opinion this is an important feature that must be in every decent solution.
  • A query language. The use of such languages facilitate the development of queries.
  • Tools, Tools and more tools. Without tools that facilitate the development, maps, objects, management tools, etc. .. development becomes harder.

Although is not a full graph database, Twitter have presented FlockDB. Backed by a MySQL database, at least this new enhanced graph database is an important solution. Finally just to say that if you find any mistake in this comparison it is entirely my responsibility. Please let me know and I'll correct them as soon as possible.

References
Published at DZone with permission of its author, Pere Urbón-bayes. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Tarik Ibrahim replied on Fri, 2011/11/18 - 5:39pm

Links to http://purbon.com/en/nosql_graphdb_feature_comparison do not work

Carla Brian replied on Mon, 2012/07/30 - 10:26am

This is really a good news . I will study more on this and be familiar on the applications. I need to practice more about this one. I think that would be a greate idea.  - Mercy Ministries

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.