cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Persistent vs. Logged Properties

ttielebein
12-Amethyst

Persistent vs. Logged Properties

edc_best_practice_banner.png

Persistent vs. Logged Properties

By Mike Jasperson, VP of IoT EDC

 

Executive Summary

ThingWorx provides several different “aspects” (or storage options) for how property values are saved.  These options each have different implications for performance and scalability.  Understanding those implications is important for designing a scalable IOT solution.

persist_vs_logged.PNG

 

Persistent Properties are best used for non-telemetry data which will change infrequently (for example only a few times in a day) and where historical values are not required.  When overused, Persistent properties can put significant pressure on the database layer of your ThingWorx implementation, leading to poor performance of your IOT application.  As the number of Things in your IOT application scales up, the quantity or frequency of persistent properties per Thing needs to be carefully considered.

 

Logged Properties are best used for telemetry data where historical values need to be retained, but also for any other value that is expected to change frequently.  Logged properties can create some additional requirements: a process for handling null/default values after restarts, more disk space, and a data retention policy. There are benefits as well, though, like more flexibility and scalability for the ingestion of larger volumes of data.

 

Persistent + Logged Properties perform database operations of both aspects.  Combined use should be very limited – only properties that update infrequently (a few times a day), and that must be in-memory in the event of a ThingWorx restart.

 

In-Memory Only Properties are neither persistent nor logged – they are not stored to the database.  These properties can greatly improve scale for values that need to be available for the application to drive UIs or compute other derived values that will be stored.  However, high-frequency updates of in-memory properties can create scale challenges in HA (high availability) ThingWorx configurations where memory state needs to be constantly shared between multiple ThingWorx nodes.

 

 

Find a complete summary as well as example cases in the document attached.

1 REPLY 1
geva
13-Aquamarine
(To:ttielebein)

Really nice article Mike.  This topic has been circulating for me lately as well, so I made a short "demonstration" video talking a little about the common pitfall of persisting all properties to make visible the impacts of such a design choice.

Announcements