Open Stack

On 08/16/2013 03:52 PM, Doug Hellmann wrote:
> However, that's just one example use case. Sometimes people do want to
> know something about the resources that have existed besides the
> aggregated samples for billing. The challenge with querying for
> resources is that the metadata for a given resource has the potential to
> change over time. The resource table holds the most current metadata,
> but the meter table has all of the samples and all of the versions of
> the metadata, so we have to look there to filter on metadata that might
> change (especially if we're trying to answer questions about what
> resources had specific characteristics during a time range).

This is wasteful, IMO. We could change the strategy to say that a 
resource is immutable once it is received by Ceilometer. And if the 
"metadata" about that resource changes somehow (an example of this would 
be useful) in the future, then a new resource record with a unique ID 
would be generated and its ID shoved into the meter table instead of 
storing a redundant denormalized data in the meter.resource_metadata 
field, which AFAICT, is a VARCHAR(1000) field.

Anything that can reduce storage space in the base fact table (meter) 
per row will lead to increased performance...

Best,
-jay