

HyperGraphDB - a new open-source graph db - labria
http://www.kobrix.com/hgdb.jsp

======
hassy
Looks rather complex. Based on hypergraphs which are generalizations of
graphs, and are difficult to draw on paper. Haskell of databases?

~~~
emileifrem
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

~~~
wheels
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.

------
ehsanul
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?

~~~
borislav
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.

------
macmac
[http://209.85.129.132/search?q=cache:PQiKtMRXBJkJ:www.kobrix...](http://209.85.129.132/search?q=cache:PQiKtMRXBJkJ:www.kobrix.com/hgdb.jsp+hypergraphdb&hl=en&strip=1)

------
mseebach
It's not just you!

<http://downforeveryoneorjustme.com/http://www.kobrix.com/>

------
cmars232
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?

~~~
mattrepl
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-...](http://www.oracle.com/technology/software/products/berkeley-
db/htdocs/licensing.html)

~~~
borislav
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.

------
borislav
it's back up

