Transcript CHEP2000

CHEP2000 – February 10, 2000
An Overview of the BaBar Conditions
Database
Igor A. Gaponenko
Lawrence Berkeley National Laboratory
( [email protected] )
CHEP2000
Introduction…


The Conditions/DB has been developed in the context of the BABAR
experiment at the Stanford Linear Accelerator Center.
Basic requirements:

The database is meant to store:
2
 detector alignments;
 calibrations constants;
 Other time-dependent records, under which the experimental events are taken.



A possibility to have multiple versions of conditions data;
The data are recorded every 30 minutes (in average).
The technology:

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

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 BaBar Conditions Database
CHEP2000
The Functional Definition

An abstraction - the Conditions Database is a collection of so called conditions
functions:

2 access keys:
 validity time
 revision


3
Provides: condition objects
The definition of validity time:

Is implemented as 64-bit unsigned integer (only 32 uppermost bits are used)
 The granularity: 1 second
 Covers a period from logical minus infinity (Jan 1, 1900 UTC) to logical plus
infinity (+232 seconds)

The secondary key is revision

Allows to choose among different versions of the same condition
 Is implemented as 32-bit unsigned integer
 Each condition function has its own set of revisions
February 10, 2000
Igor A. Gaponenko: An Overview of the BaBar Conditions Database
CHEP2000
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 BaBar Conditions Database
CHEP2000
The Database API

The main functions provided through the Conditions database API are:

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 BaBar Authorization System.

The “store” interface allows storing either:
5
 a single value for a condition for a specified validity interval;
 or a vector of conditions.

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.
 An extensive management API is intended to manage the contents of the database:
 Deletion, renaming, copying and verifying of condition functions;
 Browsing the contents of database;
 Etc.
February 10, 2000
Igor A. Gaponenko: An Overview of the BaBar Conditions Database
CHEP2000
Two-layered Namespace
<valueA> = FA ( <validity time>, <revision> )
<valueB> = FB ( <validity time>, <revision> )
<valueC> = FC ( <validity time>, <revision> )
...
...
<valueZ> = 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 BaBar Conditions Database
CHEP2000
A Layout of the Persistent Store
Link database
A
Index database(s)
Object database(s)
A
7
B
C
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 BaBar Conditions Database
CHEP2000
The File System of the Database
...conditions/
DOMAIN
emc/ ...
drc/
DETECTOR
con_drc_Link
8
con_drc_Index_core
con_drc_Index_opr-core
drc/
drc002000-002100/
con_drc_drc002000
con_drc_drc002001
con_drc_drc002002
February 10, 2000
Igor A. Gaponenko: An Overview of the BaBar Conditions Database
CHEP2000
A plain Condition Function
“Plain” history of a calibration object:
FIRST
Validity time
LAST
9
-Infinity
+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 BaBar Conditions Database
CHEP2000
A versioned Condition Function
“Versioned” history of a calibration object:
“baseline” intervals
are shown in blue.
V4
V3
V2
V1
FIRST
-Infinity
V0
10
V2
V1
V0
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 BaBar Conditions Database
CHEP2000
A Concept of Revisions
V3
FIRST
V4
V4
V2
V5
V3
V2
V1
V1
V2
V1
V0
V0
V0
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 BaBar Conditions Database
CHEP2000
The Persistent Schema (simplified)
BdbPString
Symbolic links
Link databases
12
BdbRegistry
1..n
1
BdbRevision
0..n
0..1
Condition functions
Index databases
Object databases
BdbObject
Condition A
February 10, 2000
BdbIntervalR
Condition objects
Condition B
Igor A. Gaponenko: An Overview of the BaBar Conditions Database
CHEP2000
The Modification History
State I:
. . .
-oo
Obj1
t0
Obj2
t1
+oo
[n-1]
[n ] store( Obj3, t2, +oo )
[n+1] store( Obj4, t3, +oo )
[n+2] store( Obj5, t4, +oo )
[n+3]
Operations
13
State II:
. . .
-oo
Obj1
t0
Obj2
t1
Obj3
t2
Obj4
t3
[n+3]
[n+4] store( Obj6, t3, t4
[n+5]
t4
+oo
Operations
)
State III:
Obj6
. . .
-oo
February 10, 2000
Obj5
Obj1
t0
Obj2
t1
Obj3
t2
Obj4
t3
Obj5
t4
+oo
Igor A. Gaponenko: An Overview of the BaBar Conditions Database
CHEP2000
Current Status and Plans

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 are 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.

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 BaBar Conditions Database
CHEP2000
Problems, Experience, etc…

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

15
A problem of composite objects (see the next slide):

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 BdbObject;
 Deep deletion interface in the base class.
February 10, 2000
Igor A. Gaponenko: An Overview of the BaBar Conditions Database
CHEP2000
Problem of “composite objects”
ClassA
Step I
ClassA
16
Step II
The branches have other type then
ClassA. They are not being copied
February 10, 2000
Igor A. Gaponenko: An Overview of the BaBar Conditions Database