[Hawkular-dev] Properties store?

[Heiko W.Rupp]

> 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.