Я должен сохранить большой набор хеша, который в состоянии содержать до приблизительно 200 миллионов 40 битовых значений. При хранении его как 200 миллионов 64 битовых значения были бы приемлемы (несмотря на 200 миллионов * потеря на 16 битов).
Требования:
крошечный объем потребляемой памяти (дисковое пространство не является проблемой, память),
быстро contains(long l)
и add(long l)
методы (намного быстрее, чем SQL)
встроенный
свободный и без противного лицензирования (никакой DB Беркли). Прекрасный LGPL.
никакая положительная ложь и никакое ложное отрицание, таким образом, вещи как находящиеся на диске Фильтры Цветка не то, что я после
SQL не то, что я после здесь.
Поскольку я действительно думаю, что я больше после чего-то быстро как это (уведомление, как решение намного быстрее, чем решение SQL):
Быстро находящиеся на диске хеш-таблицы?
Google имеет такой Java API?
Был бы быстрая находящаяся на диске реализация пары ключ/значение, где я буду только использовать 'ключевую' работу?
Или что-то еще?
Я не переосмыслил бы weel.
Если вы можете позволить себе 128 ГБ диска, вы можете хранить один бит на 40 значение бита. Затем вы можете использовать файл с произвольным доступом, чтобы проверить, установлен ли бит, или изменить его. Вам не нужно будет вставлять какие-либо значения или поддерживать индекс.
Я считаю, что вам нужно будет использовать B-дерево, а не хеш-таблицу. Хеш-таблицы не имеют хорошей локализации для вторичного хранилища, поэтому вы потеряете слишком много времени на дисковый ввод-вывод.
Большинство баз данных - реляционных или нет - реализуют свои индексы в виде B-дерева, поэтому вы говорите об эквиваленте хранения индекса без каких-либо других данных, прикрепленных к нему.
Будет ли у вас несколько процессов, одновременно обновляющих это хранилище данных?