知识问答

什么时候应该在python中使用uuid.uuid1（）和uuid.uuid4（）？

内容 隐藏
问题：什么时候应该在python中使用uuid.uuid1（）和uuid.uuid4（）？
回答 0
回答 1
回答 2
回答 3
回答 4
回答 5
带有随机MAC的v1（“ v1mc”）
v1 with random MAC (“v1mc”)

问题：什么时候应该在python中使用uuid.uuid1（）和uuid.uuid4（）？

我从文档中了解了两者之间的区别。

uuid1()：
根据主机ID，序列号和当前时间生成UUID

uuid4()：
生成随机UUID。

因此，uuid1使用机器/序列/时间信息来生成UUID。使用每种方法的利弊是什么？

我知道uuid1()可能会涉及到隐私问题，因为它基于机器信息。我想知道在选择一个或另一个时是否还有其他细微之处。我uuid4()现在就使用，因为它是完全随机的UUID。但是我想知道我是否应该使用它uuid1来减少碰撞的风险。

基本上，我正在寻找人们使用某一种方法与另一种方法的最佳使用技巧。谢谢！

点击查看英文原文

I understand the differences between the two from the docs.

uuid1():
Generate a UUID from a host ID, sequence number, and the current time

uuid4():
Generate a random UUID.

So uuid1 uses machine/sequence/time info to generate a UUID. What are the pros and cons of using each?

I know uuid1() can have privacy concerns, since it’s based off of machine-information. I wonder if there’s any more subtle when choosing one or the other. I just use uuid4() right now, since it’s a completely random UUID. But I wonder if I should be using uuid1 to lessen the risk of collisions.

Basically, I’m looking for people’s tips for best-practices on using one vs. the other. Thanks!

回答 0

uuid1()确保不会产生任何碰撞（假设您不会同时创建太多碰撞）。如果uuid计算机与计算机之间没有连接很重要，那么我就不会使用它，因为mac地址已被用来使它在计算机之间具有唯一性。

您可以通过在不到100ns 的时间内创建2 个以上的14 uuid1 来创建重复项，但这对于大多数用例而言都不是问题。

uuid4()如您所说，生成一个随机的UUID。碰撞的机会确实很小。足够小，您不必担心。问题在于，不良的随机数生成器使其更有可能发生冲突。

鲍勃·阿曼的出色回答很好地总结了这一点。（我建议阅读整个答案。）

坦白说，在没有恶意行为者的单个应用程序空间中，即使在每秒生成大量UUID的情况下，即使在版本4 UUID发生碰撞之前，地球上所有生命的消亡也会发生很久。

点击查看英文原文

uuid1() is guaranteed to not produce any collisions (under the assumption you do not create too many of them at the same time). I wouldn’t use it if it’s important that there’s no connection between the uuid and the computer, as the mac address gets used to make it unique across computers.

You can create duplicates by creating more than 214 uuid1 in less than 100ns, but this is not a problem for most use cases.

uuid4() generates, as you said, a random UUID. The chance of a collision is really, really, really small. Small enough, that you shouldn’t worry about it. The problem is, that a bad random-number generator makes it more likely to have collisions.

This excellent answer by Bob Aman sums it up nicely. (I recommend reading the whole answer.)

Frankly, in a single application space without malicious actors, the extinction of all life on earth will occur long before you have a collision, even on a version 4 UUID, even if you’re generating quite a few UUIDs per second.

回答 1

当你可以考虑一个实例uuid1()，而不是uuid4()为当UUID的是在不同的机器生产的，例如，当多个网上交易是在几台机器换算目的的过程。

在这种情况下，例如，由于初始化伪随机数生成器的方式选择不当而导致发生冲突的风险，以及产生的潜在数量更多的UUID使得创建重复ID的可能性更大。

uuid1()在这种情况下，的另一个兴趣是，最初生成每个GUID的机器都被隐式记录（在UUID的“节点”部分中）。仅在调试时，此信息和时间信息可能会有所帮助。

点击查看英文原文

One instance when you may consider uuid1() rather than uuid4() is when UUIDs are produced on separate machines, for example when multiple online transactions are process on several machines for scaling purposes.

In such a situation, the risks of having collisions due to poor choices in the way the pseudo-random number generators are initialized, for example, and also the potentially higher numbers of UUIDs produced render more likely the possibility of creating duplicate IDs.

Another interest of uuid1(), in that case is that the machine where each GUID was initially produced is implicitly recorded (in the “node” part of UUID). This and the time info, may help if only with debugging.

回答 2

我的团队在使用UUID1进行数据库升级脚本时遇到了麻烦，我们在几分钟内生成了约12万个UUID。UUID冲突导致违反主键约束。

我们已经升级了100台服务器，但是在我们的Amazon EC2实例上，我们几次遇到了这个问题。我怀疑时钟分辨率不佳，切换到UUID4可以为我们解决。

点击查看英文原文

My team just ran into trouble using UUID1 for a database upgrade script where we generated ~120k UUIDs within a couple of minutes. The UUID collision led to violation of a primary key constraint.

We’ve upgraded 100s of servers but on our Amazon EC2 instances we ran into this issue a few times. I suspect poor clock resolution and switching to UUID4 solved it for us.

回答 3

使用时要注意的一件事uuid1，如果使用默认调用（不提供clock_seq参数），则有可能发生冲突：您只有14位的随机性（在100ns内生成18个条目会给您大约1％的冲突机会，请参见生日悖论/攻击）。在大多数情况下，该问题永远不会发生，但是在时钟分辨率较差的虚拟机上，它会咬你。

点击查看英文原文

One thing to note when using uuid1, if you use the default call (without giving clock_seq parameter) you have a chance of running into collisions: you have only 14 bit of randomness (generating 18 entries within 100ns gives you roughly 1% chance of a collision see birthday paradox/attack). The problem will never occur in most use cases, but on a virtual machine with poor clock resolution it will bite you.

回答 4

也许没有提到的是本地性。

MAC地址或基于时间的排序（UUID1）可以提高数据库性能，因为与随机分布的数字（UUID4）相比，将数字更紧密地排序在一起的工作量更少（请参见此处）。

第二个相关问题是，即使原始数据丢失或未显式存储，使用UUID1仍可用于调试（这显然与OP提到的隐私问题相冲突）。

点击查看英文原文

Perhaps something that’s not been mentioned is that of locality.

A MAC address or time-based ordering (UUID1) can afford increased database performance, since it’s less work to sort numbers closer-together than those distributed randomly (UUID4) (see here).

A second related issue, is that using UUID1 can be useful in debugging, even if origin data is lost or not explicitly stored (this is obviously in conflict with the privacy issue mentioned by the OP).

回答 5

除了可接受的答案外，还有在某些情况下有用的第三种选择：

带有随机MAC的v1（“ v1mc”）

通过故意生成带有随机广播MAC地址的v1 UUID（v1规范允许），可以在v1和v4之间进行混合。生成的v1 UUID与时间有关（类似于常规v1），但是缺少所有主机特定的信息（如v4）。它的抗冲突性也更接近于v4：v1mc = 60位时间+ 61个随机位= 121个唯一位；v4 = 122个随机位。

我遇到的第一个地方是Postgres的uuid_generate_v1mc（）函数。此后，我使用了以下等效的python：

from os import urandom
from uuid import uuid1
_int_from_bytes = int.from_bytes  # py3 only

def uuid1mc():
    # NOTE: The constant here is required by the UUIDv1 spec...
    return uuid1(_int_from_bytes(urandom(6), "big") | 0x010000000000)

（注意：我有一个更长，更快的版本，可以直接创建UUID对象；如果有人愿意，可以发布）

如果每秒的呼叫量很大，则有可能耗尽系统的随机性。您可以改用stdlib random模块（它可能也会更快）。但请注意：攻击者只需几百个UUID即可确定RNG状态，从而部分预测未来的UUID。

import random
from uuid import uuid1

def uuid1mc_insecure():
    return uuid1(random.getrandbits(48) | 0x010000000000)
点击查看英文原文

In addition to the accepted answer, there’s a third option that can be useful in some cases:

v1 with random MAC (“v1mc”)

You can make a hybrid between v1 & v4 by deliberately generating v1 UUIDs with a random broadcast MAC address (this is allowed by the v1 spec). The resulting v1 UUID is time dependant (like regular v1), but lacks all host-specific information (like v4). It’s also much closer to v4 in it’s collision-resistance: v1mc = 60 bits of time + 61 random bits = 121 unique bits; v4 = 122 random bits.

First place I encountered this was Postgres’ uuid_generate_v1mc() function. I’ve since used the following python equivalent:

from os import urandom
from uuid import uuid1
_int_from_bytes = int.from_bytes  # py3 only

def uuid1mc():
    # NOTE: The constant here is required by the UUIDv1 spec...
    return uuid1(_int_from_bytes(urandom(6), "big") | 0x010000000000)

(note: I’ve got a longer + faster version that creates the UUID object directly; can post if anyone wants)

In case of LARGE volumes of calls/second, this has the potential to exhaust system randomness. You could use the stdlib random module instead (it will probably also be faster). But BE WARNED: it only takes a few hundred UUIDs before an attacker can determine the RNG state, and thus partially predict future UUIDs. 

import random
from uuid import uuid1

def uuid1mc_insecure():
    return uuid1(random.getrandbits(48) | 0x010000000000)