В некоторых предыдущих постах я задавал несколько вопросов о кодировании Custom Hash Map / Table в Java. Теперь, когда я не могу это решить, и, может быть, я забыл правильно упомянуть то, что я действительно хочу, я суммирую все из них, чтобы сделать это ясным и точным.

What I am going to do:

Я пытаюсь написать код для нашего сервера, на котором мне нужно найти тип доступа пользователей по URL.

Теперь у меня есть 1110 миллионов URL (приблизительно).

Итак, что мы сделали,

1) Разделить базу данных на 10 частей, каждая из 110 миллионов URL. 2) Построение HashMap с использованием параллельного массива, ключом которого является одна часть URL-адреса (представленная как LONG), а значениями - другая часть URL-адреса (представленная как INT) -key can have multiple values.

3) Затем ищите в HashMap некоторые другие URL-адреса (миллионы URL-адресов, сохраненных за один день) в день в начале загрузки системы.

What you have Tried:

1) Я перепробовал много баз данных NoSQL, но мы нашли, что они не очень хороши для наших целей.

2) Я построил нашнастраиваемая хэш-карта(используя два параллельных массива) для этой цели.

So, what the issue is:

Когда система запускается, мы должны загрузить нашу хеш-таблицу каждой базы данных и выполнить поиск по миллиону URL:

Теперь проблема в том,

1) Хотя производительность HashTable довольно хорошая, при загрузке HashTable коду требуется больше времени (для его загрузки мы используем файловый канал и буфер с отображением в памяти, для загрузки которого требуется 20 секунд - вход 220 миллионов - при коэффициенте загрузки 0,5,мы нашли это быстрее всего)

Итак, мы тратим время: (HashTable Load + HashTable Search) * Количество БД = (5 + 20) * 10 = 250 секунд. Это довольно дорого для нас, и большую часть времени (200 из 250 секунд) идет на загрузку хеш-таблиц.

Have you think any-other way:

Одним из способов может быть:

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

Поскольку мы обнаружили, что производительность HashTable хороша, но время загрузки велико, мы решили сократить ее другим способом, например:

1) Создайте массив связанных списков размером Integer_MAX (мой собственный список ссылок).

2) Вставьте значения (целые числа) в связанные списки, номер которых является номером ключа (мы уменьшаем размер ключа до INT).

3) Итак, мы должны хранить только связанные списки на дисках.

Теперь проблема в том, что создание такого количества связанных списков занимает много времени, а создание такого большого количества связанных списков не имеет смысла, если данные распределены неправильно.

So, What is your requirements:

Просто мои требования:

1) Ключ с множественными значениями вставки и поиска. Ищете хорошие результаты поиска. 2) Быстрый способ загрузки (специально) в память.

(ключи - это 64-битный INT, а значения - это 32-битный INT, один ключ может иметь максимум 2-3 значения. Мы можем сделать наш ключ также 32-битным, но это даст больше коллизий, но приемлемо для нас, если мы сможем сделать его лучше) ,

Может кто-нибудь помочь мне, как решить этот или любой комментарий, как решить эту проблему?

Благодарю.

NB:

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

2) Мы не обнаружили, что базы данных NoSQL хорошо масштабируются, поскольку наши требования просты (означает просто вставить значение ключа хеш-таблицы и загрузить и выполнить поиск (получить значения)).

3) Поскольку наше приложение является частью небольшого проекта и должно применяться в небольшом кампусе, я не думаю, что кто-нибудь купит мне SSD-диск для этого. Это мое ограничение.

4) Мы также используем Guava / Trove, но они также не могут хранить такой большой объем данных в 16 ГБ (мы используем сервер Ubuntu 32 ГБ.)