RHQ trait storage

Elias Ross genman at noderunner.net
Mon May 5 15:53:56 UTC 2014


Hi, I contributed a patch for storing traits and call times in Cassandra.

https://bugzilla.redhat.com/show_bug.cgi?id=1093948

I went with an insert-only approach for data. Schema, expiration, data
migration, etc. is all included in the patch.

The biggest thing missing (for queries) is dealing with custom sorting
and paging, because that's something Cassandra doesn't do, and plus I
know it is a general problem that needs discussion.

Probably the easiest thing to do is to simply get all results, then
slice them each time. The harder thing to do would be to cache them in
memory between queries, but I'm not sure how the caching might expire
(TTL?) or be specific to a particular client (request token?). In
general, the more paged queries done with Cassandra, the more
necessary a complete solution is.

The other point of discussion I'd like to raise is calculating when a
trait changed. My suggestions:
1) Don't display this information in the UI, except in the history view.
2) If you want to display it, create a method that queries the table,
cleans up the duplicate inserts (history) for that schedule, then
calculates the correct value. (The point of cleanup is so that
subsequent queries are faster.)

Cassandra 2.0 would be awesome as it allows paged queries, so you
wouldn't have to pull the entire history for a schedule to do 2).

The table for storing traits per agent didn't really make sense, as
the alerting cache only needs to watch a subset of traits, typically
one or two per agent. So in practice you'd only save one or two
queries (at most) over a query by schedule, versus keeping a table
that's updated constantly.


More information about the rhq-devel mailing list