Open Stack

On Fri, Aug 16, 2013 at 4:43 PM, Jay Pipes <jaypipes at gmail.com> wrote:

> On 08/16/2013 04:37 PM, Doug Hellmann wrote:
>
>> On Fri, Aug 16, 2013 at 4:15 PM, Jay Pipes <jaypipes at gmail.com
>> <mailto:jaypipes at 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 at lists.openstack.**__org
>>     <mailto:OpenStack-dev at lists.**openstack.org<OpenStack-dev at 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 at lists.openstack.**org <OpenStack-dev at 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 at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130816/b9ace657/attachment.html>