<div>Good point that pagination makes this harder.  However, thankfully the limit is implemented using a token (the last ID seen), not an absolute offset, so I believe we can still do pagination even in loosely coordinated DBs.  Good job whoever dodged that bullet (Jorge?)</div>
<div><br></div><div>(Aside #1: Sorting by uptime time - now _that's_ expensive, and has to be done for every page.)</div><div>(Aside #2: What is the point of pagination really?  I mean how many API users that are getting a list actually stop before fetching them all?)</div>
<div><br></div><div>Justin</div><div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">On Wed, Mar 16, 2011 at 9:23 AM, Paul Voccio <span dir="ltr"><<a href="mailto:paul.voccio@rackspace.com">paul.voccio@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">



<div style="word-wrap:break-word;color:rgb(0, 0, 0);font-size:14px;font-family:Calibri, sans-serif">
<div>Sandy,</div>
<div><br>
</div>
<div>Not only is this expensive, but there is no way I can see at the moment to do pagination, which is what makes this really expensive. If someone asked for an entire list of all their instances and it was > 10,000 then I would think they're ok with waiting
 while that response is gathered and returned. However, since the API spec says we should be able to do pagination, this is where asking each zone for all its children every time gets untenable. </div>
<div><br>
</div>
<div>Looking forward to the discussion. More below. </div>
<div><br>
</div>
<span>
<div style="font-family:Calibri;font-size:11pt;text-align:left;color:black;border-bottom:medium none;border-left:medium none;padding-bottom:0in;padding-left:0in;padding-right:0in;border-top:#b5c4df 1pt solid;border-right:medium none;padding-top:3pt">

<span style="font-weight:bold">From: </span>Sandy Walsh <<a href="mailto:sandy.walsh@rackspace.com" target="_blank">sandy.walsh@rackspace.com</a>><br>
<span style="font-weight:bold">Date: </span>Wed, 16 Mar 2011 14:53:37 +0000<br>
<span style="font-weight:bold">To: </span>"<a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a>" <<a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a>><br>

<span style="font-weight:bold">Subject: </span>[Openstack] A single cross-zone database?<br>
</div><div class="im">
<div><br>
</div>
<blockquote style="border-left:#b5c4df 5 solid;padding:0 0 0 5;margin:0 0 0 5">
<div dir="ltr">
<div>
<div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">Hi y'all, getting any sleep before Feature Freeze?
<div><br>
</div>
<div>As you know, one of the main design tenants of OpenStack is Share Nothing (where possible). <a href="http://wiki.openstack.org/BasicDesignTenets" target="_blank">http://wiki.openstack.org/BasicDesignTenets</a></div>

<div><br>
</div>
<div>That's the mantra we've been chanting with Zones. But it does cause a problem with a particular Use Case:</div>
<div><br>
</div>
<div><i>"Show me all Customer X Instances, across all Zones."</i></div>
<div><br>
</div>
<div>This is an expensive request. We have to poll all zones and ask them to return a list of matching instances.</div>
<div><br>
</div>
<div>There has been some water cooler chat about some things we could do to make this more efficient in the near term. One proposal has been to assume a single database, replicated across zones. I'll call it SDB for short. With SDB we can have a join table
 that links Zone to Instance ... keeping a record of all instances across zones. Maybe it's a completely separate set of tables? Maybe it's a separate replicated db? The intention is to let us talk to the appropriate zone directly. </div>

<div><br>
</div>
<div>Sure, there are a ton more optimizations we could make if we go further with SDB. We could store all the Zone capabilities in the db to make Zone selection faster. We could store all the customers in the db to make multi-tenant easier. But that's not what
 we're talking about here. We're talking about the<i> bare minimum </i>required to make the get_instances query fast. </div>
<div><br>
</div>
<div>Conversely, there are issues with a single DB. The largest being the implication it has on Bursting (Hybrid Private/Public clouds) ... a pretty funky feature imho. </div>
</div>
</div>
</div>
</blockquote>
</div></span><div class="im">
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<span>
<blockquote style="border-left:#b5c4df 5 solid;padding:0 0 0 5;margin:0 0 0 5">
<div dir="ltr">
<div>
<div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">
<div><br>
</div>
<div>Personally, I think the same query gains can be obtained by creating a separate db using off-the-shelf ETL tools to create cache/read-only db's. <a href="http://en.wikipedia.org/wiki/Extract,_transform,_load" target="_blank">http://en.wikipedia.org/wiki/Extract,_transform,_load</a></div>

</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
</div><div>Isn't the hard part keeping this in sync with what the zones have? </div>
<div><br>
</div>
<span>
<blockquote style="border-left:#b5c4df 5 solid;padding:0 0 0 5;margin:0 0 0 5"><div class="im">
<div dir="ltr">
<div>
<div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">
<div><br>
</div>
<div>I was considering SDB for Zones (phase 4), but for now, I'm going to stick with the original plan of separate databases (1 per zone) and see what the performance implications are. </div>
<div><br>
</div>
<div>What are your thoughts on this issue?</div>
<div><br>
</div>
<div>... let the games begin!</div>
<div><br>
</div>
<div>-S</div>
<div><br>
</div>
<div><br>
</div>
</div>

<pre>Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at <a href="mailto:abuse@rackspace.com" target="_blank">abuse@rackspace.com</a>, and delete the original message.
Your cooperation is appreciated.
</pre>
</div>
</div></div>
_______________________________________________ Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">
https://launchpad.net/~openstack</a> Post to : <a href="mailto:openstack@lists.launchpad.net" target="_blank">
openstack@lists.launchpad.net</a> Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">
https://launchpad.net/~openstack</a> More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">
https://help.launchpad.net/ListHelp</a> </blockquote>
</span>
</div>

<br>_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br></blockquote></div><br></div>