On 14 August 2014 11:29, Valerio Schiavoni <[email protected]> wrote:
> Hello Luca, > > Yes. The database is write-once, but reads follow unpredictable >>> patterns. >>> >> >> So you import the database at the beginning and then you make only >> traversal, right? >> > > Correct. > > >> [2] - http://en.wikipedia.org/wiki/Memoization >>> >> >> We don't support this out of the box, but you could create in-memory >> graphs as result of traversing, and then reuse them fir further queries. >> > > Ok, good to know. This suggests that internal caching is also out of the > picture. > OrientDB already caches traversed nodes and edges. So traversing the same path the second time will be a RAM-only operation. > > https://github.com/orientechnologies/orientdb/wiki/SQL-Create-Class#cluster-selection-strategy > > Thanks. > > >> If the vertices are sharded following a min-cut clustering, this cost >>> should be low...right? >>> >> >> Right >> > > Nevertheless, this seems to contradict the rationales behind any of those > 3 cluster selection strategies. Node of them seem to to be aware of the > clustering degree of the graph components. In a distributed deployment, > such strategy should be definitely worth investigating. > > >> They tested OrientDB 1.3, released on December, 19th 2012 ( >> https://code.google.com/p/orient/downloads/detail?name=orientdb-1.3.0.tar.gz&can=2&q=#makechanges >> ). >> >> Recently I found another benchmark published 2 months ago, where they >> used YCSB with recent version of NoSQL products and... OrientDB 1.0.1... >> > > I feel your pain. > Unfortunately, paper publication rate is always orders of magnitude slower > than your release-rate. > And I guess you won't slow down your release rate :-) > ;-) 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.
