@ qcon: I can't find the twitter videos on http://qconlondon.com/london-2011/ rick could you please point to further rescources?
@ aseem: I gave a detailed answer to your questions on http://www.rene-pickhardt.de/graphity-an-efficient-graph-model-for-retrieving-the-top-k-news-feeds-for-users-in-social-networks/#comment-1295 but I think we have the same oppinion. The approach that you wrote down here is exactly what my baseline STOU does. you have your friendship relations as a (S)tar and the events as (T)emporal (O)rdered (U)pdeats ( = STOU ) The merging traversal is the same in STOU and Graphity. The only difference is that in STOU I have to sort the egonetwork O(d log d) where d is infact the outdegree. Once we understand this everything else is easy: You look at your kind of application and decide what your ratio of read to write operations is. Once reading happens far more frequently you better use graphity in the other case your method seems more sufficiant. What I have learnt from your comments that not only the ratio of reads to writes is interesting but the distribution of outdegrees should be considered when deciding which algorithm to use.. If the outdegree really stays small your approach will be more efficiently. @maxdemermazi: performance with bigger k drops in both cases. retrieval with graphity is O(k log k) where STOU is O(d log d + k log k) and for small k the d part is just dominating. So what's happening here is that graphity will always be faster since no sorting of the egonetwork is involved. Besides. Why would you want to have such a big k. Even if your twitter stream genereated that many updates when you come to the website you will only get to see a small k of them and as soon as you scroll down you will see the next k + l tweets... @custom neo4j: well let's ask Peter if neotechnology will include support to handle that many relationship types again to neo4j. I certainly would be happy about that. 2011/11/22 maxdemarzi <maxdema...@gmail.com> > A couple of things bothered me about Rene's approach. > > 1. Custom Neo4j that could handle lots of relationship types. Not 100% > sure > where this fits? > 2. Performance drops like a bomb when K (the number of items retrieved) > increases. > > So it kind of works to get the top 15 items... A twitter stream could have > 500 items easy per update (on my iphone every few hours). > > > > -- > View this message in context: > http://neo4j-community-discussions.438527.n3.nabble.com/Activity-Streams-and-Twitter-Sample-App-tp3477669p3526543.html > Sent from the Neo4j Community Discussions mailing list archive at > Nabble.com. > _______________________________________________ > Neo4j mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > -- -- mobile: +49 (0)176 6433 2481 Skype: +49 (0)6131 / 4958926 Skype: rene.pickhardt www.rene-pickhardt.de <http://www.beijing-china-blog.com> _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
