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