[FoRK] Big changes (personal) ahead: soliciting help from the FoRK braintrust

Ken Meltsner meltsner at alum.mit.edu
Wed Mar 25 10:09:05 PDT 2015


For me, when I evaluated Titan Aurelius, the big draw was the ability
to deal with relative complex DAGs, but to be honest, if you can get
around the relatively cumbersome SQL, you can do the same thing with a
stock RDBMS.  [It's not that it's impossible to implement hierarchical
and DAG models in SQL, it's just that previous products did it badly
IMHO.]

I also liked the property graph approach, but if you don't need a
flexible schema, that's not an advantage.  For us, putting together
service models from various hardware and software configuration items
was simplified with property graphs -- the two most common approaches
is to have a separate table for each object type (or a common table
and an extra property table per class), or to use a vertical model
similar to triples.  The former is annoyingly inflexible, the latter
seems to run into performance issues.  I suppose we could have used
one table shared for all of the objects and a vertical table for the
extra properties, but that means some properties become second class
citizens for purposes of queries and such.

We didn't use or need Faunus, the analytics add-on to Titan, so i
can't say whether that would have changed our decision.

Ken Meltsner


On Wed, Mar 25, 2015 at 11:54 AM, Lucas Gonze <lucas.gonze at gmail.com> wrote:
> On Mon, Mar 23, 2015 at 1:22 PM, Stephen D. Williams <sdw at lig.net> wrote:
>
>> On 3/23/15 9:40 AM, Lucas Gonze wrote:
>>
>>> My current team just unhooked Neo4J. It seemed like a good idea but in
>>> practice added more complexity than it removes.
>>>
>>
>> What did you switch to?
>>
>
>
> Mongo and Postgres.
>
>
>
>> Did your problem need a graph?
>>
>
>
> The product requires spidering all the various sites where a band has a
> presence and linking the data from those sites. We link up their content
> from Soundcloud, Twitter, FB, YouTube, as well as image vendors like Getty
> and AP. It's hard not to see this as a graph problem.
>
> But we in practice we really weren't using graph algorithms.
>
> Maybe that will change once I have been here longer and get around to
> architecture of the crawler and knowledge graph.
>
>
>
>>
>> Often, an app only needs to do graph processing in memory.  Object or
>> document databases, which include RDBMS's that can handle blobs well, can
>> be a better alternative.  Or Hadoop / Spark for batch processing.
>>
>
>
> Yup. That's us to a T.
> _______________________________________________
> FoRK mailing list
> http://xent.com/mailman/listinfo/fork



-- 
After 30+ years of email, I have used up my supply of clever ,sig material.


More information about the FoRK mailing list