Является ли хорошей идеей построение индексов в памяти и обход БД при интенсивной работе на небольшом подмножестве?

Question

Я работаю над программой для автоматического поиска оптимальных назначений смены с учетом множества ограничений. Я использую grails , т.е. данные о работниках, сменах и назначениях будут храниться в СУБД.

Для самой оптимизации мне придется очень интенсивно работать с небольшим подмножеством данных (всего около 600 строк из примерно 5 разных таблиц). Мне придется перебирать и искать в различных подмножествах десятки раз, чтобы вычислить пригодные функции, изменить некоторые значения, снова вычислить пригодность, вспенить, промыть, повторить, возможно, сотни раз.

Теперь, хотя поиск и итерация - это именно то, для чего нужна СУБД, я считаю, что в этом случае издержки сотен запросов к БД могут затмить реальную работу, даже для СУБД в памяти, такой как HSQLDB. Таким образом, вместо этого я планирую вначале поместить все подмножество в память, построить свои собственные индексы (в основном HashMap) для поиска, который мне придется делать, и затем работать только с теми, которые остаются в стороне от БД до Я закончил и записал в него свой результат.

Это разумный подход? Есть идеи получше?

Answer 1

Я предполагаю, что вы должны выполнить сотни команд для базы данных? Нет способа выполнить код внутри БД?

Главное, о чем я буду беспокоиться, это честность; убедитесь, что вы правильно обрабатываете блокировку. Возможно, вы захотите, чтобы номер версии был где-то сохранен, поэтому вам не нужно блокировать весь набор данных на время обработки. В транзакции обновления вы сначала должны убедиться, что номер версии совпадает с тем, когда вы начали читать.

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