хэширование
Добрый день. стоит такая задача: есть некий ключ, идентифицирующий клиента, состоящий из 500 байт. полагается, что клиентов будет порядка сотен тысяч. ясное дело, что с приемлимой скоростью мы не сможем идентифицировать клиента. пришла в голову идея сократить этот ключ за счет какого-нибудь алгоритма хеширования. собственно сам вопрос: какой алгоритм мог бы подойти для этого лучше? первое, что пришло в голову - md5, но википедия пишет "MD5 is not suitable for applications like SSL certificates or digital signatures that rely on this property".
Что-то непонятно, чем не устраивает существующий ключ в 500 байт. Это не такие уж гигантские размеры (по объему). Тем более в 500 байтах можно разместить 2^(500*8) = 2^4000 клиентов.
Для сотни тысяч клиентов достаточно ключа длинною в 17 бит, или, если округлить, 3 байта.
Ну и посчет md5 (или недавно появившийся md6) - а вам что, этот ключ надо использовать в цифровой подписи или для сертификатов? Главное качество алгоритма хеширования - это минимальная возможность коллизии. md5, насколько я помню, имеет хорошие показатели.
Для сотни тысяч клиентов достаточно ключа длинною в 17 бит, или, если округлить, 3 байта.
Ну и посчет md5 (или недавно появившийся md6) - а вам что, этот ключ надо использовать в цифровой подписи или для сертификатов? Главное качество алгоритма хеширования - это минимальная возможность коллизии. md5, насколько я помню, имеет хорошие показатели.
ни то ни другое. просто поиск необходимого клиента в базе по 500 байтному ключу будет осуществляться долго. ищу способы ускорить эту процедуру.
А если построить бинарное дерево поиска (индекс)? И искать уже по дереву (индексу)? Если не ошибаюсь у бинарного поиска в худшем случае O(n*log(n))
Черт, сразу не обратил внимание, что речь о СУБД...
А поле ключа проиндексировано? Какая СУБД? Надо индекс создавать и тогда поиск можно ускорить многократно.
Черт, сразу не обратил внимание, что речь о СУБД...
А поле ключа проиндексировано? Какая СУБД? Надо индекс создавать и тогда поиск можно ускорить многократно.
субд еще не выбирал, пока анализировал ситуацию. но все, спасибо, ребята. отбой! задача трансформировалась и простым сравнением тут не обойтись... спасибо за ответы.