Как я могу заставить сотни одновременно работающих процессов взаимодействовать с базой данных через один или несколько постоянных сеансов?

Question

Короткая речь: Как заставить сотни одновременно запущенных процессов взаимодействовать с базой данных через один или несколько постоянных сеансов?

Вся история:
Однажды я создал механизм обработки чисел, который обрабатывает огромное количество больших файлов данных, отбрасывая одного ребенка за другим, давая каждому небольшое количество файлов для работы. Блокировка файлов, мониторинг прогресса и распространение результатов происходят в базе данных Oracle, к которой все (под) процессы обращаются в разное время, используя специальный модуль приложения, который инкапсулирует DBI.

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

Я думал об организации очереди сообщений, но не смог придумать способ соединения большого стада запрашивающих с одним или несколькими соединителями базы данных таким образом, чтобы была возможна двунаправленная связь (для сбора результата запроса).
Асинхронный подход может помочь здесь в том, что все запросы записываются в одну и ту же очередь, а соединитель базы данных, обслуживающий запрос, будет «перезванивать» для отправки результата. Но мой разум не позволяет мне генерировать достаточно четкое изображение, чтобы я мог рисовать в коде.
Потоки вместо разветвления могли бы дать мне более легкое начало, но теперь это потребовало бы значительных изменений в кодовой базе, которые я не готов сделать с живой системой.

Чем больше я об этом думаю, тем больше базовая идея выглядит для меня как предварительно разветвленный веб-сервер только в том, что он обслуживает не веб-страницы, а запросы к базе данных. Любые идеи о том, что копать, и где? Образец (псевдо) кода, чтобы вдохновить меня, ссылки на возможные связанные статьи, готовые решения по CPAN, может быть?

Answer 1

Я думаю, вы должны подумать о добавлении уровня. Я думаю, POE может справиться со средним уровнем.

Answer 2

Возможно, вы захотите поговорить со своим администратором базы данных о «Shared Server», который довольно легко реализовать в Oracle> = 10. Вы можете думать об этом как о пуле соединений на стороне сервера. Поэтому, когда вы запрашиваете соединение, вы не обязательно создаете новый процесс выделенного сервера и уничтожаете его при подключении.

Вы также можете создавать пулы соединений на своей стороне.

Answer 3

Посмотрите на DBD :: Gofer . Он разработан как отдельный процесс для объединения и управления соединениями с базой данных.

Answer 4

В данном сценарии лучше всего использовать очередь сообщений:

• Для блокировки рабочего блока: поставить в очередь запрос на блокировку / разблокировку синглтона. Если блокировка не может быть получена, перепланируйте рабочий блок на более позднее время.
• Для мониторинга прогресса: поместите все обновления прогресса в очередь для обработки каким-либо регистратором / программой обновления состояния и т. Д.
• Для отправки результатов поместите наборы результатов в очередь для вставки специальными авторами результатов. Записи в очереди могут стать очень большими, но любая порядочная очередь сообщений должна справиться с этим. В крайнем случае мы могли бы прокси-сервер полезной нагрузки в файлы и ставить в очередь только имена и местоположения файлов.
• Данные конфигурации могут быть прочитаны из базы данных при запуске до того, как рабочие процессы разветвлены, поэтому они наследуют полную конфигурацию во время разветвления и не нуждаются в собственном соединении с базой данных.

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

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

Answer 5

Вы могли бы взглянуть на SQLRELAY, который имеет некоторые другие преимущества, а также на стороне прокси.

http://sqlrelay.sourceforge.net/sqlrelay/