Open Stack

> In the past I've taken a different approach to problematic one to 
> many relationships and have made the metadata a binary JSON blob. Is
> there some reason that won't work?

We have done that for various pieces of data that were previously in
system_metadata. Where this breaks down is if you need to be able to
select instances based on keys in the metadata blob, which we do in
various scheduling operations (certainly for aggregate metadata, at
least). I *believe* we have to leave metadata as row-based for that
reason (although honestly I don't remember the details), and probably
system_metadata as well, but I'd have to survey what is left in there.

> Since the metadata is nearly always queried as a whole, this seems
> like a valid approach that would keep DB traffic low but also ease
> the burden of reassembling the collection in nova-api.

'Nearly' being the key word there. We just got done moving all of the
flavor information we used to stash in system_metadata to a JSON blob in
the database. That cuts 10-30 rows of system_metadata for each instance,
depending on the state, and gives us a thing we can selectively join
with instance for a single load with little overhead. We might be able
to get away with going back to fully joining system_metadata given the
reduction in size, but we honestly don't even need to query it as often
after the flavor-ectomy, so I'm not sure it's worth it. Further, after
the explosion of system_metadata which caused us to stop joining it in
the first place, it was realized that a user could generate a lot of
traffic by exhausting their quota of metadata items (which they
control), so we probably want to join user metadata in python anyway for
that reason.

So I guess the summary is: I think with flavor data out of the path, the
major offender is gone, such that this becomes extremely low on the
priority list.

--Dan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150812/a446e69b/attachment.pgp>