Maximum size of device managed object

,
1

What product/components do you use and which version/fix level are you on?

Cumulocity IoT 10.13

When considering different data structures for custom use cases, there is always a question how much data should I store in the device managed objects. What is the maximum size of it? When does it make sense to actually split a “big” device mo into multiple mo’s?

2

Hi Nick,

Cumulocity IoT is bound to the limit of MongoDB which is max. 16 MB: https://www.mongodb.com/docs/manual/reference/limits/#mongodb-limit-BSON-Document-Size

Even if 16 MBs are possible you shouldn’t make a managed object that big, especially when it is retrieved by many standard APIs like device MOs or assets MOs etc.
Otherwise you will drastically slow down the whole response time as the whole managed object is loaded each time you do a query.

It might be better to outsource huge data in another MO and add a correlation/reference so the “standard” API queries are not affected when only the “slim” device (parent) is retrieved.

Also from the data retention perspective it is risky to bloat the managed object with data as it is never deleted when not triggered manually which increases the data storage costs. If the data is considered to be long-term data store it in a MO and update it (if possible), if it should be deleted after some time use events.

1 Like
3

Please also keep in mind that huge managed objects can have downsides if you use Cumulocity IoT DataHub, especially if those object additionally also get regularly changed.

1 Like
4

Also consider that putting lots of data in (big) documents might limit you in:

  • usage of pagination concepts, e.g. for presentation in a UI
  • options for backend filtering, e.g. in the Inventory API
1 Like
5

I’d caution against putting bulk data like this in any managed objects. Beyond the answer about DataHub, you have:

  • Some UIs that browse device lists could get unexpectedly slower or cause more load on the system when you stumble across these objects
  • If you are using Streaming Analytics, you could get performance problems when objects like this are updated; on an update, the platform will send the entire object contents (not just deltas) to streaming analytics.

For bulk data associated with devices, I’d suggest exploring the binaries API, in which arbitrarily large files can be stored associated with a device. You’ll only ever be shown the contents on an explicit API request, so you won’t get any of these performance risks; the platform won’t serialize it to send to Streaming Analytics; no query API will return you the contents.

6

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.