On May 20, 2015, at 8:13 AM, Heiko W.Rupp <hrupp(a)redhat.com>
wrote:
On 19 May 2015, at 15:16, John Sanda wrote:
> I agree with Lukas. At lease in RHQ, we treated most things as time
> series because we are interested in changes over time. Metrics is one
> type of time series.
Of course we are interested in changes over time.
That does not imply storing everything as metric, as (to use that
argument too) also did not do in RHQ.
Traits and configuration data got a very separate treatment from
numeric metrics and also need it.
How do you aggregate traits or config objects?
How do you display traits or config objects in charts for gauge data?
I think you misunderstand what I am suggesting. 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 data means persisting a new copy of the data with a new
timestamp. 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.