On Fri, Aug 16, 2013 at 4:43 PM, Jay Pipes <jaypi...@gmail.com> wrote:
> 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... > Ah, I see. That would be another good approach. Doug > > -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<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>< >> 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 <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 <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