Вы уверены, что ваша таблица БД не подходит?Это много требований к хэш-функции.Большинство хеш-функций не позволяют вам установить длину хеша, а требование, чтобы хеш был идеальным, еще больше сужает его.Вам нужны все эти требования?Скорее всего, гораздо более простое решение будет работать так же хорошо.
Вы читаете это с диска?(100 миллиардов URL-адресов, при условии, что длина URL-адреса равна 4 для домена, + 4 для ".com" + "/" + еще 3 = 12 байт на URL = 1,09 ТиБ - и это очень консервативная оценка.)хотите изучить структуры, дружественные к диску, такие как B-деревья (и их производные, такие как B + -деревья) - эти структуры данных предлагают эффективный (log (n) теоретически, но в некоторых распространенных случаях может превзойти хэш-таблицы) поиск, удаление, вставка.Базы данных обычно используют их для индексов над хэшами, что должно дать подсказку об их производительности.(И это возвращает меня к моему первоначальному вопросу: вы уверены, что ваша таблица БД не подходит?)
Если вы используете хеш, даже один с коллизиями будет работать.Что-то вроде SHA256, хотя и является относительно дорогим для вычисления, будет иметь приемлемо низкую частоту столкновений.(Я полагаю, что он настолько низок, что вы, скорее всего, будете поражены молнией. Несколько раз. Люди используют UUID без боязни коллизий, у которых меньше половины битов по сравнению с хешем SHA256.) Стоимость процессора SHA256может не иметь значения, если вы собираетесь получить доступ к диску.
(Также: правильно ли проиндексирована таблица URL-адресов вашей БД для быстрого поиска по этому полю?)