21 April, 1999 Vincenzo Innocente LHC++ Meeting1 Time-Ordered Persistent Collections Vincenzo Innocente CMS Collaboration see also contribution to RD45

21 April, 1999 Vincenzo Innocente LHC++ Meeting

1

Time-Ordered Time-Ordered Persistent CollectionsPersistent Collections

Vincenzo InnocenteCMS Collaboration

see also contribution to RD45 workshop of 4/98


2

ProblemProblem

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??)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


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


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


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)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 Assumption summary (Primary Scenarios)(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 ArchitecturePersistent Architecture

Version (Insertion tim

e)

Time


10

Persistent ArchitecturePersistent Architecture

Version (Insertion tim

e)

Time


11

Time Series (column-wise)Time Series (column-wise)

Insertion time

PersistentList of stacks(time-slices)

This mechanism guarantees that the selected object is valid for the whole time slice


12


13

Transient ComponentsTransient Components

Documents

21 April, 1999 Vincenzo Innocente LHC++ Meeting1 Time-Ordered Persistent Collections Vincenzo Innocente CMS Collaboration see also contribution to RD45