Open Stack

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...

-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>
>     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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>