 |
 |
Hi, Niall Dalton wrote: > Hi Fabrizio > >> very interesting discussion. What I still do not know or understand >> is whether your data model (messages+store) is forcefully based on the >> concept of "file" or not. > > I'm not quite sure what you mean, but am certain the answer is no :-) > We're not tied to any type of file concept. In fact users like a more > database type feel. In practice, once there are client side libraries in > common languages, they don't care too much about the underlying storage > architecture. Uhm, yes, I see a very reasonable point in that. > >> you still can use the xrootd architecture by rewriting one or more >> plugins in order to match your needs. That's what has been done e.g. >> for PROOF at CERN. > > I shall certainly investigate that, thanks. Well, I am not sure it has been officially released (however it's working) at the moment. For sure you can search the web for the most recent presentations. Quite surely Gerri is already reading these posts, so if you are interested in that way, he is one of the right persons to ask for info. Fabrizio > >> From what you say your app looks like a sequential logger, but I >> missed an estimation of the number of concurrent writers. > > "sequential logger" is quite a good description of the feed handlers. > Its somewhat complicated by the corrections and a few other corner > cases, so we can't simply append records (vertically decomposed ideally) > as we'd like to. > > The number of writers is very small, and often one per data stream (with > number of feeds in the double digit range at most). > >> For an optimization of the read case, instead, maybe you can do a >> very nice job after having analyzed the access patterns. >> Unfortunately I haven't submitted yet to the website (through Pete) >> the last papers/presentations dealing with the access optimizations. I >> will do it asap. > > That'd be great. > > niall