← →Котик Б
(2011-09-01 22:06)
[78]
> Kerk © (31.08.11 11:40) [68]
> Для MD5 такой битовый массив займет 9.94832639 × 10^23 байт.
Какой ты умный.
> palva © (31.08.11 07:51) [64]
> да еще озаботиться тем, чтобы файл с этими битами нефрагментированно на диске лежал.
Я о файле ничего не писал.
При неоходимости можно даже простенький дисковый драйвер написать и выделить отдельный раздел.
> DVM © (31.08.11 18:30) [70]
> Я боюсь представлять размер такого массива для SHA1.
Попросите гражданина двумя постами выше, он посчитает.
> DVM © (31.08.11 18:30) [70]
> Учитывая что количество вариантов хэша SHA-1 огромно, то будем считать, что вариантов у нас очень много, "бесконечно" много. Нет тут противоречий.
Вы бы потрудились сначала верно сформулировать задачу со всеми дополнительными условиями.
В условии отсутствуют два очень важных параметра: ресурсы и скорость.
1. Какими аппартными/програмными ресурсами располагаем для решения задачи ?
Вдруг окажеться что эту задачу нужно решать в реалтайме на обычной офисной машинке.
Или же у вас в наличии вот такое http://habrahabr.ru/blogs/hi/127189/
2. Какое количество запросов в секунду должно быть обработано ?
Это пара запросов в сутки или же несколько тысяч в секунду.
Могут по дате, собственно дата одно из значений, которое участвует в формировании хэша. Но очень часто встречаются сообщения с датой совпадающей вплоть до миллисекунд, это и есть дубли.
Судя про этой фразе скорость возможна вплоть до 1000 запросов в секунду.
Даже если скорость будет всего 100 зап/сек. Давайте прикинем обьем операций.
100 за секунду
6000 за минуту
360 тыс. за час
8.64 млн. записей за сутки
Сколько за год пускай посчитает вышеупомянутый умный гражданин.
А теперь на этом объеме прогоните ваш любимый SQLite.
При предложенных в этой теме способах реализации накладные расходы на содержание структуры/индексов очень быстро перерастут в размерах само содержание таблицы хешей.
Посоветуйте как лучше сделать Найти похожие ветки
← →