Open Stack

> 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.