> 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
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
