Live data from Hacker News

Titan: A Highly Scalable, Distributed Graph Database

thinkaurelius.github.com

1–10 of 41 posts

Re: Titan: A Highly Scalable, Distributed Graph Database

#3
Very interesting. Since it implements Blueprints, does it also have support for Furnace (graph algorithms)? If so, does this imply that graph processing is done on disk rather than in-memory? I am rather unfamiliar with Blueprints but I'm wondering how Titan implements that aspect.

Re: Titan: A Highly Scalable, Distributed Graph Database

#4
Also,

What is interesting about a graph database relative to simple key-value database? Storing edges of a graph is trivial for a key-value store and so it seems like any key-value store could let store the basic graph structure?

Do graph databases support graphic-specific queries and indices?

Re: Titan: A Highly Scalable, Distributed Graph Database

#5

Also, What is interesting about a graph database relative to simple key-value database? Storing edges of a graph is trivial for a key-value store and so it seems like any key-value store could let store the basic graph structure? Do graph databases support graphic-specific queries and indices?

They seem to implement a variety of graph centric APIs. From a query standpoint, it's easier to use a graph database to do something like find all the people who share interests with someone (person interest person), or find all the grand children in a family tree.

Now whether or not Titan implements these performantly, I have no idea.

Re: Titan: A Highly Scalable, Distributed Graph Database

#6

Also, What is interesting about a graph database relative to simple key-value database? Storing edges of a graph is trivial for a key-value store and so it seems like any key-value store could let store the basic graph structure? Do graph databases support graphic-specific queries and indices?

I can only answer for one advantage I specifically know of regarding graph DB's over key value: dynamic, mergeable schemas which enforce data integrity WITHIN the database rather than with code on top of it.

There are many, many people on HN who are much more knowledgeable than I am on graph DB's, and I sure as hell hope they answer on this question.

I'm curious if this supports the RDF, OWL, and SPARQL standards?

I'm a little tired of graph DB's that focus on scale, rather than speed and flexibility though. A good one to check out is Stardog. http://stardog.com/ I think it just went into 1.0.

Re: Titan: A Highly Scalable, Distributed Graph Database

#8
What makes this graph database "highly scalable, distributed"?

There are difficult theoretical computer science problems that effectively limit the parallelization/distribution of generalized graph operators. To achieve high scalability you have to solve these computer science problems first. If this design offers a novel solution to the longstanding computer science problem then kudos, but nothing at the site suggests this is the case.

Many graph databases have claimed high scalability and distributability but none of those claims have held up over time due to the aforementioned computer science problems. This may be a very nice graph database but I am skeptical of the claims of "highly scalable, distributed" unless there is evidence that it uses fundamentally new theoretical computer science to achieve that.

Re: Titan: A Highly Scalable, Distributed Graph Database

#9
post #2

Interesting, does anyone know how this compares with the popular Neo4j Database?

Each Neo4j node stores all of the data, and it doesn't scale write horizontally well.

OrientDB tries to scale writes (I'll be testing this in a few months), but still stores all of the data everywhere.

This looks like it shards the data automagically. If it works well, I might be able to bang on it a bit, but I'm guessing that it gives shit performance for complex graph questions.

Re: Titan: A Highly Scalable, Distributed Graph Database

#10
post #9
post #2

Interesting, does anyone know how this compares with the popular Neo4j Database?

Each Neo4j node stores all of the data, and it doesn't scale write horizontally well. OrientDB tries to scale writes (I'll be testing this in a few months), but still stores all of the data everywhere. This looks like it shards the data automagically. If it works well, I might be able to bang on it a bit, but I'm guessing that it gives shit performance for complex graph questions.

Titan exposes graph data over a machine cluster. It is an OLTP system that allows you to do local neighborhood graph traversals in sub-second time. For OLAP processing (e.g. global graph algorithms), Aurelius will be releasing two projects named Faunus and Fulgora in the coming months. These provide Hadoop connectivity and compressed in-memory representations of "graph slices." We will be publishing our talk slides tonight that discuss this eco-system of graph technologies. See http://titanbiggraphdata.eventbrite.com/
Post reply on HN