13 comments

[ 5.4 ms ] story [ 51.5 ms ] thread
(comment deleted)
Looks rather complex. Based on hypergraphs which are generalizations of graphs, and are difficult to draw on paper. Haskell of databases?
I haven't looked deeply into this particular project but I agree with you: the hypergraph data model seems to add too much complexity for too little bang compared to a generic graph model. The Neo4j graph database:

http://neo4j.org

is based on generic property graphs. We sometimes get requests for hypergraph features, but we've found that the real-world problems are always solvable through a normal graph. Either way, it's very nice to see more open source graph databases out there!

-EE

My take was similar. It seems to focus too much on flexibility in storage, whether objects or graph elements, to the detriment of clarity in its API.

The one bit that piqued my interest is that it claims to be a distributed database, so looking at its mechanism for such will be interesting.

A classical hypergraph can be easily drawn as a bipartite graph (see http://en.wikipedia.org/wiki/Bipartite_graph). HyperGraphDB goes to an extra dimension (with higher order links) and that's hard to visualise if you want to see connections b/w different abstraction levels. Otherwise, once you get past the slightly unfamiliar concepts, HyperGraphDB would make working with complicated models much simpler.
I'm a little confused about the license. HyperGraphDB is LGPL, but ships with Berkeley DB. Isn't BDB GPL? Could I distribute a closed-source app with this?
They're probably using the BDB Java Edition which uses a GPL-compatible license and does require all source code be released with program distribution. Looks like you're right, HyperGraphDB can't be LGPL.

More info: http://www.oracle.com/technology/software/products/berkeley-...

We are using the C version of BDB (which is also GPL) because this makes potentially accessible from C++ if anyone cares to port the Java code :) The Java version actually started started as prototype that would become the "real" C++ version.

As for the license, HyperGraphDB is LGPL in the sense that a version where the BDB dependency is removed will have no strings attached for commercial use. Architecturally, HyperGraphDB has a low-level storage layer that is isolated by a handful of classes and is currently implemented with BDB. So it is not such a major undertaking to replace it, given a suitable (in terms of license, functionality etc.) replacement.

I wonder how performant this is, since I see no mention of benchmarks and such.

I'm currently using MongoDB to store a graph, and it's not that bad to use, except that pagination of a node's edges is unwieldy, atleast the way I have it set up.

But I don't see how to do it smoothly in HyperGraphDB either. I don't see a way to sort by edge weight within a query, and limit results to say the top 10, or skip them. So I'd have to load up all the edges to a node, and sort/limit/skip them myself?

Benchmarks are a good idea and we'll certainly post some numbers in the near feature. I've searched for some good standardized data sets and queries/algos for graph databases, but found none, so if somebody here has a pointer, I'll be much appreciated!

We haven't added pagination, sorting and the likes yet, because we thought they are more of a priority for a server-oriented database. And HyperGraphDB has been exclusively used as an embedded database where large portions of the graph are kept in main memory and such things are done by application code. But I agree it's a valid and common use case and we'll try to add those sooner rather than later. In the meantime, if you want write to the discussion forum with more info about your problem and I'll be happy to help.