How long do GUIDs really need to be?

Re:How long do GUIDs really need to be? by bkirwi on Friday October 31, 2014 @03:16PM (#8540557)

This is absolutely right. I suspect some people do this because Twitter went out of their way to get 64-bit ids[0] -- but Twitter did this in large part because they made the mistake of baking that bit-length into the protocol back when they were tiny, and since they don't control all clients, it's very difficult to change.

For comparison, here's an eager.io URL:

https://eager.io/app/ZYBle8qUhKFJ

And here's an equivalent with UUID in base-64:

https://eager.io/app/b8tRS7h4TJ2Vt43Dp85v2A

It's a rare application for which those differences matter. (NB: I don't know anything about eager.io... it might be important for them!)

[0] https://blog.twitter.com/2010/announcing-snowflake

[ Parent | on HN ]

Re:How long do GUIDs really need to be? by curun1r on Friday October 31, 2014 @04:42PM (#8541014)

There's also impact at the data layer. Larger IDs make indexes get a lot bigger. Also, any article on UUIDs that mentions locality without even mentioning using type-1 UUIDs should be taken with a grain of salt.

We looked at using UUIDs last year for a project in MySQL since we had good use cases for handling ID generation outside of the data tier. We originally prototyped using type-4 UUIDs, but found the locality problem made that a non-starter (updating indexes seemed to get exponentially slower when tables went over 10m rows). But switching to type-1 UUIDs made that problem go away. Still, we eventually chose not to use UUIDs since 128 bits made our indexes too large. At the DB level, we represented them as BINARY(16), but even with the pain that caused, our indexes were still too large.

Perhaps it's just a MySQL thing (I didn't make that choice) but, from our testing, I'd be very wary of using 128-bit IDs and would probably choose something like Snowflake or other centralized ID generation service.

[ Parent | on HN ]

Re:How long do GUIDs really need to be? by ademarre on Friday October 31, 2014 @09:21PM (#8541893)

Sometimes you don't need to index all 16 bytes, and can get by with a prefix index.

[ Parent | on HN ]

Re:How long do GUIDs really need to be? by zackbloom on Friday October 31, 2014 @03:49PM (#8540741)

It becomes a stylistic choice, but I can say we weren't happy with the experience the longer ids gave users. It made most of the url a random hash of characters, not anything significant. The URL is as much a part of the UX as anything else.

[ Parent | on HN ]

Re:How long do GUIDs really need to be? by al2o3cr on Friday October 31, 2014 @04:15PM (#8540881)

"The URL is as much a part of the UX as anything else."

Given what we've seen from the browser vendors lately (hiding bits of the address bar, etc), I'd say there's a lot of momentum to disagree with that statement.

[ Parent | on HN ]

Re:How long do GUIDs really need to be? by xahrepap on Friday October 31, 2014 @10:51PM (#8542040)

I think it depends on who your customer is / what your product is. When I'm developing against an api, I end up writing API calls in my terminal to test things. I prefer cleaner URLs for APIs.

[ Parent | on HN ]

Re:How long do GUIDs really need to be? by lmm on Saturday November 01, 2014 @05:56AM (#8542616)

Is the difference between bkirwi's two examples really significant? The eager.io URL is still a mash of random characters.

(FWIW I like seeing UUIDs in my URLs, because it tells me that the company on the other end has its shit together. That might be a bit programmer-specific though)

[ Parent | on HN ]