ВИДЫ ИДЕНТИФИКАТОРОВ В ИНФОРМАЦИОННЫХ СИСТЕМАХ

Введение

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

Идентификатор (по определению) должен быть уникальным. Существуют различные подходы к созданию ID, но все они стремятся к минимизации коллизии между идентификаторами.

Sequence-based ID

Sequence-based ID (последовательные идентификаторы) чаще всего находят свое применение в небольших монолитных системах и представляют из себя обычную последовательность целых чисел. Каждый такой идентификатор чаще всего является целым числом, которое было получено увеличением на единицу предыдущего идентификатора.

К плюсам такого подхода можно отнести:

• простоту в понимании и реализации;
• скорость генерации;
• размер может быть любой (все зависит от потребностей).

К минусам же относятся:

• отсутствие какой-либо мета-информации в идентификаторе;
• невозможность использовать в распределенных системах.

UUID

UUID (всемирно уникальный идентификатор) применяется как в монолитных, так и в распределенных системах. Занимает 16 байт, а в строчном представлении выглядит примерно так [1]:

123e4567-e89b-12d3-a456-426655440000

Пример выше состоит из пяти групп вида 8-4-4-12 шестнадцатеричных чисел. В UUID кодируется его версия и вариант.

Выделяют следующие версии UUID:

• Nil UUID — это особенный UUID, в котором все биты выставлены в ноль.
• Версия 1 (время и MAC-адрес) включает в себя MAC-адрес узла, который сгенерировал этот UUID и метку времени этого узла.
• Версия 2 (время, MAC-адрес и DCE security version) плохо описывается в спецификации RFC 4122, поэтому скорее относится к разряду зарезервированных на будущее. По этой же причине, многие программные реализации UUID обходятся без этой версии.
• Версии 3 и 5 нужны тогда, когда необходимо обезопасить информацию. Версия 3 использует алгоритм хэширования MD5, а версия 5 использует SHA-1. Данные ID выполняют одно и то же - преобразуют пространство имен и имя в один и тот же UUID, но обратно получить пространство имен и имя нельзя.
• Версия 4 (случайный) генерируется случайным образом. Под случайную часть отводится 122 бита, что является достаточно большим числом, чтобы в подавляющем большинстве задач не переживать из-за коллизии идентификаторов.

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

Чаще всего на практике в информационных системах применяют UUIDv4, поскольку он наиболее близок к тому уровню абстракции, который устанавливают сущности внутри этой информационной системы. Использование же версий 3 и 5 нецелесообразно в подавляющем большинстве задач, поскольку криптографические алгоритмы хэширования занимают достаточно много процессорного времени, что при высоких нагрузках на систему оказывается непозволительной роскошью. Версия 2, в свою очередь, слишком завязывается на физический уровень (MAC-адрес), что в эпоху облачных технологий лишено всякого смысла, поскольку все приложения работают в изолированных контейнерах. К тому же, UUIDv2 использует не самый распространенный тип временной метки - количество 100 наносекундных интервалов времени с начала использования Григорианского календаря, что накладывает дополнительные сложности в реализации и совмещении с другими гораздо более популярными типами временных меток.

Несмотря на свою универсальность, UUIDv4 имеет один существенный недостаток: множество идентификаторов, которое он предлагает не является монотонным, что приводит к невозможности установления порядка следования между сущностями информационной системы.

Snowflake ID

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

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

• временная метка;
• идентификатор узла;
• последовательный номер.

В базовом варианте под временную метку отводят 42 бита, где самый старший бит не используется, потому что отводится под знак. Строго говоря, временная метка (timestamp) означает количество миллисекунд, которые прошли с начала эпохи UNIX (00:00 1 января 1970 года). Однако, из-за небольшого объема места под это значение (фактически 41 бит), может возникнуть ситуация переполнения. Поэтому на практике чаще всего применяют другую стартовую точку, которую выбирают любым удобным способом. Например, дата основания компании, дата внедрения Snowflake ID и т. д.

У временной метки есть несколько полезных качеств, которые могут оказаться очень кстати. Обычно и оказываются, потому что выбор Snowflake ID часто оказывается результатом долгих размышлений. Первое из этих качеств заключается в том, что временная метка может рассказать о том, когда была создана сущность в распределенной системе. Для этого достаточно прочитать эту метку и прибавить к базовому времени. Таким образом достается информация о дате создания. Второе полезное качество заключается в самом явлении времени. Время всегда увеличивается и никогда не уменьшается. По этой причине временная метка обеспечивает естественную упорядоченность. Этому также способствует и ее расположение в старших разрядах идентификатора.

Следующий блок бит — это идентификатор узла. Поскольку, Snowflake ID предназначены для использования в распределенных системах, то возникает необходимость различать приложение, которое этот идентификатор сгенерировало. Это может помочь выявить дисбаланс в распределении нагрузки и обнаружить его причину. Также это бывает полезным, когда какой-нибудь узел по какой-то причине генерирует неправильные сущности. К тому же, использование отдельного битового пространства для идентификатора узла позволяет распараллелить создание сущностей в одно и то же время в распределенной системе. В базовом варианте идентификатор узла занимает 10 бит, что позволяет параллельно запускать 1024 экземпляра приложения, которое работает с какой-нибудь сущностью. При этом, если система спроектирована достаточно гранулярно, то 1024 доступных экземпляра приложения является не таким уж маленьким числом.

Последний битовый блок — это последовательный номер, которые еще называют sequence. Цель у этого блока достаточно проста — обеспечить возможность одновременного создания идентификаторов. Это может пригодится в том случае, если на каждый отдельный узел системы действует высокая нагрузка (в одну миллисекунду приходит больше 1 запроса), или если выполняется пакетная запись (например, нужно создать сразу 100 сущностей). Этот блок занимает оставшиеся 12 бит в базовом варианте. Такой размер дает возможность обрабатывать на одном узле до 4096 запросов включительно.

Выводы

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

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

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

Последовательные идентификаторы следует использовать в небольших монолитных системах, где нет необходимости в глобальной уникальности идентификаторов и где не требуется работа с распределенными системами.

UUID следует использовать в случаях, когда требуется глобальная уникальность идентификаторов и когда система может быть, как монолитной, так и распределенной. Особенно рекомендуется использовать версию 4 (случайный) UUID, так как она обеспечивает достаточный уровень уникальности и не требует MAC-адреса или других специфических данных [3].

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

Список литературы:

1. RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace. — Текст : электронный // www.rfc-editor.org : [сайт]. — URL: https://www.rfc-editor.org/rfc/rfc4122 (дата обращения: 23.05.2024).
2. Snowflake ID. — Текст : электронный // Wikipedia : [сайт]. — URL: https://en.wikipedia.org/wiki/Snowflake_ID (дата обращения: 23.05.2024).
3. UUID vs. Sequential ID as Primary Key. — Текст : электронный // Bauldung : [сайт]. — URL: https://www.baeldung.com/uuid-vs-sequential-id-as-primary-key (дата обращения: 23.05.2024).