Hello Luca,
60M of nodes and 400M of edges is not that big, you could manage the entire > graph in 1 machine, but depends by the kind of operation you do against the > graph: > > - is it mostly read than write? > > Yes. The database is write-once, but reads follow unpredictable patterns. > > - what kind of traversal you will do? > > The main operation will be a shortest-path between any two vertices. The number of hops between any two vertices follow a scale-free distribution. > > - what's the expected performance in terms of query/sec? > > I don't need to comply to a particularly stringent SLA, but it has to be fast... For instance: internally, does OrientDB memoize traversal results ? [2] - http://en.wikipedia.org/wiki/Memoization Can OrientDB automatically shard (via some kind of semi/automatic >> graph-clustering) a large graph across >> a set of OrientDB nodes ? >> > > You can shard the graph against multiple nodes. We have 3 strategies to > distribute data against different machines (round-robin, balanced and > sticky), but 99% of the times it's better to rely to the application where > to store the nodes because he better know the domain. > Can you point me to the documentation where these 3 strategies are described, if any ? > How the nodes communicate to each other ? >> > > All nodes are connected via TCP/IP, so the traversal is transparent, but > could be costly if you have many hop back and forth on machines. > Are connections established once and for all, or they are created on the fly only when a given edge is traversed, and closed once the traversal has completed ? If the vertices are sharded following a min-cut clustering, this cost should be low...right? > Is there some rebalancing mechanism in the case a graph-cluster becomes >> too big ? >> > > With 2.0 we have a "move vertex" command to move vertices to nodes, this > is very useful to move one node or entire clusters. > Interesting. Given latest version I see is 1.7.8, the question is due: when do you plan to release 2.0 ? > >> 1 - >> http://www.odbms.org/wp-content/uploads/2014/05/an-empirical-comparison-of-graph-databases.pdf >> > > This is a pretty old benchmark with the old version of OrientDB that used > local and mvrb+tree indexes. Now OrientDB is totally different, and it > scales much better. > I understand your concerns. But the paper is not so old after all, officially published back in September 2013 here: http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=6693403&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6693403 > By the way I asked to the authors of the paper to retry the very same > benchmark against 1.7.x but they never responded me... > Too bad :-( -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
