On 08/16/2013 04:37 PM, Doug Hellmann wrote:
On Fri, Aug 16, 2013 at 4:15 PM, Jay Pipes <jaypi...@gmail.com
<mailto:jaypi...@gmail.com>> wrote:
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.
To be clear, when I said "resource" I meant something like an instance,
not owned by ceilometer (rather than a row in the resource table).
As Julien pointed out, the existing SQL driver is based on the schema of
the Mongo driver where rather than doing a mapreduce operation every
time we want to find the most current resource data, it is stored
separately. It's quite likely that someone could improve the SQL driver
to not require the resource table at all, as you suggest.\\
Actually, that's the opposite of what I'm suggesting :) I'm suggesting
getting rid of the resource_metadata column in the meter table and using
the resource table in joins...
-jay
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
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
