Hmm..
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
> [email protected]
> https://lists.neo4j.org/mailman/listinfo/user
_______________________________________________
Neo mailing list
[email protected]
https://lists.neo4j.org/mailman/listinfo/user
