[openstack-dev] [Nova] Does Nova really need an SQL database?
hartsocks at vmware.com
Mon Nov 18 20:08:34 UTC 2013
+1 on changing the relationship between data persistence and scheduler rules. That's a directly addressable problem.
There was a thread on the ML a while ago dealing with the work load on the scheduler. The problem was that when the scheduler rules fire 55 times a second subsequent rules were interacting with the database at a multiple of the number of nodes in the cloud... such that 55 rule fires a second on a 10k node cloud was something on the order of 550k database interactions.
While I'm interested in working with NoSQL databases, in memory fact-bases, and other interesting ways to deal with larger amounts of data that may not need a relational database... I've got a feeling we need to address this problem more directly rather than trying to optimize a central scheduler. Decentralizing the scheduler could solve the problem permanently, while optimizing a monolithic scheduler just prolongs how long you have before you are forced to address the core problem.
That's just my 2 cents on the topic.
# Shawn Hartsock
----- Original Message -----
> From: "Mike Spreitzer" <mspreitz at us.ibm.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> Sent: Monday, November 18, 2013 2:35:05 PM
> Subject: [openstack-dev] [Nova] Does Nova really need an SQL database?
> There were some concerns expressed at the summit about scheduler
> scalability in Nova, and a little recollection of Boris' proposal to keep
> the needed state in memory. I also heard one guy say that he thinks Nova
> does not really need a general SQL database, that a NOSQL database with a
> bit of denormalization and/or client-maintained secondary indices could
> suffice. Has that sort of thing been considered before? What is the
> community's level of interest in exploring that?
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev