Три способа сформировать идентификатор пользователя.
Привет, меня зовут Рамис и я работаю дата-аналитиком в Garage Eight. Так как аналитики довольно часто (почти всегда) используют id пользователя для объединения таблиц, я хочу рассказать о различных способах формирования идентификатора пользователя (user_id, id, account_id и пр.).
Первый способ, который приходит на ум — это инкрементальное увеличение id пользователя, также известный как последовательный или автоинкрементный ID. То есть самый первый пользователь будет иметь id = 1, следующая регистрация 2 и так далее. Вроде бы идеально?
Плюсы:
Уникальность.
Порядок регистрации.
Простота реализации.
Минусы:
Требуют централизованного управления, что может замедлять работу при масштабировании.
Предсказуемы (идут по порядку), что может быть небезопасно, ведь злоумышленники могут угадать ID.
Для генерации нового ID часто нужно обращаться к базе данных (БД), что увеличивает нагрузку.В шардированных или реплицированных БД могут возникать конфликты и задержки в генерации ID.
Невозможно встроить дополнительную информацию (например, временные метки или идентификаторы сервисов).
Кстати, проблему шардирования можно частично решить следующим образом: id увеличивается не на 1, а на число k, равное количеству используемых БД.
Второй способ — UUID, или универсально уникальный идентификатор (Universally Unique Identifier), — это 128-битное число.
Плюсы:
Уникальный, почти никогда не повторяется.
Генерится где угодно, не нужна база данных.
Не угадать, особенно, v4 и v7.
Для больших систем, так что хорошо подходит для микросервисов.
Можно сортировать, в v7 есть время создания.
Минусы:
Длинный — 128 байт (обычные ID короче).
Неудобный, сложно запомнить (типа a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11).
Медленнее в БД, иногда тормозит индексы.
Без порядка, v4 нельзя сортировать (v7 решает).
Не число.
Третий способ — Twitter snowflake id (теперь X) — это система генерации уникальных 64-битных идентификаторов для объектов, таких как твиты, личные сообщения, пользователи и списки.
Бит знака — всегда равно 0 и зарезервировано на будущее.
Временная метка — количество миллисекунд, прошедших с начала эпохи UNIX.
ID ЦОД дает нам 2 ^ 5 = 32 центра обработки данных.
ID компьютера дает нам еще 2 ^ 5 = 32 компьютера в каждом ЦОД.
Номер последовательности.
При генерации каждого id на отдельно взятом компьютере или процессе номер последовательности инкрементируется на 1, каждую миллисекунду этот инкремент обнуляется.
Плюсы:
Уникальность.
Распределенная генерация.
Можно сортировать.
Эффективность. 64-битный формат обеспечивает достаточную ёмкость для идентификаторов, а также эффективную обработку данных.
Простота. Логика генерации Snowflake довольно проста для понимания и реализации.
Популярность. Идентификаторы Snowflake широко используются, что облегчает интеграцию с различными системами и библиотеками.
Минусы:
Ограничение по времени. Максимальная точность Snowflake — миллисекунды, что может быть недостаточно для некоторых приложений, требующих большей точности.
Риск переполнения. При очень высокой скорости генерации идентификаторов существует риск переполнения порядкового номера, что может привести к потере уникальности.
Зависимость от синхронизации времени. Точность временной метки зависит от синхронизации времени на серверах.
Сложность в распределенных системах. При неправильной настройке распределенной системы могут возникать проблемы с уникальностью идентификаторов.
Необходимость управления идентификаторами машин. Каждой машине, генерирующей идентификаторы, необходимо присваивать уникальный идентификатор.
На этом все, но это неполный список, есть еще сервер тикетов и прочие.
Информацию взял из книги «System Design. Подготовка к сложному интервью», Алекс Сюй.