Вы рассчитываете масштабируемые результаты на основе данных транзакций в веб-приложении?

Question

Возможен дубликат:
Разработка базы данных: расчет остатка на счете

Я работаю с веб-приложением, которое хранит данные транзакции (например, «сумма х на дату у», но более сложная) и предоставляет результаты расчетов, основанные на деталях всех соответствующих транзакций [1]. Мы вкладываем много времени в то, чтобы эти вычисления выполнялись эффективно, поскольку они являются интерактивной частью приложения: пользователь нажимает кнопку и ждет, чтобы увидеть результат. Мы уверены, что для текущих уровней данных мы можем оптимизировать выборку и вычисление базы данных, чтобы завершить ее в приемлемое время. Тем не менее, я обеспокоен тем, что по мере роста количества транзакций время будет расти линейно [2]. Я хотел бы сказать, что мы могли бы обрабатывать на порядок больше транзакций без чрезмерного снижения производительности.

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

Однако существуют реальные и существенные ограничения для любого предложения:

• В настоящее время мы должны поддерживать две несовместимые реализации баз данных, MySQL и Oracle. Таким образом, например, использование специфичных для базы данных хранимых процедур примерно вдвое увеличивает стоимость обслуживания.
• Фактические транзакции являются более сложными, чем приведенная в качестве примера транзакция, и бизнес-логика, используемая в вычислениях, сложна и регулярно изменяется. Таким образом, хранение вычислений непосредственно в SQL - это не то, что мы можем легко поддерживать.
• Любая из ранее сохраненных транзакций может быть изменена в любое время (например, дата транзакции может быть перенесена на год вперед или назад), а вычисления, как ожидается, будут обновлены мгновенно. Это имеет дополнительный эффект для стратегий кэширования.
• Пользователи могут выполнять запросы на большом пространстве в нескольких измерениях. Для объяснения рассмотрим возможность вычисления результата в том виде, в каком он будет в любой данный день, для любого конкретного типа транзакции, где транзакции фильтруются по нескольким произвольным условиям. Это затрудняет предварительный расчет результатов, которые пользователь хотел бы видеть.
• Один экземпляр нашего приложения размещен в корпоративной сети клиента, на его оборудовании. Таким образом, мы не можем легко бросить деньги на проблему с точки зрения процессоров и памяти (даже если они на самом деле являются узким местом).

Я понимаю, что это очень открытый и общий, однако ...

Есть ли предложения по созданию масштабируемого решения?

[1] Где «уместно» может быть: запрашиваемая дата; тип транзакции; тип пользователя; выбор формулы; и т.д.
[2] По общему признанию, это улучшение по сравнению с предыдущей производительностью, когда в задачах ORM n + 1 затраченное время возрастало либо в геометрической прогрессии, либо, по крайней мере, в гораздо более крутом градиенте.

Answer 1

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

Суммируйте

Мы создаем резюмена ежедневной, еженедельной и ежемесячной основе.Для нас большинство транзакций происходит в текущий день.Старые транзакции также могут измениться.Мы ведем batch, и при этом отдельные transaction записи.Каждая партия имеет статус, указывающий, можно ли использовать сводку транзакций (в таблице batch_summary).Если старая транзакция в суммированном пакете изменяется, как часть этой транзакции batch помечается, чтобы указать, что сводке нельзя доверять.Фоновое задание позже пересчитает сводку.

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

Мы поигрались с материализованным Oracleпросмотров, но в итоге мы развернули наш собственный сводный процесс.

Ограничение требований

Ваши требования звучат очень широко.Может возникнуть соблазн разместить все поля запроса на веб-странице и позволить пользователям выбирать любую комбинацию полей и выводить результаты.Это делает его очень сложным для оптимизации.Я бы посоветовал углубиться в то, что им на самом деле нужно делать или делалось в прошлом.Возможно, не имеет смысла запрашивать очень неселективные измерения.

В нашем приложении для определенных запросов ограничивается диапазон дат не более 1 месяца.Мы согласовали некоторые особенности с основанными на дате аннотациями.Например, вы можете получить результаты за весь январь 2011 года, но не за 5-20 января 2011 года.

Предоставить обратную связь с пользовательским интерфейсом для медленных операций

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

Answer 2

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

Сложная часть, конечно, обновляет материализованное представление, когда таблицы основаны на изменениях.Здесь есть хорошая статья об этом: Обновление материализованного представления при изменении таблиц-указателей .

Материализованные представления (пока) недоступны без плагинов в MySQL и ужасно сложны для реализации в противном случае.Однако, поскольку у вас Oracle, я бы посоветовал проверить ссылку выше , чтобы узнать, как добавить материализованное представление в Oracle.