Рекомендуемая низкая память hashmap для реализации для Java

Я в настоящее время работаю над связанной проблемой программирования, где я предпринят для создания крупного hashmap данных. Ключ для данных является пользовательской реализацией низкой памяти CharSequence, который реализует хэш-код () и равняется (...), и значение, Целочисленный объект.

Могут быть миллионы записей в этой хеш-таблице, и мне удалось решительно уменьшить использование памяти для значения при наличии Целого числа быть указателем в файле к данным, которые я хочу хешировать, но thbe проблема состоит в том, что ключ может быть десятками байтов (в среднем 25 байтов) и что клавиши должны быть удержаны в памяти в реализации по умолчанию HashMap.

Мне нужен hashmap, который имеет низкую память наверху, и это может возможно разбить на страницы ключи к диску или альтернативно сохранить хешированное представление ключей. Если бы ключи самостоятельно хешируются затем, я был бы обеспокоен хэш-коллизиями.

Идеально, я хотел бы смочь сохранить миллион записей в карте на 50 МБ пространства "кучи" (один массив байтов 25 байтов в ключевом и Целочисленном объекте в части значения).

У кого-либо есть опыт с низкой памятью поддержанными файловой системой Картами, которые оптимизированы для сокращения места ключей?

Спасибо,

Chris

8
задан Chris 5 March 2010 в 06:30
поделиться

3 ответа

Вы можете использовать хэш-карту Java и написать класс FileKey, который принимает RandomAccessFile, смещение и длину, предварительно вычисляет хэш при построении и реализует Comparable, считывая данные из файла только для сравнения.

В сочетании с простым кэшем MRU вы можете хранить некоторое количество ключей в памяти, используя другую хэш-карту, которая построена на тех же ключах, но использует пользовательский компаратор, который сравнивает только значения смещения и длины (не данные файла).

3
ответ дан 5 December 2019 в 22:17
поделиться

Я думаю, что стандартный HashSet - это неплохой способ - создавать пару ключ-значение самостоятельно (чтобы не оборачивать их в дополнительный объект). Этот способ довольно экономичен по памяти; он действительно требует только около (1/loadFactor)^(3/2)*4 байта дополнительной памяти поверх объекта ключа + 4 байта для значения. На практике это добавляет около 8 байт накладных расходов на каждую запись. (Вы можете уменьшить это еще больше, если вы заранее знаете, сколько ключей вы собираетесь хранить)

.
1
ответ дан 5 December 2019 в 22:17
поделиться

Как насчет Berkeley DB Java Edition ? Его класс StoredMap выглядит как то, что вы ищете.

2
ответ дан 5 December 2019 в 22:17
поделиться
Другие вопросы по тегам:

Похожие вопросы: