CHEP 2000 February 10 2000 Igor A Gaponenko

CHEP 2000 – February 10, 2000 Igor A. Gaponenko: An Overview of the Ba. Bar Conditions Database Igor A. Gaponenko Lawrence Berkeley National Laboratory ( IAGaponenko@LBL. Gov ) February 10, 2000

CHEP 2000 Introduction… l l The Conditions/DB has been developed in the context of the BABAR experiment at the Stanford Linear Accelerator Center. Basic requirements: n The database is meant to store: 2 ç detector alignments; ç calibrations constants; ç Other time-dependent records, under which the experimental events are taken. n n l A possibility to have multiple versions of conditions data; The data are recorded every 30 minutes (in average). The technology: n Is coherent with the general trends in the BABAR software: ç Provides an API for applications in C++ ç Uses Objectivity/DB as the underlying storage technology l An overview of the design, the current status and gained experience are presented in this talk. February 10, 2000 Igor A. Gaponenko: An Overview of the Ba. Bar Conditions Database

CHEP 2000 The Functional Definition l An abstraction - the Conditions Database is a collection of so called conditions functions: n 2 access keys: ç validity time ç revision n l 3 Provides: condition objects The definition of validity time: Is implemented as 64 -bit unsigned integer (only 32 uppermost bits are used) n The granularity: 1 second n Covers a period from logical minus infinity (Jan 1, 1900 UTC) to logical plus infinity (+232 seconds) n l The secondary key is revision Allows to choose among different versions of the same condition n Is implemented as 32 -bit unsigned integer n Each condition function has its own set of revisions n February 10, 2000 Igor A. Gaponenko: An Overview of the Ba. Bar Conditions Database

CHEP 2000 The Structural Components Users’ code 4 Management Utilities Proxies Transient cache Data store & fetch API Management API Transient API Persistent cache Persistent Store (Objectivity/DB) February 10, 2000 Igor A. Gaponenko: An Overview of the Ba. Bar Conditions Database

CHEP 2000 The Database API l The main functions provided through the Conditions database API are: n A two-layered namespace for the condition functions: ç A detector is used as a namespace for conditions; ç A detector corresponds to a group of the Ba. Bar Authorization System. n The “store” interface allows storing either: 5 ç a single value for a condition for a specified validity interval; ç or a vector of conditions. n The “fetch” interface is meant to retrieve stored data (values of condition functions) from the persistent store. ç It’s also possible to iterate in both dimensions in the history of a specific condition. The revision (vertical dimension in the condition function) interface. This interface supports the creation and management of revisions. n An extensive management API is intended to manage the contents of the database: n ç Deletion, renaming, copying and verifying of condition functions; ç Browsing the contents of database; ç Etc. February 10, 2000 Igor A. Gaponenko: An Overview of the Ba. Bar Conditions Database

CHEP 2000 Two-layered Namespace <value. A> = FA ( <validity time>, <revision> ) <value. B> = FB ( <validity time>, <revision> ) <value. C> = FC ( <validity time>, <revision> ). . . <value. Z> = FZ ( <validity time>, <revision> ) 6 A EMC B C T Conditions functions DCH V Y Detectors February 10, 2000 ETC Z Igor A. Gaponenko: An Overview of the Ba. Bar Conditions Database

CHEP 2000 A Layout of the Persistent Store Link database A Index database(s) Object database(s) A 7 B C A namespace for conditions. Each container has a symbolic link. February 10, 2000 Each container keeps a history of a particular condition. “Real” condition objects are stored in here. Igor A. Gaponenko: An Overview of the Ba. Bar Conditions Database

CHEP 2000 The File System of the Database. . . conditions/ DOMAIN emc/. . . drc/ DETECTOR 8 con_drc_Link con_drc_Index_core con_drc_Index_opr-core drc/ drc 002000 -002100/ con_drc 002000 con_drc 002001 con_drc 002002 February 10, 2000 Igor A. Gaponenko: An Overview of the Ba. Bar Conditions Database

CHEP 2000 A plain Condition Function “Plain” history of a calibration object: FIRST -Infinity Validity time LAST 9 +Infinity Characteristics: • In this trivial case the condition function is parameterized by a single parameter – validity time. • The history of a condition object is divided onto intervals: [begin, end). • Each interval covers a period in the validity time where the value of the condition is constant. • The intervals are connected into a linked list. February 10, 2000 Igor A. Gaponenko: An Overview of the Ba. Bar Conditions Database

CHEP 2000 A versioned Condition Function “Versioned” history of a calibration object: “baseline” intervals are shown in blue. V 4 V 1 FIRST -Infinity V 0 10 V 3 V 2 V 1 V 0 LAST +Infinity Characteristics: • The intervals above the baseline level are called versions. • Each interval may have many version within its validity time limits. • The versions are organized into trees. • Each tree grows from a baseline interval. February 10, 2000 Igor A. Gaponenko: An Overview of the Ba. Bar Conditions Database

CHEP 2000 A Concept of Revisions V 3 FIRST V 4 V 2 V 5 V 3 V 2 V 1 V 0 V 0 LAST 11 -Infinity +Infinity revision 3 Revisions: revision 2 revision 1 “baseline” Characteristics: • A revision is a second (vertical) key of the condition function. • A revision is made of intervals. Each revision, except a baseline one, has a base revision. • Each revision with their direct and indirect base revisions provides a complete timeline for the condition. February 10, 2000 Igor A. Gaponenko: An Overview of the Ba. Bar Conditions Database

The Persistent Schema (simplified) CHEP 2000 Bdb. PString Symbolic links Link databases 12 Bdb. Registry 1. . n 1 Bdb. Revision 0. . 1 Condition functions Index databases Object databases Bdb. Object Condition A February 10, 2000 Bdb. Interval. R Condition objects Condition B Igor A. Gaponenko: An Overview of the Ba. Bar Conditions Database

CHEP 2000 The Modification History State I: . . . -oo Obj 1 t 0 Obj 2 t 1 +oo [n-1] [n ] store( Obj 3, t 2, +oo ) [n+1] store( Obj 4, t 3, +oo ) [n+2] store( Obj 5, t 4, +oo ) [n+3] Operations 13 State II: . . . -oo Obj 1 t 0 Obj 2 t 1 Obj 3 t 2 Obj 4 t 3 [n+3] [n+4] store( Obj 6, t 3, t 4 [n+5] t 4 +oo Operations ) State III: Obj 6. . . -oo February 10, 2000 Obj 5 Obj 1 t 0 Obj 2 t 1 Obj 3 t 2 Obj 4 t 3 Obj 5 t 4 +oo Igor A. Gaponenko: An Overview of the Ba. Bar Conditions Database

CHEP 2000 Current Status and Plans l The status: ç The Conditions database has been in production use since May 1999; ç The total amount of data stored in the Conditions database has reached 2 GB; ç There about 250 different types of conditions grouped into 10 detectors; ç The database software has gone through a number of performance improvements and extensions in its functionality. l 14 Further development: ç More (and better) management tools are needed; ç Working on a Java-based GUI browser to simplify management and visualization of the conditions data; ç Considering a CORBA-based implementation of the Database: Þ To decouple clients from a particular federation; Þ To make management easier. February 10, 2000 Igor A. Gaponenko: An Overview of the Ba. Bar Conditions Database

CHEP 2000 Problems, Experience, etc… l Performance/space issue: ç Having multiple (more than a few 10 -s) of vertical revisions for a particular condition function does seem to create performance problems: Þ “vertical” optimization is needed ç A very detailed (highly granulated) history of a particular condition may cause a persistent space problems: Þ Splitting of the history between more than one persistent container l 15 A problem of composite objects (see the next slide): n Essential part of (250) conditions classes represent so called composite objects: ç These objects are hard to manage: copy, move, delete ç Objectivity/DB does not provide a good solution for this ç Troubles with incremental data distribution of these data around Collaboration ç Our solutions (are still under development): Þ Deep copy interfaces in a base class Bdb. Object; Þ Deep deletion interface in the base class. February 10, 2000 Igor A. Gaponenko: An Overview of the Ba. Bar Conditions Database

CHEP 2000 Problem of “composite objects” Class. A Step I Class. A 16 Step II The branches have other type then Class. A. They are not being copied February 10, 2000 Igor A. Gaponenko: An Overview of the Ba. Bar Conditions Database