Kyudos Ответов: 2

Разработка эффективного хэша


У меня есть набор узлов (N), организованных в одну или несколько сетей. Каждая сеть имеет один или несколько корневых узлов. Каждый узел имеет уникальный идентификатор (UID), представляющий собой 32-разрядное целое число. Если бы было 100 000 узлов, это было бы большой проблемой - 1 000 000 было бы почти невозможно гигантским. Мне нужно проверить, все ли узлы подключены хотя бы к одному корневому узлу, и я пытаюсь разработать хэш-функцию, чтобы помочь мне.

Мой текущий код начинается с каждого корневого узла и отслеживает все пути, записывая каждый подключенный узел. Он делает это без хэширования, так как раньше я мог полагаться на то, что жидкости относительно малы и в основном смежны. Наряду с начальным смещением он просто использует UID непосредственно для индексации в растровый массив. Растровое изображение сравнивается с членами N, чтобы определить, какие узлы не соединены.

Теперь, однако, я сталкиваюсь с ситуациями, когда есть большие пробелы в UIDS (например, скачок от 100 000 до 100 000 000) - это делает простое увеличение размера растрового изображения все более и более непрактичным, следовательно, необходимость в хэше. В общем случае, если пользователь не полностью запутался, я бы ожидал, что количество несвязанных узлов будет меньше, чем количество подключенных (но не обязательно).

Как мне, например, выбрать, сколько ведер я должен использовать для хэширования, чтобы сбалансировать использование памяти с вероятностью столкновений? Может ли это (должно ли это?) быть сделано динамически? (т. е. должен ли я динамически выделять свой массив ведер на основе размера N?) Является ли более эффективным начать с хэширования всех моих uid узлов в ведра, а затем очистить "связанные" хэши по мере их обнаружения? Как я могу определить наилучший способ обработки столкновений? Можно ли динамически создать идеальный хэш?

Что я уже пробовал:

Ничего больше, чем гуглить. Я не специалист по компьютерам, так что это немного ново для меня. Я нахожу массу онлайн - информации немного трудной для переваривания-отсюда и обращение к экспертам.

2 Ответов

Рейтинг:
2

RugbyLeague

поддерживайте список растровых изображений, а не одно большое растровое изображение - с каждым растровым изображением, способным хранить 100 000 бит (т. е. 12 500 байт) - имейте каждое растровое изображение в некоторой структуре (классе и т. д.), которая также записывает идентификатор Первого БИТа в этом растровом изображении - это позволит довольно эффективно создавать разреженные растровые изображения


Рейтинг:
1

Mehdi Gholam

Если вам нужно проверить наличие или отсутствие чего либо в списке и у вас нет достаточного объема памяти или его невозможно сохранить используйте Фильтр Блума - Википедия[^] .

Фильтры Блума дадут вам определенный негатив, если он не закодирован в битах Блума, и вероятный позитив для его существования (вероятность настраивается).

[хэш-функции по определению будут иметь коллизию, и нет никакой "идеальной" хэш-функции, только статистически ровные хэш-функции, т. е. нет сгущения значений]


Kyudos

Спасибо за это. Я заглянул в него, и мне показалось, что это сработало. Но это также довольно сложно. Поэтому я могу просто ударить по своей проблеме медленным, но надежным молотком в тех редких случаях, когда мое растровое изображение не работает.

Mehdi Gholam

То, как работает Bloom, сложно, но использовать его так же просто, как хэш-функцию. попробуй это https://gist.github.com/richardkundl/8300092