Time-Ordered Persistent Collections

1
Time-Ordered Persistent Collections

• Vincenzo Innocente
• CMS Collaboration

see also contribution to RD45 workshop of 4/98
2
Problem

• Given an object, whose state depends upon time, I
  want to know its state for any given time in the
  past (and predict the future?)
• Its state is determined from direct or deduced
  measurements (or equivalent procedure) of
  unspecified nature, precision and frequency
• Well known solution the object store a history
  of its measured states in a time-series and
  compute the best value for a given time using a
  suitable interpolation or extrapolation algorithm.

3
Assumptions (Requirements??)

• Writing (insertion in the collection)
• once (never delete, never modify in place)
• in object natural time order
• by a single producer
• Object Time Validity
• until a new object is inserted
• at each time one, and only one object, is valid
  (per version)

4
Assumptions (Requirements??)

• Version Validity
• Data themselves are WORM, the collection may not
• objects are obsoleted only by versioning
• a version tags all objects in a certain time
  period
• for a given tag and a given time a valid object
  should exists
• an object can belong to more than one version
• current version makes sense
• all versions should be available
• reproducing the state of the collection at a
  given past time should be possible

5
Assumptions (Requirements??)

• Obsolescence
• rare process few new versions will be created
  (0-10)
• some objects can NOT be obsoleted (sort of
  raw-data)
• In most of the cases all objects belonging to a
  certain time period will be obsoleted at the same
  time
• Often the validity time of the new version will
  be the same of the previous version
• In some cases the new version will have a
  different time granularity (usually finer)

6
Assumptions (Requirements??)

• Read
• Very very often, by multiple clients
• besides online applications, current real time is
  not special at all
• often in natural sequence, not necessarily
  contiguous
• random access is NOT a secondary scenario
• interpolation (and extrapolation?) should be
  supported, not necessarily implemented

7
Assumptions (Misuses)

• Versioning should be used only for making object
  obsolete
• NOT to keep two different concurrent version of
  the same logical entity (for instance online
  and offline calibrations) use distinct
  collections
• The same applies for user and test versions
  (even transient ones)
• NOT to differentiate among different parts of the
  detector use different collections or different
  components in the same super-object

8
Assumption summary (Primary Scenarios)

• Data (measurements) are WORM and not related to
  time collections by themselves
• Main insertion mode is push_back
• Random update is not frequent and it is the
  result of a computing intensive activity
• A new release tag affects long time periods
• Random reading will be frequent
• Interpolation/extrapolation should be left to the
  application software

9
Persistent Architecture
Version (Insertion time)
Time
10
Persistent Architecture
Version (Insertion time)
Time
11
Time Series (column-wise)
This mechanism guarantees that the selected
object is valid for the whole time slice
Insertion time
Persistent List of stacks (time-slices)
12
(No Transcript)
13
Transient Components