Уникальный ключ для создания/сжатия

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

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

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

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

источник

2012-01-25 Global Warrior

Вы ищете хеш-функцию, которая будет запускаться каждый раз, когда вы ищете UID или способ изменить эти UID на меньший новый диапазон? – amit

@amit: Я просто хочу сжать свой предыдущий UID, будет хорошо, если я смогу использовать текущий UID для своей задачи, но также будет хорошо, если я могу вычислить новый. В идеале H (C.UIDL) = newuidl –

Тогда почему бы просто не сортировать и не заменять? сортировать все UID и заменять старый UID новым UID, указывающим индекс старого UID в отсортированном списке. Он будет уникальным и оптимальным. Или я пропускаю то, что вы на самом деле имеете в виду? : | – amit

Отсортируйте UID и замените старый UID новым UID, указав индекс в отсортированном массиве

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

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

источник

2012-01-25 12:09:44 amit

это не может быть сделано таким образом: я всегда должен получать свой новый uid из предыдущего uid. Поэтому мне нужна функция вроде H (prev) = newuid, bcz я не могу просто изменить предыдущие данные, поскольку она присутствует на нескольких местах –

Это очень трудно сделать уникальный идентификатор сжать его и держать его UNIQUE. Вы склонны сталкиваться с столкновениями.

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

Как насчет того, чтобы создать таблицу с АВТОМАТИЧЕСКИМ ИНКРИМЕНТИРОВАНИЕМ INTEGER "ID" и строку/varchar "OldGUID". ВСТАВИТЕ все ваши старые/текущие GUID в таблицу, и теперь у вас есть соответствие 1-к-1 между GUID и коротким/сжатым «ID». Когда вы создаете новые GUID, просто вставьте их в таблицу, и вы продолжите матч 1 к 1, чтобы вы могли переключаться между длинной и короткой версиями.

источник

2012-01-25 14:45:44

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

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

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

источник

2012-01-25 21:56:58 Cyan

Уникальный ключ для создания/сжатия

ответ

Смежные вопросы