Think more along the
lines of a version control system. Every piece of data that gets
persisted has a timestamp associated with it. In general, updating
This is exactly what I am thinking of.
Cassandra excels at handling time series data, and again, I am not
just talking about metrics. It excels because of the read/write
patterns that are common with time series. In RHQ we treated most
things as time series as evidence from all of the History entities.
Whether it is a trait or some resource configuration, we do not want
to store just the latest value, but the changes over time.
I fully agree here.
And I am not questioning the use of Cassandra for this at all.
In fact Inventory uses C* behind the scenes as well.
My point is rather that traits and configurations are very similar to
each other,
while trait and numeric metric are less similar.
So the question is still, how and where to deal with that.
If we assume that configuration and traits are just ("arbitrary" long)
strings,
we need
- de-duplication - we only want to save changes, not every value when it
is
the same as the previous version
- making sure when expiring after some time, that there is always
something
left to look at (the value that was first recorded may have never
changed since)
- probably make sure we record (from time to time) the last time the
value was seen
"Consumers" on top can then decide that the contents is actually a json-
structure, and translate it to json and a Map to deal with it.
While my gut feeling is that configuration data is "closer" to a
resource, than
traits, I think at the end both are just one URI away. We could have
another
component to store those, but having a "string store" inside the metrics
project
that satisfies the above requirements (and probably more), is probably
enough.