Генерация / Сжатие уникального ключа

Question

В моей работе много пользователей, и у каждого пользователя есть набор файлов в их домашних каталогах.Из-за некоторых предопределенных правил я дал каждому файлу UID (уникальную идентификацию) на основе содержимого файла пользователя и времени его создания.Но теперь я узнал, что количество файлов в учетной записи пользователя не может превышать, скажем, 1 миллион.Текущий UID составляет около 32 символов.Есть ли способ, с помощью которого я могу уменьшить свой UID до 6 (идеальное состояние) символа до 10-12 символов, поскольку текущий uidl использует много места в моей базе данных NoSQL.

Текущий uidl выглядит как timestamp.prrocess_whichcreated_it.size

EDIT Позвольте мне перефразировать проблему.Что мне действительно нужно, так это алгоритм сжатия: например,

У меня есть список из 1 000 000 строк (каждая уникален) и длиной 32 символа.Мне нужна функция сжатия f, такая, что F (строка) = s2, где S2 имеет длину 10 символов, а все строки S2 однозначно отображаются

Answer 1

Очень трудно взять UNIQUE id, сжать его и сохранить его UNIQUE.Вы склонны сталкиваться с столкновениями.

@ Амит действительно лучший.Возможно, его реализация была немного хитрой.

Как насчет того, чтобы создать таблицу со столбцом AUTO INCREMENTING INTEGER "ID" и строкой / varchar "OldGUID".ВСТАВЬТЕ все свои старые / текущие GUID в таблицу, и теперь у вас есть совпадение 1: 1 между GUID и более коротким / сжатым «ID».Когда вы создаете новые GUID, просто вставьте их в таблицу, и у вас останется совпадение 1: 1, чтобы вы могли переключаться между длинной и короткой версиями.

Answer 2

Сортируйте ваши UID и замените старые UID новыми UID, указывающими индекс в отсортированном массиве старых UID

упрощенный псевдокод должен выглядеть так:

sorted <- sort(UID's)
for each file:
  file.UID <- sorted.indexOf(file.UID)

Answer 3

Если вам нужен только уникальный идентификатор, то моя первая мысль - UUID .

Однако общий UUID будет занимать 16 байт и является двоичным форматом. Это не соответствует вашему требованию 6 символов. По сравнению с вашим текущим методом, использующим 32 символа, он «только» экономит 50% пространства.

Поэтому более мягкой схемой было бы использование 64-битного UID (8 байт) с общей хэш-функцией. При хорошем хеше вероятность коллизии остается довольно разумной, если общее число генерируемых UID меньше 100 миллионов. Если это кажется приемлемым, тогда 8 байтов кажутся достаточно близкими к вашему пространственному требованию.