<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 20, 2013 at 3:20 AM, Flavio Percoco <span dir="ltr"><<a href="mailto:flavio@redhat.com" target="_blank">flavio@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 20/08/13 00:15 -0700, Mark Washenberger wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
       2) I highly caution folks who think a No-SQL store is a good storage<br>
       solution for any of the data currently used by Nova, Glance (registry),<br>
       Cinder (registry), Ceilometer, and Quantum. All of the data stored and<br>
       manipulated in those projects is HIGHLY relational data, and not<br>
       objects/documents. Switching to use a KVS for highly relational data is<br>
       a terrible decision. You will just end up implementing joins in your<br>
   FWIW, I'm a huge fan of NoSQL technologies but I couldn't agree more<br>
I have to say I'm kind of baffled by this sentiment (expressed here and<br>
elsewhere in the thread.) I'm not a NoSQL expert, but I hang out with a few and<br>
I'm pretty confident Glance at least is not that relational. We do two types of<br>
joins in glance. The first, like image properties, is basically just an<br>
implementation detail of the sql driver. Its not core to the application. Any<br>
NoSQL implementation will simply completely denormalize those properties into<br>
the image record. (And honestly, so might an optimized SQL implementation. . .)<br>
The second type of join, image_members, is basically just a hack to solve the<br>
problem created because the glance api offers several simultaneous implicit<br>
"views" of images. Specifically, when you list images in glance, you are seeing<br>
a union of three views: public images, images you own, and images shared with<br>
you. IMO its actually a more scalable and sensible solution to make these views<br>
more explicit and independent in the API and code, taking a lesson from<br>
filesystems which have to scale to a lot of metadata (notice how visibility is<br>
generally an attribute of a directory, not of regular files in your typical<br>
Unix FS?). And to solve this problem in SQL now we still have to do a<br>
server-side union, which is a bit sad. But even before we can refactor the API<br>
(v3 anyone?) I don't see it as unworkably slow for a NoSQL driver to track<br>
these kinds of views.<br>
You make really good points here but I don't fully agree.<br></blockquote><div><br></div><div>Thanks for your measured response. I wrote my previous response a bit late at night for me and I hope I wasn't rude :-/ </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't think the issue is actually translating Glance's models to<br>
NoSQL or NoSQL db's performance, I'm pretty sure we could benefit in some<br>
areas but not all of them. To me, and that's what my comment was referring<br>
to, this is more related to  what kind of data we're actually<br>
treating, the guarantees we should provide and how they are<br>
implemented now.<br>
There are a couple of things that would worry me about an hypothetic<br>
support for NoSQL but I guess one that I'd consider very critical is<br>
migrations. Some could argue asking whether we'd really need them or<br>
not  - when talking about NoSQL databases - but we do. Using a<br>
schemaless database wouldn't mean we don't have a schema. Migrations<br>
are not trivial for some NoSQL databases, plus, this would mean<br>
drivers, most probably, would have to have their own implementation.</blockquote><div><br></div><div>I definitely think different drivers will need their own migrations. When I've been playing around with this refactoring, I created a "Migrator" interface and made it part of the driver interface to instantiate an appropriate migrator object. But I was definitely concerned about a number of things here. First off, is it just too confusing to have multiple migrations? The migration sequences will definitely need to be different per driver. How do we support cross-driver migrations?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The bigger concern to me is that Glance seems a bit trigger-happy with indexes.<br>
But I'm confident we're in a similar boat there: performance in NoSQL won't be<br>
that terrible for the most important use cases, and a later refactoring can put<br>
us on a more sustainable track in the long run. <br>
I'm not worried about this, though. <br></blockquote><div><br></div><div>Okay, that is reassuring.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

All I'm saying is that we should be careful not to swap one set of<br>
problems for another.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My 2 cents: I am in agreement with Jay.  I am leery of NoSQL being a<br>
direct sub in and I fear that this effort can be adding a large workload<br>
for little benefit.<br>
The goal isn't really to replace sqlalchemy completely. I'm hoping I can create<br>
a space where multiple drivers can operate efficiently without introducing bugs<br>
(i.e. pull all that business logic out of the driver!) I'll be very interested<br>
to see if people can, after such a refactoring, try out some more storage<br>
approaches, such as dropping the sqlalchemy orm in favor of its generic engine<br>
support or direct sql execution, as well as NoSQL what-have-you. We don't have<br>
to make all of the drivers live in the project, so it really can be a good<br>
place for interested parties to experiment.<br>
And this is exactly what I'm concerned about. There's a lot of<br>
business logic implemented at the driver level right now which makes<br>
it really difficult (impossible?) to even think about using a NoSQL<br>
database. However, I'm not even sure that taking BL to a higher level<br>
would be the "go-time" for new NoSQL drivers. <br>
As mentioned already, this might end up in app-level implementations<br>
that shouldn't be there.<br></blockquote><div><br></div><div>I appreciate this concern. I do think that moving the BL out of the driver is just good because its good, though, as well.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Again, I'm not arguing NoSQL capabilities in this matter - I'm a huge<br>
fan of NoSQL technologies -, what I'd argue is whether they are the<br>
best tool for this task. This is something that should be evaluated in<br>
a per module basis, which I obviously don't have a complete knowledge<br>
of.<br></blockquote><div><br></div><div>I think its possible that some folks just really want the HA and reliability attributes of NoSQL. I feel compelled to support this desire in some form or another. But I don't want to create a mess for the project to do it, so I appreciate your concerns.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cheers,<div class="HOEnZb"><div class="h5"><br>
-- <br>
Flavio Percoco<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>