Open Stack

I'm not sure the problem is that we use a general SQL database. The
problems as I see it are:

-Multi-master in MySQL sucks. Complicated, problematic and not performant.
Also, no great way to do multi-master over higher latency networks.
-MySQL and Postgres require tuning to scale.
-We tend to write queries badly when using SQLA. Ie. lots of code-level
joins and filtering.
-SQLA mapping is pretty slow. See Boris and Alexei's patch to
compute_node_get_all for an example of how this can be worked around[1].
Also comstud's work on the mysql backend[2].
-Thread serialization problem in eventlet, also somewhat addressed by the
mysql backend

Some of these problems are addressed very well by some NOSQL DBs,
specifically the multi-master problems just go away for the most part.
However our general SQL databases provide some nice things like
transactions that would require some more work on our end to do properly.

All that being said, I am very interested in what NOSQL DBs can do for us.

-Mike Wilson

[1] https://review.openstack.org/#/c/43151/
[2] https://blueprints.launchpad.net/nova/+spec/db-mysqldb-impl


On Mon, Nov 18, 2013 at 12:35 PM, Mike Spreitzer <mspreitz at us.ibm.com>wrote:

> 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?
>
> Thanks,
> Mike
> _______________________________________________
> 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/20131118/97134b7e/attachment.html>