From stdenis@fnal.gov Fri Mar 16 23:56:07 2001 Date: Mon, 11 Dec 2000 15:14:35 -0600 (CST) From: Rick St. Denis Reply-To: r.stdenis@physics.gla.ac.uk To: Bill Ashmanskas Cc: Mark Lancaster , Marjorie Shapiro , Jim Amundson , Stephen Wolbers , Terry Watts , stefano.belforte@ts.infn.it, rharris@fnal.gov, ksmcf@fnal.gov, sexton@fnal.gov, Rob Snihur Subject: Re: Offsite Database Export Review Hi bill > On Sun, 10 Dec 2000, Mark Lancaster wrote: > > Thanks again for filling me in. I have several follow-ups, one or two of > which are I think pertinent to database export and the rest of which are > related more generally to DB, not DB exporting, and thus you are well > within your rights just to "pass." > > Your COTWPO table seems to have a row per version per wire, so reading one > complete alignment requires reading O(nwires) small rows, rather than one > big row. Is it safe for me to assume that this comes with no particular > cost? (I think probably the benchmark I quoted--the read times for the > complete set of CTC constants, stored in whatever way you plan to store > the COT constants--would answer this.) Again you are free to dismiss this > question as, "not pertinent for this week's review." Oracle: No quantitive through tests, but the sitting at your terminal and noticing how long it took test is convincing. We are now striving to use arrays of constants instead of one /row since rows are waht oracle cares about. 17K rows of silicon peds (one per barrel 4 channel) with channel, ped, noise, dnoise, took, say 40s. 173 rows of peds ARRAYS where we had the same info in "byte array" format like chipid ped1(128) ped2(128) ped3(128) threshold took a hesitation (1 s?) to read. So it was like getting all that info for free. So free that we put lots of effort into float and int arrays and the silicon types are converting that 17K row table to arrays. > > > For now I am not convined we should get hung up on the details of access > > times and storage overheads - with some optimisation these will all be > > acceptable. We should rather I think concentrate on how easy it will be to > > administer the exports. > > I am still curious to see the results of a simple extension of the > performance test that you already did, which is to write 1000 rows in run > order, then read back those rows in random order, for both database > candidates. I consider this semi-pertinent, as a comparison of the two > databases' performance. indexes on the primary key exist on both databases and should make this work. We have lots of things to analyze about our indexes being "balanced". You pay for this in x2 more disk as a rule, by the way. > > On my two points "first access vs subsequent access" and "frequently used > vs infrequently used" constants, I think that maybe twice I managed not to > ask the question that I really wanted to ask (though the answers were > useful anyway). I'm wondering if some of the constants, such as SVX > pedestals, will be deemed by consensus to be so infrequently needed by > remote users (not necessarily node by node), that they would not be > exported, and then one could fall back to some kind of direct socket-based > access to the FNAL database. I'm not so concerned about having to wait > until the next day to read constants from FNAL. If the pure-network > fall-back mechanism exists for a subset of the DB, though, then maybe a > process-by-process switch could be thrown (getenv, talk-to, etc.), > allowing one to function with no exported database. I didn't necessarily > mean that one wants to cook up a separate export list for each remote > instititution; that sounds like a big hassle for FNAL-based > administrators. I'm wondering if direct TCP/IP socket access to some FNAL > DB server is a straightforward upgrade/downgrade of the current plan, > since it seems like a really simple fallback option for new nodes, > temporary nodes, transient export failures, and who knows what other > unforseen scenarios. > > > True CID does map onto comp/attr/run/version and can then via SET_RUN_MAPS > > and USED_SETS be mapped to a higher level identifier e.g. beam-fix-hack-1. > > Great, this sounds like exactly the solution we need for the worst of the > Run I DB's deficiencies, the what-version-to-use problem. I still have no > concept, though, of how one specifies, for a given job, whether or not to > use "beam-fix-hack-1." It would seem nicer to do it by talking to a > central DB manager, rather than requiring each piece of code that accesses > the DB to have a talk-to parameter allowing one to select the set of > constants to be used. But this is not at all pertinent to tomorrow's > review. There is a central DB manager. We have developed clear recommendations (in email!) to our developers to allow talk-to parameters to determine 1. if they use keyed vs unkeyed access. in english, do they get the comp/attr/run/version from explicit talk-to as you MUST have for code and algorithm development where you run over the same run again and again, OR do you let the database contain that information. 2. if they use the "default" database defined by the manager or they explicitly say what database they use. This leads them to the ability to say 1. I want all tables except for this one that i am working on to come from oracle and i want my table to come from a text file. 2. I want all tables to come from oracle, but i want to specify which tables are to be used by a run with my own text database of this There are some handy tools still missing but effectively the muon crisis ate that manpower.... > > > The only space/compressions/access issues are with SVXPED - I think with > > everything else you buy enough disk and don't worry about it - it will not > > effect your analysis. Clearly there is some padding with storing data in > > tables (key, index overhead) compared with a binary C-struct file. We get > > some padding at the expense of increased funtionality and a cure for run-1 > > deficiencies. > > I more or less accept this as a general argument, but I won't stop > worrying about it until I see the actual numbers. If I am ever a reviewer > for general database issues, I will want a quantitative performance (time > and space) analysis. But I probably have no right to expect an answer to > this question in the context of this meeting (unless there is a gross > difference in time/space performance between the two remote database > technologies)--again, just curious. > I am glad to do the analysis if you tell me what it is you are storing on the database. With your 1000 runs: is this 1000 in the middle of a database with 2000000 other entries? BIG difference.... What is the rest of the database looking like? Example: we see that if we dont have the rollback segments sized properly (out of the box oracle is stupid) then we get performance slowdowns at about 4 million rows..... > Thanks again for all the detailed information. > > -Bill >