> Beyond refactoring the way we add in data for response extensions, I think > the right way to get this database performance is make the compute-cells > approach the "normal". In this approach, there are at least two nova > databases, one which lives along with the nova-api nodes, and one that lives > in a compute cell. The api database is kept up to date through asynchronous > updates that bubble up from the compute cells. With this separation, we are > free to tailor the schema of the api database to match api performance > needs, while we tailor the schema of the compute cell database to the > operational requirements of compute workers. In particular, we can > completely denormalize the tables in the api database without creating > unpleasant side effects in the compute manager code. This denormalization > both means fewer database interactions and fewer joins (which likely > matters for larger deployments).
I agree with this paragraph whole heartedly! I would definitely like to see this separation not only for the reasons you list above (performance, all installations behaving the same way) but also because I think it gives us a lot more power to help handle seamless upgrades - another topic I'm sure we will be discussing at the conference. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
