<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 16, 2013 at 4:15 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 08/16/2013 03:52 PM, Doug Hellmann wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
However, that's just one example use case. Sometimes people do want to<br>
know something about the resources that have existed besides the<br>
aggregated samples for billing. The challenge with querying for<br>
resources is that the metadata for a given resource has the potential to<br>
change over time. The resource table holds the most current metadata,<br>
but the meter table has all of the samples and all of the versions of<br>
the metadata, so we have to look there to filter on metadata that might<br>
change (especially if we're trying to answer questions about what<br>
resources had specific characteristics during a time range).<br>
</blockquote>
<br></div>
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.<br>
</blockquote><div><br></div><div>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).</div><div><br></div><div>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.</div>
<div><br></div><div>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Anything that can reduce storage space in the base fact table (meter) per row will lead to increased performance...<br>
<br>
Best,<br>
-jay<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>