Time Based Sllow Data DB

We want to see what happens if we write all FACT slow data into a databases. If this works out nicely, we want to try next to allow people to access and analyse slowdata less painfully than using the aux files directly. We are not sure yet, if it is possible to provide easier access, without hiding to much from the users. Often simplicity comes at a price and we try to reduce this price, while gaining as much simplicity as possible.

Table design

First we want to try, and see what happens if we directly translate the aux file bin table extension format into MySQL tables. No relations will be created at this point. Already this simple step, is not trivially possible, since arrays cannot be stored triviall in an RDMS. So our first approach would be to translate an array "stuff" of size 100 into 100 columns named "stuff_00" to "stuff_99".

Of course when reading the data back from the DB, the information, that the data has been an array before will be lost. (Well, not if we provide some helpful code, that is able to 'recreate' the array-like data structure just by 'looking' at the column names, but this is not included in the first approach).

Here is an overview over most of our aux files, sorted by size.

name	delta t [s]	stddev [s]	rows	width [bytes]	size = rows*width [bytes]
BIAS_CONTROL_DAC	0.568	6.419	137359	1676	230213684
BIAS_CONTROL_VOLTAGE	0.568	6.419	137359	1676	230213684
FEEDBACK_CALIBRATED_CURRENTS	1.230	9.689	63269	3372	213343068
FAD_CONTROL_EVENT_DATA	5.386	15.066	7050	23052	162516600
BIAS_CONTROL_CURRENT	0.686	7.046	113823	844	96066612
FTM_CONTROL_DYNAMIC_DATA	1.415	1.239	61082	1086	66335052
FTM_CONTROL_TRIGGER_RATES	1.415	1.239	61082	844	51553208
FAD_CONTROL_STATISTICS1	1.000	0.003	86431	428	36992468
FSC_CONTROL_BIAS_TEMP	16.722	4.993	5168	1304	6739072
FTM_CONTROL_COUNTER	0.647	1.043	133532	36	4807152
FAD_CONTROL_TEMPERATURE	5.392	15.020	7043	654	4606122
FTM_CONTROL_STATIC_DATA	15.309	69.539	5063	752	3807376
DATA_LOGGER_STATS	1.035	0.004	83494	44	3673736
FAD_CONTROL_STATS	1.048	0.006	82476	44	3628944
DRIVE_CONTROL_TRACKING_POSITION	1.068	0.555	33809	76	2569484
DRIVE_CONTROL_POINTING_POSITION	1.054	0.111	81983	28	2295524
FAD_CONTROL_STATUS	1.996	24.535	18960	96	1820160
FAD_CONTROL_RUN_NUMBER	3.992	34.784	9480	180	1706400
FAD_CONTROL_TRIGGER_COUNTER	1.081	6.753	35122	44	1545368
FSC_CONTROL_TEMPERATURE	16.722	4.993	5168	252	1302336
DRIVE_CONTROL_STATUS	1.054	0.111	81983	15	1229745
FAD_CONTROL_REFERENCE_CLOCK	5.392	15.020	7043	174	1225482
FAD_CONTROL_EVENTS	1.094	6.809	34703	28	971684
BIAS_CONTROL_MESSAGE	1.132	10.282	70635	12	847620
FSC_CONTROL_CURRENT	16.722	4.993	5168	136	702848
FSC_CONTROL_VOLTAGE	16.722	4.993	5168	136	702848
BIAS_CONTROL_STATE	1.698	14.192	47076	12	564912
SQM_CONTROL_DATA	5.000	0.001	17286	32	553152
LID_CONTROL_DATA	5.002	0.202	17278	32	552896
FAD_CONTROL_DAC	44.923	442.293	800	684	547200
FAD_CONTROL_CONNECTIONS	3.893	34.286	9722	53	515266
RATE_SCAN_DATA	102.766	956.443	573	836	479028
RATE_SCAN_MESSAGE	1.769	125.806	33225	12	398700
PWR_CONTROL_DATA	5.137	0.399	16826	20	336520
FEEDBACK_MESSAGE	3.339	19.504	23943	12	287316
MAGIC_WEATHER_DATA	19.767	7.996	4372	42	183624
FSC_CONTROL_HUMIDITY	16.722	4.993	5168	32	165376
AGILENT_CONTROL_24V_DATA	15.000	0.033	5762	28	161336
AGILENT_CONTROL_50V_DATA	15.000	0.032	5762	28	161336
AGILENT_CONTROL_80V_DATA	15.000	0.072	5762	28	161336
GPS_CONTROL_NEMA	60.000	0.001	1441	40	57640
MAGIC_WEATHER_MESSAGE	19.748	7.038	4376	12	52512
MCP_CONFIGURATION	22.903	75.766	1659	28	46452
FAD_CONTROL_MESSAGE	11.919	55.860	3187	12	38244
MCP_MESSAGE	12.409	56.926	3061	12	36732
TEMPERATURE_DATA	60.407	4.864	1431	24	34344
FTM_CONTROL_MESSAGE	29.959	538.642	2614	12	31368
FEEDBACK_CALIBRATION_STEPS	7977.991	15955.981	6	5008	30048
MCP_STATE	22.847	75.683	1663	12	19956
TNG_WEATHER_DATA	300.010	0.156	288	68	19584
RATE_CONTROL_MESSAGE	50.982	1019.175	1521	12	18252
TEMPERATURE_MESSAGE	59.288	6.809	1458	12	17496
FAD_CONTROL_STATE	26.647	81.170	1426	12	17112
FTM_CONTROL_STATE	62.956	782.737	1234	12	14808
FEEDBACK_CALIBRATION	39889.953	0.000	2	6668	13336
FAD_CONTROL_START_RUN	84.382	127.959	451	28	12628
DIM_CONTROL_MESSAGE	44.932	111.104	913	12	10956
FAD_CONTROL_RUNS	80.277	124.719	474	20	9480
RATE_CONTROL_STATE	108.382	1483.901	716	12	8592
FSC_CONTROL_MESSAGE	127.224	18.792	680	12	8160
FEEDBACK_CALIBRATION_R8	39889.953	0.000	2	3340	6680
DATA_LOGGER_STATE	88.927	131.025	428	12	5136
DRIVE_CONTROL_SOURCE_POSITION	694.667	722.352	53	91	4823
RATE_CONTROL_THRESHOLD	299.184	165.609	121	30	3630
DRIVE_CONTROL_MESSAGE	381.581	2995.895	221	12	2652
DATA_LOGGER_NUM_SUBS	608.098	3594.266	121	20	2420
TIME_CHECK_MESSAGE	447.689	441.846	192	12	2304
FEEDBACK_STATE	451.599	2810.061	178	12	2136
DATA_LOGGER_FILENAME_NIGHTLY	608.098	3594.266	121	16	1936
FAD_CONTROL_DRS_RUNS	651.135	10020.114	56	32	1792
TIME_CHECK_OFFSET	900.005	0.192	96	16	1536
DRIVE_CONTROL_STATE	307.644	595.365	127	12	1524
MAGIC_LIDAR_DATA	612.450	53.593	21	36	756
FAD_CONTROL_FILE_FORMAT	948.925	1698.665	39	14	546
FAD_CONTROL_REGION_OF_INTEREST	1976.848	1879.630	20	16	320
MAGIC_LIDAR_MESSAGE	612.822	52.446	21	12	252
FAD_CONTROL_INCOMPLETE	0.330	0.919	11	20	220
TEMPERATURE_STATE	2014.740	3929.100	18	12	216
TNG_WEATHER_DUST	7200.273	1.052	12	16	192
RATE_SCAN_STATE	4199.063	7709.202	15	12	180
TNG_WEATHER_MESSAGE	7200.041	0.049	12	12	144
RATE_SCAN_PROCESS_DATA	14632.373	15636.454	5	24	120
DIM_CONTROL_STATE	6773.531	14085.157	7	12	84
EVENT_SERVER_MESSAGE	10905.531	10767.661	5	12	60
LID_CONTROL_MESSAGE	9297.873	15467.975	5	12	60
LID_CONTROL_STATE	12040.861	16997.522	4	12	48
MAGIC_WEATHER_STATE	3122.660	4404.884	4	12	48
EVENT_SERVER_STATE	43622.122	0.000	2	12	24
GCN_MESSAGE	6.311	0.000	2	12	24
GCN_STATE	6.311	0.000	2	12	24
PWR_CONTROL_MESSAGE	40274.024	0.000	2	12	24
PWR_CONTROL_STATE	40274.024	0.000	2	12	24

So if we simply stick to this table deisgn, we can estimate, that for out longest table (the one with the most rows -- 137k per night) we might end with about 0.5 giga lines after 10 years. I think, this is still no problem for an InnoDB table index, so in principle, I don't see a problem in creating one table per file, for the entire lifetime of the experiment.

Table width

Since MySQL tables cannot be wider that 64kb , out widest fits tables might create problems, if we don't take care about column sizes: These are our widest tables:

name	delta t [s]	stddev [s]	rows	width [bytes]	size = rows*width [bytes]
FAD_CONTROL_EVENT_DATA	5.386	15.066	7050	23052	162516600
FEEDBACK_CALIBRATION	39889.953	0.000	2	6668	13336
FEEDBACK_CALIBRATION_STEPS	7977.991	15955.981	6	5008	30048
FEEDBACK_CALIBRATED_CURRENTS	1.230	9.689	63269	3372	213343068
FEEDBACK_CALIBRATION_R8	39889.953	0.000	2	3340	6680
BIAS_CONTROL_DAC	0.568	6.419	137359	1676	230213684
BIAS_CONTROL_VOLTAGE	0.568	6.419	137359	1676	230213684
FSC_CONTROL_BIAS_TEMP	16.722	4.993	5168	1304	6739072
FTM_CONTROL_DYNAMIC_DATA	1.415	1.239	61082	1086	66335052
BIAS_CONTROL_CURRENT	0.686	7.046	113823	844	96066612
FTM_CONTROL_TRIGGER_RATES	1.415	1.239	61082	844	51553208

arrays --> columns, Number of columns

I found on SO that there is a limit on the total number of columns in a table at 3398 columns. Since storage of arrays is not suported natively by MySQL we decided to create a large number of columns fo each array.

This limit is crossed by FAD_CONTROL_EVENT_DATA, which ends up having 5762 columns. So we omit this aux file for the time being.

omitted FITS files

the following slow data files were omitted during table creation:

• 'CLIENT_LIST' # ???
• 'CHAT_MESSAGE' # ???
• 'FAD_CONTROL_START_RUN' # ???
• 'FAD_CONTROL_EVENT_DATA' # too many columns
• 'FEEDBACK_CALIBRATION' # omitted because it generates a strange error, that might be connected to a column name, that is the same as an internal innoDB table name or so... strange
• 'GPS_CONTROL_NEMA', # omitted, because of column name 'Time' and 'time', maybe my mysql installation is case insensitive .. :-| stupid me.

First experiences with slow data insertion

In about 8h I only managed to insert 262MB of data. While neither the python process, that was reading the data, nor the mysqld, that was writing the data comsumed 100% CPU load at any time. Not sure why this is the case? Mybe the stuff was io blocked.

--> python script is 40...500 times faster when not inserting the data into the DB, but just reading... so input side is not io blocked.

apparently one can improve the situation a bit by using bulk inserta, but one must also stay below the maximum paket size

Mongo

without bulk creation. 1day slow data (20130701) = 227MB in 356seconcs into the DB. (roughly 3 CPUs at ~60% maybe) So we write into this DB also with only ~0.6MB/sec, but its worked right away ... no tweaking necessary.

filesize of DB --> 1.0GB So an increase of a factor of ~5 is observed. That means for our 2TB of slow data, we would need already 10TB diskspace.

And loading 2TB, i.e. (2 years of slow data) into the DB would take roughly 5 weeks.