Зачем нужен генератор идентификаторов, если базы данных уже предлагают нам идентификаторы с автоинкрементом?
С одним экземпляром записи мы можем использовать идентификатор автоинкремента в качестве первичного ключа для базы данных. Но что, если у нас много экземпляров записи? В этом случае необходимо предоставить глобальную службу, которая создает отдельные идентификаторы для всех экземпляров базы данных.
Почему тогда UUID не вариант?
- UUID не являются последовательными, поэтому при масштабировании вы столкнетесь с проблемами производительности.
- Это занимает 128 бит, слишком долго.
Каков же тогда ответ? Почему мы не могли использовать временную метку вместо этого? Он будет уникальным и отсортированным, но что, если две системы генерируют идентификатор одновременно?
ID: ‹отметка времени›
Затем давайте объединим идентификатор системы с отметкой времени. Но что, если мы запустим два процесса генерации идентификаторов на одной машине?
ID: ‹отметка времени›‹идентификатор машины›
Затем позволяет соединить порядковый номер с отметкой времени и идентификатором машины. Порядковый номер генерируется из счетчика с машины, на которой он работает, каждый поток или рабочий процесс получит порядковый номер.
ID: ‹отметка времени›‹идентификатор машины›‹порядковый номер›
Это не соответствует строгому порядку, но и не является полностью случайным, размер составляет половину UUID. Вот как Твиттер генерирует уникальные идентификаторы, это называется снежинка, и это широко адаптированный способ создания уникальных идентификаторов.
Это пока!!!!!!!!!!!!!!!!!!!!
Надеюсь, вам понравилось. Если вы дочитали до этого момента и нашли какие-либо ошибки в чем-либо из вышеперечисленного или можете придумать способ сделать это более понятным для будущих читателей, не стесняйтесь оставлять комментарии. Спасибо!
