Treat it as event log. Sort in inverse order of the date they became followers and return it in pages which include adds and deletes. This will allow an in synch copy of the data to be mantained elsewhere.
On Mon, Sep 7, 2009 at 5:09 AM, Dewald Pretorius<dpr...@gmail.com> wrote: > > I don't understand why it would be foolish. Nevertheless, if flat > files are considered archaic, then memcache dedicated to caching large > social graph id lists for several minutes would provide the same > benefits, wouldn't it? > > The reason why I would prefer flat files above memcache is that you're > not limited to the memory available and won't have an older entry of > @aplusk being deleted before the caching period has expired simply to > make space for a new one of @ev. In other words, you have absolute > control over how long a "cached" data set remains available. > > Dewald > > On Sep 7, 6:40 am, freefall <tehgame...@googlemail.com> wrote: >> Flat file generation and maintenance would be foolish at this stage. >> Seperating out the individual data sets purely for api to be served >> by different clusters with server side caching may fit the bill - but >> tbh if this isn't happening already I'll be shocked. >
