роблема

Я ищу отзывы об этом исследованиилокально уникальная альтернатива для GUIDсо следующими требованиями:

Имеет очень низкую вероятность столкновения (до такой степени, что мы предпочитаем сталкиваться раз в год, а не выполнять проверки)Не протекаетчувствительный информация, например, сколько существует предметовИмеет высокую производительность в базе данных SQLКопируется / вставляется для ручного запроса (как строки запроса, так и результата запроса)Может использоваться в качестве компонента URI без кодирования

Чтобы соответствовать требованиям, я определился с формой64-разрядное целое число без знака, Он легок в использовании процессора, приятен и компактен для использования первичным ключом, легко читается человеком, содержит только цифры и легко копируется / вставляется при выполнении запросов вручную. (В качестве контрпримера, большие двоичные объекты сильно затрудняют ручные запросы в большинстве баз данных SQL.)

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

Предлагаемая структура

Слева направо, наиболее значимые биты находятся слева

46 бит.Отметка, Время Unix в миллисекундах. (По крайней мере, в C # время менее миллисекунды недоступно.) Это будет продолжаться до 4199 года. Это дает нам монотонно растущие значения.8 битЧасть локального IP, Последний компонент внутреннего IP-адреса аппарата, самый быстрый из доступных сетевых интерфейсов. Должна быть локальная сеть Ethernet для большинства серверов.10 битUniquefier, Статический счетчик, который увеличивается (блокируется) при использовании, с циклическим изменением.

Столкновения

Вероятность столкновения составляет 1/1024 (~ 0,1%) всякий раз, когда:

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

Ограничения

Интересно, что мы, кажется, отвечаем требованиям (№ 2 изворотливо). Давайте посмотрим на некоторые ограничения.

Локальные IP-адреса серверов должны тщательно поддерживаться - даже в разных дата-центрах, если это применимо.Мы не можем поддерживать более 255 серверов - возможно, меньше, если существуют другие ограничения на IP-адреса.Мы пропускаем информацию о том, какие идентификаторы были созданы одним и тем же сервером. Я полагаю, что это имеет место со многими реализациями GUID также, однако.Информацию об объемах трафика можно получить, проверив приращения счетчика между запросами пользователя. Эффективность снижается из-за того, что счетчик используется для различных типов данных, быстро увеличиваясь и таким образом, что его трудно приписать какому-либо конкретному типу данных.Идентификаторы гораздо более вероятны, чем те, которые имеют много случайностей. Атаке грубой силы потребовалось бы около 512 вызовов (uniquefier) ​​за попытку миллисекунды. В идеале, эта атака ничего не дает, то есть система сообщает о «несанкционированном доступе» независимо от того, существует ли идентификатор или не принадлежит пользователю, и устойчива ли он к атакам по времени. Реально, давайте предположим, что выделенный злоумышленник обнаружит утечку.

Соображения

Ограничения № 1 и № 2 должны просто соответствовать компании.

Ограничение № 3 представляется приемлемым в существующих реализациях GUID, и я с этим согласен.

Ограничение № 4 сложно. Насколько конфиденциальна эта информация? «Таким образом, мы выполняем 10 000 вставок в минуту в неизвестное количество таблиц». Относительные объемы дают больше понимания: «Между 08: 00-09: 00 активность в два раза выше, чем часом ранее». Тем не менее, это обычно будет общеизвестно в данной области. Неожиданные пики могут привести к утечке дополнительной информации. «Таким образом, система усердно работает в 03:00 утра». Насколько все это плохо? Судя по количеству компаний, которые выставляют идентификаторы автоинкремента, мы можем сказать, что это улучшение чаще, чем нет ... Но это может стать нарушителем условий.

Мы могли бы использовать (крипто) случайные биты в качестве уникального идентификатора, чтобы справиться с ограничением № 4, но это привело бы к третьей возможности коллизии: всякий раз, когда система генерирует несколько идентификаторов в течение миллисекунды. Парадокс дня рождения там особенно проблематичен.

Мы могли бы освободить 2 бита, если бы мы позволили метке времени обернуться в 2527 году. Эгоистичен и нечувствителен к будущим поколениям, или высокомерно полагать, что наш код будет использоваться дольше? :-)

Что-то еще?

Я приветствую ваши отзывы, улучшения, идеи, ограничения, которые я пропустил! Как бы вы решили эту проблему?