Реализация UUID для лучшей производительности

Question

Требование:
нам нужно присвоить продавцам случайное, достаточно длинное число / строку, чтобы они были однозначно идентифицируемыми (не нужно, чтобы кто-то угадывал идентификатор). Это необходимо, поскольку мы печатаем этот номер / строку в виде QR-кода и даем его продавцам, чтобы наши пользователи могли прочитать QR-код и получить информацию о продавце.

текущая реализация:
мы не можем печатать идентификаторы, так как они будут последовательными, поэтому мы ввели новое поле (externalId) для хранения уникального идентификатора, сгенерированного TimeBasedGenerator генератора JUG UUID. Поскольку я исследовал больше, я обнаружил, что есть проблемы производительности с UUID. Во всех статьях говорится о UUId как первичном ключе, я не использую UUID в качестве первичного ключа, а в качестве вторичного идентификатора. Я не беспокоюсь о вставках и обновлениях, так как их будет меньше по сравнению с поиском. Поскольку пользователь будет отправлять нам UUID, считанный из напечатанного QR-кода, и нам нужно будет искать продавца, используя это поле UUID, следовательно, это будет иметь огромное влияние на производительность.

решение по мне:
вместо UUID мы дадим комбинацию ID: UUID, так что, когда мы получим запрос, мы можем разделить и извлечь продавца, используя ID, и проверить, соответствует ли externalId(UUID), присутствующий в нашей БД, указанному, если он совпадает. мы возвращаем торговцу иначе.

Это решение значительно увеличит производительность или время, затрачиваемое на строковые операции, сведет на нет эффект.

Есть ли лучший подход для этого?

Спасибо

Answer 1

UUID генерируются в разных вариантах. Как вы, возможно, уже знаете, RFC 4122 описывает вариант (то есть схему UUID), который определяет пять разных версий. Я предлагаю вам взглянуть на версию 1 RFC 4122.

Версия 1 использует MAC-адрес компьютера, генерирующего UUID, в качестве последних 12 цифр сгенерированного UUID.

Предположим, вы идете к подержанному переработчику компьютеров и приобретаете устаревший адаптер Ethernet; включите его и получите MAC-адрес этого адаптера; а затем уничтожить адаптер (шредер, дробовик, кислота и т. д.). Теперь вы можете быть уверены, что никакой другой компьютер в юниверсе никогда не сгенерирует UUID V1, используя этот MAC-адрес.

Теперь вы можете написать генератор UUID (RFC 4122, V1), который будет использовать собранные MAC-адреса.

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

БОНУС: Вы можете поэкспериментировать с UUID V1, используя UUID Махонри Морианкумера и GUID Generator и Forensics.

Answer 2

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

Либо это, либо, как вы предложили, ID будет служить той же цели. Преимущества индексации частичного UDID состоят в том, что

1. Вы можете настроить количество символов для повышения производительности
2. идентификатор не используется извне, что может вызвать проблемы.

С другой стороны, целочисленный индекс, вероятно, использует меньше памяти и не нуждается в настройке

С точки зрения производительности, для моей реализации мы столкнулись с поисковыми запросами 1 на миллион, занимающими 7-8 секунд. С этим решением мы упали до нескольких миллисекунд