Thingworx Study of Thing Persistent & Logged

 

1      Study of Persistent

According to Thingworx help document:

(

Persist— If selected or set to true, each value change is persisted to the database. Persistent property database writes occur asynchronously to avoid deadlocks. While the property value is set immediately, the database write occurs asynchronously at a later point in time.

Updates and restarts do not affect queue processing.

)

The persistent data are stored in Table of property_vtq.

Each time the property value is changed, the related Database record will be Updated.

This Table only has 1 index of “id” & “name”, so Update operation will NOT require change of Index.

 

 

As explained above, value change of persistent property triggers Update of property_vtq Table.

We need to check property feature before we set it.

For normal properties, it’s OK to enable it.

But for frequently changed properties(such as speed, temperature), it’s NOT recommended to enable it, otherwise there will be too many Update operations in Database, which will impact Database performance.

 

2      Study of Logged

According to Thingworx help document:

(

Log— If selected or set to true, the property value is automatically logged to a value stream when the data changes (based on the data change type).

)

And logged data are actually written into Thing’s linked Value Stream.

And for Value Stream:

(

ThingWorx value streams provide time series information about a Thing’s property values.

)

The data of Value Stream are stored in Table of value_stream, with Procedure of upsert_value_stream_entry.

Each time logged value changes, a new record will be Insert into value_stream Table.

The Table has 1 index of most columns, so the Delete operation will also trigger change of Index.

 

 

The Value Stream is configured with a Persistence Provider during creation.

And for Persistence Provider:

(

In ThingWorx, value streams, streams, data tables, blogs, and wikis are data providers. Data providers are databases that store run time data. Run time data is data that is persisted once Things are composed and used by connected devices to store their data (such as temperature, humidity, or position). Model providers are used to store the metadata for the Things. Persistence providers are initially set to have one database for model providers and data providers, but administrators can separate them based on requirements.

)

Thingworx has Model Provider and Data Provider.

Model Provider is used to define models, it always use internal Database which is configured during installation.

Data Provider is used to store data, it can use internal Database, and it can also use external Database as second Data Provider.

 

 

The Logged data are Inserted into value_stream Table.

The logging operation is very different than the other operations from perspective of Database.

In most cases, data are more Read(Select) and Less Write(Insert/Update/Delete).

But for value stream data, there’re more Write(Insert) and less Read(Select).

So it’s much better to setup 2nd Persistence Provider mapped to external Database, and use it to store Value Stream data.

PTC document link:

https://community.ptc.com/t5/IoT-Tips/How-to-set-up-a-second-Persistence-Provider/ta-p/820508 (How to set up a second Persistence Provider - PTC Community)

Any Database supports Thingworx installation can be used to build 2nd Persistence Provider.

Key note is that we must build all Thingworx build-in Database objects before we create new Persitence Provider inside Thingworx.