[Neo] Dispell the myth? FlockDB vs. Neo4j

Neil Ellis neil.ellis at peepwl.com
Tue Apr 13 16:51:55 CEST 2010


Yep, that sounds about right.

I wonder how long it would have taken to write a sharding abstraction for their use case compared to writing FlockDB, but hey I'm not trying to second guess the problems they have at hand. 

I myself am pretty ruthless about what technologies I use, it just doesn't take a genius to shard many graphs by hand and how long would it take to use a hash based sharding for example on the client and then do something like:

node.setProperty("node.ref", "node://shard-name/nodeId")

on a node acting as a proxy when creating a relationship to a node outside of the current shard.

Sure, the logic is in the application, but you're going to write an abstraction around Neo to translate into the appropriate domain anyway (as we always do with persistence)?

Sorry going tangental .....

On 13 Apr 2010, at 14:45, Alastair James wrote:

>> (not sure why they didn't use a proven high speed graph DB myself - but
>> then I am biased!).
> I am guessing its because they only need 1st order relations (there are
> little friend of a friend or higher operations on twitter) and were very
> worried about scalability and sharding (as far as I am aware there is no way
> for a Neo Db to be bigger than one machine at the moment). Not
> to mention that they probably have considerable mysql infrastructure and
> expertise....
> I think its pretty obvious that FlockDB will be very slow for 'deep'
> traversals (network protocol speed alone will ensure this as FlockDb will
> need to talk to mysql on each node visited), but for order 1 traversals
> (e.g. what boils down to a join across a mapping table) mysql is probably a
> lot faster (no transactional overhead for read ops).
> Al
> _______________________________________________
> Neo mailing list
> User at lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user

More information about the User mailing list