Reasoning behind switching from UUID v4 to UUID v1?
voxpelli opened this issue · 3 comments
In the move from node-uuid to uuid there was also the move from v4 to v1 UUID:s – what was the reasoning behind this? Doesn't uuid support v4 very well? To me v4 seems generally preferable to v1.
A quick googling shows others prefering v4 over v1 as well, like http://stackoverflow.com/a/20342413/20667 and also Wikipedia mentioning critique against v1: https://en.wikipedia.org/wiki/Universally_unique_identifier#Version_1_.28date-time_and_MAC_address.29
To make them more sequential which is better for storage and indexing.
The Stackoverflow post you linked to has a link to an article for optimizing the UUID storage in MySQL.
Elasticsearch documentation also recommends UUID v1 and reference an article which tests different id schemes for Lucene.
CouchDB has a note in their documentation under uuid algorithm which also recommends sequential uuids.
I'll also will add these links:
- http://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html#function_uuid-to-bin
- https://www.codeproject.com/articles/388157/guids-as-fast-primary-keys-under-multiple-database
- http://mysql.rjweb.org/doc.php/uuid
And about the critic on Wikipedia.
- I don't see it as a problem that it includes identity information. You are probably logging this anyway.
- The
nodefield is in the uuid npm lib is generated on startup. That does happen fairly rare, so it is unlikely to collide, but maybe I should expose that field as an option so it can be configured? - The last critic is about to a to fast processor. The uuid lib uses an incremental counter that fixes that.
My conclusion is that v1 has arguments for it while v4 does not have any.
Do you have any arguments for v4?
Thanks for explaining the reason of the switch, makes sense.
I've commonly opted for v4 as they are totally random, but in the case of eg. request id:s it do sound like v1 is the preferable one.
Closing this as I just wanted to hear more about the reasoning than was in the commit message and I'm happy with the reasoning you've given! (A suggestion would be to put some kind of reasoning like this into a self-created issue and/or into a changelog for future changes like this so people can more easily understand your reasoning and not draw the wrong conclusions as is so easy to do otherwise)
Added a change log :)