<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><title>Re: [Openstack] Database replacement?</title><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>+1<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> openstack-bounces+dedutta=cisco.com@lists.launchpad.net [mailto:openstack-bounces+dedutta=cisco.com@lists.launchpad.net] <b>On Behalf Of </b>Joshua Harlow<br><b>Sent:</b> Monday, September 26, 2011 11:20 AM<br><b>To:</b> Monty Taylor; Brian Lamar<br><b>Cc:</b> openstack<br><b>Subject:</b> Re: [Openstack] Database replacement?<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>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:</span><o:p></o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><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>></span><o:p></o:p></p></div></body></html>