Насколько эффективно будет использовать базу данных в памяти для хранения миллионов временных значений?

1

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

Полная история здесь, если вам нужна дополнительная информация.

Одним из решений, которое было предложено, является использование базы данных в памяти.

Итак, если я пойду с этим решением, я буду использовать эту базу данных для хранения моих значений в таблице для замены текущего Map<String, List<Double>>, например:

create table CALCULATION_RESULTS_XXX (
  deal_id varchar2,
  values number
);

(одна таблица за расчет, XXX - это идентификатор вычисления)

Поэтому во время вычисления я сделаю следующее:

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

Как объясняется в другом теме, в настоящее время мой расчет может хранить в памяти несколько сотен Мбайт данных в виде списка из 30 * 1,000,000 из Double потребуется около 240 МБ.

Теперь вопросы:

  • Если я пойду с базой данных в памяти, уменьшится ли моя потеря памяти?
  • Каковы конкретные моменты, которые мне придется позаботиться о использовании базы данных (или создании таблицы), вводе данных и т.д.?
  • Думаю, я выберу базу данных H2. Как вы думаете, это лучший выбор для моих нужд?
Теги:
performance
in-memory-database

4 ответа

0
Лучший ответ

Проблема достаточно проста, что вам действительно нужно просто дать ей понять, как работают результаты (производительности).

У вас уже есть реализация, которая просто использует простые структуры в памяти. Лично, учитывая, что даже самый дешевый компьютер от Dell поставляется с 1 ГБ + ОЗУ, вы также можете придерживаться этого. В стороне, это должно быть довольно просто разбудить в базе данных или два. Я бы подумал, что у Sleepycat Berkerly DB (который теперь принадлежит Oracle...), потому что вам не нужно использовать SQL, и они должны быть достаточно эффективными. (Они поддерживают Java).

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

Поделиться
  • 0
    В прошлую пятницу я проводил тестирование с использованием H2 database но оно не было удовлетворительным в отношении использования памяти и процессора. Поскольку я наконец решил свою первоначальную проблему, не используя сложное решение, я не буду углубляться в дальнейшие исследования.
  • 0
    Действительно, по словам Оккама, «цель больше должно быть сделано несколько.» :)
2

Простой HashMap, поддерживаемый Terracotta, будет лучше и позволит хранить коллекцию больше виртуальной памяти JVM.

Встроенные базы данных, в частности, основанные на SQL, добавят сложности и накладные расходы на ваш код, поэтому это не стоит. Если вам действительно нужно постоянное хранилище со случайным доступом, попробуйте один из nosql DB, например CouchDB, Cassandra, neo4j

Поделиться
  • 4
    Downvoter мог бы сказать, почему ...
  • 0
    Я согласен, downvoter должен сказать, почему. (Только для нескольких миллионов записей (240 МБ на моем настольном компьютере 4 ГБ ...) у меня возникнет искушение сначала попробовать карту, чтобы посмотреть, что произойдет. Ответ Евгения прост в реализации и, таким образом, будет хорошим базовым тестом, если ничего не произойдет. остальное.
Показать ещё 3 комментария
0

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

Поделиться
0

Я не знаю, будет ли это быстрее, поэтому вам придется попробовать. То, что я хочу порекомендовать, - это делать пакетные вставки всего списка, когда вам не нужен этот список. Не сохранять значение по значению:)

Если конечный алгоритм может быть выражен в SQL, это также может стоить того времени, чтобы сделать это, а не загружать все списки обратно. В любом случае не ставьте ничего, как индекс или ограничение на значения, и предпочтительно также не допускать NULL (если возможно). Поддержание индексов и ограничений требует времени, а также позволяет NULL также может стоить времени или создавать накладные расходы. deal_ids могут (и) конечно индексироваться, поскольку они являются первичными ключами.

Это не очень, но, по крайней мере, лучше, чем один проголосовавший ответ:)

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню