Лучшая архитектура для 30-часового запроса

У меня есть интересная проблема для решения. Один из моих клиентов заставил меня разработать программу анализа запасов с почти 50-летними данными запаса почти на тысячу символов. Я разработал серию фильтров, которые применяются в любой день, чтобы узнать, не выпало ли что-либо для торговли.

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

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

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

Есть ли у кого-нибудь общие идеи или опыт работы с веб-архитектурой, которые будут поддерживать ультра-длинные асинхронные процессы?

Спасибо

Ответ 1

В качестве общего предложения я бы рекомендовал отдельное приложение Windows Service, консольное приложение или подобное с очень тщательным управлением временем и протоколированием, которое будет работать постоянно и проверять (опрос) на "задания для обработки" в базе данных, а затем обновлять базу данных с результатами и информацией о ходе работы.

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

Лучше всего поддерживать веб-запросы на минуту или два максимум - они никогда не были предназначены для тяжелых периодов обработки. Таким образом вы можете "проверять" статус работы каждую минуту или около того (используя веб-службу).

Если у вас есть какие-либо вопросы о мне или о идее, напишите комментарий, и я буду рад помочь, уточнить или предложить.

Надеюсь, что это поможет!

(Дополнительно: я считаю, что службы Windows недоиспользуются! Все, что требуется, это быстрый базовый класс или набор методов повторного использования помощника, и у вас есть зарегистрированный, надежный, автоматический, настраиваемый и быстрый процесс реализации под вашим быстро и прототип!)

Ответ 2

Есть ли причина не просто запускать службу в фоновом режиме и архивировать отдельные результаты в таблицу результатов только для чтения по мере их запроса? Вам нужно запустить запрос в реальном времени? Приложение может извлекать страницы результатов по мере их создания службой.

Ответ 3

Похоже, вы делаете SQL-запросы напрямую против этих данных. Рассматривали ли вы загрузку данных, например. SQL Server Analysis Services и настройка куба с (для начала) временем, запасами и символами? В зависимости от характера ваших запросов вы можете получить разумное время отклика. Реляционные базы данных хороши для обработки онлайн-транзакций (в рамках определенных параметров времени загрузки и ответа), но аналитическая работа иногда требует вместо этого методов и технологий хранилищ данных. (Или, возможно, ассоциативные базы данных... есть альтернативы.)

Однако, учитывая Мерфи, у вас, вероятно, будут длительные запросы. Различаются ли данные для разных конечных пользователей? Если нет, почему бы не прекомпилировать ответы? Ничто из http-основанного не должно занимать больше минуты, чтобы обработать, если при этом - по крайней мере, не по дизайну!

Ответ 4

В зависимости от специфики вашего фильтра это похоже на задачу, которая может выиграть от распараллеливания - разделить запрос на несколько вычислительных узлов, которые запускают фильтр по подмножеству (осколку) данных. Если ваш фильтр сосредоточен на анализе одного запаса на протяжении многих временных данных, вы можете разделить работу над символом запаса и одновременно использовать несколько вычислительных узлов, обрабатывающих разные символы запаса. Если вам нужно изучить отношения между символами запаса с течением времени, может быть разумнее разделить работу по временным интервалам и объединить результаты после операции (mapreduce). Это случай, когда бросать больше аппаратных средств в проблему может существенно улучшить время отклика. Рассмотрим пример поисковой системы Google.

Применяются обычные предостережения: сначала просмотрите текущую реализацию фильтра для узких мест производительности. Убедитесь, что таблицы, на которые вы нажимаете, соответствующим образом проиндексированы и т.д. Предварительно расчитайте отношения и дайджесты часто необходимых вычислений заранее. Хранение дешево, если это сэкономит время.

Ваш веб-запрос может начать операцию запроса разброса/сбора, распространяя запрос на доступные вычислительные узлы в облаке (Windows Azure, Google Apps, Amazon). Учитывая достаточные вычислительные узлы и соответствующее распределение работы, вы, вероятно, сможете получить ответ в ближайшем реальном времени.

Ответ 5

Как правило, ультра-длинные асинхронные процессы не идут в Интернете.

Его запрос должен быть поставлен в очередь, а другой процесс должен запускать задание и хранить данные в том формате, в котором пользователь будет использовать его.

Ответ 6

Шесть минут для фильтрации недели данных? Кажется, что ваш db нуждается в правильном индексировании индекса.

Ответ 7

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

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

Ответ 8

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

И предложение использовать "вычислительные узлы" просто завершило мое бинговое бинго, спасибо dthorpe! вам не нужны "вычислительные узлы" только ядра. Большинство РСУБД имеют встроенный PX (параллельное выполнение). Зачем платить за облачные вычисления, которые вы используете каждый день, просто купите сервер с достаточным количеством процессоров, вы будете в порядке... Нет необходимости в запросах "разбросать", просто включите PX...

Понтус указывает вам в правильном направлении. Удовлетворяясь 6-минутной производительностью и заботясь о том, как планировать, это ваша проблема. Существует множество стратегий управления вашими данными в форматах, которые способствуют ускорению. Индексы, разбиение на разделы, кубы, IOT. Вы, возможно, делаете два прохода, а не в сортировках памяти. Ваша статистика может быть устаревшей, вызывая плохой план.

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

Ответ 9

Майк,

Есть много способов ответить на этот вопрос, но более важный вопрос, который я вижу, что вы должны спрашивать, - это то, что для фильтрации акций требуется 6 минут?

Да, я знаю, что у вас 50 лет данных и много акций, НО это не должно занимать 6 минут. Что еще более важно, я бы посмотрел на эту структуру таблицы, индексы там и на запрос и на то, что он делает.

Раньше я работал в аналогичной компании со столами со 100 ГБ каждый. Да, размер таблицы, а не весь db, и после некоторой тонкой настройки получили запросы, которые занимали 15 минут + до 3 секунд.

Я хотел бы помочь вам, особенно если вы работаете на SQL Server. Напишите мне ryk99 [at] hotmail [dot] com, и мы увидим, что мы можем сделать оттуда.

Ответ 10

Считаете ли вы, что использовать ETL-решение, такое как SSIS, для предварительного заполнения ваших данных?