<HTML>
<HEAD>
<TITLE>Re: [Openstack] Database replacement?</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>We’ll I think part of it is just having a good abstraction and having the possibility of hooking in nosql engines or sql engines (maybe this isn’t in the end using SQLAlchemy? Or at least not directly)<BR>
It would be nice & neat if this was possible. At least for a company like yahoo, at its scale I can pretty much guarantee a simple centralized DB model wouldn’t work.<BR>
The concept provided in <a href="http://wiki.openstack.org/MultiClusterZones">http://wiki.openstack.org/MultiClusterZones</a> might help, but that isn’t there yet (afaik).<BR>
So this was more of just a thought “exercise” on how or if its possible to abstract out that part.<BR>
<BR>
On 9/25/11 5:15 PM, "Monty Taylor" <<a href="mordred@inaugust.com">mordred@inaugust.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
<BR>
<BR>
On 09/24/2011 10:50 AM, Brian Lamar wrote:<BR>
> Hey Josh,<BR>
><BR>
>>> Has there been any thought on having a nova-db service that<BR>
>>> responds to requests for information from the db (or something<BR>
>>> like a db).<BR>
><BR>
> No plans that I'm aware of, there is a Database-as-a-Service project<BR>
> called 'Red Dwarf' which might fit this bill however. I honestly<BR>
> haven't looked too much into it.<BR>
><BR>
>>> This could be useful for companies that don't necessarily want to<BR>
>>> have a limiting factor being a database. Since when u scale past<BR>
>>> a certain number of compute nodes the database connections<BR>
>>> themselves may become a bottleneck (especially the heartbeat<BR>
>>> mechanism which updates a table every X seconds).<BR>
><BR>
> Not sure what you mean by this. Currently the OpenStack architecture<BR>
> was built to allow hundreds and thousands (maybe?) of compute nodes<BR>
> in the same environment. The keys is to group compute nodes into<BR>
> clusters as outlined here:<BR>
><BR>
> <a href="http://wiki.openstack.org/MultiClusterZones">http://wiki.openstack.org/MultiClusterZones</a><BR>
><BR>
> Long story short the database isn't being shared between all compute<BR>
> clusters, but instead a hierarchy of clusters is formed (something I,<BR>
> in a pinch, would consider akin to a distributed Map/Reduce model of<BR>
> data sharing).<BR>
<BR>
What are the actual scaling concerns? Have you seen scaling problems, or<BR>
are you just concerned that they might be hit? I'm not seeing any<BR>
mention of numbers here that would even come close to exceeding the<BR>
MySQL-scales-that-far-without-breaking-a-sweat range of things... so I'd<BR>
love to try and help address specific problems rather than re-architect<BR>
something before we even know what the problem we're trying to solve are.<BR>
<BR>
> Does something like this help out with your scaling concerns? I do<BR>
> know that personally I'd be interested in a CouchDB/NoSQL alternative<BR>
> to the Nova database layer...but what we have right now seems to<BR>
> conceptual work for scaling out to many hundreds of compute nodes.<BR>
<BR>
Again - to what end? What is it that the current db setup isn't<BR>
providing that CouchDB would do a better job of?<BR>
<BR>
>>> It would be interesting if these types of request could go to the<BR>
>>> message queue instead<BR>
><BR>
> 110% agree. Hopefully this is something we can talk about at the<BR>
> upcoming conference in Boston. :)<BR>
<BR>
I will definitely agree that message queues can be a way of adding<BR>
scalability (async systems are often able to provide for interesting<BR>
parallelism) ... but at the end of the day the unit of work still has to<BR>
get accomplished, and if the request for data to the underlying message<BR>
store is still slow (sql or nosql, whatever) - under extremely high load<BR>
if your disk and/or cpu are saturated on the db infrastructure, async or<BR>
sync is going to make a flips work of difference. So I'm going to be<BR>
really annoying and again ask: to solve what actual problem? Example<BR>
queries and/or any logging/capturing of system information during<BR>
scaling issues would be a great start ... we can take a stab at solving<BR>
any current problems that are there - and as part of solving those<BR>
problems we can of course discuss approaches such as async message<BR>
queues or nosql alternatives.<BR>
<BR>
Monty<BR>
<BR>
><BR>
> -----Original Message----- From: "Joshua Harlow"<BR>
> <<a href="harlowja@yahoo-inc.com">harlowja@yahoo-inc.com</a>> Sent: Friday, September 23, 2011 5:40pm To:<BR>
> "openstack" <<a href="openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>> Subject: [Openstack]<BR>
> Database replacement?<BR>
><BR>
> _______________________________________________ Mailing list:<BR>
> <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a> Post to :<BR>
> <a href="openstack@lists.launchpad.net">openstack@lists.launchpad.net</a> Unsubscribe :<BR>
> <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a> More help :<BR>
> <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a> This email may include<BR>
> confidential information. If you received it in error, please delete<BR>
> it. Howdy all, congrats on the diablo release!<BR>
><BR>
> Has there been any thought on having a nova-db service that responds<BR>
> to requests for information from the db (or something like a db).<BR>
><BR>
> This could be useful for companies that don't necessarily want to<BR>
> have a limiting factor being a database. Since when u scale past a<BR>
> certain number of compute nodes the database connections themselves<BR>
> may become a bottleneck (especially the heartbeat mechanism which<BR>
> updates a table every X seconds). It would be interesting if these<BR>
> types of request could go to the message queue instead and then the<BR>
> db backing could be swapped out with something more scalable (or<BR>
> still use mysql/sqlite...).<BR>
><BR>
> Any thoughts?<BR>
><BR>
> -Josh<BR>
><BR>
><BR>
><BR>
> _______________________________________________ Mailing list:<BR>
> <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a> Post to :<BR>
> <a href="openstack@lists.launchpad.net">openstack@lists.launchpad.net</a> Unsubscribe :<BR>
> <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a> More help :<BR>
> <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><BR>
><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>