Hi Valerio, My responses inlined. On 13 August 2014 23:00, Valerio Schiavoni <[email protected]> wrote:
> Hello OrientDB community, > I've been following the discussions of this group in stealth-mode for a > while, > and even looking through the archives I could not find an answer to my > question, > therefore it's time to ask you all. > I've personally never used OrientDB until today. > > I need to store a very large graph (+60M nodes, approximately 400M edges). > Nodes are labeled with few attributes (floats, strings), and so are the > edges. > The overall memory footprint of the resulting graph makes it impractical > to store > everything on a single-machine, even one with 16GB of memory. > 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? - what kind of traversal you will do? - what's the expected performance in terms of query/sec? 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. > 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. > 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. > Finally, have you seen [1] comparing 4 graph databases (including > OrientDB) ? It does not win in all cases, and maybe it might serve as a > good motivator to boost even more the performances of the system. > > Thanks, > Valerio > > 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. 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... Lvc@ -- --- 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.
