This repository has been archived by the owner on Jul 11, 2022. It is now read-only.
BZ1093948 - Metric traits, call times in Cassandra #70
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Traits are stored into two tables, call times one. There is a secondary index
on call name in Cassandra. (Unclear if this is really needed, but required
when doing filtered queries.)
TTL is used for expiry. No more need to purge this data hourly.
Known bugs:
reported, not when it changed. To display properly, need to access history
table, but this might be too many round trips for this piece of data.
Possible issues:
Cassandra does have some support for ranges on hashed fields but would need to build
infrastructure around this. PageControl could hold this hash.
eccentric; they pull extra data in without any clear explanation.
are updated usually every hour to 24 hours. With a small window, there are
few duplicates. The window to look back is about 8 days. Even if a trait
doesn't change, the history table will hae duplicaes.
Questions:
really necessary, although I do like the idea of grouping traits by resource.
this work? This may be unneeded optimization.
to change the TTL. Older data not changed.
TODOs: