[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?
http://docs.openstack.org/developer/nova/devref/filter_scheduler.html

I did some very old blueprints related to heterogeneous architectures that had similar goals.  
https://blueprints.launchpad.net/nova/+spec/heterogeneous-instance-types


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>
wrote:

> 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