Что такое 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, допускающих значение null. Модель также упрощает обработку транзакционной логики; дочерние записи, которым нужна ссылка на их родителя (например, ассоциации Author нашего сообщения), могут быть вставлены немедленно, без обращения к базе данных для получения идентификатора, который был назначен родителю.

В будущем ваше приложение блога может переместить больше логики в клиент. Возможно, во внешнем интерфейсе появится поддержка полного создания черновиков в автономном режиме, эффективно создавая экземпляры BlogPost, которые временно сохраняются на устройстве пользователя. Теперь клиент может генерировать UUID сообщения и передавать его на сервер при восстановлении подключения к сети. Если клиент впоследствии получит копию черновика с сервера, он сможет сопоставить ее с любым оставшимся локальным состоянием, поскольку UUID уже будет известен.

UUID также помогают комбинировать данные из разных источников. Объединение таблиц базы данных и кэшей, использующих целочисленные ключи, может быть утомительным и подверженным ошибкам. UUID обеспечивают уникальность не только внутри таблиц, но и на уровне всей вселенной. Это делает их гораздо лучшими кандидатами для реплицируемых структур и данных, которые часто перемещаются между разными системами хранения.

Предостережения, когда UUID встречаются с базами данных

Преимущества UUID весьма убедительны. Однако есть несколько ошибок, на которые следует обратить внимание при их использовании в реальных системах. Одним из важных факторов в пользу целочисленных идентификаторов является то, что их легко масштабировать и оптимизировать. Механизмы базы данных могут легко индексировать, сортировать и фильтровать список чисел, которые идут только в одном направлении.

Чего нельзя сказать об UUID. Начнем с того, что UUID в четыре раза больше, чем целые числа (36 байтов против 4 байтов); для больших наборов данных это само по себе может быть важным фактором. Значения также намного сложнее сортировать и индексировать, особенно в случае наиболее распространенных случайных UUID. Их случайный характер означает, что они не имеют естественного порядка. Это ухудшит производительность индексирования, если вы используете UUID в качестве первичного ключа.

Эти проблемы могут усугубляться в хорошо нормализованной базе данных, которая интенсивно использует внешние ключи. Теперь у вас может быть много реляционных таблиц, каждая из которых содержит ссылки на ваши 36-байтовые UUID. В конце концов, дополнительная память, необходимая для выполнения операций объединения и сортировки, может оказать существенное влияние на производительность вашей системы.

Вы можете частично смягчить проблемы, сохранив свои UUID в виде двоичных данных. Это означает столбец BINARY(16) вместо VARCHAR(36). Некоторые базы данных, такие как PostgreSQL, включают встроенный тип данных UUID; другие, такие как MySQL, имеют функции, которые могут преобразовать строку UUID в ее двоичное представление и наоборот. Этот подход более эффективен, но помните, что вы все равно будете использовать дополнительные ресурсы для хранения и выбора данных.

Эффективной стратегией может быть сохранение целых чисел в качестве первичных ключей, но добавление дополнительного поля UUID для справки вашего приложения. Таблицы реляционных ссылок могут использовать идентификаторы для повышения производительности, пока ваш код извлекает и вставляет объекты верхнего уровня с UUID. Все зависит от вашей системы, ее масштаба и ваших приоритетов: когда вам нужна децентрализованная генерация идентификаторов и простое слияние данных, UUID — лучший вариант, но вы должны осознавать компромиссы.

Краткое содержание

UUID — это уникальные значения, которые вы можете безопасно использовать для децентрализованной генерации идентификаторов. Столкновения возможны, но они должны быть настолько редкими, что их можно не принимать во внимание. Если бы вы генерировали один миллиард UUID в секунду в течение целого века, вероятность встретить дубликат составила бы около 50% при условии наличия достаточной энтропии.

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

Хотя UUID теперь повсеместно используются в разработке программного обеспечения, они не являются идеальным решением. Новички, как правило, зацикливаются на возможности коллизий, но это не должно быть вашим главным соображением, если только ваша система не настолько чувствительна, что необходимо гарантировать уникальность.

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