<div dir="ltr">I'm +1 on grooming that ticket and sprint nominating it. I commented on question there about how to handle RQ.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 11, 2018 at 4:53 PM, Dennis Kliban <span dir="ltr"><<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@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 dir="ltr">Thanks David. I am in favor of this  change.<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 11, 2018 at 4:39 PM, David Davis <span dir="ltr"><<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@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 dir="ltr">There is now:<div><br></div><div><a href="https://pulp.plan.io/issues/3848" target="_blank">https://pulp.plan.io/issues/38<wbr>48</a><span class="m_4159354970266600113HOEnZb"><font color="#888888"><br clear="all"><div><div dir="ltr" class="m_4159354970266600113m_-6808776236495353478gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div><br></font></span></div></div><div class="m_4159354970266600113HOEnZb"><div class="m_4159354970266600113h5"><br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 11, 2018 at 4:23 PM Brian Bouterse <<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>A 30% improvement I think is a good case for integers over uuids.</div><div><br></div><div>Is there a ticket tracking that change?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 11, 2018 at 3:55 PM, Daniel Alley <span dir="ltr"><<a href="mailto:dalley@redhat.com" target="_blank">dalley@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 dir="ltr"><div>w/ creating 400,000 units, the non-uuid PK is 30% faster at  42.22 seconds vs. 55.98 seconds.</div><div><br></div><div>w/ searching through the same 400,000 units, performance is still about 30% faster.  Doing a filter for file content units that have a relative_path__startswith={som<wbr>e random letter} (I put UUIDs in all the fields) takes about 0.44 seconds if the model has a UUID pk and about 0.33 seconds if the model has a default Django auto-incrementing PK.</div></div><div class="m_4159354970266600113m_-6808776236495353478m_-8599575293896022535HOEnZb"><div class="m_4159354970266600113m_-6808776236495353478m_-8599575293896022535h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 11, 2018 at 11:03 AM, Daniel Alley <span dir="ltr"><<a href="mailto:dalley@redhat.com" target="_blank">dalley@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 dir="ltr"><div>So, since I've already been working on some Pulp 3 benchmarking I decided to go ahead and benchmark this to get some actual data.</div><div><br></div><div>Disclaimer:  The following data is using bulk_create() with a modified, flat, non-inheriting content model, not the current multi-table inherited content model we're currently using.  It's also using bulk_create() which we are not currently using in Pulp 3, but likely will end up using eventually.<br></div><div><br></div><div>Using normal IDs instead of UUIDs was between 13% and 25% faster with 15,000 units.  15,000 units isn't really a sufficient value to actually test index performance, so I'm rerunning it with a few hundred thousand units, but that will take a substantial amount of time to run.  I'll follow up later.<br></div><div><br></div><div>As far as search/update performance goes, that probably has better margins than just insert performance, but I'll need to write new code to benchmark that properly.<br></div></div><div class="m_4159354970266600113m_-6808776236495353478m_-8599575293896022535m_3491470222955849401HOEnZb"><div class="m_4159354970266600113m_-6808776236495353478m_-8599575293896022535m_3491470222955849401h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 24, 2018 at 11:52 AM, David Davis <span dir="ltr"><<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@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 dir="ltr">Agreed on performance. Doing some more Googling seems to have mixed opinions on whether UUIDs performance is worse or not. If this is a significant reason to switch, I agree we should test out the performance.<br><div><br></div><div>Regarding the disk size, I think using UUIDs is cumulative. Larger PKs mean bigger index sizes, bigger FKs, etc. I agree that it’s probably not a major concern but I wouldn’t say it’s trivial.</div><div class="gmail_extra"><span class="m_4159354970266600113m_-6808776236495353478m_-8599575293896022535m_3491470222955849401m_8458828713642419313HOEnZb"><font color="#888888"><div><div class="m_4159354970266600113m_-6808776236495353478m_-8599575293896022535m_3491470222955849401m_8458828713642419313m_5408261673236411045m_7778541513043329500gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div>
<br></font></span><div class="gmail_quote"><div><div class="m_4159354970266600113m_-6808776236495353478m_-8599575293896022535m_3491470222955849401m_8458828713642419313h5">On Thu, May 24, 2018 at 11:27 AM, Sean Myers <span dir="ltr"><<a href="mailto:sean.myers@redhat.com" target="_blank">sean.myers@redhat.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_4159354970266600113m_-6808776236495353478m_-8599575293896022535m_3491470222955849401m_8458828713642419313h5">Responses inline.<br>
<span><br>
On 05/23/2018 02:26 PM, David Davis wrote:<br>
> Before the release of Pulp 3.0 GA, I think it’s worth just checking in to<br>
> make sure we want to use UUIDs over integer based IDs. Changing from UUIDs<br>
> to ints would be a very easy change at this point  (1-2 lines of code) but<br>
> after GA ships, it would be hard if not impossible to switch.<br>
> <br>
> I think there are a number of reasons why we might want to consider integer<br>
> IDs:<br>
> <br>
> - Better performance all around for inserts[0], searches, indexing, etc<br>
<br>
</span>I don't really care either way, but it's worth pointing out that UUIDs are<br>
integers (in the sense that the entire internet can be reduced to a single<br>
integer since it's all just bits). To the best of my knowledge they are equally<br>
performant to integers and stored in similar ways in Postgres.<br>
<br>
You linked a MySQL experiment, done using a version of MySQL that is nearly 10<br>
years old. If there are concerns about the performance of UUID PKs vs. int PKs<br>
in Pulp, we should compare apples to apples and profile Pulp using UUID PKs,<br>
profile Pulp using integer PKs, and then compare the two.<br>
<br>
In my small-scale testing (100,000 randomly generated content rows of a<br>
proto-RPM content model, 1000 repositories randomly related to each, no db funny<br>
business beyond enforced uniqueness constraints), there was either no<br>
difference, or what difference there was fell into the margin of error.<br>
<span><br>
> - Less storage required (4 bytes for int vs 16 byes for UUIDs)<br>
<br>
</span>Well, okay...UUIDs are *huge* integers. But it's the length of an IPv6 address<br>
vs. the length of an IPv4 address. While it's true that 4 < 16, both are still<br>
pretty small. Trivially so, I think.<br>
<br>
Without taking relations into account, a table with a million rows should be a<br>
little less than twelve mega(mebi)bytes larger. Even at scale, the size<br>
difference is negligible, especially when compared to the size on disk of the<br>
actual content you'd need to be storing that those million rows represent.<br>
<span><br>
> - Hrefs would be shorter (e.g. /pulp/api/v3/repositories/1/)<br>
> - In line with other apps like Katello<br>
<br>
</span>I think these two are definitely worth considering, though.<br>
<span><br>
> There are some downsides to consider though:<br>
> <br>
> - Integer ids expose info like how many records there are<br>
<br>
</span>This was the main intent, if I recall correctly. UUID PKs are not:<br>
- monotonically increasing<br>
- variably sized (string length, not bit length)<br>
<br>
So an objects PK doesn't give you any indication of how many other objects may<br>
be in the same collection, and while the Hrefs are long, for any given resource<br>
they will always be a predictable size.<br>
<br>
The major downside is really that they're a pain in the butt to type out when<br>
compared to int PKs, so if users are in a situation where they do have to type<br>
these things out, I think something has gone wrong.<br>
<br>
If users typing in PKs can't be avoided, UUIDs probably should be avoided. I<br>
recognize that this is effectively a restatement of "Hrefs would be shorter" in<br>
the context of how that impacts the user.<br>
<span><br>
> - Can’t support sharding or multiple dbs (are we ever going to need this?)<br>
<br>
</span>A very good question. To the best of my recollection this was never stated as a<br>
hard requirement; it was only ever mentioned like it is here, as a potential<br>
positive side-effect of UUID keys. If collision-avoidance is not desired, and<br>
will certainly never be desired, then a normal integer field would likely be a<br>
less astonishing[0] user experience, and therefore a better user experience.<br>
<br>
[0]: <a href="https://en.wikipedia.org/wiki/Principle_of_least_astonishment" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/<wbr>Principle_of_least_astonishmen<wbr>t</a><br>
<br>
<br></div></div><span>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></span></blockquote></div><br></div></div>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>
</blockquote></div>
</div></div><br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>