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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
