For Rapid Betas, we'll need to aggregate data based on build dates and provide "rolling windows" over them (e.g. "builds from the last 7 days") in top crashers and probably also graphs. The same functionality has been requested for esp. Nightly analysis for some time as well, and bug 672606 has been around for a while with a proposed solution.
Current Situation & Proposal Overview from CrashKill
Current topcrash reports and graphs are already providing rolling "last x days" views, but those are based on crash dates.
The proposal is to create a new, additional aggregated data set (matview) based on build days and use the same UI and middleware code with only a switch added to switch between crash-day and build-day oriented views of data.
UI and Middleware
As stated above, the goal is to keep the same UI and middleware code and only add a switch between crash-day and build-day oriented views of data to the topcrasher and graph UIs that is handed down to the middleware which selects the matview to use. No further changes to that code should be necessary.
The meat of the needed work is new, parallel matviews and stored procedures to create those. The new views would be structured to exactly match the crash-day-based ones (so that users can easily switch between them), just that their date column is being derived from build IDs stored in crashes instead of crash days.
The other change is that for betas, reports will not be made for different betas separately, but for all of a version in beta, i.e. instead of separate reports for "16.0b1", "16.0b2", "16.0b3", etc. there would be one category of "16.0 Beta", looking at all builds with a "16.0" version number and a "beta" channel - similar to how reports for Nightly and Aurora channels are done now.
Mostly for performance reasons, a window of crash dates to make it into the aggregation probably might need to be provided, the proposal calls for 7 days starting with the build date.
So, when the matview entries for "16.0 Beta" are generated on 2012-09-13, the value for the 2012-09-12 date is being calculated as the sum of crashes with a "16.0" version number, a "beta" channel and a build ID starting in "20120912", with crash submission/collection timestamps between 2012-09-12 00:00:00 UTC and 2012-09-19 00:00:00 UTC. Due to the crash date window, the values for the 6 days before that need to be regenerated as well. This means that every day, the values for 7 days of data need to be calculated/aggregated.
The same as for topcrashers is true with the daily data used in graphs, it needs a parallel DB structure based on build-day instead of crash-day. In this case, the same technique as for the crash matviews needs to be done for ADUs as well, i.e. summing up the ADUs from multiple collection days for build IDs starting with a certain day string. This data is available in metrics, but the metrics data push needs to be changed to make this available to Socorro, the tables need to be updates to hold it, and stored procedures for ADU matviews need to be updated as well. (There's some math in the bug for explaining why summing up ADUs for multiple days is fine here, for those with doubts on a statistical basis.)
Synergy with Existing Data
Similar data, at least on a highly aggregated basis, might already be available from bug 640238 work, some adjustments are possible to avoid redundancy in that data (e.g. if a 10-day instead of 7-day crash timestamp window might make more sense to fit both report types).