| | 5 | 1. ** slony ** : A replication system for the underlying DRMS/SUMS database. |
| | 6 | 2. ** SUMS ** : Storage Unit Management System. |
| | 7 | 3. ** sunum ** : Storage Unit Number. Depending on context, may be the identifier, or the storage unit being tracked. |
| | 8 | 4. ** series ** : A collection of the same type of data within DRMS. May refer to the table in the database or the actual data. Examples include 'aia.lev1', 'aia.lev0', and 'hmi.s_720s' |
| | 9 | 5. ** recnum ** : Record number. Unique identifier (autonumber) for records in a series table in DRMS. |
| | 10 | 6. ** prime key ** : Effectively, a primary key (unique identifier) to a given **observation** within a series. Note that it is **not** unique within the series -- you have to look at the maximum recnum for a given 'prime key' to determine what the current best record is. To determine what the 'prime key' for a series is, look at '(namespace).drms_series' for 'primary_idx' |
| | 11 | 7. ** shadow table ** : A parallel table in DRMS that's kept in sync with the official DRMS tables. Tables are named either : |
| | 13 | {{{ |
| | 14 | vso.(instrument)_(series) |
| | 15 | }}} |
| | 16 | |
| | 17 | This is used originally for the test series, or : |
| | 18 | {{{ |
| | 19 | vso.(instrument)__(series) |
| | 20 | }}} |
| | 21 | |
| | 22 | The renaming of tables arose because the JSOC does not allow the VSO identifiers update to point to the 'best' data for a given observation. If this were to happen, an identifier that had previously been from before official release would later retrieve the well-calibrated data. The shadow tables use the 'prime key' as their primary key - they do **not** track older metadata. They're also well-indexed, so you can search on them directly, and times have been converted to use database date fields rather than stings. A VSO search will use **only** the shadow tables, not the official DRMS tables. (This might need to be qualified as 'vso shadow tables', since the JSOC may have started doing something similar, in which case they have their own "shadow tables". |
| | 23 | |
| | 24 | |
| | 25 | 8. ** Storage unit ** : Unless qualified (storage unit number), refers to a directory of data being managed by SUMS. Note that there is **not** a 1:1 mapping between storage units and recnums; if the metadata is updated but not the data, the new recnum just points to the old storage unit. In some series, blobs of data are not tracked individually; the actual identifier to get to a file is a combination of SUNUM, slot (sometimes called 'unit') number and 'segment'. |
| | 26 | 9. ** slot ** : aka. ** unit ** : Subdirectories within a storage unit directory so that SUMS can group together multiple DRMS records and track them as one item. Note : every unit has the same basic structure, and each unit corresponds to a record in DRMS (possible more than one, if the metadata's been updated). Although it's possible to do for any series, the default is in '(namespace).drms_series' under 'unitsize' at the top of each storage unit directory is a 'Records.txt' and a series of directories such as 'S00000' which has a mapping of recnums to the slots |
| | 27 | 10. ** segment ** : Different files within a given SUNUM / slot. The difference between this and slots is that they are somehow fundamentally different. For instance, within 'aia.lev1' there is 'image_lev1' and 'spikes' (bad pixel map). |
| | 28 | |
| | 29 | |
