Когда я должен использовать uuid.uuid1 () против uuid.uuid4 () в python?

Я понимаю разницу между этими двумя документами.

uuid1():
Генерировать UUID из идентификатора хоста, порядкового номера и текущего времени

uuid4():
Генерировать случайный UUID.

Поэтому uuid1использует информацию о машине / последовательности / времени для генерации UUID. Каковы плюсы и минусы использования каждого?

Я знаю, что uuid1()может иметь проблемы с конфиденциальностью, так как она основана на информации о машине. Интересно, есть ли что-нибудь более тонкое при выборе одного или другого. Я просто использую uuid4()прямо сейчас, так как это совершенно случайный UUID. Но мне интересно, должен ли я использовать, uuid1чтобы уменьшить риск столкновений.

По сути, я ищу советы людей по передовым методам использования одного против другого. Спасибо!

uuid1()гарантированно не вызовет никаких коллизий (при условии, что вы не создаете слишком много их одновременно). Я бы не стал использовать его, если важно, чтобы между uuidкомпьютером и компьютером не было связи , поскольку MAC-адрес используется для того, чтобы сделать его уникальным для всех компьютеров.

Вы можете создать дубликаты, создав более 2 ¹⁴ uuid1 менее чем за 100 нс, но это не проблема для большинства случаев использования.

uuid4()генерирует, как вы сказали, случайный UUID. Вероятность столкновения действительно, на самом деле, на самом деле мало. Достаточно маленький, чтобы не беспокоиться об этом. Проблема в том, что плохой генератор случайных чисел повышает вероятность возникновения коллизий.

Этот превосходный ответ Боба Амана хорошо подводит итог. (Я рекомендую прочитать весь ответ.)

Честно говоря, в одном пространстве приложений без злонамеренных акторов вымирание всей жизни на Земле произойдет задолго до того, как вы столкнетесь, даже с UUID версии 4, даже если вы генерируете довольно много UUID в секунду.

Один случай , когда вы можете рассмотреть вопрос, uuid1()а не uuid4()является , когда UUID , производится на отдельных машинах , например , когда несколько онлайн - транзакций являются процесс на нескольких машин для масштабирования целей.

В такой ситуации, например, риск возникновения коллизий из-за неправильного выбора способа инициализации генераторов псевдослучайных чисел, а также потенциально более высокого числа создаваемых UUID делает более вероятной возможность создания дублированных идентификаторов.

Другой интерес uuid1()в этом случае заключается в том, что машина, на которой каждый GUID был изначально создан, записывается неявно (в части «узел» UUID). Это и информация о времени, может помочь, если только с отладкой.

Моя команда только что столкнулась с проблемой при использовании UUID1 для сценария обновления базы данных, где мы сгенерировали ~ 120k UUID за пару минут. Конфликт UUID привел к нарушению ограничения первичного ключа.

Мы обновили сотни серверов, но в наших экземплярах Amazon EC2 мы несколько раз сталкивались с этой проблемой. Я подозреваю, что плохое разрешение часов и переход на UUID4 решили это за нас.

Одна вещь, на которую следует обратить внимание при использовании uuid1: если вы используете вызов по умолчанию (без указания clock_seqпараметра), у вас есть шанс столкнуться с коллизиями: у вас есть только 14 бит случайности (генерирование 18 записей в течение 100 нс дает вам примерно 1% шансов на столкновение). день рождения парадокс / атака). Проблема никогда не возникнет в большинстве случаев использования, но на виртуальной машине с плохим разрешением часов она вас укусит.

Возможно, что-то, что не было упомянуто, - это местность.

MAC-адрес или упорядочение по времени (UUID1) может позволить повысить производительность базы данных, поскольку сортировать числа ближе друг к другу меньше, чем случайным образом (UUID4) (см. Здесь ).

Вторая связанная с этим проблема заключается в том, что использование UUID1 может быть полезно при отладке, даже если исходные данные потеряны или не сохранены в явном виде (это явно противоречит проблеме конфиденциальности, упомянутой в OP).

Помимо принятого ответа, в некоторых случаях может быть полезен третий вариант:

v1 со случайным MAC («v1mc»)

Вы можете сделать гибрид между v1 и v4, преднамеренно генерируя UUID v1 со случайным широковещательным MAC-адресом (это разрешено спецификацией v1). Результирующий UUID v1 зависит от времени (как обычный 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 напрямую; может публиковать, если кто-то хочет)

В случае БОЛЬШИХ объемов вызовов в секунду это может привести к потере случайности системы. Вместо этого вы можете использовать randomмодуль stdlib (вероятно, он также будет быстрее). Но имейте в виду: требуется всего несколько сотен UUID, прежде чем злоумышленник сможет определить состояние RNG и, таким образом, частично предсказать будущие UUID.

import random
from uuid import uuid1

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