Open Stack

On Wed, Jan 23, 2013 at 4:55 AM, Julien Danjou <julien at danjou.info> wrote:

> On Wed, Jan 23 2013, Lu, Lianhao wrote:
>
> > Hi guys,
> >
> > If my understanding is correct, the current resource_metadata stored by
> the ceilometer collector could be any python object which can be serialized
> to the JSON format, so the resource_metadata could be a dict containing
> values of dict/list/string, e.g.
> >
> >   {"key1": [
> >           { "key11": 11},
> >           { "key12": 12}
> >          ],
> >    "key2": "v2"
> >    "key3": {
> >         "key31": 31
> >        }
> >   }
> >
> > Does the metaquery support complex conditions, like the form of
> > metadata["key3"]["key31"] > 30 or { "key11": 11} in metadata["key1"],
> > besides the simple form of metadata["key2"]=="v2"?
>
> Nop. The plan for now is to limit metadata querying to key = value where
> value is of a simple type (string, int). I think it's a sane limitation,
> and that will allow us to index more efficiently metadata.
>
> > Besides, supporting the metaquery in sqlalchemy is not easy as that in
> > mongodb. The question is where should the query filter operation
> > happen? We may do the metadata query filter operation on the
> > sqlalchemy client side in python, which is comparably easy to
> > implement and easy to be adapted to complex filter conditions, but is
> > bad in performance because it needs to get all the records from
> > backend DB to do that.
>
> We discussed this with Nick back then, and IIRC the idea is to add a
> metadata table with colums 'meter_id', 'key' and 'value' and to index
> those last fields.
> If we were using PG I'd suggest to try arrays or PL/v8 to do JSON
> filtering, but since we have to support MySQL that's not an option I
> guess. D'oh.
>

Right. We will need to create the new table, populate it from any existing
data with a migration, and update the code that stores new events to also
update the new table.


>
> > The other way is to do the metadata query filter operation on the
> > backend DB side which should have better performance, but I don't know
> > how to do that to support complex conditions other than the simple
> > form of metadata["key2"]=="v2".
>
> You got the solution: we don't allow that. :)
>
> --
> Julien Danjou
> /* Free Software hacker & freelance
>    http://julien.danjou.info */
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20130124/6082adcc/attachment.html>