For real-time and average trending, how is data stored in the database when the parameter's value does not change for a period of time. It appears that for real-time trended parameters, entries are only added to the dbase table when the value changes, but for average trended points I have seen this same behavior at times but also entries at 5 min intervals at other times. Trying to understand this behavior so I can in turn understand the response from various Webservices API calls.
Thanks
For real time trending it is indeed the case that when a value changes it gets written to the database.
For average trending a point is written to the database when:
- During the window a value change happened (1)
- During the previous window a value change happened (2)
This means that if a value changes at 12:48 the following points will be written to database
- RT: time:12:48
- AVG: time:12:50 (For case (1))
- AVG: time: 12:55 (For case(2))
1)This is only the case for RT, for AVG there will still be points written after the value change. 1 point once the timewindow in which the valuechange happened has passed, and another point once another timewindow without changes has passed. Which means 2 points can be written after a valuechange per timewindow.
2)Yes, as mentioned in case of average there will always be a point written after the value change where minvalue == maxvalue == avgvalue. This will happen for each of the 5 min points and the hourly trendpoint.
Small sidenote things that generate a gap (element restart, value clear, timeout,….) are also considered a valuechange.
3)Correct, there is no difference here between Cassandra and MySQL
4)That depends on the kind of GetTrendData call that is sent. The response will process some of the raw points from the data and might duplicate points in memory to account for gaps,incomplete windows.
The simplest example for 1h of trending where at T=-28min the value changes from 1 to 2.
RT:
T=-60~value=1 (start of the requested timeframe)
T=-28~ValueChange=2 (the value change)
T=0~DuplicatedValueNotFromDB (a duplicated point to note the end of the requested timeframe)
AVG:
T=-60~1|1|1 (start of the requested timeframe)
T=-30~1|1.5|2 (changes in AVG only happen on windowclose
T=-25~2|2|2 (the extra point after the valuechanged window has closed)
T=-10/T=-5~2|2|2 DuplicatedValueNotFromDB (a duplicated point to note the end of the requested timeframe)
As stated before, if element/dma restarts happened or some action that could generate a gap, then you might see extra values in the DB or in the response
Ok, Thanks for the info.
So just to clarify:
1) For both RT and Avg trending, data is only stored in database when values change and if a parameter is enabled for both RT and AVG and its value does not change for 2 hours or 2 weeks the database will not have any entries for this parameter since the last time it changed value?
2) If above is correct, is there any case where an Avg trended parameter that does not change still gets stored in the db every 5 min. I ask because I have seen this before.
3) I would assume this is same for MySQL and Cassandra?
4) In the case where the parameter value has not changed, what should the WebServices API return for all the “GetTrendData….” related calls
Thanks again