Есть очень большое о очень дорогое Java/Oracle приложение с GUI интерфейсом.
Пользователи могут пользоваться GUI и обрабатывать небольшой набор данных, но есть еще и batch задачи, которые тоже запускаются пользователями. Batch-задачи запускаются в бэкграунде: много потоков забирает данные, процессирует их и обновляет базу.
С ростом данных (каждый год растет на 50%), появляются проблемы: если 2 batch-задачи запускаются одновременно, иногда откатываются транзакции или пользователи не могут сохранить данные (получают экспешин), т.к. база занята (к примеру, обновлением данных).
Все это работает как одно приложение и задеплоино на app-сервер. Стоит задача сделать так чтобы рост данных не провоцировал новые эксепшины и перформанс был небольшой. Все приложение никто переписывать не будет (бюджет), хотя логично было бы вынести batch-задачи в отдельное приложение. Для кэша используем хибернейт. Как лучше реинженирить это приложение чтобы избежать описанных проблем? Спасибо.

Здравствуйте, Аноним, Вы писали:

>Все это работает как одно приложение и задеплоино на app-сервер. Стоит задача сделать так чтобы рост данных не провоцировал новые эксепшины и перформанс был небольшой. Все приложение никто переписывать не будет (бюджет), хотя логично было бы вынести batch-задачи в отдельное приложение. Для кэша используем хибернейт. Как лучше реинженирить это приложение чтобы избежать описанных проблем? Спасибо.

Для начала нужно провести анализ. Очевидно для этого тоже нужно выделить какой-никакой бюджет. Во многих случаях можно обойтись оптимизацией БД с минимальными исправлениями кода приложения. "Во многих" — это если при начальной разработке на архитектуру базы наплевали, или ее лепил тот же Java кодер, что и приложение. В общем, для начала пригласите специалиста по Ораклу для анализа производительности БД.

Если же у вас в базе все грамотно, нужно рассматривать другие варианты, которые обойдутся уже дороже. Например апгрейд железа, которое является узким местом. Часто это дисковая подсистема.

У Оракла есть много фишек для масштабирования, в том числе и не требующих переписывания кода приложения. Правда, большинство из них доступны только в EE, так что может потребоваться апгрейд лицензии. И в большинстве случаев также затраты на железо. Например перенос read-only нагрузки на стендбай-базу.

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

P.S. Что такое "небольшой перформанс" :)

Здравствуйте, wildwind, Вы писали:

Да, еще часто помогает прием "перенести алгоритмы поближе к данным". В вашем случае это переписать batch обработку на PL/SQL, c грамотным использованием доступных там приемов.

Спасибо за совет.

W>Но для начала я бы аккуратно выяснил насколько текущие проблемы на самом деле остры и мешают бизнесу. Если мешают, но не очень, и руководство вообще не готово выделять бюджет на оптимизацию, я бы даже не чесался.

Руководство готово выделять бюджет, т.к. перформанс падает из-за дня в день и мы уже GC настраиваем и делаем маленькие полировки.
Приложение в продакшине и большие изменения мы сразу внести не можем (работаем над другими проектами), поэтому пытаемся постепенно поддерживать обработку роста данных.

Здравствуйте, Аноним, Вы писали:

А>Есть очень большое о очень дорогое Java/Oracle приложение с GUI интерфейсом.
А>Пользователи могут пользоваться GUI и обрабатывать небольшой набор данных, но есть еще и batch задачи, которые тоже запускаются пользователями. Batch-задачи запускаются в бэкграунде: много потоков забирает данные, процессирует их и обновляет базу.
А>С ростом данных (каждый год растет на 50%), появляются проблемы: если 2 batch-задачи запускаются одновременно, иногда откатываются транзакции или пользователи не могут сохранить данные (получают экспешин), т.к. база занята (к примеру, обновлением данных).
А>Все это работает как одно приложение и задеплоино на app-сервер. Стоит задача сделать так чтобы рост данных не провоцировал новые эксепшины и перформанс был небольшой. Все приложение никто переписывать не будет (бюджет), хотя логично было бы вынести batch-задачи в отдельное приложение. Для кэша используем хибернейт. Как лучше реинженирить это приложение чтобы избежать описанных проблем? Спасибо.

Batch процессы стоит вынести в отдельный процесс. В перспективе на отдельную железяку. Тем самым разгрузить пользовательский сервер приложений.
Если батчи грузят БД чтением, то можно настроить репликацию оракла на дублирующий сервер, который использовать для этих самых батч процессов. Читать оттуда. Писать в основную базу.
Это всё требует минимальных затрат.
Батч задачи нужно отдельно проанализировать, чем именно они именно занимаются. Пишут? Читают? Почему так много? Лочат ли что-то? Зачем лочат?
Существует масса способов оптимизаций на уровне БД — денормализация, обновление счетчиков при записи, чтобы не сканировать все эти записи при подсчете статистики. И ещё огромная масса тонких настроек и готовых решений в Oracle.

On 20.09.2013 08:35, Аноним 846 wrote:

> С ростом данных (каждый год растет на 50%), появляются проблемы: если 2
> batch-задачи запускаются одновременно, иногда откатываются транзакции
> или пользователи не могут сохранить данные (получают экспешин), т.к.
> база занята (к примеру, обновлением данных).

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

--
WBR,
Serge.

спасибо, а что такое обновление счетчиков при записи? где про это почитать? как по-английски будет?

Здравствуйте, Аноним, Вы писали:

А>спасибо, а что такое обновление счетчиков при записи?

Если часто выполняется запрос вида

select x, count(x), sum(y), ...
from t
group by x

то можно сохранить его результат в таблицу и брать оттуда; обновлять при изменении данных в исходной таблице t (например в триггере).

Реализовывать это вручную не стоит, в Oracle есть для этого системный механизм — материализованные представления.

Здравствуйте, Аноним, Вы писали:

А>спасибо, а что такое обновление счетчиков при записи? где про это почитать? как по-английски будет?

persistent views