An Overview of the BaBar Conditions Database

1
An Overview of the BaBar Conditions Database

• Igor A. Gaponenko
• Lawrence Berkeley National Laboratory
• ( IAGaponenko_at_LBL.Gov )

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

3
The Functional Definition

• An abstraction - the Conditions Database is a
  collection of so called conditions functions
• 2 access keys
• validity time
• revision
• 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

4
The Structural Components
Users code


Management Utilities
Proxies
Transient cache
Data store fetch API
Management API
Transient API
Persistent cache
Persistent Store (Objectivity/DB)
5
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
• 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.
• Its 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.

6
Two-layered Namespace
ltvalueAgt FA ( ltvalidity timegt, ltrevisiongt
) ltvalueBgt FB ( ltvalidity timegt, ltrevisiongt
) ltvalueCgt FC ( ltvalidity timegt, ltrevisiongt ) .
. . . . . ltvalueZgt FZ ( ltvalidity timegt,
ltrevisiongt )
EMC
DCH
Conditions functions
ETC
Detectors
7
A Layout of the Persistent Store
Link database
Index database(s)
Object database(s)
A
B
C
B
C
Each container keeps a history of a particular
condition.
A namespace for conditions. Each container has a
symbolic link.
Real condition objects are stored in here.
8
The File System of the Database
...conditions/
DOMAIN
emc/ ...
drc/
DETECTOR
con_drc_Link
con_drc_Index_core
con_drc_Index_opr-core
drc/
drc002000-002100/
con_drc_drc002000
con_drc_drc002001
con_drc_drc002002
9
A plain Condition Function
Validity time
Plain history of a calibration object
FIRST
LAST
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.

10
A versioned Condition Function
baseline intervals are shown in blue.
Versioned history of a calibration object
V4
V3
V2
V2
V1
V1
LAST
FIRST
V0
V0
Infinity
-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.

11
A Concept of Revisions
V4
V3
V4
V2
V3
V5
V2
V1
V1
V2
V1
FIRST
LAST
V0
V0
V0
Infinity
-Infinity
revision 3
revision 2
Revisions
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.

12
The Persistent Schema (simplified)
Symbolic links
Link databases
0..n
0..1
1..n
1
Condition functions
Index databases
Object databases
Condition objects
13
The Modification History
14
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.
• 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.

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

16
Problem of composite objects
ClassA
Step I
Step II
The branches have other type then ClassA. They
are not being copied