A Comparison of 7 Graph Databases by Alex Popescu.
Alex links to a graphic from InfiniteGraph that compares Infinite Graph, Neo4j, AllegroGraph, Titan, FlockDB, Dex and OrientDB.
The graphic is nearly unreadable so Alex embeds and points to a GoogleDoc spreadsheet by Peter Karussell that you will find easier to view.
Thanks Alex and Peter!
From the post:
Was it just two or three years ago when choosing a database was easy? Those with a Cadillac budget bought Oracle, those in a Microsoft shop installed SQL Server, those with no budget chose MySQL. Everyone in between tried to figure out where they belonged.
Those days are gone forever. Everyone and his brother are coming out with their own open source project for storing information. In most cases, these projects are tossing aside many of the belts-and-suspenders protections that people expect from the classic databases. There are enough of them now that some joker started calling them NoSQL and claiming, perhaps tongue-in-cheek, that the acronym stood for Not Only SQL.
I remember reading somewhere that the #1 reason for firing sysadmins was failure to maintain proper backups. A RDBMS system isn’t a magic answer to data security and anyone who thinks so, is probably a former sysadmin at one or more locations. 😉
You need to read Jim Grey’s Transaction Processing: Concepts and Techniques if you want to design reliable systems. Or that is at least one of the works you need to read.
Do use the “print” option so you can read the article while avoiding most of the annoying distractions typical for this type of site.
Not detailed enough to be particularly useful. Actually I haven’t seen a comparison yet that was detailed enough to be really useful. I suppose in part because the approaches are different, would be hard compare apples with apples.
What might be useful would be to compare the use cases where each system claims to excel. Now that might be a continuum of interest to readers.
What do you think?
User Generated Content and the Social Graph by Chris Chandler.
Uses Twitter as a case study. Covers Gizzard and FlockDB, both of which were written in Scala.
Wants to coin the term “MoSQL! (More than SQL).”
A couple of points of interest to topic mappers.
Relationships maintained as forward and backward edges. That is:
“A follows B” and
“B is followed by A”
Twitter design decision: Never delete edges!
Curious if any of the current topic map implementations follow that strategy with regard to merging? Thinking that the act of creating a new item either references other existing item (in which case create new version of those items) or it is an entirely new item.
In either case, a subsequent call returns a set of matching items and if more than one, take the most recent one by timestamp.
As Chris says, disk space is cheap.
Works for Twitter.
General overview of Neo4J, FlockDB, AllegroGraph, GraphDB, InfiniteGraph.
Powered by WordPress