 |
 |
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. > 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. > 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