When using the volatile option on a protocol table, the documentation mentions that the primary keys will not be saved.
https://docs.dataminer.services/develop/schemadoc/Protocol/Protocol.Params.Param.ArrayOptions-options.html#volatile
Does this mean the volatile option will only prevent data being stored for the particular table in the elementdata table? Or are there other tables impacted when using the volatile option?
Hi Brecht,
By default, the Primary key column, the display key column (which could be multiple columns) will be saved to the elementdata table in Cassandra. The reason why these columns are saved by default, is to ensure the alarms have the proper (display) keys linked to them. Imagine the bitrate (alarmed) is filled before the service name (display key), then it could be an alarm is generated with an incorrect display key (empty name).
When you restart an element you will see already rows in the tables that where in there before the restart, where the primary key and display column are already filled before the connector had time to fill that particular table (other columns will have not initialized). When using the volatile option on a table those keys will not be saved on that particular table. You can choose this for every table.
Saved parameters that change continuously have a large impact on the Cassandra DB, this is why you should always think before saving a value or making it part of the primary or display key. If your table has rows that are continuously being added and removed, then that table is ideally volatile as it will otherwise have a big impact on your DB.
So the sum up… The only table impacted when using volatile options is the elementdata table?
And as stated by Laurens, some other data (like alarms) might be indirectly impacted because the data wasn’t stored.
Small item to add to that one: if the table is volatile and there is an alarm on a parameter then, when the element restarts, the table will be initially be empty and the open alarm will be closed. When the table fills up with data again it will raise a new alarm, and previous info like who executed “take ownership” will be lost because it’s a new alarm and new notifications might be sent out. Hence why it is not advised to have alarming on volatile tables.