<br><br><div class="gmail_quote">On Wed, Jan 23, 2013 at 4:55 AM, Julien Danjou <span dir="ltr"><<a href="mailto:julien@danjou.info" target="_blank">julien@danjou.info</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 Wed, Jan 23 2013, Lu, Lianhao wrote:<br>
<br>
> Hi guys,<br>
><br>
> 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.<br>

><br>
>   {"key1": [<br>
>           { "key11": 11},<br>
>           { "key12": 12}<br>
>          ],<br>
>    "key2": "v2"<br>
>    "key3": {<br>
>         "key31": 31<br>
>        }<br>
>   }<br>
><br>
> Does the metaquery support complex conditions, like the form of<br>
> metadata["key3"]["key31"] > 30 or { "key11": 11} in metadata["key1"],<br>
> besides the simple form of metadata["key2"]=="v2"?<br>
<br>
</div>Nop. The plan for now is to limit metadata querying to key = value where<br>
value is of a simple type (string, int). I think it's a sane limitation,<br>
and that will allow us to index more efficiently metadata.<br>
<div class="im"><br>
> Besides, supporting the metaquery in sqlalchemy is not easy as that in<br>
> mongodb. The question is where should the query filter operation<br>
> happen? We may do the metadata query filter operation on the<br>
> sqlalchemy client side in python, which is comparably easy to<br>
> implement and easy to be adapted to complex filter conditions, but is<br>
> bad in performance because it needs to get all the records from<br>
> backend DB to do that.<br>
<br>
</div>We discussed this with Nick back then, and IIRC the idea is to add a<br>
metadata table with colums 'meter_id', 'key' and 'value' and to index<br>
those last fields.<br>
If we were using PG I'd suggest to try arrays or PL/v8 to do JSON<br>
filtering, but since we have to support MySQL that's not an option I<br>
guess. D'oh.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> The other way is to do the metadata query filter operation on the<br>
> backend DB side which should have better performance, but I don't know<br>
> how to do that to support complex conditions other than the simple<br>
> form of metadata["key2"]=="v2".<br>
<br>
</div>You got the solution: we don't allow that. :)<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Julien Danjou<br>
/* Free Software hacker & freelance<br>
   <a href="http://julien.danjou.info" target="_blank">http://julien.danjou.info</a> */<br>
</font></span><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br>