[openstack-dev] [Nova] New DB column or new DB table?

Brian Schott brian.schott at nimbisservices.com
Thu Jul 18 03:28:49 UTC 2013

How is this different than extra_specs used by the filter scheduler?

I did some very old blueprints related to heterogeneous architectures that had similar goals.  

Fully support the idea, but probably can adapt the existing functionality to also target metric data.
Sent from Mailbox for iPad

On Wed, Jul 17, 2013 at 10:56 PM, Lu, Lianhao <lianhao.lu at intel.com>

> Hi fellows,
> Currently we're implementing the BP https://blueprints.launchpad.net/nova/+spec/utilization-aware-scheduling. The main idea is to have an extensible plugin framework on nova-compute where every plugin can get different metrics(e.g. CPU utilization, memory cache utilization, network bandwidth, etc.) to store into the DB, and the nova-scheduler will use that data from DB for scheduling decision.
> Currently we adds a new table to store all the metric data and have nova-scheduler join loads the new table with the compute_nodes table to get all the data(https://review.openstack.org/35759). Someone is concerning about the performance penalty of the join load operation when there are many metrics data stored in the DB for every single compute node. Don suggested adding a new column in the current compute_nodes table in DB, and put all metric data into a dictionary key/value format and store the json encoded string of the dictionary into that new column in DB. 
> I'm just wondering which way has less performance impact, join load with a new table with quite a lot of rows, or json encode/decode a dictionary with a lot of key/value pairs?
> Thanks,
> -Lianhao
> _______________________________________________
> 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/20130717/ee57979c/attachment.html>

More information about the OpenStack-dev mailing list