[rodionos]

Not specific to GraphEngine, but you could store all meta-data about the device separate from the time-series itself. The composite metric name (key?) would then include the measurement name and the entity name (device name in this case).

[crudbug]

That is one possible solution. But, for queries we will need some kind of JOIN at runtime.

I do store the entity data separately in a transactional row store.

For analytical queries, we use a column store. For this, I have to include the entity data (context) for each fired event.

The whole Compute & Storage semantics are different.

If only, we had a persistent data-aware compute & storage graph engine that supported transactional & analytical workloads.

[rodionos]

Storing time-series in a columnar format (blobs o time-values) and entity data in row format sounds good to me.

If you look at data historians (PI et al), that's how they lay out the data: metrics storage is separate from the asset store, or Asset Framework as it's called.