<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 16, 2013 at 4:43 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 04:37 PM, Doug Hellmann wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Fri, Aug 16, 2013 at 4:15 PM, Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a><br></div><div><div class="h5">
<mailto:<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>>> wrote:<br>
<br>
On 08/16/2013 03:52 PM, Doug Hellmann wrote:<br>
<br>
However, that's just one example use case. Sometimes people do<br>
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<br>
potential to<br>
change over time. The resource table holds the most current<br>
metadata,<br>
but the meter table has all of the samples and all of the<br>
versions of<br>
the metadata, so we have to look there to filter on metadata<br>
that might<br>
change (especially if we're trying to answer questions about what<br>
resources had specific characteristics during a time range).<br>
<br>
<br>
This is wasteful, IMO. We could change the strategy to say that a<br>
resource is immutable once it is received by Ceilometer. And if the<br>
"metadata" about that resource changes somehow (an example of this<br>
would be useful) in the future, then a new resource record with a<br>
unique ID would be generated and its ID shoved into the meter table<br>
instead of storing a redundant denormalized data in the<br>
meter.resource_metadata field, which AFAICT, is a VARCHAR(1000) field.<br>
<br>
<br>
To be clear, when I said "resource" I meant something like an instance,<br>
not owned by ceilometer (rather than a row in the resource table).<br>
<br>
As Julien pointed out, the existing SQL driver is based on the schema of<br>
the Mongo driver where rather than doing a mapreduce operation every<br>
time we want to find the most current resource data, it is stored<br>
separately. It's quite likely that someone could improve the SQL driver<br></div></div>
to not require the resource table at all, as you suggest.\\<br>
</blockquote>
<br>
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...<br></blockquote><div><br></div><div>
Ah, I see. That would be another good approach.</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>
-jay<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Anything that can reduce storage space in the base fact table<br>
(meter) per row will lead to increased performance...<br>
<br>
Best,<br>
-jay<br>
<br>
<br>
<br></div>
______________________________<u></u>___________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.<u></u>__org<br>
<mailto:<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.<u></u>openstack.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> <<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>><div class="im">
<br>
<br>
<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>
<br>
</div></blockquote><div class="HOEnZb"><div class="h5">
<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>