Универсальный уникальный идентификатор (UUID - Universally Unique Identifier) – это форма идентификатора, которую можно с уверенностью признать уникальной для большинства практических целей. Даже если два UUID были сгенерированы в двух различных средах двумя сторонами, они имеют ничтожные шансы на то, чтобы оказаться идентичными. Именно поэтому UUID считаются универсально уникальными.
В этой статье мы с вами рассмотрим характеристики UUID, то, как работает их уникальность, и сценарии, для которых они могут упростить процесс идентификации ресурсов. Несмотря на то, что мы будем рассматривать UUID с точки зрения программного обеспечения, которое взаимодействует с записями базы данных, их также можно применять и в других ситуациях, где требуется децентрализованная генерация уникальных идентификаторов.
Что такое на самом деле универсальный уникальный идентификатор (UUID)?
UUID – это просто значение, которое с уверенностью можно рассматривать как уникальное. Вероятность обнаружения двух одинаковых UUID настолько мала, что ее можно просто игнорировать. Вы можете встретить и другие термины для UUID, например, GUID (Globally Unique Identifier, - глобальный уникальный идентификатор) (такой вариант предпочитает Microsoft), однако смысл и свойства остаются теми же.
Истинный UUID – это уникальный идентификатор, который был сгенерирован и представлен в стандартизированном формате. Допустимые UUID определены в спецификации RFC 4122. Она описывает алгоритмы, которые можно использовать для генерации UUID, которые бы сохраняли свою уникальность в различных реализациях без участия основной выдающей стороны.
В RFC есть пять различных алгоритмов. У каждого из этих алгоритмов есть свой собственный механизм генерации значений. Ниже приведено краткое описание доступных «версий»:
- Версия 1 – Time-Based – объединяет метку времени, тактовую последовательность и значение, которое является характерным для генерирующего устройства (как правило, это MAC-адрес); таким образом создается выходное значение, которое является уникальным для этого хоста на определенный момент времени.
- Версия 2 – DCE Security – эта версия была создана как модификация Версии 1, которую можно использовать в среде распределенных вычислений (DCE - Distributed Computing Environment). Применяется не так часто.
- Версия 3 – Name-Based (MD5) – MD5 хеширует «пространство имен» и «имя» для того, чтобы создать значение, которое будет уникальным для этого имени в пределах пространства имен. Попытка создать другой UUID с тем же пространством имен и тем же именем приведет к тому, что вы получите идентичный результат. Так что, этот метод дает воспроизводимые результаты.
- Версия 4 – Random – большинство современных систем выбирают именно эту версию, поскольку здесь для получения выходного значения используется источник случайных и псевдослучайных чисел. Вероятность того, что будут созданы два одинаковых UUID, ничтожна мала.
- Версия 5 – Name-Based (SHA-1) – эта версия в какой-то степени похожа на Версию 3, но здесь для хеширования пространства имен и имени используется более криптостойкий алгоритм SHA-1.
Хоть в RFC алгоритмы и обозначены как «версии», это ни в коем случае не значит, что всегда нужно использовать Версию 5, потому что она вроде бы самая новая. Выбор версии зависит от вашего варианта использования; зачастую выбирается Версия 4 из-за случайного характера генерации значений. Именно это делает ее идеальным вариантом для простых сценариев из разряда «дайте мне новый идентификатор».
Алгоритмы генерации на выходе дают 128-битное целое число без знака. Но при этом UUID чаще всего рассматривают как шестнадцатеричные строки. Также их можно хранить в виде двоичной последовательности из 16 символов. Ниже приведен пример UUID:
16763be4-6022-406e-a950-fcd5018633caЗначение записано с помощью пяти групп буквенно-числовых символов, разделенных дефисом. Последние не являются обязательными составляющими строки; их наличие связано с историческими тонкостями спецификации UUID. А еще они значительно облегчают зрительное восприятие идентификатора.
Варианты использования UUID
В основном UUID используют для децентрализованного создания уникальных идентификаторов. Вы можете создать UUID где угодно и с уверенностью сказать, то он уникальный, независимо от того, был он создан на вашем сервере, в клиентском приложении или в вашей базе данных.
UUID упрощают определение и обеспечение идентичности объекта в изолированных средах. Согласно сложившейся практике, большинство приложений в качестве первичного ключа используют целочисленное поле с автоинкрементом. В таком случае, когда вы создаете новый объект, то вы не узнаете его идентификатор до тех пор, пока не добавите его в базу данных. С помощью UUID вы можете определить идентификатор в вашем приложении намного раньше.
Ниже приведен демонстрационный пример, написанный на PHP, который покажет разницу. Для начала давайте посмотрим на целочисленную систему:
class BlogPost {
public function __construct(
public readonly ?int $Id,
public readonly string $Headline,
public readonly ?AuthorCollection $Authors=null) {}
}
#[POST("/posts")]
function createBlogPost(HttpRequest $Request) : void {
$headline = $Request -> getField("Headline");
$blogPost = new BlogPost(null, $headline);
}Мы должны инициализировать свойство $Id как null, поскольку мы не будем знать его фактический идентификатор до тех пор, пока не добавим его в базу данных. Это не самый идеальный вариант – $Id не должен обнуляться, из-за этого экземпляры BlogPost находятся в незавершенном состоянии.
Перейдем к UUID; это решит проблему:
class BlogPost {
public function __construct(
public readonly string $Uuid,
public readonly string $Headline,
public readonly ?AuthorCollection $Authors=null) {}
}
#[POST("/posts")]
function createBlogPost(HttpRequest $Request) : void {
$headline = $Request -> getField("Headline");
$blogPost = new BlogPost("16763be4-...", $headline);
}Идентификаторы публикаций теперь можно создавать прямо в приложении, не думая о том, что они могут повториться. Это гарантирует, что экземпляры объекта всегда находятся в действительном состоянии и что ну нужно присваивать ID нулевое значение. Также эта модель упрощает обработку транзакционной логики; дочерние записи, которым нужна ссылка на родителя (например, взаимосвязи автора (Author) нашей публикации), могут быть добавлены немедленно, и не нужно обращаться к базе данных для того, чтобы получить идентификатор родителя.
В перспективе большую часть логики данного приложения-блога можно будет переместить на клиентскую сторону. Возможно, внешний интерфейс сможет поддерживать полностью автономное создание черновиков, по сути создавая экземпляры BlogPost, которые будут временно сохраняться на устройстве пользователя. Теперь клиент может создавать UUID для публикации и, если ему нужно будет восстановить подключение к сети, передавать его на сервер. Если в обозримом будущем клиент получит копию черновика с сервера, то он сможет сравнить ее с любым сохранившимся локальным состоянием, так как он уже будет знать UUID.
С помощью UUID можно комбинировать данные из различных источников. Объединение таблиц базы данных и кэшей, которые используют целочисленные первичные ключи, может оказаться довольно трудоемким процессом, и, плюс ко всему, в процессе могут возникать ошибки. UUID обеспечивает уникальность идентификатора не только внутри таблиц, но и на уровне всего пространства. Это делает их более предпочтительным вариантом для дублируемых структур и данных, которые часто необходимо перемещать из одной системы хранения в другую.
Нюансы, возникающие при встрече UUID с базами данных
Преимущества UUID довольно привлекательны. Однако есть несколько подводных камней, о которых следует помнить при использовании UUID в реальных системах. Один из значительных факторов в пользу целочисленных идентификаторов – их легко масштабировать и оптимизировать. Механизмы управления базами данных могут с легкостью индексировать, сортировать и фильтровать список чисел, которые идут одно за другим.
А вот про UUID такого сказать нельзя. Прежде всего, UUID в четыре раза больше, чем целое число (36 против 4 байтов); для больших наборов данных этот факт уже может быть существенным моментом. Такие значения намного сложнее сортировать и индексировать, особенно если речь идет о случайных UUID, которые являются самыми популярными. Их случайный характер говорит о том, что они не имеют естественного порядка. Если вы используете UUID в качестве первичного ключа, то это может навредить производительности при индексировании.
Все эти проблемы могут усугубляться в хорошо нормализованной базе данных, которая активно использует внешние ключи. В таком случае у вас может оказаться большое количество реляционных таблиц, каждая из которых хранит ссылки на ваши 36-байтные UUID. В конечном счете, дополнительная память, которая необходима для выполнения операций объединения и сортировки, может негативно сказаться на производительность вашей системы.
У вас есть возможность немного сгладить нежелательные последствия, сохранив свои UUID в виде двоичных данных. Это значит, что вместо столбца VARCHAR(36) у вас будет столбец BINARY(16). Некоторые базы данные, например, PostgreSQL, имеют встроенный тип данных UUID; другие, например, MySQL, имеют специальные функции, которые преобразовывают строку UUID в двоичную форму и наоборот. Такой подход, конечно, более эффективный, но не забывайте, что вам по-прежнему придется использовать дополнительные ресурсы для хранения и выборки данных.
Эффективной может оказаться стратегия, когда вы в качестве первичных ключей оставляете целые числа, но при этом добавляете дополнительное поле UUID для того, чтобы ваше приложение могло на него ссылаться. Реляционные таблицы ссылок могут использовать идентификаторы для повышения производительности, пока ваш код извлекает и вставляет объекты верхнего уровня с UUID. Здесь все зависит от вашей системы, ее масштаба и ваших приоритетов: если вам нужна децентрализованная генерация идентификаторов и простейшее слияние данных, то лучший вариант – это UUID, но вам следует помнить и об обратной стороне медали.
Заключение
UUID – это уникальные значения, которые можно использовать для децентрализованной генерации идентификаторов. Совпадение идентификаторов возможно, но вероятность такого события настолько мала, что ее можно не учитывать. Если бы вы генерировали один миллиард UUID в секунду в течении 100 лет, то вероятность обнаружить дубликат составила бы около 50% при условии наличия достаточной энтропии.
У вас есть возможность использовать UUID для установления идентичности независимо от вашей базы данных до того, как вы добавите объект в базу данных. Такой подход упрощает код прикладного уровня и не допускает того, что объекты в вашей системе будут идентифицированы неправильно. UUID также содействуют репликации данных, гарантируя уникальность вне зависимости от хранилища данных, устройства или среды, чего нельзя сказать о целочисленных ключах, которые действуют на уровне таблиц.
Несмотря на то, что UUID широко используются при разработке программного обеспечения, они не являются идеальным решением. Новички часто зацикливаются на возможности обнаружения совпадений, но это не должно быть вашим главным аргументом, если только ваша система не настолько чувствительна, что вам просто необходимо гарантировать уникальность идентификаторов.
Более очевидная проблема для большинства разработчиков заключается в хранении и извлечении сгенерированных UUID. Примитивное использование VARCHAR(36) (или VARCHAR(32), если вы удалите дефисы) в долгосрочной перспективе может оказывать негативное влияние на ваше приложение, так как большая часть попыток оптимизировать индексацию базы данных будут неэффективными. Изучите встроенные средства обработки UUID в вашей системе управления базой данных для того, чтобы максимально улучшить производительность вашего программного решения.
